大きくて複雑なものを作る人達へ送る一冊
この記事は株式会社ヘンリー - Qiita Advent Calendar 2024の13日目の記事です。前回は 林さん の「Henryのお客様：医療DXの先駆者たち」でした。
私は PM（Product Manager）として、中小病院向けのクラウド型電子カルテ・会計システム「Henry」を開発しています。医療業界は様々な職種や法規制が絡み合うため、複雑な要求定義と大規模な機能拡張が日常的に求められる領域です。医師、看護師、薬剤師、放射線技師、検査技師、療法士、栄養士、医療事務など、多様な職能がかかわることで一つの機能追加でも大きな波及範囲を持ち、既存のワークフローや法規制の枠組みもあってその開発には難易度があります。さらに、医療機器や部門システムとの連携、保険診療制度の2年ごとの改定といった要素が絡み合い、Henry は常に多面的な検討を要しています。
こうした「大きくて複雑なもの」をどう作ればよいのか、逆にどうしてうまくいかないことが多いのかは、常々気にかけているテーマです。そんな中、『BIG THINGS どデカいことを成し遂げたヤツらはなにをしたのか？』という書籍を手に取ったのは、Henry のような大規模システム開発だからこそ学べることがあるのではないかと感じたからです。本記事では、この本に書かれている考えを自分なりに噛み砕き、Henryの開発現場で感じている課題を踏まえながら考察を共有していきたいと思います。もしあなたが大きくて複雑なものを作っていると感じているなら、何かしら学びがあるかも知れません。
ゆっくり考え、素早く動く
大規模なシステムを計画する際、「計画段階にどれくらい時間をかけるべきなのか」と悩むことは多いです。ある程度要求を分解しても、なお「もう少し考えた方がいいのか、それとも早く決めて実行フェーズに移るべきなのか」と迷うことがあります。
『BIG THINGS』では、これに対して「ゆっくり考え、素早く動く」ことの重要性が語られています。創造的で多面的な思考は時間を要するものであり、焦って短絡的な結論を出すことが、後々の大きな手戻りにつながってしまうからです。ただし、素早く決めること自体が悪だとは言っていません。もし後戻りが容易な決定であれば、さっさと決めて前進するメリットはあります。要は「戻しやすさ」が意思決定スピードを測る目安になる、という考え方だと私は理解しています。
なぜ我々は「早く決めたい」と強く思うのでしょうか。それは「不安や恐れから早く解放されたい」「進んでいる実感がほしい」といった人間的な衝動によるものかもしれません。何らかの具象的な成果物がないと進歩を感じづらく、その焦りが早期決断を促すこともあると思います。
この衝動に対処するためには、次のことが有効だと考えています:
企画や計画そのものを価値ある成果物と捉えること
考える時間をしっかり確保すること
計画や要件定義のプロセスで生まれる知見も立派なアウトプットであり、それらを適切に評価することで精神的な焦りを軽減できます。また、どれくらい考えるかは「計画を開始してからの時間を含めた全体最適」を意識するといいと感じています。
不確実性や恐怖心への対処として、問題を細かく分解して理解しやすくすることや、チームメンバー全員で考えることで「集合的な勇気」を発揮することも有効だと思います。
最小限の実験
仮に「アジャイル＝小さく作って市場に出し、そこから学ぶ」と捉えると、長い計画フェーズはウォーターフォール的だと感じるかもしれません。私自身、そう感じていた時期もあります。しかし、『BIG THINGS』では「試行・学習・反復」を最小限のコストで繰り返す実験的アプローチが強調されており、これはアジャイルの精神と通じるところがあると感じました。
ピクサーがアイディアをブラッシュアップするとき、まずは一言のコンセプトから、短い説明文、絵コンテへと段階的に検証を進め、重いコストをかけずにリスクを取り除いていきます。これをソフトウェアの世界で考えるなら、実際にコードを書いて機能を実装する前にも、ビジネス価値を示す説明文やUXリサーチ、プロトタイプやUIデザイン、仕様策定といった形で段階的な「実験」が可能です。具体的には、顧客やドメインエキスパートとの対話を通じて要求のギャップを発見し、紙や図で事前検証できる部分はしておくわけです。
もちろん、ソフトウェア製品とアニメーション制作ではコスト構造が違うので、ソフトウェア製品では「実際に出して市場に問う」戦略が有効だと思うかも知れません。それが効くのは、価値が不確実で、検証コストが低く、間違ってもリカバリが容易な場合です。Henryのようなプロダクトでは、法規制がある分、不確実性はそれほど高くないものの、検証コストは大きく、間違えたときに戻すコストも高くなりがちです。そのため、一部の顧客を限定して導入するパイロットテストや、プロトタイプ段階での要件確認など、段階的にリスクを下げる工夫が必要だと考えています。
見積もり
大規模プロジェクトで恒常的な悩みとなるのが見積もりです。『BIG THINGS』にはシドニーのオペラハウス建設をはじめとした興味深い事例が多く紹介されており、「なぜ見積もりはここまで当たらないのか」を考えさせられます。
本書が指摘するのは、私たちが見積もりに使う「物差し」が誤っていることが多いという点です。初めて行うプロジェクトでは、つい「過去に見たことがある何か似ているプロジェクト」を参考にしがちで、実はそれが全然似ていないことも珍しくありません。
ここで紹介されているRCF法（参照クラス予測法）は、カーネマンやトベルスキーの研究に基づく手法で、次のステップでより現実的な見積もりを目指します。
類似プロジェクトの参照クラスを特定し
その実績データから確率分布を作り
現行プロジェクトがその分布上でどのあたりに位置するかを評価する
アジャイルな手法が内部実績（自分たちがこれまで蓄積してきた経験）から学ぶものだとすれば、RCF法は外部事例（社外の類似プロジェクト）から学ぶアプローチとも言えそうです。これらを組み合わせれば、初期段階でのより正確な見積もりと、イテレーションを回しながらの改善が両立できるのではないかと思います。
ただし、医療分野の独自性を考えると、どこから「参照クラス」を持ってくるかは新たな難題です。同業界の成功事例や学会、コミュニティで共有されている知見を探るなど、地道な情報収集が必要になるかもしれません。
まとめ
本書から得られる示唆を、私がHenry開発の文脈を踏まえて行動指針としてまとめると、以下のようになります。
計画フェーズでの学習は、小規模な実験的プロトタイプや顧客ヒアリング、思考実験によって行う。
参照クラスを確保するため、同業種の事例や社内外での類似プロジェクト情報を収集し、初期見積もりの精度を上げる。
焦りや不安から早く決断したくなったら、問題をさらに細分化し、チームの知見を総動員して恐怖の正体を小さくしていく。
計画フェーズは「儀式」ではなく「価値あるアウトプットを生み出すプロセス」だと捉え、そこに時間を投資することを正当化する。
本書では、これら以外にもイノベーションと計画性が必ずしもトレードオフではない話や、ものづくりにおけるモジュール性、チームの重要性などが語られています。Henryのような大規模システムを扱う際、何かのヒントが得られるかもしれません。気になる方は、ぜひ手に取ってみてください。