豆蔵の元経営者の方の、開発プロセスの話。
プロセスっちゅうのは時系列を見える化することだ、と。
逆にUMLなどは局所的な部分を見える化することである、と。
・ウォーターフォール・・・管理しやすい。受発注に向いてる
・反復型・・・開発リスクに柔軟に。
・アジャイル・・・開発者のモチベーションを高めやすい
上記の3つを軸にした講演。
その場で挙手式なアンケート。
会場内は大体ウォーターフォール。(自社開発ですがなんちゃってウォーターフォールです･･･)
アジャイルな人がチラホラ。
・ウォーターフォールの問題点。
昔はアーキテクチャに制限があったから。
画面と帳票が決まれば、それでOKだった。
が、今は、みんな裏でミドルウェアとかフレームワークとか、
検証やってるよね？と。
検証やりながら、そのフィードバックを取り込みながら開発してるなら、
それは厳密なウォーターフォールじゃない。(自分のとこはまさにそうです。)
ウォーターフォールの裏で隠れプロセスとして、検証とかやったダメだ。
ちゃんと見える化しないと。管理者がわかるように。
・パラレル型開発。
RUPとかの反復開発プロセスは全部その通りやってもうまくいかない。
リファレンスモデルの一つとして、カスタマイズして導入しないと。
・ユースケースドリブン(要求に重き)
・アーキテクチャセントリック(アーキテクチャに重き)
検証されたものをいかに提供するかって観点で、
両方やろうとすると破綻しがち。
やり方考えないと。
・アジャイル開発
“プロセス”っていう言葉が嫌いな印象。
でも、必ずそこに、プロセスは存在する。
それが見えないようなのはよくない。
設計をしないのではなく、検証重視の設計をしてるだけで。
モデリングしないのではなく、書き過ぎてないってこと。
無駄なドキュメントを書かないだけ。
開発ドキュメントと保守ドキュメントは違うから。
誰も読まないようなドキュメントなら無駄。
・反復型とアジャイル
反復型は計画(管理)重視→最初に決めた価値を守っていく
アジャイルは価値重視→拡大のための反復
・予算ドリブン
予算にあわせて、人だけ積んで、オリャっと。
→そんなの全然クリエイティブじゃない。エンジニアリングはクリエイティブでないと、いかん。
・アジャイル
ToBeを最も早くみせるのに一番適しているが、
アジャイルにやるとしても、ビジネスのスケールで考えないことには話にならない。
『開発』だけアジャイルでも、顧客が要求を出してから、そのアウトプットが出るまでに
時間がかかってしまったら、開発だけアジャイルでも意味がない。
開発プロジェクトにとじこもって要求を待っていてもダメ。
ビジネスの世界に飛び込んでいかないと。
・こたつモデル
戦略を決定する人(経営層)、業務屋、ＩＴ屋
みんなが、ひとつのこたつで。
時系列を伴うプロセスで正しい要求は難しい。
そもそも正しい要求なんてなくて。
だからみんなで近くでお互いが協力しあって。
—
終始、”その環境を俺が作る”的な、萩本さんの心意気というか。
ガツガツした向上心というか、そういうの素敵だな、と思いました。
コメント