はじめに
従来開発にありがちなアンチパターンとおすすめ対応案を3つ挙げてみました。
同じ様に悩む現場の薬になれば幸いです。
パターン１．キツツキ戦法
開発現場では必ずしも1人が1つの案件を専任出来るとは限らず、しばしば何かを兼務します。
また従来開発ではマネージャ・リーダ・エンジニアという3役が良く立てられますが、この役割も2つ3つ兼務する状況が生まれがちです。
一方で、この様なアサインでは
役割の切り替えによるオーバーヘッド（無駄なコスト）の発生
他者との依存関係の低いタスクなど、本来価値とは異なる理由でタスクの優先順位が劣後しやすい
などから、期待していた成果が出なくなる危険があります。
対応案
下図のように、「アサインは最大ふたつまで」を厳守しましょう。
3つ以上が発生しそうな場合は、全体最適を考えたアサインの見直しが必要です。
パターン２．円卓の騎士
複数のチームが関係する様な開発では、しばしばリーダー会の様な打合せが開かれます。
情報共有や認識統一をはかるための会議ですが、実は自分の納得出来る解釈を得ているだけの時があります。
この結果、（はた目から見て）何故か連動しない開発が生まれてしまいます。
対応案
重要な意思決定を全員で見える化し、各自はそれを正として活動しましょう。
資料は合意の下で常にメンテナンスが可能であり、状況の変化に応じて更新しましょう。
パターン３．連環の計
案件ではしばしば他者とのタスクに依存関係が発生します。
特に上流工程などタスクの全体感が見通しにくい状況では、他人の作業を止めない様、常にタスクを回し続ける状況に陥る場合があります。
この結果、ワークファイルや口頭情報などが体系化されず、中長期的に属人化や生産効率の低下を招いていきます。
対応案
情報を整理する時間を含めてマスタスケジュールを引きましょう。
手を止める期間があることを明確にすることで、他人の作業を止めるという視点を排除することが出来ます。
なんだアジャイル開発じゃないか
- パターン1の対応案は、アジャイルな見積りと計画づくり2章40ページでも同様に語られています。
- パターン２の対応案は、アジャイルサムライの著者 Jonathan Rasmusson氏発案のインセプションデッキがフレームワークとして役立つでしょう。
- パターン３の対応案は、アジャイル開発において技術的負債への対応として一般的に取られる方法論です。
この様に、本稿は日頃アジャイル開発に馴染んでいる方にとっては当たり前の顛末と対応案となっています。
一方で従来開発に馴染んだ現場では、2020年現在もこの様な事象がまだまだ発生しがちです。
まとめ
従来開発において陥りやすいアンチパターンを３つ挙げてみました。
本稿の対応案は即自的な方法として参考となるでしょう。
願わくば、組織的にアジャイル開発への知識を身につけていくことで、皆さんの組織において中長期的に撲滅されることを祈っています。
※本稿の図中に登場する人名は架空の存在であり、実在のものとは関係ありません
※各パターンの名称は筆者独自のものであり、一般性を持つものではありません
(おまけ：元ネタ)
キツツキ戦法
キツツキ戦法は川中島の戦いで武田軍が上杉軍に仕掛けた戦法で、本隊をおとりに別動隊を敵背後へ進軍させ挟み撃ちにする作戦です。
一方で、この作戦を見破った上杉謙信は逆に武田本隊を急襲。手薄の武田本隊は大苦戦したと言われます。
円卓の騎士
アーサー王物語におけるアーサー王に仕えたとされる騎士。
上座下座の無い円卓を囲むことで全員が対等であることとされています。
なお、「1兆ドルコーチ シリコンバレーのレジェンド ビル・キャンベルの成功の教え」では、同じく円卓の騎士を例に「円卓には上座がないが、その背後には玉座がなくてはならない。」として意思決定の必要性を説いています。
連環の計
連環の計は中国兵法における「鎖の環が連なるように、兵法を幾つも連続させる方法」を指します。
本稿では特に三国志演義 赤壁の戦いで用いられた連環の計を指しています。
龐統の助言により船同士を鎖で繋いだ魏軍は、その後の火計で船同士を切り離せなくなり、敗着となる大炎上を起こしてしまいました。