Software Engineering
良いソフトウェアを、つくり続けるための工学 The engineering of building and keeping good software
ソフトウェア工学（Software Engineering）は、ソフトウェアを「正しく・効率よく・長く使えるように」設計し、作り、保守するための体系的な方法論を扱う学問分野です。個人の技巧としてのプログラミングを、チームで大規模かつ長期に成り立たせるための工学へと広げたもの、と言えます。 Software engineering is the discipline of designing, building, and maintaining software in a systematic way, so that it is correct, efficient, and durable over time. It extends programming from an individual craft into an engineering practice that holds up across teams, scale, and years.
「ソフトウェア工学」という言葉は、1968年のNATO会議で、増大するソフトウェア開発の困難（いわゆる「ソフトウェア危機」）に工学的な規律で立ち向かおうという問題意識から広まりました。IEEEはこの分野を、ソフトウェアの開発・運用・保守に対する「体系的で、規律ある、定量的なアプローチの適用」と定義しています。単に動くコードを書くことではなく、限られた時間と人手のなかで、変更に耐え、信頼できるソフトウェアを継続的に届けることが目標です。 The term "software engineering" gained currency at a 1968 NATO conference, framed as a response to the growing difficulty of building software (the so-called "software crisis"). The IEEE defines the field as the application of a systematic, disciplined, and quantifiable approach to the development, operation, and maintenance of software. The goal is not merely writing code that runs, but delivering reliable software that withstands change, under real limits of time and people.
プログラミングとの違いNot the same as programming
プログラミングは「どう書くか」。ソフトウェア工学はさらに、要求の把握、設計、品質保証、チームでの協調、そして長期の保守までを対象にします。Programming is about how to write code. Software engineering adds understanding requirements, design, quality assurance, coordinating teams, and long-term maintenance.
なぜ「工学」なのかWhy "engineering"
大規模・長寿命・多人数という条件では、思いつきではなく、計測と根拠に基づく判断が要ります。工学的な規律が、コストと品質を扱える形にします。At large scale, over long lifespans, with many people, decisions need measurement and evidence rather than intuition. Engineering discipline makes cost and quality tractable.
なぜ重要かWhy it matters
ソフトウェアは「作って終わり」ではないSoftware is never finished when it ships
現代のソフトウェアは、長く使われ、何度も変更され、多くの人の手を渡ります。実際、ソフトウェアにかかる費用の多くは、最初の開発ではなくその後の保守と進化に費やされます。変更のたびに品質を保ち、その場しのぎの実装が積み上げる「技術的負債」を管理できるかどうかが、長期のコストを大きく左右します。ソフトウェア工学は、この「作り続ける」プロセスを支えるための知見を積み上げてきました。 Modern software is used for years, changed repeatedly, and passed between many hands. In fact, much of the total cost of software goes not to the first build but to maintenance and evolution afterward. Whether a team can preserve quality across changes, and manage the "technical debt" that expedient shortcuts pile up, largely decides long-term cost. Software engineering has accumulated the knowledge that supports this ongoing process of keeping software alive.
開発の流れ（ライフサイクル）The software lifecycle
要求Requirements
何を作るべきかを、利用者や現場から引き出し・整理する。Elicit and organize what should be built, from users and context.
設計Design
変更に耐える構造とアーキテクチャを決める。Decide the structure and architecture that will absorb change.
実装Implementation
設計をコードにする。読みやすさと規約も品質のうち。Turn design into code. Readability and standards are part of quality.
テスト・検証Testing
欠陥を見つけ、期待どおり動くことを確かめる。Find defects and confirm the software behaves as intended.
保守・進化Maintenance
修正・改善を重ねる。最も長く、費用のかさむ段階。Fix and improve over time. The longest and costliest stage.
この分野の研究Research in the field
一般的に、どんな研究があるのかWhat is commonly studied
ソフトウェア工学の研究は、開発のどの段階にも広がっています。近年は、GitHubなどに蓄積された膨大な開発データを分析して現実の開発を明らかにする経験的（実証的）研究が大きな潮流です。代表的な領域を挙げます。 Research spans every stage of development. A major current is empirical research that analyzes the vast development data accumulated on platforms like GitHub to understand how software is really built. Some representative areas follow.
要求工学Requirements EngineeringRequirements Engineering
曖昧な要望を、実装できる仕様へと引き出し・分析・合意する方法。Methods to elicit, analyze, and agree on implementable specifications from vague needs.
設計・アーキテクチャDesign & ArchitectureDesign & Architecture
変更に強く、理解しやすい構造の設計。設計の劣化や依存の管理も含む。Designing structures that resist change and stay understandable, including managing design decay and dependencies.
プログラム解析・自動修正Program Analysis & RepairProgram Analysis & Repair
コードを静的・動的に解析し、欠陥の検出やパッチの自動生成（APR）を行う。Analyzing code statically and dynamically to detect defects and generate patches automatically (APR).
テスト・検証Testing & VerificationTesting & Verification
テストの自動生成、欠陥予測、形式手法による正しさの保証。Automated test generation, defect prediction, and formal methods for guaranteeing correctness.
保守・進化Maintenance & EvolutionMaintenance & Evolution
既存コードの変更容易性、リファクタリング、技術的負債の検出と管理。Changeability of existing code, refactoring, and detecting and managing technical debt.
経験的SE・リポジトリマイニングEmpirical SE & MSREmpirical SE & MSR
課題管理システムやコミット履歴などの開発データを分析し、現実を実証的に解明する。Mining issue trackers, commit histories, and other data to explain development empirically.
開発者と協調・OSSHuman & Collaborative AspectsHuman & Collaborative Aspects
チーム開発、コードレビュー、オープンソースコミュニティなど、人と協働の側面。Team development, code review, and open-source communities: the human side of building software.
AIとソフトウェア工学AI & Software EngineeringAI & Software Engineering
大規模言語モデルによる開発支援や、AIを含むシステムの品質保証という新しい潮流。A newer current: using large language models to assist development, and assuring the quality of AI-based systems.
木村の研究との関係Where my research sits
「保守・進化」と「経験的SE」の交差点でAt the crossing of maintenance and empirical SE
私（木村祐太）の研究は、上の領域のうち保守・進化と経験的SE・リポジトリマイニングにまたがります。開発者が実際に「技術的負債」と認識した箇所を、開発データから検出・分類・特徴づけることをテーマにしてきました。分野の全体像のなかで、各研究がどこに位置するのかを見ていただけます。 My work (Yuta Kimura) spans maintenance and evolution and empirical SE and repository mining among the areas above. I study how to detect, classify, and characterize the code that developers themselves recognize as technical debt, using development data. Against this map of the field, you can see where each of my studies sits.
- 技術的負債の検出・特徴づけ（保守・進化 × 経験的SE）Detecting and characterizing technical debt (maintenance × empirical SE)
- 返済とリファクタリング、自動生成パッチの品質、課題票の分類などRepayment and refactoring, quality of auto-generated patches, issue classification, and more