受託開発でなく自社サービス企業なのに、開発組織に社内受託感がある――。この課題に昔から多くの企業が頭を悩ませてきました。エンジニアのエンゲージメントを高めて、安定した開発体制を維持するためにも、主体性をもった開発ができるように組織運営をしていく必要があります。
日本最大級のオフィスビル情報プラットフォーム「estie pro」やテナント企業向けの賃貸オフィスマッチングサービス「estie」を提供する株式会社estieでも、社内のエンジニアリング組織の成長にともなって、ときにエンジニアが指示をこなすだけの「作業者」のようになることが課題となっていました。
これに対して、同社ではデリゲーションポーカーという手法を取り入れ、チームを生まれ変わらせる取り組みを進めました。この記事では、CTOの岩成達哉さんに、経緯や取り組みの内容について詳しく解説していただきます。
目次
CTO就任時、チームに対して大きな懸念を感じていた
私がCTOに就任したときは、徐々に開発チームの肥大化による課題が顕在化してきたときでした。このまま何もせずにチームが拡大していくと「エンジニアが言われたことをおこなう作業者のようになってしまうのでは」という懸念がありました。
estieは賃貸オフィスマッチングサービス「estie」のワンプロダクトで始まりましたが、顧客のニーズをカバーする過程でプロダクトを増やしてきた結果、チームも複数生まれることとなりました。リソースの問題で、その後チームをひとつにまとめることとなったのですが、チームが大きくなることは、ただ与えられた仕事をこなすだけの単なる「作業者」が生まれてしまう危険性をはらんでいました。
実際に、新機能を試すプロジェクトでは、短期間でやりきらなければいけなかったこともあり、指示通りに作業をこなすだけになってしまっていた人も出はじめていたと思います。このとき決められた開発スケジュールに対して、開発側から「もっとこうしたらよいものが作れるのに」という声が出ることもありました。チームの力を最大限に生かしてプロダクトを作ることができているとはいえない状態でした。
チームとしてスピードを出し、事業をスケールさせるには、各々が自律して動ける体制が必要であるという課題を改めて感じることになったのです。
課題解決のために取り組んだ4つのこと
前述の課題に対して取り組んだことを大きく4つに分けて説明します。
デリゲーションポーカーの導入
デリゲーションポーカーとは、それぞれのタスクやテーマにおいて「誰がどこまで権限を持つか」を、カードを用いながらすり合わせていくものです。ポイントは、すり合わせ（権限移譲）とは移譲する・移譲しないの二択ではないということです。
デリゲーションポーカーでは移譲を7段階に分けて考え、管理者が意思決定をおこなうレベル1、チームと一緒に意思決定を下すレベル4、チームに完全に任せるレベル7といった具合に、レベルの数字が大きくなるほどチームメンバーに決定権を委ねる仕組みになっています。
estieではもともとエンジニアにも権限はありました。しかし、フラット組織であったこと、権限の範疇について言語化しきれていない部分があったことから、経営陣・リーダー・メンバーでお見合い状態になることがあったのです。そのせいで決定までに長い時間を要することもありました。
メンバーからの提案でデリゲーションポーカーを導入したところ、誰がどこまで決めるのかが明確になって意思決定のスピードが上がり、メンバーが判断に迷うこともなくなりました。
質問責任と説明責任の明確化
企業規模が小さいうちはあうんの呼吸でなんとなくうまくいっていたものが、メンバーが増えてしまったせいで「どうして今これをやっているんだっけ？」となってしまうことは少なくありません。そういったことが起きないよう、CTOとしては「なぜこれをやるのか？」をしっかりと言語化し説明する責任があると感じています。
同時に、仕事を一緒にするメンバーもわからないことがあれば質問をする責任が生じると考えています。あとから「なぜ自分はこれをやらされているんだろう」と思いながら仕事をするよりも、最初に質問をして解決しておいたほうがいいです。
また質問をすることで、本当に必要とされている開発範囲がわかり、あふれるタスクを整理できたことから自分で課題の本質を突き止め解決へとつながるケースもありました。
当社では、プロダクトごとの進捗状況を毎週レポートに書いて、他のチームにも状況共有ができるようにしています。全員が気軽にわからないことを質問する機会を作り、質問に答えることによって、より議論が深まることもあります。
またCTOとしては、説明責任の浸透を促すためにも逆にどんどん質問をすることを心がけています。そうすることで聞かれた側は説明の必要性に気づくことができます。
議論のフォーマットを決める
疑問点を質問によって解消し、すべてをクリアにすることは、批判ではなく相互理解のためのコミュニケーションを生み出しました。このことが心理的安全性の確保にもつながり、より議論を活発化させることがかないました。一方で、フラットな組織において話し合いが活発になると、議論が長期化することもあります。
議論を活発化させつつ、スピードを下げないために、議論のフォーマットを決めました。たとえば、プロダクト開発においては「最終的にこれはプロダクトマーケットフィットにどうつながるのか」などと常にメンバーに聞き、その場で話し合うべきポイント（達成したいゴール）を示すようにしています。
また、話し合うべきポイントを示すためにもロードマップを引き、ゴールまでの道筋を示すことが重要だと考えています。
少人数のユニット制への改変
前述のデリゲーションポーカーを導入する際には、組織改変もあわせておこないました。
当社はもともと、開発組織が「estie」と「estie pro」、その2つのサービスに複数のデータソースからのデータを統合して届ける「date pipeline」、esiteのみが持つデータによって賃料を予測する「e-賃料」という4つの内容ごとにチームが分かれていました。さらに「estie pro」はその中でも機能ごとに複数チームに細分化されていたため、合計で5～6チームが常に動いている状態でした。
同じ顧客に対して価値を届けているにもかかわらず、それぞれのチームが独自に動いていたので、認識の齟齬によるリリースタイミングのずれやコミュニケーションミスがありました。また、チームに所属する人数が少なかったため、チームというよりは「人」ベースになっており、リソース配分がうまくいかないということも起こっていました。
そこでチームをひとつにまとめ、助け合いをしながらリソース不足を解消していこうと考えました。当初は全体で優先順位を決め、それに従ってリソースをうまく配分できると思っていましたが、どのチームがやっていたことも優先順位が高く、やらないことをなかなか決められないというのが実情でした。
優先順位を決められない理由のひとつは、もともと自チーム以外が何をやっているか・なぜやっているかをきちんと共有できていなかったため、全社的な重要度とコストを見積もれなかったからです。他にも、議論のトピックが数多くあり、複数の議論を同時に進行することになりがちで深い議論にならず、なかなかひとつのチームにはなりきれませんでした。
そのような状況下では、コストを正しく見積もることができず、なんとなく誰かができそうというあいまいな見積もりでスケジュールが切られていました。結果的にスケジュールがきつくなり「ただ作業をする」という状態が生まれてしまいました。
そうした経緯があったことと、メンバーが増えたため、今回もう一度小さなユニット制に戻すことにしました。その際に合わせてデリゲーションポーカーを取り入れ、不透明だった権限の範疇を明確にすることで初期の課題を解決しています。
今はユニット制でありながらもワンチームを作ることを意識し、かなり有機的につながったり解散したりしながらマトリクス型に近い組織形態をとっています。
組織に起きた変化と手応え
これらの取り組みによって、社内には3つの変化が起きました。
- 裁量が明確になるということで、当事者意識が強くなった
- なぜやるかを全員がしっかり考えることで、ユーザー目線で考えられるようになった
- 長期的な目線で考えられるようになった
ベンチャー企業では、今日作ったものが来週にはまったく違うものになっていることもよくあります。そのため以前は中長期のスケジュールをひく意味があるのかといった議論が出ることもありました。しかし当社ではフェーズも変わり、ロードマップをしっかり引くことで、以前より明確に未来を見通すことができるようになりました。
また質問と説明を繰り返すことに慣れてきて、こちらから提案をすれば当たり前に質問が出るようになり、深い議論へとつながるようになったこともよい変化でした。
ときには「ここまでにプロダクトの検証を終わらせなくてはいけない」という期限や、お客様との約束があります。そんな中で作業者となってしまう問題を回避するならば、やはり説明責任と質問責任を互いに果たすということに尽きるかと考えています。そのためには、議論の土台となる「検証したいこと」を言語化し、説明・質問がしやすい環境を作ること、そしてその時間を捻出することが必要です。
今となっては、こうして振り返ってまとめられますが、実際に経験してみないと適切な行動が取れないことはあると思います。ぜひこれを読んでいる皆さんにはわたしたちの失敗を教訓とし、「作業者」を生み出さない環境づくりの参考にしていただければと思います。
われわれの技術で不動産業界を活性化したい
当社には、不動産業界出身で業界そのものやユーザーへの理解の深いメンバーと、IT業界出身で技術力がありよいプロダクトを作ることができるメンバーを含む心強い仲間がそろっています。われわれは不動産データプラットフォーム事業を通して、この業界をもっと発展させていきたい。市場を破壊するディスラプターとしてではなくお客様と一緒となって、これまで重ねてきた最適解を、技術によってさらに成長・拡大させていきたいと考えています。
そのためには、技術面はできるけど、ビジネスについて分からないエンジニアであってはいけないし、ビジネスサイドも技術に理解がない人ではよくないと考えています。部門や職種ではなく、ワンチームでビジネスを推進させていくという意識で取り組んでいく。それをかなえられるようなチームづくりをこれからも続けていきたいです。
