ホロラボ Advent Calendar 2024の7日目の記事です。
はじめまして、2024年12月から執行役員に就任した及部です。得意分野である「アジャイル開発」をテーマに記事を書きました。
「ホロラボとアジャイル開発」
- 受託開発でもアジャイル開発はできるのか、について本気出して考えて取り組んでみた
- 社員65人規模の会社におけるアジャイル開発のリアル
今回は、第一弾の「受託開発でもアジャイル開発はできるのか、について本気出して考えて取り組んでみた」をお届けします。
はじめに
この記事では、リアルな取り組みをご紹介したいと思います。その前に、私のコンテキストについて簡単にご紹介します。
自己紹介
私たちのチームはSilver Bullet Clubという名前です。ソフトウェア業界では「銀の弾丸はない」という比喩がよく使われますが、「己（チーム）こそが銀の弾丸たれ」という思いを込めて、この名前をつけました。
私たちは、事業会社でのプロダクト開発や新規事業開発を通じてアジャイル開発を実践し、それらの経験をコミュニティで共有してきました。以下はその一部です。
そして、私たちは2022年7月にホロラボにチーム転職をしました。
ホロラボは、XRやメタバースなどの技術を得意とし、受託開発を中心に活動している会社です。数年前にこれらの技術がバズワード化し、多くの企業がPoC（Proof of Concept = 概念実証）に取り組み、最近では実用化に向けた動きが加速しています。ホロラボにも、そうした案件の依頼が増えています。
会社を取り巻くビジネス環境が変化する中で、ホロラボ自身も会社として変化に適応していく必要がありました。アジャイルコミュニティでのつながりをきっかけに、たまたまタイミングが重なり、チームでホロラボに参画しました。
入社当時の受託開発への印象
入社以前、受託開発には正直あまり良いイメージは持っていませんでした。理由は、エンジニアコミュニティやスライド、ブログ、書籍などを通じて耳にする話がネガティブなものばかりだったからです。
チームで転職活動をしていた際、ホロラボから声をかけていただいたときも、受託開発という言葉に少しだけ「うっ」ときました。しかし、そのときに改めてなぜ「うっ」とくるのかを考えてみましたが、なんとなくという曖昧な感覚以外の明確な理由はよくわかりませんでした。
ホロラボに参画することを決めた理由は受託開発がやりたかったからではありません。それ以外のさまざまな理由をもとに参画することを決めました。この仲間たちと一緒に未来を創っていきたいと考えたときに、受託開発という仕事が目の前に現れたというのが私たちの感覚です。
なんとなく「うっ」と来るけど明確な理由はわからない。 自分たちが経験したこともないのにとやかく言うのはダサい。 であれば、まずは受託開発に思いっきり向き合って取り組んでみよう。
本記事では、そんな受託開発との出会いから、受託開発に向き合い続けてきて得た学びを共有します。
受託開発における難しさの正体
受託開発における難しさは、
- チームが長続きしない
- 「私契約する人、あなたつくる人」問題
- 「私考える人、あなたつくる人」問題
に集約されているように感じます。
チームが長続きしない
受託開発ではビジネスモデルの特性上、リソース効率を重視する傾向があり、プロジェクトベースのチームになりがちです。プロジェクトがはじまるときにチームが集められ、プロジェクトが終わるとそのチームは解散します。
「私契約する人、あなたつくる人」問題
受託開発はざっくりと、
- 依頼を受ける
- 見積もりを出し調整をする
- 契約をする
- プロジェクト開始
- プロジェクト終了
というフローに分かれています。受託開発では、営業・プロジェクトマネージャー・開発者など、各役割がフェーズごとに関与します。もちろん会社やチームやプロジェクトによって、役割ごとに人で分かれている場合とそうでない場合があるでしょう。ここで注目したいのは、開発者＝つくる人が後の工程になってからプロジェクトに加わることが多いという点です。
受託開発の経験が豊富なコミュニティ仲間と会話する中で、「つらくてニューゲーム」という言葉が出てきました。開発者がプロジェクトに参加するタイミングでは、既に多くのことが決まっていることがあります。既に決められた厳しい前提条件のもとで開発をはじめる状況を表現した言葉です。
このつらくてニューゲームこそが、「私契約する人、あなたつくる人」問題の正体です。
「私考える人、あなたつくる人」問題
今度は仕事を発注する側の立場になって考えてみます。
発注者が他社に仕事を依頼する際には、自分たちでは対応できない業務（ex. システム開発）を依頼するケースが一般的です。自分たちだけではわからないこと・実現できないことがあるからそれができるプロフェッショナルの力を借りたい、と考えると自然な話です。
いざ受託開発のプロジェクトがはじまったときに、受託会社の開発者から「つくるものを決めてください！決めてくれたらつくります！」といったニュアンスのコミュニケーションをされたと仮定します。発注者からすると自分もよくわかっていないんだけど、仕事を進めるためにとりあえず決めます。
これを繰り返していくと、発注者はわからなくてもとりあえず決めるという仕事に慣れていきます。そして、徐々に「私考える人、あなたつくる人」という関係性ができていきます。
受託開発において、発注者と受託会社間の関係性の問題が度々話題にあがります。しかし、その関係性をつくっているのは自分たちのコミュニケーションによるものなのかもしれません。しかし、これは誰かが悪かったのではなく、全員が真面目に仕事に取り組もうとした結果です。
それぞれの問題は関連している
この3つの受託開発における難しさは、それぞれ独立しているものではなく連鎖しています。
チームが長続きしないことで、契約時にチームが存在しないため、契約を進める役割が必要になります。だから「私契約する人、あなたつくる人」問題が生まれます。
「私契約する人、あなたつくる人」問題が起きることで、チームができたばかりで仕事を進めないといけないので、チームの内側にも力をさかなければいけないので、どうしても顧客との間に壁が生じやすくなります。だから「私考える人、あなたつくる人」問題が生まれます。
突破口はチームで働くこと
これらの受託開発の難しさは、私たちが入社した当時のホロラボの中で実際に起きていたことです。当時のホロラボでは、ほとんどのチームがプロジェクトベースのチームでした。チームベースで仕事をしているチームは1〜2チームのみでした。
そんなところにチームで転職をしてきた私たちが参画し、はじめての受託開発に取り組みはじめました。私たちは、受託開発のフロー全体をチームで取り組むところからスタートしました。チームが最初から最後まで顧客と話しますし、見積もりや契約もチームで行います。そして、そのチームがそのまま開発も行います。
これを繰り返す中で、見積もりや契約も学びの対象だと気づきました。
「見積もりのときに考慮しておけば、もっといい開発ができたな」 「契約をもっとこうしておけば、ここまで支援することができたからもっと顧客体験があがったかもしれない」
見積もりや契約からプロジェクトの実行までを同じチームがやっているからこそ、このような学びが生まれます。一方で、見積もりや契約とプロジェクトの実行で人が分かれていると、プロジェクト全体を通してのフィードバックループがまわりにくくなります。
受託開発におけるプロダクトは「問題解決できるチーム」
受託開発というビジネスモデルは、顧客の問題解決に対して報酬を得る仕組みです。ほとんどの取り組む問題は、複雑で難解であり、かつ解決するまでのスピードを求められることが多いので、個人ではなくチームで問題解決にあたる必要があります。つまり、受託開発におけるプロダクトは「問題解決できるチーム」と言えます。
受託開発会社が、利益率をあげるためにリソース効率を高めたくなることは当然のことです。しかし、それは受託開発側の都合に過ぎません。同時に、プロダクトとしての「問題解決できるチーム」の質をどうやって高めるかという問いにも向き合い続けなければならないのです。
受託開発の難しさは連鎖しているという話についても、「チームが長続きしにくい」というところから取り組んでいくのが定石です。
受託開発におけるチームづくりの方向性として、
- チームベースで仕事をするチームを増やし、チームを育てていく
- クラウド環境のように必要なときに必要なチームが素早く立ち上げられるようにする
という2つのアプローチがあります。私たちは、まずは自分たちのコンテキストにマッチしていたチームベースのチームからはじめました。
「クラウド環境のように必要なときに必要なチームが素早く立ち上げられるようにする」についても、少し前から海外のアジャイルコミュニティでは流動的なチームに関する関心も増えています。流動的なチームについての詳細は省きますが、参考リンクを置いておきます。
この2つは二者択一ではなく、フェーズや組織の状況に合わせて組み合わせていくのがよいです。個人的に流動的なチームにも興味があり、今さまざまな試行をしているところです。
受託開発かどうかは関係ないよね
プロダクト開発や新規事業開発に取り組んできて、会社に入る前は受託開発に「うっ」ときていた自分たちが受託開発に思いっきり取り組んでみてはや2年、今感じていることは「受託開発もプロダクト開発もあんまり変わらないよね」でした。この言葉は、コミュニティの仲間と受託開発に関して会話をしているときにも度々出てくる言葉でもあります。
発注者と受託会社、事業部と開発部、プロダクトオーナーと開発者。言葉は違えど、構図は同じです。違いがあるとしたら、受託開発では両者で会社が分かれていて、パワーバランスや契約などが制約になりやすいということです。しかし、事業会社の中でも「社内受発注」という言葉が出てくることがあり、同じ会社の中にいてもパワーバランスなどの制約に悩んでいるチームを数多く見てきました。それぞれのコンテキスト下の制約がある中でどのように関係性を構築してチームで仕事をしていくのか、という点で共通しています。
実際に、受託開発で取り組んできたことや、その中でやってよかったことなどは、これまでプロダクト開発や新規事業開発でやってきた取り組みと違いはありませんでした。
このトピックに関しては、先日イベントで講演をしました。詳細な取り組みについてももう少し掘り下げて紹介しているので、もしご興味があればこちらを御覧ください。
楽しそうに受託開発を語っている人が増えると嬉しい
最後なので、主語デカに個人的な想いを伝えさせてください。
入社時の私たちのように、受託開発にネガティブな印象を持つ人は少なくありません。特に「受託開発は難しい」「顧客に振り回されるだけ」といった固定観念が根付いている場合もあります。
一方で、「受託開発は不要だ」という意見も耳にします。しかし、受託開発がこれほど大きな存在感を持つのは、明確なニーズがあるからです。実際、日本のIT産業において、受託開発は非常に大きな割合を占めています。だからこそ、日本のIT産業全体を元気にするためには、受託開発が元気になる必要があると私は本気で信じています。
もちろん、AIの活用拡大や市場環境の変化によって受託開発の需要が減少していく可能性はあります。しかし、それは自然な流れであり、不要なものは淘汰され、必要なものが残るだけです。受託開発もまた、時代の変化に適応しながら進化し、必要とされ続ける領域であると信じています。
だからこそ、受託開発に携わる人々がその価値や面白さを楽しそうに語る機会が増えたらいいなと心から思っています。楽しそうに働いている人のまわりには、楽しい仕事や素晴らしい仲間が自然と集まるものです。その連鎖が、受託開発に対するネガティブなイメージを払拭し、新しい可能性を切り開くきっかけになるはずです。
最後に
ホロラボで一緒に働くことに興味を持ってくださった方、募集しております。 hololab.co.jp
そうでなくても、もしよければぜひ気軽に雑談しませんか？ pitta.me
