worldあるかどうかわからないけど、あるみたい。要点1986年にソフトウェアエンジニアリングについて書かれたフレデリック・P・ブルックス氏(以下、Brooks)『人月の神話』「銀の弾はない」はすごい(久しぶりに読み返した)。本質的な困難と、その攻略を通じて、アジャイル開発を理解するとスッキリする(個人的な見解です)。はじめにアジャイル開発は、ソフトウェアエンジニアリングにおいて迅速かつ適応的にソフトウェア開発を行う軽量な開発手法群の総称である。アジャイル開発の「なぜなのか(WHY)」や「どのような問題を解こうとしているのか」を、自分なりに整理したかった。その時、Brooks『人月の神話』を改めて読んで、びっくりした。2018年10月9日に書いたメモがある。整理や考える余地はあるけれど、少し読めるようにして、とりあえず公開してみる。アジャイルは、どんな問題を解いているのか2001年に「アジャイル」と名付けられたソフトウェア開発手法のアジャイルソフトウェア開発宣言(以下、マニフェスト、もしくはアジャイルマニフェスト)が公開されている。よい開発方法を見つけだそうとしている。この活動を通して、私たちは以下の価値に至った。認めながらも、私たちは右記のことがらにより価値をおく。マニフェストは、どのような問題を解いているのであろうか。右側のことがらに価値がおくのだろうか。その結果、導かれるアジャイルのマインドセットやプラクティスの解釈や評価基準はなんであろうか。Brooksによって発表された、今(2018年)から30年以上も前だ。この論文は、広く知られていて、ソフトウェアエンジニアリングにとって大切な古典である。狼人間は慣れ親しんでいるものを不意に恐怖に変えてしまうからだ。私たちはこの狼人間を魔法のように鎮めることができる銀の弾を探し求める。ソフトウェアエンジニアリングにおいても問題を簡単に解決できる方法やツール「銀の弾」が話題になる。そのような解決策は、継続的な効果がなく消えていくことが多い。本質的な問題を理解し、根気強く持続的に取り組むしかない。困難の種類ソフトウェアテクノロジーにおける難しさを本質的なものと偶有的なものにわけた。「難しさの本質とはソフトウェアの性質に固有な困難のことであり、偶有的難しさとは、実現するとき派生するが本来備わっているものではない困難のことである。ソフトウェアは、組み合わさったコンセプトで構成されている。その同じ概念構造体が多くの異なる表現で表されるという点で抽象的である。それにもかかわらず、非常に正確で十分に詳細なものである。実現するとき派生する本来備わっているものではない困難ソフトウェア構築において困難な部分は、概念構造体の仕様作成とデザインおよびテストにあって、表現することやその表現に忠実かをテストすることではないと考えている。本質的に銀の弾という特効薬がない。「ソフトウェアは妄想の産物である(大槻氏)」にあるように、概念構造体とその操作が難しいことが本質的な困難であるといえよう。本質的な困難は、このような4つの性質があるとされている。規模の拡大は、異なる要素の数が増える。場合、その要素は互いに非線形で影響し合う。全体としての複雑性の増加は線形どころではない。本質的な複雑性と、その複雑性が非線形に増大することに由来。数学や物理学は、複雑な現象を単純化したモデルを構成...この方法でうまくいったのは、モデルで無視された複雑性が現象の本旨的な性質ではなかったからだ。複雑性が本質の場合は、この方法は使えない。純粋な思考の産物であってきわめて融通性に飛んでいる。それらは絶えず変化し続ける。ソフトウェア実体は本質的に空間に埋め込めない。ソフトウェアの構造は、一つではなく複数の一般的な有向グラフで構成され、それらが互いに重なり合っている。(不可視性についての「複数の一般的な有向グラフで構成され、互いに重なり合っている」だけで、深く味わえる。ソフトウェアエンジニアで使われるUMLやモデル、さらには数学の圏論も有向グラフで構成されている。)なお、同調性は、仕様書や要求への順応ではなく、人間の慣習や社会制度である人間の慣習や社会制度である。この表現は、顧客にとっての価値と解釈することに違和感を感じない。偉大なデザイナーが紹介されている。そのソフトウェアシステムも漸増的開発によって育成されるべき。複雑な実体を育成できることがわかった両方ともに、アジャイル開発のコンセプトと本質的に同一であろう。世界観(マインドセットや文化)の違い世界観や価値観が異なっていることから、アプローチの違いが生み出される。マインドセットや文化と呼ばれることもある。私の解釈で哲学や思想を背景にこれらを雑に分類してみる(これらの世界観の比較は、たくさんの引用文献と相当に長いリストになり、かつ、それぞれの丁寧にマッピングする必要がある。ここでは大胆に捨象している)。今までは、全体を認識できると前提を置いていたため、その全体を分離することによって局所化していたが、全体が説明できないことがわかったため、その主観的な関心に対して、相互にコミュニケーションを行いながら探索する世界観へ移行している。銀の弾になるためのアジャイル開発Brooksの『銀の弾はない』『人月の神話』は、1986年に公開されている。本人を含むさまざまな人が、さまざまなタイミングでレビューしている。デザイナー」といい、アジャイルと深く関連する攻略だ。2001年にアジャイルマニフェストを作ったメンバー全員は、間違いなく読んでいるはずだ。と私は思った(時間と興味があったら後で調べる)。ウォーターフォール開発とアジャイル開発の主たるアプローチこのメモでは、システム開発標準のV字型モデルのような、要件定義書や仕様書をあらかじめ完全にモレなく書くことを目指すスタイルをウォーターフォール開発と書いている。ウォーターフォール開発に近いアジャイル開発もあるし、ウォーターフォール開発でもアジャイルのスタイルを取り入れていることも多いため、厳密な分離は難しい。そのため「いわゆる」と雑な分類になっている。いわゆるウォーターフォール開発とアジャイル開発の主たるアプローチを比べてみよう。双方向のやりとり(主体的・対話的で深い学び)つまり、アジャイルマニフェストにおいて「変化への対応」は、同調性や可変性への対応への主張ともとらえられる。いわゆるウォーターフォール開発でもうまくいくためにやっていることも評価できるだろう。「なぜなのか」の解釈を加えたアジャイルマニフェスト本質的な困難を通じて、アジャイルマニフェストに追加してみた。元になっている文章は、イタリック(斜体)で表記している:ソフトウェアエンジニアリングが持つ本質的な困難を攻略するため、よりよい開発方法を見つけだそうとしている。重なり合っている複数の一般的な有向グラフで構成された概念構造体は、空間に埋め込めず見ることはできないため、プロセスやツールよりも個人と対話に価値を置く。インターフェースを人間の慣習や社会制度との順応(顧客から見た品質)を調べるため、包括的なドキュメントよりも動くソフトウェアに価値を置く。本質的に複雑なソフトウェアに対して、相互のコミュニケーションを通じて攻略するため、契約交渉よりも顧客との協調に価値を置く。はめ込められているため、計画に従うことよりも変化への対応に価値を置く。私たちは以下の原則に従う:人間の慣習や社会制度に順応する同調性を向上させるため、顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。組み込まれている文化的マトリックスは固定ではない(可変性がある)ため、要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。リリースして同調性を確認しつつ可変性を確保するため、動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。組み合わさった概念構造体の不可視性を攻略するため、コミュニケーションを密にします。ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。健康的で効果的なコミュニケーションを用いるので、意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。組み合わさった概念構造体によって生み出される複雑性を、ノンバーバル(非言語)を含めたコミュニケーションによって攻略するため、情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。リリースしたソフトウェアと社会との同調性を計測するため、動くソフトウェアこそが進捗の最も重要な尺度です。本質的な困難を回避する特効薬(銀の弾)などなく、反復しながら育成する必要があるため、アジャイル・プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。本質的な困難を攻略するための土台を作り、価値を担保するため、技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。複雑性を攻略するための心がけとして、シンプルさ(ムダなく作れる量を最大限にすること)が本質です。組み合わさったコンセプトで構成される概念構造体を重ね合わせ、統合していくプロセスが含まれる(複雑性を用いた同調性の獲得)ため、最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。同調性を生み出す可変性を調整するため、チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。して、とても良くできている。本質的な困難の攻略を支援する道具たちコミュニケーションを支援する環境・技術(例)双方向のコミュニケーションを実現するために、このようなことが言われている(例)。組織構造による支援(ティール組織やホラクラシー組織)アジャイル開発のプラクティスが支援する仕組み(例)アジャイル開発のプラクティスは、本質的な困難をどのように攻略しようとしているのか、の観点を加えると使いどころがより明確になるのではないだろうか。スプリント計画・スプリントレビューコミュニケーションによって価値の探求と探索を実現するものとして有効に活用する。外に真実があるのではなく、コミュニケーションの中で価値がわかる。それを実現するため「オーナー」は、システムの中に入って主体性の獲得を目的とする有効なプラクティス名である。領域を分割しているわけではないため、それぞれの行動について、その都度の領域を決める必要がある。アジャイル開発(プラクティスのセット)は、うまく行くための支援するノウハウが詰まっているため、有効に使おう。アジャイル開発をやることを目的にしてしまうと、本末転倒になりがちである。アジャイルである(be-agile)ようにしよう。おわりに本質的な困難へのアプローチ、という観点でアジャイルマニフェストとその原則やプラクティスを整理すると、アジャイル開発の「なぜなのか(WHY)」や目的がすっきり理解できた。アジャイル開発も含むソフトウェアエンジニアリングは、たくさんの経験や知見を通じて進化している。そのため、1986年の『銀の弾はない』の議論で止まることがいいわけではない。さまざまな知見や経験を通じて、さらなる進化が大切である。病気治療の第一ステップは、悪霊信仰を細菌説によって生理学的理論に置き換えることだった。このステップこそ希望の始まりであり、すべての魔法のような解決策の夢を打ち砕いた。医療従事者は、進歩は段階を追いながら多大な努力を払って遂げるもので、健康回復には持続的で根気強い介護がなされなければならないと教え込まれた。今日のソフトウェアエンジニアリングにおいても、それは変わらない。アジャイルは銀の弾である、少なくともポテンシャルはある、と言えるかもしれない。特効薬や弾ではなく、じっくり効果を発揮していくのでやっぱり銀の弾ではない、とも言えるかもしれない。今日のところはここまで。おいしいものを食べようよ。ピアソン・エデュケーション、2002年。978-4-89471-665-0本記事における引用は、20周年記念増訂版を用いている。追記・コメントなど2018/11/04「銀の弾はない」は、1975年との記載は誤りで、1986年が適切です。お詫びして訂正いたします(本文中は訂正しました)。ご指摘ありがとうございました。»Profileid:masanariあるかどうかわからないけど、あるみたい。