先日の記事に書きましたが、香港で行われた国際学会のFSEにて論文のプレゼンテーションを行ってきました。
英語の論文を作成するにあたって、まずは日本語で論文を書いて、それを英訳したのち、改めて意訳して意図が通るように書き直す、という作業をおこないました。２度手間ではあったのですが、本来の意図を伝えるためにも、大変ですがそうしました。
ということで、私の書いた日本語の論文と、英語になった論文は、意図は同じでも、もしかしたら結構中身が違っているかもしれません。今回の記事では、私の書いたオリジナルの原稿を公開します。英語の論文と見比べてみると面白いかもしれません。
提出した英語の論文：
A New Business Model of Custom Software Development for Agile Software Development
以降は元にした日本語の論文：
目次
アジャイル開発のための新しい受託開発のビジネスモデルの考察と実践
- 倉貫 義人 (Kuranuki Yoshihito) ソニックガーデン (SonicGarden)
- 牛尾 剛 (Tsuyoshi Ushio)
- 安井 力 (Tsutomu Yasui)
- 山崎 進 (Susumu Yamazaki) 北九州市立大学 (University of Kitakyushu)
概要 (Abstract)
本稿では、ソフトウェア受託開発において変化に対応するためのアジャイル開発に向いている新しいビジネスモデルを提案する。スコープを決めて人月で見積りをする従来のビジネスモデルではアジャイル開発と齟齬があった問題に対して、月額定額にして毎週スコープを調整し実現するという継続型の新しいビジネスモデルにすることで解決することを提唱する。我々は、既に3年間で20件以上の事例を作ることに成功している。本稿ではそれらの事例の1つを紹介する。
Category and Subject Descriptors
D.2.9 Management: Software Process Models
General Terms
Management
キーワード (Keyword)
Agile Software Development, Lean Startup, Business Model, DevOps
1. はじめに
1.1 背景 (Background)
ソフトウェアを利用するビジネス環境は常に変化している。特に、インターネットを通じて消費者にサービスを提供するソフトウェアに求められるのは、ユーザのニーズにあわせた継続的なバージョンアップである。また、リーンスタートアップ[1]のように新規事業の立ち上げでは、ユーザからのフィードバックを受けて改修していくことが肝要となる。
そうした環境下で求められるソフトウェア開発のニーズは、継続的に変化に対応していくことである。変化に対応するニーズに応えるためにアジャイル開発[2][3]がある。アジャイル開発では、小さなスコープを短いサイクルで、分析・設計・プログラミング・テストまで並列に行い、ユーザが利用する環境へ展開していくことを繰り返す。動くソフトウェアを少しずつ開発していくことで、途中で変化する要件にも対応することが出来る。
アジャイル開発は、ソフトウェアを必要とする企業がエンジニアを雇用して内製する場合はうまくいくが、スコープを決めて見積りをする伝統的な受託開発のビジネスモデルとの相性は非常に良くない。顧客にとってソフトウェアは利用開始してからのフィードバックを受けての改修することが重要であるのに対して、受注する開発会社にとってソフトウェアは顧客に納品するまでが重要であり、お互いの利益が相反している。
アジャイル開発は変化に対応するための手法であるにも関わらず、スコープを決めて見積もってしまう受託開発のビジネスでは、変化に対応していくことが困難となる。あらゆる企業がエンジニアを雇用できる訳ではないため、アウトソースする手段を考えなければいけないが、スコープと納期を決めた受託開発ではアジャイル開発はうまくいかない。
そこで、我々は受託開発のビジネスモデルから変えてしまうことで、受託開発であっても変化に対応したいソフトウェア開発のニーズに応えることが出来ると考えた。本稿では，我々の成果を記述した著書[4]を元にして，問題点と解決アプローチの本質を紹介する。
1.2 目的 (Purpose)
従来のスコープを決めて見積りをする受託開発のビジネスモデルでは、変化に対応するためのアジャイル開発の適用が困難だった。本稿では、アジャイル開発に向いている受託開発の新しいビジネスモデルを提唱する。
1.3 アプローチ (Approach)
新しいビジネスモデルによって、従来のスコープを決めて見積りするビジネスモデルに起因してアジャイル開発を困難にしている問題を解決する。新しいビジネスモデルでは、終わりを決めない月額定額にすることで見積りなく継続的な開発を行うことを実現しつつ、開発会社にとってもうまみのあるビジネスを実現する。
1.4 構成 (Organization)
本論文の残りの構成は、第２章でその新しい受託開発のビジネスモデルについての説明し、第３章では適用した事例について紹介し、第４章で今後の展開について考察し、最後に第５章でまとめる。
2. 新しいビジネスモデルの提案
2.1 解決したい問題
我々が実現したいことは、変化に対応するアジャイル開発に向いている新しいビジネスモデルの提案である。従来のスコープを決めて見積りをする受託開発のビジネスモデルで、アジャイル開発を行って変化に対応していこうとする際には、以下の３つの問題があった。
- 沢山の人手をかける問題: 少数精鋭で分業を減らして効率化を図りたいが、人月で見積りをすると開発会社はなるべく多くの人手をかけようとしてしまう
- 無駄な機能を作る問題: 使われない無駄な機能を作らないようにしたいが、スコープから見積もる場合だと一度に沢山の機能を作ろうとしてしまう
- 改修コスト増大の問題: 運用開始後も継続的に開発を続けていきたいが、納品後の都度の見積りをして改修していくとコストは非常に高くなってしまう
スコープから金額を決めるビジネスでは、受注する開発会社が重視するのは、ソフトウェアそのものの有用性よりも、最初に決めたスコープを守ることであり、そのことは顧客にとっての利益と相反する。我々は、これらの問題を引き起こす引き金となっている要因は、”収めて終わり”のビジネスモデルそのものではないかと考えた。その象徴が”納品”と”納期”である。
我々は受託開発から”納品”と”納期”をなくすことで、これらの問題を解決できるのではないかと仮説を立て、新しい受託開発のビジネスモデルを考案した。
2.2 新しいビジネスモデルで解決
我々の考案したビジネスモデルのポイントは以下の２つである。
- 月々の定額払いとする: スコープから金額の見積りを行うのではなく、毎月決まった金額で開発と運用を行う
- 毎週スコープを調整する: 人月のようにかけた時間は関係なく、毎週スコープを調整して開発と運用を行う
新しいビジネスモデルでは、必要最小限の機能から動くソフトウェアを開発していく。開始から２週間ほどで、顧客が確認できる環境で運用を開始する。毎週のミーティングと開発を繰り返していき、３ヶ月程度でエンドユーザ向けにリリースを行う。リリース後も、変わらず開発と運用を続けていく。顧客にはソースコードを渡すことはせず、任意のクラウド上で運用し続ける。
１つの顧客に対して１人のエンジニアが担当し、要件の検討から設計、プログラミング、テスト、運用までの全ての工程を行う。ただし、エンジニアはその顧客だけの専任ではなく、複数の顧客を受け持っている。顧客からみれば、月々の決まったコストがかかるのでエンジニアを雇用している状態に近いが、自社で採用や教育を行う必要がないため、確実に優秀なエンジニアの力を借りることができる。それはまるで、弁護士を雇用せずに顧問として契約するのに似ている。
開発中でもリリース後でも、いつでも仕様変更に応じる。月額定額なので見積りもなく、優先順位が変わるだけである。エンジニアはその仕様変更にかかるコストを下げるように、常に保守性を高くするよう開発を行っている。担当のエンジニアがひとりで開発から運用まですべての工程を担当するので、引き継ぎに必要となるドキュメントを残すこともしない。
エンジニアは顧客のところへ赴いて働くことはなく、働く時間を約束するものでもない。その代わりに、新しい機能や改修のための開発を続けることと安定した運用を約束する。顧客にとっては、エンジニアをマネジメントする必要がなく、確実に成果を得ることができる。顧客が満足しない状態が続けば、月単位で契約を終了することもある。それがペナルティになる。エンジニアにとっては、技術力を磨き生産性を高めれば、より多くの顧客を担当することができ、そのことは利益にも直結する。
このようなアプローチにより、次のように前述の問題が解決される:
- 沢山の人手をかける問題: 人月のようにかけた時間ではないので、開発にかける時間を増やすよりも効率化にインセンティブが働く
- 無駄な機能を作る問題: 月額定額であるため、沢山の機能つくることよりも無駄なコストをかけずに費用対効果を高めることで開発会社にも利益となる
- 改修コスト増大の問題: 月額定額の契約がずっと続くため、エンドユーザへのリリース後であっても変わらずに見積りも追加料金もなく対応できる
新しいビジネスモデルにすることで、顧客と開発会社の利益の相反することがなくなり、共通のゴールに向かって開発をすることが出来るようになる。
2.3 開発プロセス
図1 は本ビジネスモデルでの開発プロセスである。
新しい受託開発のビジネスモデルをより効果的に実現するため，次のように具体化する。
- 無償の相談期間での顧客のビジネス目標の共有 (図1中では○○)
- 無償のお試し期間での開発パフォーマンスの確認 (図1中では○○)
- 1週間ごとの反復開発と定期ミーティング (図1中では○○)
- 開発と運用の一体化 (図1中では○○)
2.3.1 相談期間
本ビジネスモデルでは、一度に大きな開発を行うことがないため、契約期間が長く続くことの方が価値がある。顧客の事業が続かずに短期間で終わってしまうことのないように、開発を始める前に見極めを行う相談期間がある。相談期間では、そもそも何を作るのかを顧客と共に検討する。顧客の事業計画書がインプットとなり以下の2点を確認する。
- ミッション: なぜ作るのか
- ビジョン: 何を実現したいのか
ミッションとビジョンがはっきりしている事業は成功する確率が高い。約3ヶ月でエンドユーザ向けにリリース出来る内容まで設計することが出来れば、相談期間は終了である。
2.3.2 お試し期間
本ビジネスモデルでは、エンジニアが毎月成果を出すことを約束するが、どれだけの成果を出すか顧客は事前に知ることが出来ない。その顧客の不安を払拭するため、開始から”1ヶ月間”は無料で開発を行うお試し期間がある。顧客が、お試し期間の成果で満足した場合は、2ヶ月目からが正式な契約開始となる。
お試し期間では、最初の2週間でソフトウェアの骨格となる部分の開発を行う。ドキュメントなど用意せず最初からプログラミングを行って、顧客が動作確認できる環境まで用意する。3週目以降は、毎週の打ち合わせと開発を繰り返す形で、追加改修を行う。
2.3.3 反復開発
毎週の打ち合わせがあり、その場で顧客とエンジニアが一緒に設計を行う。設計を行うのは次の1週間でプログラミングを行う分だけである。打ち合わせ後から1週間は、エンジニアは自分のペースで開発する。次の打ち合わせでは、1週間で開発した内容の確認を行ってから、また次の設計を行う。これが契約期間の間ずっと続く。
顧客が毎週の打ち合わせで動作確認を行っていき、動作確認の終わった動くソフトウェアを仕様とする。ソフトウェアとドキュメントの二重管理を防いでいる。
開発開始から約3ヶ月以内にエンドユーザ向けにリリースする。リリースに大きなコストもかからず、リリース後も毎週の打ち合わせと開発は続く。約3ヶ月の単位で、ロードマップの見直しを行い、3ヶ月先の見通しを立てる。本ビジネスモデルでは、必ず完成させるという約束はしないが、顧客の事業にとって重要なタイミングは把握して、間に合うように何を作るか設計を行う。
2.3.4 開発と運用の一体化
お試し期間の2週目から顧客が動作確認するための環境の運用を開始し、約3ヶ月目のエンドユーザが利用するための環境の運用を開始する。顧客が動作確認する環境は、他の案件と共通で使える環境を用意している。エンドユーザが利用する環境は、顧客ごとに設計を行う。
継続的に開発と運用が並行に進む。円滑に進めるために、ソースコード管理にgit/githubを利用したり、テストを自動化したり、継続的にリリースできるようにしている。
3. 新しいビジネスモデルを適用した事例
この新しいビジネスモデルを適用した事例を紹介する。我々は、既に3年間で20件以上の事例を作ることに成功している。その中でも、特に長い関係を築いている企業である株式会社AsMamaでの事例を紹介する。
3.1 採用するに至った動機
株式会社AsMamaは、パソコンや携帯電話を使って、顔見知りの母親同士が安心して子どもの送り迎えや託児を頼り合う「子育てシェア」というサービスを展開している。子育てを支援してくれる人がいることで自己実現できる人と、支援することで自己実現できる人を両立させる仕組みを社会のプラットフォームとして広めることをミッションとしている。
インターネットを介して、子育てを支援する側と支援を受けたい側のマッチングをするサービスであるため、その事業にソフトウェアは必須であるが、AsMamaの社内にはエンジニアがいなかったため、以下の２つの選択肢を検討した。
- エンジニアを採用する
- ソフトウェアを外注する
エンジニアの採用は、エンジニアのスキルや能力の見極めをすることが困難であり、優秀なエンジニアを採用することが出来なかった。採用したとしても、エンジニアの評価と教育が難しいことから、この選択肢は諦めた。
ソフトウェアを外注するためには、納品を行うビジネスモデルの開発会社は、スコープを決めることを求めてくるが、新規事業であるため、すべての機能を事前に決めきることは不可能であることから、この選択肢も諦めた。
AsMamaが求めていたニーズは、そもそも何を作るのかという点から一緒に検討し、一度に仕様を決めて開発をして納品で終わるのではなく、一緒にサービスを成長させていってくれるパートナーであった。そのニーズに対して、本稿の新しいビジネスモデルが解決できると考えられたため、取引を行うことになった。
3.2 採用した結果
AsMamaとは2012年8月から相談期間が始まった。当初は、AsMama側はSNSに近いものをイメージしていたが、本来やりたかったことを聞き出して、共に検討した結果、マッチング機能が中心であり、必要最小限のマッチング機能からリリースすれば良いことがわかった。
2012年の12月からは、お試し期間として開発を始めた。お試し期間では、最も肝である子育ての支援して欲しい側のユーザが、支援者の一覧から選ぶことの出来る画面から作ることになった。お試し期間の間に、その機能を作り上げ、ブラッシュアップとして、地図上に支援者をマッピングして視覚的に選ぶことが出来るところまで行った。
AsMamaは、お試し期間での打ち合わせの進めかたと、実際に動くソフトウェアでの動作確認に満足したため、2ヶ月目以降の契約に進んだ。別の事例では、お試し期間での成果に満足がいかず、契約に進まないケースもあった。
2012年4月にエンドユーザの利用開始が始まった。ベータ版とすることで、限定的なユーザに利用してもらい、フィードバックをもらうことにした。そこで出たフィードバックを受けて、継続的に改修を行い、ユーザの数も増やしていった。本ビジネスモデルにしたことで、ユーザの声にあわせて、本当に必要な機能から作っていくことが出来た。
2014年6月現在で登録ユーザ数は1万人に達し、その数は今もまだ拡大を続けている。その裏で今も開発と運用は継続的に行っており、ソフトウェアの規模にあわせて、エンジニアを2人体制に増援して開発も行っている。
これにより本ビジネスモデルが、顧客の事業とユーザの声にあわせて変化に対応していけることと、顧客の事業の成長にあわせて我々も成長していけることの実績として残すことができた。
4. 考察
本稿で紹介した新しい受託開発のビジネスモデルで応えられるニーズは、従来の納品するビジネスモデルとは大きく異なっている。つまり、我々は解決の手段を変えたのではなく、捉える問題意識を変えたと言える。その違いは下記の通りである。
- 納品をするビジネスモデル：
- 要件と納期が確定しており、一度に開発してしまいたい
- 「ソフトウェアの完成」をゴールとする
- ウォーターフォールの開発プロセスが向いている
- 本稿でのビジネスモデル：
- 要件の予測が困難で変化していくため、開発を続けていきたい
- 「ビジネスの成長」を目指している
- アジャイル開発が向いている
このように、対象とするニーズが異なるため、ビジネスを行うマーケットも違ってくる。ソフトウェアのビジネスをする際の業態を、オーダーメイドで作るかどうか、納品をするかどうか、という２軸で分類してみたものが、図2となる。
日本においては、この左上のマーケットはまだ未開拓であり、これから広がっていくと考えられる。それは、既に我々の取り組みが業界全体で大きく注目され、実際に既に多くの引き合いを受けていることからの考察である。このマーケットでは、少数でも優秀なエンジニアを抱えていることが強みとなる。
本ビジネスモデルに取り組むにあたり、いくつかリスクがあり、我々はその対策を行ってきた。
- 最初にスコープを決めて納品してほしい顧客をどう避けるか
- 担当するエンジニアが違う中で品質を保つためにはどうするか
- 顧問で担当するエンジニアがいなくなったときにどうするか
- 優秀でないエンジニアを採用してしまうことをどう避けるか
ワークショップでは、この新しい受託開発のビジネスモデルについて、以下の２点について議論したい。
- 本ビジネスモデルにおける上記以外のリスクは何か、その対策として何があるか
- 本ビジネスモデルの日本市場以外での可能性について
リスクの対策については、我々の３年間の経験から取り組んだことを、ワークショップの際に紹介したい。
5. おわりに
本稿では、変化に対応していくためのアジャイル開発を、受託開発のビジネスの中できちんと効果を発揮させるためには、技術やマネジメントといった観点からアプローチではなく、そもそも伝統的な商習慣である納品を行うビジネスモデルをやめて、新しいビジネスモデルにする必要があることを示した。
そして、受託開発でもアジャイル開発に向いている新しいビジネスモデルを提案した。その新しいビジネスモデルを導入した事例を紹介をすることで実績とした。リスクヘッジの観点と今後の展開という部分がワークショップで議論したいポイントである。
謝辞 (Acknowledgement)
本稿の執筆が出来たのも、新しいビジネスモデルの価値を認めてくださった多くのお客さまのご理解とご支援、そして現場で実践してくれている株式会社ソニックガーデンのエンジニアたちがいてこそと、心から感謝しています。
参考文献 (References)
- [1] Ries, E., 2011. The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Business. Crown Business, New York.
- [2] Beck, K. et al., 2001. Manifesto for Agile Software Development. available at http://agilemanifesto.org.
- [3] Beck, K., 2000. Extreme Programming Explained: Embrace Change. Addison-Wesley, Reading, MA. Business. Crown Business, New York.
- [4] Kuranuki, Y., 2014. Nouhin wo Nakuseba Umaku Iku: Sofutouea Gyokaino “Joshiki” wo Kaeru Bijinesu Moderu. (In Japanese) (No Deliver: A Business Model Changing Business Custom of Software Developer.) Nippon Jitsugyo Publishing, Tokyo, Japan.
