ITコーディネータの
今回は開発プロセスのお話です。
10年以上も前から
ウォータフォール型開発の欠点が指摘され
アジャイル型開発が多く実践されてきていますが
未だに旧来のウォータフォール型開発に
固執している現場があるというのは残念なことです。
システム開発プロセスの基本は
ウォータフォール型であると言われていますが、
これはあくまでも工程の順番の話。
計画→設計→実装→検証という流れは
アジャイル開発であっても共通だ
という程度のことに過ぎません。
原理的なウォータフォール型開発の
決定的な欠点は「手戻りを認めない」ということです。
例えば、要件定義工程で要件を出し尽くし、
要件定義工程のアウトプットが承認され
次の設計工程に移行したら
要件の追加や変更は認めないというものです。
この「認めない」という宣言は
かなり強力に思えます。
実際どれほどの効力があるのかは
疑わしいところですが、
本当に認めなかったとしたら
どうなってしまうのか
何故想像がつかないのか不思議です。
手戻りを認めないというのは
言い方を変えれば、
前工程の「失敗を認めない」ということです。
これはかなり厳しい制約です。
人間の活動に失敗はつきものだからです。
失敗が許されないとしたら
必要以上に慎重に作業を行い、
必要以上に慎重にレビューや検証を行い
つまり必要以上に工数を投入しなければならない。
それでも失敗はするものです。
何故か。
F.P.ブルックス,Jr.は
著書「人月の神話」の中で次のように述べています。
ソフトウェア製作者が顧客のために行うもっとも重要な仕事は、製品の要件を繰り返し抽出し、洗練していくことだ。実際のところ、顧客自身何を希望しているのか分かっていないものだ。彼らは通常、どんな質問に答えなくてはならないかを理解しておらず、指定しなければならない問題の詳細さについて考えたことなどほとんどない。
フレデリック.P.ブルックス,Jr.著
「人月の神話 新装版 ―狼人間を撃つ銀の弾はない―」
（ピアソン・エデュケーション）・186ページ
いわば、ユーザーが要件を出し尽くすことはない
と言っているようなものです。
手戻りを認めないということは
実際に手に入るシステムは
ユーザーの本当の要件に
合致していないものとなるということです。
規定されたプロセス通りに開発を行い
ユーザーの要件からずれたシステムを手に入れて
本当に成功なのでしょうか。
そんなことはないですよね。
ユーザーの要件にフィットしたシステムが
完成してこそシステム開発の成功です。
だから手戻りを想定しない開発プロセスは
欠陥以外の何物でもありません。
システム開発を成功させることではなく、
プロセスに従うことが目的になってしまっています。
このようなプロセスを推進している組織は
プロセスの変更を検討してほしいと思います。
欠陥プロセスに闇雲に従い続ける組織、
それは成長や学習のチャンスを
自ら捨てているのと同じです。
有意義なフィードバックなしに改善は望めない。間違いを警告してくれる「信号」をシステムの中に取り入れることが肝心だ。
マシュー・サイド著
「失敗の科学」（ディスカヴァー）・323ページ
関連記事
プロマネの右腕
プロジェクトマネジメントの支援を行っています。
新サービスの企画を任されたけど どう進めていいか悩んでいる担当者、
部下に新しい企画を任せたけど このままで大丈夫か不安な管理職の方、
以下のサイトをご参照ください。
https://www.crossidea.co.jp/services/right-hand-pmo.html
YouTubeにて動画配信中！
プロジェクトマネジメントのノウハウをYouTubeで配信しています。
ブログと併せてご活用ください。