勘と経験と読経 (original) (raw)
20年前の2004年ごろ「要求は開発するものである」という言説がソフトウェア開発の世界にあった。ちょっと思うことがあって、このテーゼについて勝手に振り返ってみたり考えたという話。
なお、この話は情報システム開発の、現在の文脈でいうならSoRに関するものである。SoEとかWeb開発、プロダクト開発の分野は関係ない話だと思っていただきたい。
「要求は開発するものである」というテーゼは要求開発アライアンスというコミュニティ（勉強会）で提言されていたもの。本家のサイトは停止してしまっているのだが資料はクリエイティブ・コモンズで公開されていたのでこちらの記事で紹介している。具体的にどのような記述だったのかを確認する際には参考にしていただきたい。
「要求は開発されるものである」とはどういうことか？
情報システムに対する要求は、あらかじめ存在しているものではなく、ビジネス価値にもとづいて「開発」されるべきものである。
これはストレートにいえば「ベンダーやコンサルに要件定義を丸投げするな」ということだ。この宣言が表明されたゼロ年代前半のIT業界では、プロジェクトマネジメントが注目されており、情報システムの構築に失敗するということは減ってきた時期であった（それ以前の時代では、システムがよく完成しなかった）。システムは一応完成するようになり、次はビジネス貢献度に注目が移ってきた。単に業務を電子化するだけのシステム化（今風に言えばデジタイゼーション）やユーザーの課題や要望を御用聞きスタイルで取り組むだけではダメで、ユーザーと開発者が「あーだこーだ」議論しながら要求そのものを作り出していくべきである、というのがこの宣言の趣旨だった。要件定義を単なる文書化プロセスではなく、利害関係者による創作プロセスであると捉えるべきなのだ。
当時見聞きした要件定義の失敗はこういったものがあった
- 経営の求める抜本的な業務改善がほとんど落とし込まれていない
- ビジネスの将来像を考えずに業務最適化した結果、新規ビジネスの足かせになった
- 部署ごとの要望を全部取り込んで、とても複雑で高価なシステムになった
- 現行システムの機能と帳票は全部移植した
- あらゆるイレギュラーケースに対応できるようにしたら構築費用が大きく増大した
- 思いつきの要望により作った機能が実際にはまったく使用されない
- 声の大きなパワーユーザーの言う通りにした結果、一般ユーザーには使えないシステムになった
こういったものを防止するために要求開発は宣言され、いろいろな議論が20年前から行われてきた。だが、しかし
あれ？ これ、いまでも起こっていない？
「要求は開発されているか？」
残念ながら、2024年の現代においても（企業情報システム開発の世界においては）「要求は定義するもの」という状況は変わっていない。
経産省で2018年に公開された「DXレポート」では以下のような問題提起がされている。
我が国においては、要件定義から請負契約を締結するケースも少なくない。これは、何を開発するかをベンダー企業に決めてくれと言っていることと同じである。ベンダー企業もそのまま要望を受け入れてしまっている。
このような状態のままでは、アジャイル開発のようにユーザ企業のコミットメントを強く求める開発方法を推進しようとしても無理がある。要件の詳細はベンダー企業と組んで一緒に作っていくとしても、要件を確定するのはユーザ企業であるべきことを認識する必要がある。
- DXレポート ～ITシステム「2025年の崖」克服とDXの本格的な展開～（METI/経済産業省） 簡易版、2.４ ユーザ企業とベンダー企業との関係より
そして現在も主要な要求関連ガイドの多くは「要件定義」パラダイムのままなのである。つまり、要求は開発されていない！
「なぜ要求は開発されてこなかったのか？」
ここからは私論である。要求開発は（現在でも筆者は良いものだと思っているのだが）なぜ流行らなかったのだろうか。その理由について考えてみたい。
ターゲットを外していた説
要求開発宣言を丁寧に読めば理解できるのだが、この方法論は現代で言えば「SoR」のみを対象にした議論だった。しかし当時はSoE/SoRといった名称も発明されておらずソフトウェア開発全般の議論として捉えられていた印象がある。また時代的にはクラウドコンピューティングとアジャイル開発の発展時期であり、SoEの領域においては大きく開発方法論が変化していく時代でもあった。うまく適用範囲を限定することができなかったために、波に乗れなかったという可能性はあると思う。
ユーザーの真のニーズを外していた説
（実システムでの試行錯誤が許されないSoR的な企業情報システムにおいて）上流工程にて創発的に良い要求開発（要件定義）を行うアプローチは一見すると良いものに見える。しかし実際には
ユーザーは本当はそんなことをしたくなかった
という可能性もあったと思う。
- 自分が望んで担当になったわけではない
- より良いシステムを作りたいというよりは、失敗しなければ良い
- できればベンダーに外注したい
- 難しい作業にはできるだけ関わりたくない
じっさい、ゼロ年代後半というと、企業のシステム部門がすこし弱くなってきた時期でもあったと思う。ビジネス部門のユーザーであれば収益の向上などを目的にモチベーションはあったと思うが、「システムはシステム部門が担当」という役割分担の中で、あえてチャレンジングな要求開発のアプローチを取ろうとしたユーザーは多くなかったのではないかとも思う。
SIerのモチベーションも高くなかった説
一方でシステム開発を受注（受託）するSIerのモチベーションも当時は高くなかっただろうと思う。要求開発は難易度が高いことに加えて、うまく成功すれば（理論上は無駄がそぎ落とされて）システム開発の規模が減少する方法論であるからだ。悪名高い「人月商売」とすればハイリスクでデメリットが多いという点で、SIerの立場で要求開発を強く推進するメリットは（当時としては）低かったのではないかと思う。
米国発の方法論や標準に（文化的な理由で）呼応できなかった説
現代でも、ソフトウェア開発の方法論やスタンダードは米国発のものが多い。それらに対して、要求開発が異質のように見えたというのも流行らなかった理由の一つではないかと考えている。
ただこれは文化的な側面があって、米国発の方法論には書かれていないプラグマティズム的思想的な背景が原因ではないだろうか。つまり、米国発の方法論には（書かれていないけど）要求開発的な要素が含まれているのではないかと最近思うようになっている。
「うまくいかなかったら、見直せばいいじゃない」
という態度が日本人は特に苦手だ。この態度が問題で、肩の力を抜けばうまくいくはずの要件定義が失敗しやすくなっているのではないか。
（なおプラグマティズムの問題は要求開発のみならず、ソフトウェア開発全般に影響しているとも考えている。もはや日本でもアジャイル開発が一般化しているが、これがうまくいっている要因のひとつに文化的障壁を超えてプラグマティズムを日本のエンジニアに注入できたということはいえないのだろうか。まあこれは別の話なので機会があれば別の記事で書く）
むすび：要求はやっぱり開発すべき
というわけで勝手に要求開発宣言について振り返ってみた。改めて考えてみると、要求開発が主流化しなかったのはかなり残念なことである。今回は取り上げていないが方法論としての難しさもある。しかしそれでも、（アジャイル開発宣言のパロディだとしても）要求開発宣言はいいことを言っていると思うし、改めて顧みられても良いと思うのだ。
ご意見があればX（Twitter）もしくははてなブックマークで言及いただきたい。最後までお読みいただきありがとうございます。
参考文献など
当時は「白本」と呼ばれてましたね
当時は「黒本」と呼ばれてましたね
これも（良い内容なのに）流行らなかった
現時点の本分野のバイブルといえばこれ
この記事では2021年に閉鎖され、現在はアクセスできない要求開発アライアンスというコミュニティのサイトで公開されていた「要求開発宣言」を紹介する。もう一つの記事「要求開発宣言について振り返る 2024」のためのものでもある。『情報システムに対する要求は、あらかじめ存在しているものではなく、ビジネス価値にもとづいて「開発」されるべきものである』というコンセプトを中心に構成された宣言は現在でも興味深い。なお文中でも示されるがこの宣言は2004年（20年前！）になされたものであり、当然のことながら現在の状況や慣行とは相違する点がある。
参考
以下は要求開発アライアンスがクリエイティブ・コモンズ-帰属-2.5 (CC-by-2.5) で公開していた文書「Openthology 要求開発方法論【コンセプト編】」から、「3. 要求開発宣言」を抜き出したもの。
要求開発宣言
要求開発宣言は、システム開発の分野で 2002 年に発表された、アジャイル宣言にインスパイアされ、要求開発アライアンスの理事を中心としたメンバーにて 2004 年 12 月に採択された、要求開発の「こころ」といえるものです。当時のメンバーが今後学び・明らかにすべきことを明文化したものと言えます。要求開発宣言は、要求開発を実践する際に、実践者やコミュニティそして要求開発方法論策定チームが大切にすべきコンセプトです。要求開発方法論は、この基本コンセプトを元に策定されています。
要求開発宣言
私たちは、企業でのITシステム開発を通じて、「要求」に関して以下のことを学んだ。
- 情報システムに対する要求は、あらかじめ存在しているものではなく、ビジネス価値にもとづいて「開発」されるべきものである。
- 情報システムは、それ単体ではなく、人間の業務活動と相互作用する一体化した業務プロセスとしてデザインされ、全体でビジネス価値の向上を目的とするべきである。
- 情報システムの存在意義は、ビジネス価値の定義から要求開発を経てシステム開発にいたる目的・手段連鎖の追跡可能性によって説明可能である。
- ビジネス価値を満たす要求は、直接・間接にその価値に関わるステークホルダー間の合意形成を通じてのみ創り出される。
- 要求の開発は、命令統制によらず参加協調による継続的改善プロセスを指向すべきである。
- 「ビジネスをモデルとして可視化する」ということが、合意形成、追跡可能性、説明可能性、および継続的改善にとって、決定的に重要である。
私たちはこれらの気づきから、「要求開発」という新しい知的活動分野を創造し、それをみずから実践していく。その過程で獲得したナレッジをOpenthology（オープンソロジー）として体系化し、かつ、クリエイティブコモンズの下に公開・共有することで、同様の課題を持っている人々と、コミュニティ活動を通じて分かち合うことを決意する。
解説
要求開発宣言
情報システムに対する要求は、あらかじめ存在しているものではなく、ビジネス価値にもとづいて「開発」されるべきものである。
これが、要求開発宣言の中心文です。情報システム開発を行なう場合に、その入力となる「要求」を私たちはどのように扱っているのでしょうか。要求定義、要求収集、要求整理、などの言葉が使われていますが、これらの用語はあたかも、要求というものがそこに存在しているような錯覚を与えています。要求は「定義されたり、集められたり、整理されるのを待っている」ものではなく、私たちが意識的な活動を通じて「創り出す」ものです。この要求を創り出す活動を「要求開発」と呼ぶこととします。システム開発が「要求」を入力して「情報システム」を出力するものであるならば、要求開発とは「ビジネス価値」を入力して「要求」を出力する創造的活動です。このように要求を開発するものであると捉えることによって、要求が本来持っている難しさを想起させると同時に、私たちが経験してきた「システム開発」におけるアナロジーが援用できる、というメリットもあります。そう、要求は私たちが「開発する」ものなのです。ビジネス価値に基づいた正しい要求を開発しない限り、下流であるシステム開発は正しくないものを正しく作る無為な行為となってしまいます。
情報システムと業務活動との相互作用
情報システムは、それ単体ではなく、人間の業務活動と相互作用する一体化した業務プロセスとしてデザインされ、全体でビジネス価値の向上を目的とするべきである。
情報システムは、ビジネス価値向上の一手段であり、それそのものが単体で価値を持つわけではありません。情報システムのデザインは、業務プロセスという上位のデザインの一部であり、そこでは、人間の業務活動と情報システムが相互作用をすることによってはじめてビジネス価値の向上をもたらすものです。情報システムのみに関心を向けることは、まったくの局所最適であり、手段を目的化する間違いだと認識しましょう。そして、デザインされた業務プロセスが果たすべきビジネス価値に、私たちの目を向けましょう。
追跡可能性による説明可能性
情報システムの存在意義は、ビジネス価値の定義から要求開発を経てシステム開発にいたる目的・手段連鎖の追跡可能性によって説明可能である。
なぜ、この情報システムに投資するのでしょうか。この問いに答えるためには、システムに対する要求がいったいどこから出てきたのか、を常に明確にしておく必要があります。このシステムはどのようなビジネス価値に結びつくのか。また、それを実現する手段は何なのか。この目的・手段の構造は目的（WHY）方向の末端をビジネス価値とし、手段（HOW）方向の末端を情報システム（もしくはそれに対する要求）とするツーリー構造をなしています。この目的・手段連鎖が追跡可能（traceable）でなければ、間違った問題に答えようとしているのかもしれない、あるいは、目的を果たすために別の手段の方がよりコストが低く効果が高いかもしれない、という不安から逃れることはできません。さらに、ステークホルダーに対する説明責任も果たせません。私たちはなぜこの情報システムを作るのか。この問いに答えましょう。
ステークホルダーの合意形成
ビジネス価値を満たす要求は、直接・間接にその価値に関わるステークホルダー間の合意形成を通じてのみ創り出される。
要求開発は個人に閉じた活動ではありません。その情報システムが実現する業務プロセスの価値に関わるステークホルダーの「合意」こそが、要求の開発プロセスとして重要なのです。ここでのステークホルダーに、情報システムユーザー企業の経営者、エンドユーザ、情報システム部門、ビジネス部門、さらに、情報システムベンダーも含まれています。異種ステークホルダーの合意形成が、困難であることは言うまでもありません。しかし、だからこそ、そのプロセスを定義し、継続的に進めることが重要なのではないでしょうか。
継続的改善プロセス
要求の開発は、命令統制によらず参加協調による継続的改善プロセスを指向すべきである。
要求開発が複数のステークホルダー間の合意形成であることから、そのプロセスは一方向の命令統制ではなく、参加協調が必要でしょう。さらに、その合意は複数フェーズにまたがる多段階コミットとなります。このプロセスは、継続的改善や PDCA（Plan-Do-Check-Action）ループと相似形をなすものであり、徐々にゆるやかに合意をブートストラップしていくものです。これは、要求開発がブレークダウン型の情報流では作り出せないこと、そして、よりコミュニケーション重視の創発的な活動が重要であることを示しています。
モデルと可視化
「ビジネスをモデルとして可視化する」ということが、合意形成、追跡可能性、説明可能性、および継続的改善にとって、決定的に重要である。
私たちは、情報システムの開発を長く経験してきました。そして、要求開発にシステム開発のアナロジーを当てはめることができると考えています。おりしも、オブジェクト指向開発方法論および UML が情報システム開発の標準となり、そのモデリング手法の体系ができあがりつつあります。これを援用することで、ビジネスそのものをもモデル化、可視化できると考えています。そして、要求開発においても、「見える」ということを第一義に重要としています。見えなければ合意形成はできません。見えなければ目的と手段は追跡できません。見えなければ説明できないのです。見えなければ継続的改善はできないのです。私たちは、要求開発の出発点を、このモデル化と可視化に置きます。
最近また何度か質問を受けたのと、好みの感じでまとまった記事がネットで見当たらなかったので書いておく。オラのサブスクことO'reilly learning platformの入会方法、使用感、書籍の収録状況（日本語、英語）などついて。オライリーの技術書を年に何冊も読む人は加入を検討すると良いと思う。
この記事の要点
- O'reilly learning platform は技術書を中心とした読み放題のサブスク。O'reilly以外の書籍や日本語書籍も収録されている。Webで読めるので洋書は日本語翻訳も容易
- 会費は比較的高価だが、ACM会員になって（99$/年）ACM Skills Bundle Add-Onのオプション（75$/年）をつければ定価の3分の1くらいの費用で利用できる
- 最近はO'reilly Japanの翻訳書も1か月ほどで登録されるようになってきた
O'reilly learning platform の紹介
サブスクリプション形式で提供される書籍、動画その他の学習コンテンツ提供プラットフォームである。勝手にオラのサブスクと呼んでいる。
- 現在は公式日本語の紹介ページがあるので、まずはそこを見るとよい
- アクセス方式はWebおよびモバイルアプリ（iOS,Android）。UIは英語で提供されている
- Web版では基本的にふつうのページとして書籍の内容が提供される（特殊なリーダーは使用しない）のでブラウザ機能で翻訳なども問題なくできる
- モバイルアプリではWebのように翻訳はできない一方で、書籍単位でダウンロードしてオフラインアクセスで書籍の閲覧が可能
- フリートライアル可能なので興味があればまずは触ってみるとよい
- ただしフリートライアル後に契約に進んでしまうと費用が高くなってしまうので、フリートライアルが完了したら継続しないことをおすすめする
- よってフリートライアル中に読んだ本やハイライトのデータは捨てることになってしまう点には注意
《筆者の利用イメージ（単なるトップページのスクリーンショット）》
費用に関して
個人契約であれば一番割引の多い年契約でも499$/年とちょっと高価である。たまにキャンペーンで割り引かれるようだが私は目撃したことがないので詳細は不明。
チーム単位や企業単位でのプランも存在する。ときどき福利厚生で利用できる会社もある（うらやましい）ので所属企業で利用できるかは念のため確認しておくとよい。
費用を抑えて利用するのであれば、ACM（米国計算機学会）のプロフェッショナル会員となりオプションとして利用するという方法がある。
- プロフェッショナル会員の会費は99$/年
- O'reilly learning platformを利用するためには、ACM Skills Bundle Add-Onの追加が必要。この費用は75$/年
- ACM会員としての特典は他にもいろいろある
というわけで普通に考えればACM会員として利用するのが良さそうだ。
ただし、ACM会員特典はときどき見直されるので継続的に O'reilly learning platform が利用できるかは不明だ。実際に過去に一時的に利用できなくなったこともある（ただ利用できなくなったタイミングでACM会員が大幅に減ったようで、その後オプションとして復活した）。年会費の更新時などには変更点やニュースをよくチェックするとよいだろう。
読むのがホネな技術書やビジネス書を取り上げて2週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第70回。同僚と読書期限を約束することによって積読が確実に減るという仕組み。過去記事はこちら。
さて、今回読む本は「ソフトウェアアーキテクチャメトリクス ―アーキテクチャ品質を改善する10のアドバイス」である。骨太のソフトウェアアーキテクトが書いた論文集といった本である。
ソフトウェアアーキテクチャメトリクスの概略と感想
概要は前述の訳者の島田さんのスライドに書かれている通りなのだけれども、個人の印象としてはこんな本だと思っている。
- 薄々多くの人が気づいていた「アーキテクチャの継続的な改善の方法」について「進化的アーキテクチャ ―絶え間ない変化を支える」で良いコンセプトが提言された
- 一方で同書が提示しているのはコンセプトであり、「良さそうだけど、コレ実際にどうやるの？」という疑問が芽生えた
- 本書はこの疑問に対して、一線のアーキテクトであり論者である人々が考えたことが示されている
というわけで大変に興味深い本なのだけれども、本当に10人の意見が述べられているだけという点は読み解きも難しかったと思う。全体を俯瞰したり、総括するような章が無いのである。とはいえ様々な意見に触れることができるので、異論反論を考えながら対話的に読むのが正しいように思う。その点では「ソフトウェアアーキテクトが知るべき97のこと」に似た感じともいえる。
当然の大前提
よいソフトウェアを作るためにはよいアーキテクチャが必要、というのは言うのは簡単だが難しいことである。本書のアプローチは（私の理解では）測定して改善するというものである。だからソフトウェアアーキテクチャ「メトリクス」が必要というわけだ。そして、測定して改善するということは、一発で良いものを作るというよりは継続的に（長期的に）良くしていくということでもある。ここは、SI屋的には難しい課題であもる。
第9章のこの言葉が重要だと思った。
ゴールに達するごとに少しずつ基準を上げていきながら、継続的改善を続けていくようにしましょう。もちろん、それをする意味があるのは、ビジネス的な価値があり、開発が継続しているシステムに限ります。開発が終わっているコードベースのメトリクスを改善することには、ほとんど意味がありません。
ソフトウェアアーキテクチャメトリクス ―アーキテクチャ品質を改善する10のアドバイス、9章 ソフトウェアメトリクスを使用して保守性を確保する より
とはいえ「評価してくれ」「測定してくれ」というのはよくあるトピックであるので知っておくことには大きな意味があるだろう。10章のGQMあたりは取り掛かるのが容易でありここから始めるのが良いのではないかと思った（GQMは確かIPAが推していたこともあって、情報入手しやすかったはず）
「ソフトウェアの「詳細設計書」とはなんなのか」というブログ記事を読んで考えたこと。設計に関するプロセスとドキュメンテーションの関係性についての考えの整理。SI屋的な視点で。
2024/8/18追記：文中にあった雑な文系disが不愉快というご指摘を受けました。ご指摘の通りだと思いましたので訂正しています。大変失礼しました。
「詳細設計書」とはなんなのか
こちらの記事では詳細設計書とは以下のようなものであると整理されている。
- 表現を変えたコーディング（の一種）
- 机上プロトタイプ（の一種）
- 分析資料
- 保守（のための）資料
- （水平作業の場合の）作業指示書
- （委託している場合の）契約資料
上記以外で考えられるのは次のようなものがあるだろう
- 利害関係者が要求している
- たとえば受託開発において発注者が要求している場合
- ほかには連携している相手先システム側から要求される場合
- 品質担保のためのレビューのため
このあたりは以前に以下のような記事を書いていた
逆に言えば、上記のいずれにも該当しない場合は設計書を作成する必要はないし、受託開発で発注者が要求しているだけの場合はコストとバーターで作成を回避する交渉も可能だろう。納入しても読まれないんだったら無駄だし。
要は詳細設計書は必要だったら（必要な範囲についてのみ）作ればいいし、不要だったら作らなくても良いのだ。ただし、ここには落とし穴がある。
詳細設計とはなんなのか
詳細設計書は不要と書いたが、プロセスとしての詳細設計（もしくは単なる「設計」）は省略できない。ソフトウェア開発についてわかっていない初心者PMがやらかしがちなミスは「コスト削減のために詳細設計書の作成を不要として、設計する時間が不足するくらいにスケジュールを短縮してしまう」ことである。この場合はだいたいうまくいかない。
設計書を作ろうと作るまいとプログラミングをする上で設計は必要で、削減できるのは（時に珍妙なExcel方眼紙に）設計結果をアウトプットする時間だけなのだ。
では（アウトプットすることは別にして）詳細設計では何をやるのだろうか。
いろいろな表現があるだろうが、要求仕様を分析し、非機能要件（〇〇性）を満たしたプログラムの構造を検討するということになるだろう。
偶然いま読んでいる「ソフトウェアアーキテクチャメトリクス ―アーキテクチャ品質を改善する10のアドバイス」だと以下のような特性が列挙されていたが、設計時間を短縮しすぎるとだいたい犠牲になるやつだと思った。結果として品質が下がるのだ。
- モジュール性
- 凝集性
- 関心事の分離
- 抽象化・情報隠蔽
- 結合度
- テスト容易性
- デプロイ容易性
ソフトウェアアーキテクチャメトリクス ―アーキテクチャ品質を改善する10のアドバイス、3章 進化的アーキテクチャ：テスト容易性とデプロイ可能性でアーキテクチャを導く より抜粋
というわけで、詳細設計書は別として、詳細設計は必要だと考えている
忙しいときに質問されたら「ここに書いておいたから読んでおいて」というためのブログ記事。システム開発では様々な問題に直面することになるが、その解決方法について経験的に有効だと思う方法について書き連ねておく。考えが変わったらあとでアップデートするかもしれない。私はこうやっているよ、という話。
基本としての「いかにして問題をとくか」
もっとも汎用的な問題解決の手法としては、有名なポリアの「いかにして問題をとくか」を参考にすると良い。書籍は名著だと思うが癖があるので購入する場合はサンプルを確認することをお薦めする。骨子はWikipediaで確認できるのでそれを読むだけでも十分である。書籍ではこの内容を深める（独特の）エッセーが読める。
（2022年より前に刷られた活版印刷版が特に味わい深い。書店の在庫や古書店をチェックしてみよう）
まあひとことで言えば次の4つのステップだ。
- 問題を理解する
- 計画を立てる
- 計画を実行する
- ふりかえる
あ、あたりまえじゃねーか......と思うかもしれないが、この基本ステップをちゃんとできていない例は多い。ぱっと思いつくだけでも次のようなことが起こりがちである。
- 問題と願望（こうであってほしい）が混ざり合って、問題を正しく理解できていない。「起こったことだけ教えて」
- 問題と現象が混ざり合って、問題を正しく理解できていない。「何が問題なの？」
- 前提知識が不足しすぎて、問題を理解できていない。「問題はどこで起こっているの？」
- 計画がない。「こどものサッカーか？」
- 計画がないので無限に時間を溶かしている。「次のチェックポイントは何時？」
- 計画どおりにやっていない。途中でうまくいかないで別のことを試し始める。「なんで別のことをやってるの？」
- ふりかえらずに時間を溶かしている。「で、ここまでで何がわかったの？」
おかしくなった系に有効な「問題の記述」メソッド
ある時まではうまく動いていないものがおかしくなったというパターンは、Brendan Greggの「詳解 システム・パフォーマンス 第2版」で紹介されている「問題の記述」メソッドが有効だ。
問題の記述は、サポートスタッフが問題に最初に対処するときのルーチン作業である。顧客に次の項目を尋ねて書いていく。
- パフォーマンスに問題があると思ったのはなぜか。
- このシステムは、良好なパフォーマンスで動いていたことがあったか。
- 最近の変化は何か。ソフトウェアか、ハードウェアか、負荷か。
- その問題はレイテンシか実行時間で表現できるか。
- その問題はほかの人やアプリケーションに影響を及ぼしているか（それとも、影響があるのはあなただけか）。
- 環境はどうなっているのか。どのソフトウェア、ハードウェアを使っているのか。バージョン、構成はどうか。
単にこれらのことを尋ね、答えを聞くだけで、直接的な原因や解決方法がわかることがよくある。そこで、ここでは独立したメソドロジとして、問題の記述を入れてある。新しい問題に立ち向かうときには、最初のアプローチとしてこれを使うべきだ。
詳解 システム・パフォーマンス 第2版 、2章 メソドロジ より引用
同書はパフォーマンスに関する本なので当然パフォーマンスのことを問うているが、ここを適宜読み替えて（たとえば「機能」とか「画面」とか）使えば良いだろう。自分もよく使っている。
読むのがホネな技術書やビジネス書を取り上げて2週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第69回。同僚と読書期限を約束することによって積読が確実に減るという仕組み。過去記事はこちら。
さて、今回読む本は「ソフトウェア開発現場の「失敗」集めてみた。 42の失敗事例で学ぶチーム開発のうまい進めかた」である。わりと好物な切り口！ しかし現代的というか、タイトルが長い～
『42の失敗事例で学ぶチーム開発のうまい進めかた』の概略
表題のとおり、ソフトウェア開発のよくある失敗事例を通じてどうすべきだったかを学んだり考える本である。著者がメーカー系の出身ということで、コンテキストをまとめるとこんな感じ。
- 組み込み系、デバイス制御系の製品に関するソフトウェア開発
- 自社開発（受託開発ではない）
- 委託開発もしているが部分的で、基本的には内製開発
- 大規模（複数チーム並列）ではないサイズの開発
- 組織文化はブラックではないが、ほどほど理不尽
このコンテキストと読者の距離が近ければ共感度は高いだろう。
「はじめに」で著者はこう書いている。
- 失敗の経験が危険を検知する
- （しかし）失敗自体はマイナスでしかない
リーダーとしてよい判断を下すには、自分の中に豊富な失敗のケースを持っておくことが必要です。一方、失敗を豊富にやらかしていると失敗を生かす前に会社をクビになってしまうというジレンマがあります。
そこで新しくソフトウェアプロジェクトのリーダーになった皆様、もしくはリーダーを目指す皆様に、著者の豊富な失敗経験から作った「失敗事例集」を提供できればと考えました。この「失敗事例集」を皆様がよい判断を下すためのガイドとして活用いただきたいと思います。当然、本書と全く同じ失敗はあり得ないと思いますが、それぞれの失敗をパターンとして覚えておけば、きっと役に立つはずです。
ソフトウェア開発現場の「失敗」集めてみた。 42の失敗事例で学ぶチーム開発のうまい進めかた、はじめに より
この考え方は大賛成だ。
ほどよく抽象的なレベルの42のパターン
さて、本書の目次は出版社のサイトなどでも閲覧できるので、興味があれば参照してみるとよい。上級者であればタイトルを見ればだいたいなにがテーマかわかるだろう
全体としては、抽象度がほどよく、誰にでも考えさせることができる記載になっているという印象だ。
- アーキテクチャやコードそのものまで深掘りされているわけではない（プログラマでなくても読める）
- 特定の開発プロセス（ウォーターフォールとかアジャイルとか）にも依存しないし、どんなプロジェクトでも直面しそうなフェーズが揃っている
というわけで新人エンジニアでも若手でも十分楽しめるのではないだろうか。
むしろ、若手を含むチームで読書会などをして、チームの教養として本書を取り込むとよいだろう。
事例の表題がパターン名のようになっているので「あー、これは42事例本の『初期企画至上主義』になってませんか」「そうかもー！」といった会話がチーム内でできると良さそうだ。
一方でベテランでも改めて通読することで、忘れていたことを思い出して「ウッ！」と感じることもできる（とりあえず、わたしはそうだった）。
なかなか興味深い本である。
他人の失敗から学ぶのはスキルアップの早道
著者の言うとおり、自分のプロジェクトでみずからやらかして経験値を得るのはリスクも高いし非効率だ。だから、他人の失敗を疑似体験するのが良い。
本書で（失敗事例が）もの足りない人もいるだろうと考えて、思いつく限りの類書を挙げておこう。