STAY-FOOLISH.COM

インターネット業界に居るのですが、情報収集ばかりで、”発信” 出来て無いなぁと思い、一念発起してみました。

「失敗体験から学ぼう」一括請負でのアジャイル

      2016/05/24

ad_kijishita_pc

スポンサーリンク

なんとか、もっともっと楽しく、幸せな開発をしたいっっ!
とお考えのみなさま、こんにちは。
 

僕は受託開発を主な生業とする仕事を、会社員として凡そ10年。
フリーランスや仲間と興した会社として凡そ5年やってきました(一方で、発注側の企業で企画的なお仕事も5年程やった経験があります)。
 

その中で、ウォーターフォールでの開発や、SCRUM を中心としたアジャイルでの開発 を経験してきました。
 

それなりの数のシステム開発の案件を経験しました。
 

ここまで書いてみて、自身のウォーターフォール的な開発と、アジャイル的な開発の割合が気になってきたので、ザッと自分の職務経歴を眺めてみました。 

受注側としてのウォーターフォール的な案件の経験数は 17 件。アジャイル的な案件は 10 件くらいでした。
 

発注側に居た時は、ほとんどがウォーターフォール的な開発でした。
 

ちなみに、社会人になって5年程は、メンバーとしてプロジェクトに参画しておりましたが、それ以降は、ほぼプロジェクトマネージャーとして参画してました。
 

僕は自身の経験の中で、少なくとも今現在は、アジャイルのマインドと、SCRUM という、チームがアジャイルになる為のフレームワーク が一番好きです♪
 

ウォーターフォール+コマンドコントロール型の進め方よりも、アジャイルで自律的な進め方の方が、絶対に楽しいと思っていますし…

それに、「開発したシステム(サービス)の価値を最大化する」 ことを最上位の目的と設定するならば、SCRUM が一番適していると信じています。
 

また、SCRUM は、強いチームを作ることを助けてくれるフレームワークだと思うので、ここも気に入っているポイントです。 ただ、SCRUM で進めることは、想像を絶するくらい、とてもとても難しいのですが…。
 

この記事では、一括請負でのアジャイル的なプロジェクトでの失敗事例に的を絞り、何故失敗したのか?どうすれば失敗を減らせるのか について、自分なりに考えを整理したいとおもいます。
 

正直、このような失敗談をこうやって記事にすることはとても抵抗がありました。
 

ただ、自分自身の失敗談をちゃんと見つめなおし、次に向けて動き出したい!

という思いと、似たような状況で苦しんでいる方に少しでも役に立てばと思い、思い切って記事にすることにしました。
 

ご参考まで:ちなみに、SCRUM について全体像をサクッと知りたい方。
実際に導入しているけどイマイチ上手くいかないと言う方

僕が、とてもとてもお世話になっている、超オススメの本です。
 

随所で、師匠と弟子の会話形式でのQAがあり、これまた 現場で実際に起こりがちなテーマ が採用されていてるところもオススメポイントです。
    

アジャイルと 3 つの契約形態

先ずは、何はともあれこれが無いとスタートをきれない 契約に関するお話です。
 

一般的には、アジャイルに適した契約は、SES だと言われています。
 

ただ、運用保守や支援/人出し系の案件ではなく、一括でまるっとシステム開発を請け負う際の契約について、発注側企業が望む契約形態は、請負契約が大多数をしめており、更に開発の規模が大きくなればなるほど、SES で契約締結する事は難しくなると思います。
 

自身が発注側企業の企画者として働いていた時も「SES!?いや、意味がわからないですよね、何で受注者が何の責任も負わない契約にする必要があるのか!怒!」と言うような温度感であり、レベニューシェアでの契約を好む傾向が強かったです。
 

レベニューシェアは、ある条件が整えば、アジャイルでの契約形態として、僕は 1 番適していると思っています。
 

レベニューシェアの契約においては、サービス(システム)利用者へ提供する価値を最大化する事が発注側にも受注側にも求められますが、それは、アジャイルが目指しているところと一致しますので。
 

ただ、レベニューシェアでの契約は、受注側からみると、かなり敷居が高くなるはずです。
 

なぜなら・・・
  

システム屋さんには、開発のプロは居ても、いわゆる事業企画やサービス企画のプロは居ないパターンが殆どだと思います。
 

レベニューシェアの契約を締結する前に、先ず、実現しようとしている事業の分析(売上の見込みやリスクなど)から始める必要があります。
 

ココで失敗すると開発体制を維持する為に投資(主に人件費)したけど、サービスローンチ後に、閑古鳥が泣き、投資に対する十分なリターンが得られないまま資金がショートしてしまい、サービスを維持出来ない状況となり、投資を回収出来ないと。

こんな感じの、目も当てられない状況になるからです。
 

上記のことを考えると、残念ながら、やっぱり、現実的に多いのは、一括請負型の契約となると思います。
 

アジャイルで一括請負契約。
 

ここの時点でプロジェクトは、おおきなおおきな、リスクを持つことになります。
    

アジャイルと一括請負契約

アジャイルな開発が得意とするのは、開発するシステムの価値を最大化する為に、状況の変化にあわせてフレキシブルにシステムを創っていくことです。
 

なので、たとえば、ローンチ日程とシステム開発の予算を固定化し、開発するシステムの機能は、刻々と変化するビジネス環境と開発実績を鑑みながら取捨選択をしていくような流れが、アジャイルな開発には適していると思います。
 

一方で、一括請負型の契約においては、ローンチ日程とシステム開発の予算の固定化に加え、開発するシステムの機能も固定化されているパターンがほとんどだと思います。
 

プロジェクトの主要なパラメーター(機能、予算、スケジュール)全てを固定化するのか?しないのか?
と言う部分において、契約と開発プロセス(開発の進め方)が矛盾 してしまっていますよね。

おかしいですよね? 厳密に言うと、これから作る機能を固定化すると言う事は、かなり無理があると思っているのですが… システムって目に見えないですからね…
 

これだけ見れば、誰が見ても「そんなのはおかしい!」と気づくはずなのです。
 

なのですが・・・
  

1. 契約締結する人と、実際に開発する人が異なり このような矛盾が発生してしまったり。
 

2. この矛盾に気づいていながらも、開発するシステムの機能をしっかりと変更管理(契約時に定義していた機能と、そうではなく後から追加した機能の量の管理と対応)していける!きっと大丈夫だと思ってしまったり。
 

3. この矛盾に気づいていながらも、現場のお客さんとは「契約に縛られず、フレキシブルにやっていきましょう!」と握れている と思っていたり。
 

というような事情があり、「アジャイルで一括請負型の契約」が出来上がってしまいます。

スポンサーリンク


    

失敗プロジェクトの紹介

いよいよ、僕が数年前に経験した、失敗プロジェクトのご紹介です。

さすがに発注側の企業や、受注側の企業が特定されてしまうような内容は書けない為、ちょっと注意しながらご紹介させて頂ければと思います。

また、多少のフェイクを織り交ぜます。

ではでは、いってみましょう。

発注社は、超大手の WEB サービスのプロバイダーであり、新規事業立上げ に際し、事業のプラットフォームとなるWEBサービスを開発したいと考えた
 

およそ6ヶ月間の提案期間があり、受注側企業 10 社くらいのコンペとなる
 

提案担当者達は、最初は SES での契約を申し出るが、発注社より「この規模のシステム開発を SES で発注する事への社内承認がおりない」という理由で、SES を断念
 

提案担当者達は、発注社の担当の方より「僕も昔 SIer に在籍しており、アジャイル(SCRUM)のコンサルをやっていた事がある」という話や「会社からの無茶な要望追加は、僕がふせぐ」という話を聞く
 

提案担当者達は、提案書の作成、発注社の担当の方とのとても濃いコミュニケーション、機能の見積、プロジェクトが立ち上がった場合に備えメンバー集めの各種調整に加え、他案件のタスクもこなしつつ、時には徹夜もしながら対応する
 

プレゼンの直前に、提案の責任者であり、かつ受注後の PM をやると言っていた仲間が一身上の都合によりチームを抜けてしまう…
 

残されたメンバーは焦りに焦り、話し合う。このまま続けるのか?降りるのか?
 

提案チームの外からは…

「6ヶ月も複数人で提案しておいて、つまり、それだけのコストを掛けておいて、ここで降りるなんてあり得ない」

っという声も聞こえてくる
 

明日がプレゼンなのに答えが出ない…

焦る…

時間が欲しい。少し立ち止まって冷静に判断する時間が。
 

今、思うと、意地 と 過信 そして、誰に対するでも無い怒りが勝ってしまったのだろう、やらなきゃいかんのだ!と思い込んでしまう
 

プレゼンは、やることになった。1次のメインスピーカーは僕。
 

選考は三段階となり、全ての選考に通過した
 

そう、提案担当者達は上記のような状況の中「発注社に、アジャイルのマインド、詳細な進め方、メリット/デメリット」を十分に伝えきることが出来ないまま、一括請負でアジャイル的な進め方をするという提案をし、コンペに勝利し、契約が成立した
 

プレゼン当日は、良いことだけを言わないように特に意識した。

発注社に対するデメリットも出来る限り伝えた
 

しかし、それは書面には残っていなかった
 

プロジェクトの全体体制としては、システム受託開発社、特定分野に特化したプロダクトを提供する会社(x 6社)、デザイン会社それに発注社
 

プロジェクト初期の1ヶ月間は、アーキテクチャの開発、ストーリー収集とストーリーマッピングそして、開発環境の構築をした
 

2ヶ月目より、期間を一ヶ月と設定した開発を繰り返し行う
 

プロジェクトが始まると、プロジェクトに対するマインドからプロジェクトの細かい部分の進め方まで、ものの見事に 発注社の担当者や発注社の文化と、受注側のそれとのズレが明るみ となる
    

どうすれば失敗を減らせるのか?

実現不可能な計画やコミットメントの事は考えない。
〜中略〜「私たちは、いまここで分かっていることを元に計画を立てます。あなたにとって一番大事な目標を達成できるように、私たちは計画を変更します。プロジェクトが進んで新たな知識を得たら、それにプロジェクトと計画を適応させます。私たちからあなたへのお願いは、ビジネスの変化へ柔軟に適応することと、当初の計画を死守することとは矛盾した要求だと、きちんと理解しておいて欲しいということです。」

 

と「アジャイルな見積もりと計画づくり」の中で、MIKE COHN も言っています。
 

システム価値の最大化がトップレベルの目標であり、それを実現するのに一番適した開発の進め方が「アジャイル的なシステム開発」だとすると、その開発を 成功させる事が出来るか否かの全ては、この言葉に集約されている と僕は信じています。
 

初めてこの本を読んだ時は、この言葉に、おおきなおおおきな感銘を受け、身震いし、とても興奮したのを覚えています。
 

受注側企業は「アジャイル開発をすることで発注側企業に提供出来るメリットとデメリットについて真摯に伝え、理解してもらう」その上でアジャイル開発を行うのか行わないのか?を判断してもらう必要があると。
 

また、僕としてもう一つ重要視したいのは、受注側企業も 「発注側企業がちゃんと理解してくれているか?僕達はこの人達と一緒にやっていけるのか?」を判断する 必要があると思います。
 

上記 2 つの判断結果に「OK」を出せた場合にのみ、プロジェクトを始めるべきだと思います。
 

この 2 つの判断結果に「OK」が出せるのであれば、たとえ一括請負の契約においても、アジャイルに適した契約内容にて、両社で合意が取れるはずです。
 

決してどちらかが「NG」なのに、一時的なお金の欲しさ、社内評価の向上、その他いかなる理由 があったとしても、アジャイル開発プロジェクトを始めてはいけないはずです。
 

発注側企業も、受注側企業も、不幸になるだけです、悲しいかな、経験者(僕)は語るです。
 

もちろん、これはプロジェクト開始時点でのお話です。進めていく中でも色々と気をつけなければならない事は盛りだくさんです。
 

でも、最初の時点でのミスを、後から取り返せる。なんとかなる。

と思うのは、あまりにも馬鹿過ぎる思います。
残念ながら、これも、経験者(僕)は語るです。
 

 

孫正義さんも、孫の二乗の法則 の中で、そう言われていますが・・・
 

あと、1つ付け足すとすると 「ケチにならない」 という事です。
 

「せっかく、ここまでやったのに、今辞めたら、それらが無駄になる、掛けたコストはどうするんだ!?」
 

ビジネスにおいて、この考え方は、僕は “悪” だとおもいます。
 

熟考した上で、このまま続けたらジリ貧だ。

もっと大きいしっぺ返しを食らってしまう。

この可能性が高いと、当事者達が判断するのであれば…勇気ある撤退をすべき だと思います。
    

おわりに

同じ様な状況に居る方、厳しい判断をせねばならない状況にある方、そんなあなたに少しでもヒントとなれば、超絶に嬉しいです。
 

気が向いたら、このプロジェクトの「ふりかえり(KPT方式)」結果があるので、(そのままは出せませんが 笑)それも記事にさせて頂くかもしれません。
    

この記事を読まれたあなたにオススメの記事です

もし、よろしければ、下記の記事もあわせてど〜ぞ♪
 

なぜアジャイル開発が必要なの?

【アジャイル開発で学んだこと】アジリティ最大化の為の10のポイント

アジャイル開発における契約前のコミュニケーション

【小資本起業の奥義!?】LEANSTARTUPワークショップに参加してみた

 - 企画・プロダクト開発 ,