アーキテクチャ近代化の実行: いつから見積もりが締め切りになったのか?

 (domainanalysis.io)
5 ポイント 投稿者 GN⁺ 2024-11-21 | 1件のコメント | WhatsAppで共有

  • 複雑なソフトウェア近代化プロジェクトでのヒント: 見積もりは締め切りではなく、指針として扱うべき。

  • 個人的な経験:

    • ソウルと束草での楽しい休暇の後、システム思考と『Zen and the Art of Motorcycle Maintenance』という本について書こうとしていたが、ここ2週間の出来事によって計画が変わった。
    • アメリカの選挙前の週末に事故に遭い、勤務先であるNew York Timesでの技術者ストライキも経験した。

  • 見積もり - 芸術か科学か?:

    • 自動車修理の過程で、保険査定人と修理工場の間にある見積もりの差と交渉の過程を説明している。
    • 予期しない損傷が見つかった場合は追加費用が発生する可能性があり、保険会社の承認が必要になる。

  • 複雑なソフトウェアアーキテクチャ近代化との類似性:

    • レガシーソフトウェア近代化の過程で、初期見積もりと実際の複雑さの違いを説明している。
    • 追加の複雑さが見つかるたびに、追加承認が必要になる。

  • 優れたリーダーは正しい質問をする:

    • 複雑な問題を解決するためには、正しい質問を投げかけることが重要。
    • 予期しない複雑さが見つかったときの対応方法について論じている。

  • 続行するのか、それとも全損とみなすのか?:

    • 近代化プロジェクトで追加費用が承認されて作業が続く場合と、プロジェクトが中止される場合を説明している。

  • 複雑な文脈か、複雑な文脈か?:

    • Cynefinフレームワークを使って、複雑な状況における意思決定プロセスを説明している。
    • 複雑なレガシーソフトウェアプロジェクトにおける学習と実験の重要性を強調している。

  • 否認 - 怒り - 交渉 - 抑うつ - 受容?:

    • 近代化プロジェクトでの予期しない状況への対応方法を説明している。
    • 組織文化がこうした状況にどう対応するかについて、Ron Westrumのモデルを紹介している。

  • 近代化イニシアチブを率いるリーダーへのヒント:

    • 複雑なドメインでは実験的な管理手法が必要であり、失敗を受け入れることが重要。
    • リーダーが秩序を押し付けようとすれば失敗し、パターンが現れることを許容するのが成功の鍵である。

  • 新たな希望:

    • 自動車修理と保険処理の過程での経験を通じて、近代化プロジェクトにおける見積もりの重要性を強調している。
    • ソフトウェア企業とリーダーシップが、成功を測るための正しいフレームワークを使うことを願っている。

関連記事

1件のコメント

 
GN⁺ 2024-11-21
Hacker Newsの意見

  • 管理者が見積もりを締め切りとして扱うことがあった。仕様が頻繁に変更されるたびに「ヘッドライトを浴びたシカ」のような反応で時間を稼ぎ、見積もりはできるだけ保守的に出して予定より早く終わらせる戦略を使っていた。良い管理者の下では、こうした戦略は必要なかった。

  • モダナイゼーション・プロジェクトにはソフトな締め切りがあり、予算の圧力やユーザー要件はあるものの、1日遅れても大きな問題にはならない。一方で、宇宙探査機の打ち上げやFordのような大企業では、締め切りを逃すと大きな損失が出る可能性がある。

  • ミケランジェロは教皇ユリウス2世の墓を5年で完成させると見積もっていたが、実際には40年かかった。これは顧客要求の変更、サプライチェーンの問題、契約再交渉などの理由でプロジェクトの規模が縮小されたためだった。

  • 初期の見積もりは記憶に残りやすく、新しい情報を出しても最初の見積もりを変えるのが難しいことが多い。そのため、見積もりを出すのを嫌がる人がいる。

  • 保険会社が当初の見積もり額しか払おうとしないことはよくある。これは自動車保険、住宅保険、健康保険のすべてに当てはまり、必ずしも合理的な結果につながるとは限らない。

  • 固定されたスコープに対する見積もりを提示し、追加で見つかった作業については新しいマイルストーンを加えることが重要だ。ただし、このアプローチを理解する管理層が必要になる。

  • リーダーシップは締め切りが動機づけになると考えがちだが、これは誤ったアプローチだ。締め切りを現実的に調整しなければ、チームの士気が下がる可能性がある。

  • 「No Estimates」アプローチを支持する。正確な見積もりが可能なのは、過去と同じ作業であるか、残っている作業が明確に定義されている場合だけだ。

  • 面白い見積もりの公式があり、これは個人の経験に基づく非公式な公式だ。たとえば、プロジェクトに参加する人数、新しいツールの数などを考慮して実際の所要時間を計算する。

  • 最高の見積もりシステムは、完了日を予想し、最も近かった人が昼食をおごってもらえるという方式だ。これは友人同士で行われており、非常に正確な結果をもたらした。

  • 企業は未来を正確に予測したがるが、それは不可能だ。見積もりは主に管理層で重視されるものであり、正確な見積もりを出した人に報酬が与えられるわけでもない。時間だけに集中すると、ほかの重要な要素に悪影響が及ぶ可能性がある。