受託開発におけるアジャイルに限界を感じた私が、「納品のない受託開発」を始めるまで - 倉貫義人の「はじめてのアジャイル」

Agile Journeyをご覧のみなさん、はじめまして。株式会社ソニックガーデンの代表をしている倉貫義人と申します。
私はもともと大手システム会社でプログラマとして働いていました。そのとき出会ったアジャイル開発に魅了され、これこそ自分にとって理想の姿であると確信し、それ以来アジャイル開発を広めるための様々な活動を社内外で行ってきました。

最終的に、本当に自分の理想とするソフトウェア開発と、それを実現する組織をつくるためには、自ら会社を経営する立場になるしかないと考え、起業することになりました。そうしてできたのが株式会社ソニックガーデンです。

ソニックガーデンでは「納品のない受託開発」というサービスを提供しています。従来的な受託開発から、そもそものビジネスモデルを見直したことで、今では「アジャイル開発」を意識せずとも、自然とそれに取り組める組織として機能しています。

思い返すと、私のアジャイル開発との関わりは芸道や武道で示される修得の段階、いわゆる「守破離」の過程をたどってきたように思います。いま私とソニックガーデンの仲間が取り組む「納品のない受託開発」は、いわば最終的に至った「離」の段階です。では、私が実践してきたアジャイル開発の「守破」とは。私がアジャイル開発と出会い、学び、実践してきた、これまでの足跡を振り返ってお伝えします。

現場は疲弊、でも上流は平静。SIerで直面した課題の解がXPだった

今は経営を仕事にしている私ですが、小さな頃にプログラミングに触れてその楽しさに目覚め、その後、進んだ大学の研究室では仲間と共にゲームを制作し、当時ちょうど登場したばかりのインターネットで公開する活動をしていました。

自分たちでアイデアを出し合い、設計してプログラミングし、公開したらインターネットを通じて多くのユーザから反応がもらえて、また新しいアイデアを実装していく。こうした開発のサイクルがとても楽しく刺激的で、昼夜なく没頭して取り組んでいました。このとき経験したソフトウェア開発は、私にとっての原体験であり、同時に理想の姿になりました。

その後、大手のシステム会社に新卒で入社することになりますが、いざ現場で働き出すと、私が学生時代に体験してきたソフトウェア開発とは大きく様相が異なることに気付きます。上流工程を設計するシステムエンジニアと下流工程で実装するプログラマは別だとされているのです。同期たちは、こぞってシステムエンジニアを目指し、プログラミングに興味を持つものは殆どいませんでした。

なまじプログラミングできた私は下流工程に配属され実装に携わりますが、上流工程で決められた仕様書に従うだけで、そこに面白みを見出せず、おかしな仕様であっても上流工程に戻すことはできないことに理不尽さを感じていました。なにより、開発が無理なスケジュールで進行しており、毎日がとてもハードで疲弊する日々でした。

ご存じかとは思いますが、こうした開発の仕方はウォーターフォールと呼ばれており、下流工程になるほどスケジュールなどの皺寄せがかかり大変な状況になりがちです。一方で、遡って上流工程の状況を聞いてみれば、さほどトラブルもなく進んでいたというのです。この工程の一方通行と分断に、私は強い憤りと疑問を覚えました。

そうした問題意識を持った私が、2000年にご縁があって平鍋健児さんと出会い、彼に教わったケント・ベック著の『エクストリーム・プログラミング（XP）入門』(第一版) を読んだのです。そこに書かれていたアジャイル開発の源流のひとつであるXPは、まるで自分が学生の頃に没頭していたソフトウェア開発のようで、「自分のことが書かれているようだ！」と感銘を受けたのでした。

プログラミングこそがソフトウェア開発の根幹であり、プログラマを中心に据えたソフトウェア開発というXPのコンセプトは、まさしく自分の理想とする姿でした。大手システム会社の中でプログラマ、つまりマイノリティとして疎外感を感じていた自分にとって、理想とする考え方、やり方に「XP」という名前が付いていて、書籍として出版されていることに大いに勇気をもらえたのです。

XPを忠実に取り組む。アジャイルを実践できる現場に、自ら飛び込んでいく【守の段階】

XPに出会い衝撃を受けた私は、矢も盾もたまらずXPを実践するべく取り組み始めます。しかし、当時の私はまだ入社２〜３年目くらいの若造です。プロジェクトの一員として貢献はできても、開発プロセスやチーム全体に影響を与えられるほどの経験も影響力も持ち合わせていませんでした。

そこで、まずは自分ひとりでも取り組める実践から始めました。テストファーストプログラミングの考え方で開発し、リファクタリングを徹底しました。先々の心配をして無駄につくり込むことを避けるYAGNI（You Ain't Gonna Need It：機能は、その機能が実際に必要になるまでは追加しない、というXPにおいて提唱された考え方）も取り入れました。もちろん、これだけでXPを実践したとは言えませんが、私にとっては大きな一歩でした。

その後、社会人4年目の頃に大きなチャンスが舞い込みます。金融系のシステム開発で開発リーダーを担うことになったのです。難易度の高いシステムではありましたが、そこまで規模が大きくないこともあり、まだ配属されたばかりの新人たち数人をメンバーにしたプロジェクトを任されたのです。

私はここぞとばかりに、XPを全面的に導入します。ただし、マネジメント経験もない当時の私でしたから、ケント・ベックのXP本を擦り切れるほど読み込み、本に書かれていることとまったく同じやり方を真似して取り組みました。まさに、守破離における「守」の取り組みです。結果、「顧客を巻き込む」までは難しかったですが、開発チームはXPっぽいやり方ができたように思います。

私にとって初の本格的なXPを実践したプロジェクトは、一応の成功を果たしました。そして、初めての実践を通じて、さまざまな課題や学びも得られたのです。たとえば、プログラムの品質に難があって夜中に私が全部直してしまいメンバーのやる気を奪ってしまったり、ペアプログラミングで集中しすぎて燃え尽きる人が出てしまったり……。なお、このとき得た学びは「XPアンチプラクティス」としてまとめましたが、後にソルトレイクで行われたアジャイルカンファレンスで平鍋健児さんと共に発表することになるのです。

「XPアンチプラクティス」の資料はいまもオンライン上で閲覧可能だ

わざわざ海外まで行って自分の事例を紹介したのには、理由がありました。XPに熱狂していた若かりし私は、社内で仲間を募ろうと勉強会など企画するも、なんと共感してくれる人はゼロ。こんな状態に絶望し、XPユーザ会という社外のコミュニティに参加するようになっていました。コミュニティでは、今はマイクロソフト本社で活躍されている牛尾剛さんをはじめ、多くの先輩や仲間たちの活動や発信から大いに刺激を受け、自分自身でも情報発信やコミュニティ運営に取り組むようになっていたからです。

一方で、社内では引き続きアジャイル開発を実践していくために、炎上プロジェクトに飛び込むこともしてきました。ある種、救世主のような立ち位置で参加できれば、新しい取り組みも導入しやすいからです。その際は忌避感を持たれないよう「ペアプログラミング」などのアジャイル開発の言葉を使わないことが重要でした。なぜなら、大事なことはプロジェクトの成功であって、アジャイル開発の導入ではないと気付いたからです。

自分の立場を変えて、アジャイルを追求。しかし受託開発での難しさに直面【破の段階】

アジャイル開発に拘泥しないことで、プロジェクトの成功に素直に向き合えます。こうした「手段としてのアジャイル開発」を徐々に使いこなせるようになってきたころ、私に転機が訪れました。当時いた会社として初の研究開発に近い部門である「基盤技術センター」が設立され、社内外での活動の実績が認められたのか、その最初のメンバーに最年少で選ばれたのです。それまで会社業務においてはアンダーグラウンドで行ってきた私のアジャイル開発の普及への取り組みが、会社公認になった瞬間でした。

そのころから、私はプログラマからプロジェクトマネージャ、さらには営業までこなすように立場を変えていきました。アジャイル開発のプロジェクトに取り組むうえで、従前のように、開発チームの中だけでアジャイル開発だと叫んでも、それはいわば「ごっこ遊び」のようなものです。本当に理想とするアジャイル開発を実現するためには、顧客を巻き込むことが欠かせないからです。

「顧客を巻き込んだアジャイル開発案件」を実現するためには、より上位の立場で、座組からつくる必要がありました。しかし、そんなことは、誰もやってくれません。だからこそ、根っからのプログラマだった私が、いよいよ覚悟を決め、立場を越境させマネジメントやビジネスに取り組むようになったのです。その甲斐もあってか、最初は数人だったチームは徐々に大きくなり、やがて20人規模にまで成長しました。私も管理職となり、アジャイル開発を推進するセクションを担うことになりました。

当時の私にとってアジャイル開発は、本に書かれた通りにやるものではなく、プロジェクトの状況に合わせてカスタマイズしていくものになっていました。守破離でいう「破」の段階だったといえるでしょう。私に任されていたセクションでも、自分たちでアジャイルという言葉をことさら強調もせずとも、社内の周りから「倉貫流の開発」と認識されるようになっていきました。

現場では「守」の段階よりも、さらに豊富な実践に取り組んでいます。たとえば、テスト駆動開発をベースにした独自の開発メソッドで運用したり、いまで言うモブプログラミングのような形でチーム全員で実装する、などです。また、ビジネス的にはウォーターフォールの上流工程を「試作工程」と呼び、プログラミングできる人材も巻き込んでいく体制をつくり、「実態としてのアジャイル開発」を実践できるようになっていたのです。

そうして受託開発の中でもアジャイル開発に取り組んできましたが、どうやっても越えられない壁に直面します。それは、「要件定義して決めた機能一覧で受発注する」というビジネスにおいては、最終的にはすべての機能をつくって納品しないと顧客に検収してもらえず、開発会社としては売上がたたないという、ビジネス構造とアジャイル開発の大きな齟齬でした。

いかにアジャイル開発で顧客とコミュニケーションを重ね、本当に必要なものを少しずつリリースする、ということを繰り返しても、最後には最初に決めたものを一括で納品しないと、ビジネスとして成立しません。こうした壁に直面したことで、一括請負の受託開発のビジネスモデルにおいて、アジャイル開発を追求することは本質的には不可能なのだと、私は思い至ったのです。

ビジネス構造を越えたチャレンジ。社内システム開発から「納品のない受託開発」へ【離の段階】

私が受託開発でのアジャイル開発に絶望していたのは、折しも社内では巨大プロジェクトが動き出していたころでした。私のチームメンバーも、その大半が巨大プロジェクトへ異動となり、チームは解散することになりました。意気消沈もありましたが、これを契機に、私は受託開発から足を洗い、会社の社内システム開発に取り組むことにしました。

研究開発の一環という位置付けでしたが、私は自社内の技術者同士の情報交換を促すサービスの開発と展開を行いました。いわば社内向けの情報系システムですが、仕様の策定からプログラミングまでをすべて、外部のリソースを一切使わずに、チーム解散後に残された若者一人と私の二人だけで行いました。マネージャになっていた私にとっては久しぶりのプログラミングでした。

その後、ベータ版のような粗い状態から社内提供を始めましたが、社内システムにもかかわらず招待制でユーザを募ったおかげで、システムを使ってくれるのは「熱意のあるユーザばかり」という状況になり、多くののポジティブなフィードバックが得られました。ユーザである社員たちからのリクエストを受け付けながら、毎週のようにバージョンアップを繰り返すことで、私たち開発者とユーザの関係は良好なものになり、楽しいだけでなく生産的なプロジェクトに成長してくれたのです。社内システムの内製には、アジャイル開発が非常に有用であるという知見を得ると同時に、これこそが私の望むアジャイル開発だったと気付くのでした。

社内システムは波に乗りましたが、一方で、私はある危機感を持っていました。いかに評判がよくとも、研究開発の部門で社内向けの開発しているだけなので、緊急性の高いプロジェクトにまた人を持っていかれるリスクが常に存在しています。社内システムがうまくいったことで再びチームに人が増えて、せっかく素晴らしいアジャイル開発チームができたのに、また会社の都合で解散させられることは避けたかったのです。

そこで私が考えたのは、その社内システムをベースにした新規事業企画を立ち上げて、自分たちで稼げるようになることでした。とはいえ一部門の管理職でしかなく、まして新規事業立ち上げの経験などないので、苦労は非常に大きかったですが、さまざまな人たちの協力も得ながら紆余曲折を経て、最終的には社内ベンチャーとして独立採算型の組織ができあがったのです。そのとき、私たちの組織に付けた名こそ「ソニックガーデン」です。2009年のことでした。

そこから2年間は、B2Bプロダクトを提供するスタートアップとして活動を続け、新規事業の難しさに直面しつつも、仲間と共に困難を乗り越え、なんとか黒字化の目処が立ちます。困難も多数ありましたが、それらも経営者としての得難い経験でした。そして、さらに未来のことを考えた時、いまのチームで一緒に仕事をしていきたいと決意し、生殺与奪権を会社ではなく自分たちが握るべく、チームと事業ごと買い取って独立を果たすのです。そうして誕生したのが株式会社ソニックガーデンです。

独立した私たちは、プログラマを一生の仕事にできるような会社をつくりたいというビジョンを持ちました。それも一括請負の下請けではなく、決められたものをつくるだけのプログラミングでもなく、言うなれば私たちが理想とするアジャイル開発を体現し続けようというビジョンです。そのために考え出したのが月額定額で顧問型のビジネスモデル「納品のない受託開発」です。顧客と開発者、開発と運用を分断してしまう「納品」をなくせば、顧客と私たちは同じゴールを目指すチームとなって、不確実さにも柔軟に対応していくことができる。こうした状態になれれば、もはやアジャイル開発を意識せずとも、自然とアジャイル開発ができるようになると考えたのです。

アジャイル文化をもつ組織づくりと、アジャイル開発の本質

「納品のない受託開発」を始めた当初は、業界の多くの人たちから応援だけでなく疑問視や批判などもありました。しかし、それから12年と数ヶ月の月日が経ったいまも、私たちのビジネスモデルは継続しており、これまで100社以上の顧客との事例を得てきました。5人で始めた会社でしたが、今は創業メンバー全員を含む、60人を超える組織になりました。

このビジネスモデルを通じて、私たちが得たのは、「アジャイルという文化」だと感じています。顧客と一体となって開発を進めていくなかで、アジャイルは、もはや私たちの組織に文化として根付いています。アジャイル開発は会社の仲間たちにとっては当たり前のことであり、おそらく意識すらしていないでしょう。社外の方たちから見たらアジャイル開発をしているようでも、なかで働くプログラマたちにとっては、普段通りの仕事でしかないのです。

私のアジャイル（XP）との出会いから四半世紀が経ちましたが、最初は忠実に従って取り組んだ「守」の段階があり、ビジネスの成功のためにカスタマイズする「破」の段階があり、今はアジャイルを意識せず取り組めるような「離」の段階までたどり着きました。ここまでは順風満帆ではなく、ときには絶望することも、アジャイル開発から離れることも、回り道をすることもあったからこそ辿り着けたように思います。ようやくアジャイルの世界で言われる”Don’t just Do Agile, Be Agile（アジャイルをするな、アジャイルであれ）”となれたのかもしれません。

私たちソニックガーデンがスローガンとして掲げる言葉は「一緒に悩んで、いいものつくる」です。受託開発であっても、もちろん内製開発であっても、ソフトウェア開発において大事なことは、ただ決まったものをつくることだけでなく、何をつくるべきか、どうすれば良い成果につながるのか、という根本からプログラマも一緒に考えることです。

ビジネスや経営には正解がなく、経営者やプロダクトの責任者は、ときに「何をつくるべきか」に悩むこともあるはずです。私たちプログラマはそうした悩む人たちと伴走し、一緒に悩みたいと願っています。ともに悩み、答えを模索するからこそ、本当に良質なソフトウェアがつくれるし、テクノロジーやイメージの実現に長けたプログラマという存在が一緒に考えることで、事業やサービスにとって、より良い一手を導き出すことができると信じています。

最後に、ひとつ私見を。私の考えるアジャイル開発の本質は「未来の結果を確約しないこと。その代わり、いまベストを尽くすこと」です。将来のことを約束して、それを達成するためのマネジメントはウォーターフォール的な発想です。対して、未来の不確実さを受け入れていくためには、いまにフォーカスし続けていくことが重要です。「不確実さ」は悪いことだけでなく、「想像するより良い未来」も含んでいます。最善の意思決定と行動を積み上げていくことこそが、良い未来につながっていくのです。

ソフトウェア開発にかぎらず、これから先、経営、事業運営、マーケティング、人事など、さまざまな職域の人が、さまざまな不確実さに適応していくことが求められます。そのときにとるべき姿勢が、「未来の結果を確約」しないアジャイルであり、『エクストリーム・プログラミング入門(第1版) 』に記されていた「変化を抱擁する」ことだと、私は考えています。

合わせて読みたい関連記事

編集：はてな編集部

倉貫義人（くらぬき・よしひと） @kuranuki

大手SIerにて経験を積んだのち、社内ベンチャーを立ち上げる。2011年にMBOを行い、株式会社ソニックガーデンを設立。月額定額＆成果契約で顧問サービスを提供する「納品のない受託開発」を展開。全社員リモートワーク、オフィスの撤廃、管理のない会社経営など先鋭的な取り組みも行っている。著書に『人が増えても速くならない』『ザッソウ 結果を出すチームの習慣』『「納品」をなくせばうまくいく』など。
ブログ：https://kuranuki.sonicgarden.jp/