アジャイルの取り組みが大きく遅れている
http://itpro.nikkeibp.co.jp/article/COLUMN/20121214/444385/
最近、偶然に大規模な業務システムを開発する現場を訪問する機会があった。開発のプロセスは基本設計＞詳細設計＞製造＞結合テストといわゆるウォーター フォール型で遂行中で丁度詳細設計書のレビューの実施中とのことだっ た。
ファイルサーバには実に数百もの設計書のファイルがあり、それらを一通りレ ビューして実装のベースに足る品質に早期にもっていきたいという。
プロジェクトの管理チームが設計書のレビューを実施し品質を確認するタスクに 入っており、しばらくの間は設計書にかかりきりだなあという嘆息が漏 れ聞こ えた。
しかし、プロジェクトの管理チームがレビューに掛かりきりになったら、誰がプ ロジェクトの管理をするのだろうか。
特に大きなプロジェクトでは日々色々な事が起こるし、人間的なメンタリティに 関わる問題などは決して後回しにするわけにはいかない。
取捨選択の末にレビューを後回しにする。そしてスケジュールはジリジリと破綻 に向かって後ずさりを始める。
そして、この遅れを取り戻すために管理チームは「銀の弾丸」を投入する。。。
普段、テストファーストで開発して製品のアジリティを落とさないことを是とす る文化の中で仕事をしている私にとって、この見聞は一種の驚きとして 深く記 憶に残った。
年の瀬の週末だというのに職場でモニタに向かっている多くのメンバ。彼らが何 をしでかしたというのか。
彼らは極めて正しい。しかし同時に極めて間違っているともいえる。
数百名にも上る規模のプロジェクトを遂行しようとすれば、品質と資源の管理の 手間は膨大である。したがって自ずと管理しやすい方法を選択する他は なくなる。
どの世界でもアジャイルですべてが丸く収まるなどということはない。それは幻 想である。
トラックに乗用車のハンドルは適していないし、乗用車に自転車のハンドルをつ けることもできない。
ウォーターフォールでないと解決しない問題が存在するのも事実なのだ。
しかし、膨大なしかも実装にどれだけ貢献するか分からない設計書を作成してメ ンテナンスをしながら開発を進めることのリスクは今の時代誰しも理解 している。
究極の答えを求める、本来の目的と乖離していっていないか。
そこに疑問を持ちプロセスをカイゼンする視野がまず重要になる。
これは、答えを出すということを重視するか、答えを出すプロセス自体を重視す るかの違いであり、いくら考えても発想の転換は自力では難しい。
管理を細かい単位に分割した結果、小規模のチームで定義したイテレーションが うまく機能するならば、一枚岩でなくともそれは一つの成功といえる。
こうした試みは通常想像以上に困難であり、文化の違い、言語の違い、慣習の違 いなどが見事にそれらを阻害する。
故に、上記の記事にもあったエンジニアの流動性というファクターは重要な意味 を持つ。
大陸を地盤として生き抜いてきた人たちにとっては常に地続きに異文化が存在 し、異文化間で交流するということは普通である。
しかし、日本ではそうした意識はやっとこの百年あまりで意識され始めたに過ぎ ず、根付いているとはいえない。
ここでも”ガラパゴス化”という言葉が見え隠れするけれど、ネットの普及によっ て意外に早くこの溝は埋まるかもしれない。
私は、これに加えて極めて日本的な「カイゼン」が生まれることを期待する者の 一人である。
