ポストSIビジネスのシナリオ: アジャイル型請負開発（２）
アジャイル開発の本質は、「全部作らない」ことだ。これが、ウォーターフォール開発と本質的に異なる点だ。アジャイル開発は、「業務上必要性が高い機能やプロセスを選別し、優先順位を決めて、そこにリソースを傾注することで、必要なシステムのみを作り上げよう」という考え方だ。結果として、短期間、高品質での開発が実現する。
一方、ウォーターフォール開発は、「全部作ること」を前提とする。そのため、ユーザーの要求がすべて決まらなければ開発に着手できない。また、いったん作り始めると、途中で変更することは難しく、すべてを作り上げることが優先される。変更や品質保証は全部コードを書き終えた最後の最後に対応しなければならない。
アジャイル開発の手法を使っても、「全部作る」のであれば、ウォーターフォールと本質的には何も変わらない。アジャイル開発は「全部作らない」かわりに、短期間・高品質・変更への柔軟性を担保しようというもので、「全部作る」こととトレードオフの関係にある。
アジャイル型請負開発は、このアジャイル開発の思想を請負開発に持ち込もうという取り組みだ。
アジャイル型請負開発では、ビジネス価値、つまり、「業務を遂行するうえでなくてはならないプロセスを実現する機能」に絞り込んで開発すべき対象範囲を決めてゆく。「必要かどうかわからない」「あったほうがいいかもしれない」というものは、対象から外す。そして、おおよその工数と期間の見通しを立てて金額を決め、請負契約を締結する。
そのうえで、ビジネス価値で優先順位を決めて、ひとつひとつ完成させてゆく。開発の途中でこの優先順位が変われば、合意した工数と期間の範囲内で入れ替えることができるので、ユーザーの変更要求に柔軟に対応できる。
重要なところから完成させてゆくので、リスクは開発期間の初期に片寄せされる。また、期間後期になると重要なプロセスほど多くの検証が入るため、それらのバグは徹底して潰される。また、後期になればなるほど重要度の低いプロセスになるので、たとえそこで問題が生じても全体に及ぼす影響は少なく、結果的に期間内に出来上がるシステムの完成度は高いものになる。
また、請負契約を締結し、金額を確定しているので、日々改善に努め、生産性を高めていけば、原価を低減させ、利益を拡大させることができる。アジャイル開発で行われる朝会や振り返りなどの取り組みは、まさにそのためのものだ。
このようなやりかたで、次の３つの狙いを実現します。
- ユーザーが本当に使うシステムだけを作ることで、ムダな開発投資をさせない。
- ユーザーからの変更要求にも柔軟に対応し、ユーザーが納得して使えるシステムを実現する。
- ユーザーが納得できる予算の中で最善の機能を実装し、約束した期間の中で最高の品質を実現する。
「アジャイル型請負開発は、この３つの狙いを実現することで、「顧客満足」という顧客価値を提供すると同時に、「幸せな働き方の実現」と「利益の拡大」という事業者価値の享受を両立する、新しい受託開発のビジネスモデルだ。
しかし、このようなメリットあるやり方も、広く受け入れられているとはいえない。それは、これまで工数の積算でしか仕事をしてこなかったＳＩ事業者と情報システム部門の双方に抵抗感が大きいためだ。
まず、ＳＩ事業者はこれまで「全部作ること」を仕事にしてきたわけで、「全部作らない」という考え方自体に抵抗がある。「全部作らない」ので、工数を積み増すことをビジネスのゴールと考える彼らにとっては利益相反だ。
本来、アジャイルは「改善」によって不断に生産性を改善して工数を減らし、コストの低減を進めていくことを前提としている。そのような経験のないＳＩ事業者にとって、これはリスク以外の何ものでもない。
一方、情報システム部門は、これまで「人月単価×工数」で金額の妥当性を判断してきたが、アジャイル型請負開発ではそこが曖昧になる。金額算定の根拠が崩れてしまうからだ。成果物の品質や変更への柔軟性は、それ自体価値のあることだが、それをどのように金額として評価すればいいのかがわからない。また、情報システム部門は、エンドユーザーとＳＩ事業者との間で、優先順位の設定や頻繁な変更要求への対応などで、業務面での議論に深く関わりながら、その橋渡しを努めなければなりません。このような未経験の仕事が増えることへの抵抗も少なくはないだろう。
いろいろな障害はあるだろう。しかし、エンジニアは、ユーザーとのコミュニケーションを通じて、彼らの納得を肌で確認できる。また、改善の努力はエンジニアにとってスキルを磨くことであり、それが評価される。同時、原価を低減し利益率を高めることができる。そういう自分たちの努力によって、成果を確認することができるので、モチベーションは上がる。そうすれば、エンジニアも幸せな働き方ができる。
こちらから仕かけていかなければ、ユーザーを変えることはできないし、チャンスは生まれない。また、自らのスキルを磨く機会も訪れない。きっかけを作る努力が大切だろう。
なお、ここに紹介した方法は、決して机上の空論を描いた訳ではない。次回は、その事例を紹介する。
＊更新しました＊ 今週のブログ ---
専任の “「お客様の立場」責任者” を持つ
「なんで、俺たちが、そんなことしなきゃいけなんですか？」
ある社内プロジェクト会議で、ベテランのエンジニアが、営業の責任者にかみついていました。こんな不毛な議論を続けても、仕事がうまくすすむわけはありません。
なぜこんなことになるのでしょうか。どうすれば良いのでしょうか。
今週のプログは、そんなことを考えてみました。
【無料】イベント『受託開発ビジネスはどうなるか、どうすべきか』
来る8月27日(水)に、「納品のない受託開発」でおなじみのソニックガーデンの倉貫さんとトーク&ディスカッション・イベントを開催します。SIビジネスや受託開発まの課題、今後どうしてゆくべきなのかを話し合います。こちらの一方的なスピーチではなくご来場の皆さんを巻き込んだイベントにしようと考えています。
ほぼ、同じ時期にお互いに本を出版したことをご縁に開催することとなりました。詳しくは、こちらのFacebookのイベントページをご覧いただき、「参加する」ボタンを押して下さい。
Kindle版 「システムインテグレーション崩壊」
〜これからSIerはどう生き残ればいいか？
- 国内の需要は先行き不透明。
- 案件の規模は縮小の一途。
- 単価が下落するばかり。
- クラウドの登場で迫られるビジネスモデルの変革。
Facebookページを開設しています。「いいね！」やご意見など頂ければ幸いです。