ソフトウェア開発（リーンとアジャイル） その２ からの続きです。
システム構築プロジェクトにおいて、ITベンダーを選定するステップは一般に、次のようなものです（図1）。
- ステップ1：要求事項をRFP（提案依頼書）にまとめ候補のITベンダーに配布
- ステップ2：候補のITベンダーが価格やスケジュールを含めた提案書を提示
- ステップ3：提案書を元に事業会社がITベンダーを選定
図1：一般的なITベンダーの選定プロセス
このようなITベンダーの選定プロセスは、事業会社における調達の客観性や透明性を確保するためには欠くことができないものです。RFPには、ウォーターフォールモデルを前提とした要求仕様（機能的な要件と非機能的な要件）を記載し、それを実現するシステムをできる限り安価に作り上げる、あるいは提案させるために、コンペによってITベンダー間の競争をうながします。
“お抱え”のITベンダーは真のパートナーたり得るか
ITベンダーサイドは、受注を目指して魅力的な提案書を作成しようとします。ですが、選定ポイントとして価格が大きな比率を占めるために、さまざまな工夫を凝らして原価を切り詰めようとします。
めでたく受注できたとしても、そもそも余裕のない予算なわけですから、プロジェクトが始動してから以降の変更要望には、追加費用を要求するか変更自体を拒否することで応じることになります。結果、発注者との間で相互不信を招き、ひいてはプロジェクト自体が予想外の失敗に終わるということが多いのです。
私の経験からすれば、このような発注プロセスである限り、事業会社がITベンダーと良好なパートナーシップを構築することは大変に難しいでしょう。
とはいえ、事業会社の多くは、いわゆる“お抱え”のシステムインテグレーターと取引しています。それが１社か数社に分割しているかは別にして、自社システムの初期構築を任せて以後、追加の開発や保守業務を依頼し続けているITベンダーです。
かつて、ある大手システムインテグレーターの幹部から、「（ITベンダーにとって）初期開発は、ほとんどが赤字になる。そこは諦めざるを得ないが、その後の追加開発や保守で利益が出せる」とお聞きしたことがあります。この話は業界の実情を正しく反映しています。
初期の開発では受注したいがために複数のITベンダーが競い合い、ウォーターフォールモデルによる手戻りも発生し、多くのプロジェクトが赤字になってしまう。ITベンダーのプロジェクトマネジャーにすれば、いかに赤字幅を小さくするかが腕の見せ所はなります。そうして一社独占状態になれば、高めの費用を提示し続けることで利益を出していくというわけです。
追加開発や保守で利益が得られる期間をできるだけ長くするためには、他のITベンダーに発注しづらい状態、つまり“ロックイン状態”を、できるだけ長く維持する必要があります。
軌道修正を歓迎できることがパートナーシップの鍵
そもそも事業会社とITベンダーのパートナーシップとは、どのような状態を指すのでしょう？筆者は「最終ゴールを共有できていること」「その関係を長く維持できること」「継続的に利益が確保できること」が最低限の必要条件だと考えます。
最終ゴールの共有とは、事業会社の目標であるビジネス面での成功を目指すことが、そのままITベンダーの利益にもつながるということです。ゴールが共有されるからこそ、パートナーの関係を長く維持できるわけです。
本連載では一貫して、リーンスタートアップ手法によるビジネスゴールの追求を訴求してきました。リーンスタートアップの鉄則は次の4つです。
- 鉄則1：仮説をできる限り低コストで素早く形にし、必要最小限の製品として顧客に提供する
- 鉄則2：製品が受け入れられるかどうかについて顧客からフィードバックを得る
- 鉄則3：フィードバックの結果を元に改善や軌道修正を繰り返す
- 鉄則4：そもそもの仮説が誤りであれば、ダメージが少ないうちに進路を変更（ピボット）する
成功への王道は、変更を恐れず、正しい方向への軌道修正を歓迎することです。このことをITベンダーと共有できるかどうかがパートナーシップ構築の鍵を握ります。それには、ITベンダーとの契約内容が重要になりますが、それは次回に触れるとして、パートナー候補のITベンダーは、どのようにすれば見つけられるのでしょうか。
規模よりも得意分野で絞り込む
当然のことながら、デジタルシフトのためのパートナーですから、そのための開発に必要な技術要素を得意分野に持つことが大前提です。図2に、デジタル化の対象分野と、それを実現する技術的な要素をおおくくりですが、まとめてみました。
図2：デジタル化の対象分野と技術要素
得意分野について、すでに付き合いがあるITベンダーに相談すれば、それが大手システムインテグレーターであれば必ず「当社も、それは得意としています！」と言ってくれるでしょうし、そのような部門や技術者を紹介してもくれるでしょう。
しかし筆者は、そのような受け身の姿勢では自社の将来を託せるだけのパートナーを得られる可能性は低いと考えます。要素技術のトレンドをきちんと理解し、それを実現してくれるITベンダーを、事業会社が主体的に動き、広く日本全国から探し出す必要があります。特にデジタルシフトのための開発領域では、ITベンダーの規模ではなく、得意分野で絞り込むことが重要です。
では、そのようなITベンダーは、どのように探せばよいのでしょうか？筆者がお薦めする一番の近道は、ITベンダー各社が出展するカンファレンスやセミナーに積極的に参加することです。
たとえばIoT（Internet of Things：モノのインターネット）に取り組むのであれば、「IoT カンファレンス」といったキーワードでネット検索するだけで、IoTをテーマに掲げる展示会が、毎月のように開催されているのが分かります。そこへ出かけて行って、展示内容を見学し、積極的に質問してみれば良いのです。
ITベンダーと対等に話せるだけの技術トレンドを知るべき
より小規模なセミナーであれば、「TECH PLAY」や「connpass」など、IT系のセミナーや勉強会に特化した情報サイトを活用しましょう。メールアドレスを登録しておけば、興味がある分野のセミナー情報をメールで知らせてくれます。
事業部門や企画部門の方にすれば、IT系のセミナーは技術者以外には敷居が高いと思われるかも知れません。ですが実際には、テーマに掲げる分野に強い技術者が、その技術を取り巻くトレンドを分かりやすく解説してくれます。逆に解説が上手くなければ、技術を十分に咀嚼し切れていないのかもしれません。
セミナー後の交流会にも積極的に参加するべきです。そこで質問すれば、当該分野を得意とするITベンダーの技術者とも知り合いになれます。これはと思う技術者がいれば、自社での開発上の課題などを気軽に相談すれば良いのです。
なによりも技術トレンドを自らが理解できるようになれば、ITベンダーとも対等に、かつ誠実に会話ができるようになります。このことはプロジェクトを成功に導くためにも不可欠な要素であり、パートナー探しにも、きっと役立つはずです。
「クラウド」「コンテナ」「DevOps」への取り組み状況も要チェック
契約内容を考える前に、ITベンダーを探す際には、もう1つ、気にしておいてほしいキーワードがあります。デジタルシフトに向けたアプリケーションの高速開発における要素技術として現在、「クラウド」「コンテナ」「DevOps（開発と運用の融合）」が非常に重要になってきています（図3）。クラウドについての解説はいまさら不要かと思いますが、残り２つは、まだまだ馴染みがないかもしれません。
図3：ソフト開発をスピードアップする基盤技術
コンテナは、アプリケーションの開発やリリースの効率を高めるために、サーバー仮想化よりも大幅に軽量化を図った基盤要素技術です。DevOpsは、システムの開発（Development）と運用（Operations）を組み合わせた造語で、両者を密接に連携させることで、ソフトウェアの構築からテスト、リリースまでを迅速・頻繁に、かつ安全に実行するための仕組みや活動を指しています。
クラウドはもちろん、コンテナとDevOpsもソフトウェアの開発サイクルを大幅に高速化するためには必要不可欠な技術です。これらの技術に積極的に取り組んでいるかどうかが、デジタルシフトのための開発を委託するITベンダー選定では重要な条件になります。眼鏡にかなうITベンダーが見つかれば、ソフトウェア開発の契約を結ばなければなりません。アジャイル開発に適したITベンダーとの契約は、どのようなものであるべきでしょうか。
一括請負契約はアジャイル開発には根本的に向いていない
ソフトウェアの開発契約は大きく、（1）一括請負型契約、（2）準委任型契約の２種類があります。一括請負型契約は、受注者がシステムの完成に責任を持ち、成果物を発注者に引き渡すことを約束する契約です。
この一括請負型契約は、要求仕様の提示、成果物の納入、検収という流れで契約が完結します。つまり要求自体の変更を前提としていません。変更があれば、ITベンダーは追加費用を請求することになります。正しい方向への変更によってビジネスゴールを追求するアジャイル開発には、根本的に向いていないのです。
一方の準委任型契約では、開発側は機能の完成義務および瑕疵（かし）担保責任を負いません。ただ開発側は、業務遂行にあたり専門家としての「善管注意義務（善良な管理者の注意義務）」を負っています。「善管注意義務」とは、開発側の業務品質が一般的な水準を下回わらないことを保証するものと考えて良いでしょう。
一括請負契約が向かないアジャイル開発では、準委任型契約を結ぶことになります。そのうえで、アジャイル開発にチューニングした契約を結ぶ必要があります。これを筆者は「ラボ契約」と呼んでいます。
ラボ契約でビジネスゴールと開発スピードの両立を図る
IT業界で準委任契約といえば「派遣契約ではない技術者常駐サービス」を指し、アジャイルのためのチーム開発とは異なるイメージで使われています。そのため筆者は、アジャイル開発について顧客と話す際には、ラボ契約あるいは「ラボ型開発」という表現を使うようにしています。
ラボ契約という表現は、これまでも中国やベトナムなどに開発を委託するオフショア開発業務において多用されてきました。そこでのイメージは「チーム単位による期間契約」というものです。
アジャイル開発におけるラボ契約は、たとえば「6カ月間のチーム単位での専属開発契約」と言えます。契約金額は月額の単金 × 期間で、単金はエンジニアのレベルにより異なります。開発場所はITベンダーの施設になることが基本です。法律的には準委任型契約ですから、成果物や完成に対する責任は負いませんが、業務品質に対する責任はあります。
こうした契約なら、仕様が変化することや、開発ずみの機能をスクラップ＆ビルドすることは契約上も、なんら問題はありません。ラボ契約、あるいはラボ型開発こそが、事業会社とITベンダーがパートナーシップを築き、アジャイルな開発や、それによる新しいサービスの提供を推し進めるための最善の方法と言えるでしょう。
ただラボ契約で絶対に誤解してはならないのは、「ITベンダーは受注者であるのだから、発注者の依頼にはすべて従うべき」ということではないことです。
顧客向けサービス画面の開発を例にとれば、デジタルマーケティングの手法によって効果を検証する担当者と、サービス画面上にあるボタンの色や配置を実装するフロントエンドの技術者が、プロダクトオーナーを混じえて、対等の立場で考え意見を出し、変更にトライすることが、より良いサービスを素早く作り出すには不可欠です。
“あるべき姿”としてのサービスプロダクトを追求するビジネスチームと、それを実装する開発チームが同じ立場に立ち、両者が活発にコミュニケーションを取りながらビジネスゴールを目指してこそパートナーシップが成立します（図4）。ラボ契約は、素早い変更を阻害しないためにあるのであって、主従関係を持ち出すのなら不要です。
図4：変化を恐れずゴールを追求するパートナーシップ
イテレーション単位で個別契約を結ぶ方法もある
筆者はかつて、ある事業会社とのシステム開発において、同社の規定により一括請負型契約以外での契約が許されないケースがありました。開発コストを資産として処理するか経費として処理するかの会計上の問題によるものです。
そうしたケースでは、開発単位（イテレーション）ごとに見積もりを出し、それぞれに個別契約を結ぶという方法を採りました。開発全体に対する基本契約を結んだうえで、開発スケジュールに従って、個別見積りと個別契約を繰り返すのです（図5）。
図5：スパイラル開発のための個別契約方式の例
この契約方法は、アジャイルとは考え方が異なりますが、反復型の開発という意味で「スパイラル型開発」の場合に時々見受けられます。スパイラル型開発は、最初に約束した全体機能を少しずつ開発し、リリースしていく開発方法です。
スパイラル型開発の場合、個別契約によって開発した機能は最終的には全体の総和に近いものになるので問題はありません。ただリーンスタートアップとアジャイルによるプロジェクトの場合は、以前のイテレーションで開発した機能を大幅に作り変えるようなことが頻繁に起こります。そのためイテレーション単位の個別契約をアジャイル開発で採用する場合は、個別契約の完成責任を問わないように、基本設計の内容を決めなければなりません。
※この記事は以前、Webメディア（（DIGITAL X（デジタルクロス） | インプレス社））に連載したものを、最近の自分の問題意識とともに手直ししてまとめ直したものです。もう一回続きがあります。
ソフトウェア開発（リーンとアジャイル） その４ に続きます。