はじめに 2000年代の開発現場では、UML という語は一種の共通語でした。オブジェクト指向を語るならUMLを知っていて当然だとされ、書籍も研修もツールも、その前提で組まれていました。しかし現在、日常会話の中で「UMLを描こう」と言う場面は激減し、代わりにMermaid(軽量な図記述ツール)やPlantUML(テキスト記述からUML図を生成するツール)で必要な図だけを書くという言い方が普通になっています。この落差は、単なる流行語の交代ではありません。設計の正本をどこに置くのかという、開発の重心そのものが移った結果です。 本稿はラショナル起源の重いUML と、ファウラーが後から整理した 軽いUML と、2010年代以降の 高速な開発環境 が、どのようにぶつかったのかということを語ります。結論を先取りすれば、消えたのは図そのものではなく、UMLという名称に付着していた制度と商売でした。そして残

はじめに ウォーターフォール開発がなぜおかしくなりやすいのかを説明するうえで、弁護士が通常は請負契約で仕事をしないという事実は、非常に強い比較材料になります。なぜなら、両者はともに、依頼者が自分では十分に理解できない対象について、専門家に助けを求める知的専門業務だからです。それなのに片方は委任で運用され、もう片方は長年請負で大量流通してきたからです。 もちろん、厳密には「ウォーターフォール=必ず請負」「アジャイル=必ず準委任」と言い切るのは雑です。経済産業省のモデル契約でも、フェーズごとに請負と準委任を選択するとされており、要件定義のような不確実性の高い段階は準委任に寄り、成果物が具体的に特定できる段階は請負に寄ると整理されています。同じ留保は弁護士側にも必要で、契約書作成のように成果物が明確な業務では定額受任もあり得ますし、日本の着手金+報酬金という慣行は純粋な準委任とも少し違います。し

はじめに アジャイルという言葉は広く普及していますが、その本質を正確に理解している人は多くありません。表面的には「変化に強い開発手法」「小さく作って早く回す」という説明が一般的ですが、実際のアジャイルははるかに本質的で、人間の認知能力と組織構造に強く依存した哲学的な方式です。本レポートでは、アジャイルの本質を掘り下げ、なぜ特定の条件を満たすチームでのみ成立するのかを論理的に整理します。そのうえで、アジャイルが成功するために必要な“人の条件”と組織の前提について考察します。 アジャイルとは「真実 × 目的 × 推論」が揃う方式である アジャイルが他の開発方式と決定的に異なるのは、根幹に「真実を操作しない」という前提が置かれている点です。嘘や政治的配慮を最小化し、現実をありのまま扱います。これにより、チーム内の各メンバーが事実を基点として矛盾なく行動できます。しかし、事実の共有だけでは組織は前