株式会社Honeysolの紹介
池田徳正氏（以下、池田）：はじめまして。株式会社Honeysolの池田と申します。本日は東大関連のスタートアップの方が登壇されるイベントにお招きいただき、ありがとうございます。
ただ、弊社はスタートアップという感じではなく、受託開発を主要業務にしている会社です。なので、他の方とは少し違う視点からお話しできるかと思います。
事業会社の方から見ると、受託開発は技術的挑戦とは縁が遠くて、「言われたことをやっているだけ」というイメージを持っている方も多いと思います。しかし必ずしもそうではなくて、受託開発だからできる技術的挑戦もあるし、そのあたりでみなさまの参考になる話ができればと思っています。
本題に入る前に、弊社の業務を簡単に紹介したいと思います。弊社の業務は大きく分けてコンサルティングと受託の2つを行っており、コンサルティングでは主にAIやデータ分析を用いた事業について、事業構築のコンサルティングを行っています。弊社でプロデュースしたビジネスは今、年間20億円を超えるくらいになってきています。
あとは一般的な受託開発も行っていて、ローコード技術を用いた効率的なシステム開発の他、AWS、GCPなどのサービスにTelephony、Video Streaming、3Dなどの技術をテクニカルに組み合わせたような事業案件が多いです。こうした事業案件をいかに素早く、事業性の判断をしてローンチできるかというあたりに強みを持っている開発会社です。
クライアントはAI関連のスタートアップさまが多いですが、その他大企業や研究機関、大学など多彩なところからお仕事をいただいています。
技術的挑戦には「緩慢なサボタージュ」の側面もある
ここで私の駆け出し時代というか、ITエンジニア1年目から2年目くらいのことを少し振り返ってみたいと思います。当時私がいた会社は、「とりあえず結果を出せればいい」という、ちゃんとしたマネジメントはされていない会社でした。その代わり、開発の方針はかなり任せられていて、自由でした。そうすると、どこまで技術的に新しいことをすればいいか迷うじゃないですか。
私の場合はあまり上司に相談しないというか、説明しないで勝手に技術的挑戦をしていた記憶があります。新しい技術の実験とかをするとそのぶん納期が伸びるわけですが、そこはあえて言わないで見積もりで吸収したり、こっそり休日に開発したりで、自身の技術水準を維持することと会社としての技術資産を確保することを無意識に行っていたんじゃないかと思います。
ただ技術的挑戦は、短期的に見ると納期が伸びたり無駄になったりする。それで済めばいいのですが、場合によってはプロダクトそのものの品質が下がったりするわけですね。そういう意味で、技術的挑戦は言ってみれば働き方としてはサボタージュというか。「緩慢なサボタージュ」と言っていますが、そういう面もあるんじゃないかと思います。
もちろん長期的な開発の効率化につながるような挑戦を「サボタージュ」と言うのはちょっと言い過ぎだと思いますが、純粋に興味でやるようなものも当然あるわけなので、そのあたりの線引きはすごく難しいんじゃないかと思っています。
余談ですが、新しい勉強会とかあるじゃないですか。PM（プロジェクトマネージャー）とはちょっとタイプの違う勉強会だと思いますが、そちらだと、そういうサボタージュマインドの方が意外に多い気がします。LTなどを聞いていて「いやー、そのプロダクトにその技術は使っちゃダメなんじゃないかな」と心の中で思ったりとか（します）。
それは極端かもしれないですが、新しい技術に関心を持っている方にはどうしても新技術に振り切れている方が多いと思います。個人としてはそれでいいんですが、エンジニアの組織マネジメント的な観点から見ると、エンジニア教育や採用活動の範囲でやっていくのか、それとも実務でどんどん使っていくのかは、すごく難しい問題になっていくんじゃないかと思います。
技術的挑戦に取り組むメリット・デメリット
少し話が逸れましたが、このあたりで今回の勉強会のテーマである技術的挑戦について、課題を私なりにまとめてみました。なぜ技術的挑戦を意識することが必要なのかというと、短期的に開発効率を追求していくと開発体制が劣化していって、中長期的な開発効率や組織の発展が犠牲になってしまうからだと思います。
一方で、新しい技術をどんどん取り入れればいいか、挑戦していけばいいかというとそうでもない。（それをすると）今やっているプロジェクトの納期が伸びる。先ほども言ったようにそれで済めばいいんですが、プロダクトの品質が下がる場合もある。そのあたりはどうしてもPMはもちろん、エンジニアにとっても関心を持たざるを得ない問題になるんじゃないかと思います。
技術的挑戦の3つのバランス
このバランスをどうとっていくか。すごくざっくり言うと、3段階くらいあるんじゃないかと思っています。
（まず、）なるべく技術的挑戦をしない立場、なるべく枯れた技術やメンバーが使い慣れた技術を使う場合もあると思うんですよね。「そんな会社、うちは違う」というところもあるかもしれませんが、なんだかんだいってプロジェクト単位ではそういう選択をしなきゃいけないことがあると思います。
もう少し一般的なケースとして、「一般的に使われている技術はフォローしておこう」とか、あるいはもっと先鋭的にというか、将来使われるかどうかわからない新しい技術にもどんどん挑戦してプロダクトに組み込んでいこうという、むしろ技術をリードする方針でやっている会社もあります。
実際にはもっとグラデーションがあると思いますが、「一般的に使われる技術はフォローしておこう」みたいな方針がだいたい一般的というか、この方針を選んでいる組織が多いんじゃないかという気はします。
とはいえ、この「一般的」がどの程度まで一般的なのかは人によって違うし、プロジェクトの特性や経営方針、採用方針、エンジニア個人の考えによってもこの判断はすごく大きく変わってくると思います。
じゃあどうやってバランスをとるかについては、すごくつまらない話ですが、結局は経営判断で、そんな簡単には答えが出ないんじゃないかと思っています。なぜかというと、この技術的挑戦のバランスは、短期的なリスク／ベネフィットや長期的なリスク／ベネフィットのバランスの問題だし、あるいは経営資源をどこに置くかというバランスの問題でもある。
なんだかんだいって、CTOなりVPoEなりが技術的方針を立てないと決まらない面があると思うんですね。そして、その方針があって初めて会社が組織としてスケールするようになるという面もあると思います。
技術的挑戦を可能にする開発体制作りのポイント3つ
ちょっと話を戻します。（ここで）どうやってこのバランスをとるかという各論というか経験談などをお話しすることもできるわけですが、そうすると他の登壇者さんと被りそうなので、今回私からは少し違う話をしたいと思います。
それは、この技術的挑戦のバランスをどうやって技術的挑戦をする方向に傾けていくか。その工夫というか手法があるんじゃないかと思っていて。それらをけっこう意識してきたので、そのあたりの話をしようと思っています。
技術的挑戦を可能にする開発体制について、3点お話しします。1点目は、リソースに余裕をもたせて技術的挑戦をする。2点目が、短期的プロジェクトで技術的挑戦をする。3点目が、コードの共通化によって技術的挑戦をすることです。
1つ目の、リソースに余裕をもたせて技術的挑戦をすることについて少しお話ししたいと思います。これはすごく単純な話ですが、あらかじめ技術的挑戦にリソースを使ってもいいようなスケジュールを考えておくということです。これは一見すると効率が悪くなりそうですが、技術的挑戦のぶんがダメだったら方針変更しやすいところではあります。
なので、意外と納期の確度を上げることにつながる面もあります。ただ注意しなければいけないのは、ダメだった場合に方針転換の判断を誰がするかということだと思うんです。人間はどうしても情が入ってしまうので、いったんコストをかけて作ったソースコードや仕組みなどをそのまま使いたくなるバイアスがあります、なのでそれを捨てる判断をいつ、誰がするのかを事前に決めておくことが、この戦略のすごく大事なところだと思っています。
次に、これもけっこう単純な話ではありますが、短期的プロジェクトで技術的挑戦をすることを意識するようにしています。この「短期的プロジェクト」は、納期が短いという意味ではなくて、ライフサイクルが短いプロダクトという意味です。
ライフサイクルが短いプロダクトを作る案件では実験的試みをしやすいので、そういうところで技術的挑戦をしていくことが、けっこう有効な方法じゃないかと思っています。
これは特に受託の会社の強みだと思うのですが、プロモーション案件や納品しっぱなしの請負の案件などがたまにあるわけです。それらは、技術的挑戦をしやすいです。実際の現場では、短期的案件は同時に納期が短いことも多いので「既存の技術で適当に作っておこう」となりがちなんですが、あえて技術的挑戦を入れていくことがポイントじゃないかと思っています。
最後に、コードの共通化で技術的挑戦をしやすくできます。受託開発ではソースコードの権利がクライアント側に行ってしまうことが多くて、そうすると長期的な技術的発展ができません。これが多くの企業が抱えている問題だと思います。そこでローコード的な開発思想というか、フレームワーク的なものを作るという開発体制にして、共通部分を企業の資産として維持していく。それが弊社で行っている試みです。
共通化するとソースコードのライフタイムが長くなるので、先ほどの話とは少し矛盾しているんですよね。ライフタイムが長くなれば当然技術的挑戦がしづらくなるわけですが、メインのブランチやメインのコードは長いライフタイムで維持しつつ、プロジェクトブランチで技術的挑戦をして、それをフィードバックしていくような仕組みを作ることで、この共通化でむしろ技術的挑戦の基盤にしやすくする仕組みを作るようにしています。
このためには1つポイントがあって、契約の段階からそれに合ったものにしなければいけないんです。弊社で使っている基本の受託の契約書（では、納品物を）共通部分と非共通部分に分けて、共通部分に関しては著作権共有で双方が販売・公開可能、改変なども全部自由にしていいという、必ずしも公開しないのでOSSとは少し違うんですが、OSSと類似した情報を契約書に入れておく。
一方で、非共通部分や個別部分、ビジネスロジックに関わる部分は、クライアントに移転するかたちにしています。これで受注側と発注側の双方がメリットを得られるような開発ができるんじゃないかと考えていて、会社を作った時にこの契約書の整備から始めたことで、こういう開発体制が可能になったと思っています。
技術的挑戦をしやすくするマネジメントがある
最後に簡単にまとめます。技術的挑戦は、エンジニア個人にとっても組織の継続的発展や維持にとっても不可欠です。ただ、技術的挑戦をどこまで行うかというバランスはプロジェクト次第だし、組織次第だし、経営方針次第だし、一概には言えないと思います。
ただ、この技術的挑戦をしやすくするというか、技術的挑戦をする方向に倒すマネジメントはいろいろあって、それらの方法を導入していくことも大事なんじゃないかと思っています。
以上で私のLTを終わります。
