前書き
こんにちは。カナリーで Development Architect をしている中山です👋🏻
私たちは【もっといい「当たり前」をつくる】をミッションに掲げ、「Canary」という BtoC の部屋探しポータル（アプリ/Web）や「Canary Cloud」という BtoB SaaS（不動産の仲介会社様向けの顧客管理システム）などの開発・運用を行っています。
最近ではテレビＣＭも放送され（不動産情報アプリ「カナリー(Canary)」、全国各地で初のテレビCM放映）、もしかしたらご覧になった方もいらっしゃるかもしれませんね。
あまり馴染みのない言葉かもしれませんが、私は Development Architect という立場で簡単に言うと 「よりよい作り方を作る」 という事をさせて頂いています。今日は具体的にどの様な事に取り組んでいるのか、考えている（考えていた）事などについて紹介させて頂きたいと思います。
「チームって何だろう？」「より高いバリューを生み出せる開発組織体制とは？」という問いに対して我々なりの答えを探してきた道のり、あるいはその中でのエンジニアの働きといった部分のお話になります。カナリーにご興味がある方には是非読んで頂きたいと思っています！ エンジニア向けの Engineer Entrance Book もありますので、ご興味がありましたら是非こちらも読んでみて下さい。
自己紹介
実は私は最近ジョインして3ヶ月ほど経ったところなのですが、入社エントリー的な意味も込めて少し自己紹介させてください。これまでのキャリアを簡単にサマると、
- 受託開発・自社開発のソフトウェアベンダーで何でも屋さん
- DeNA でソーシャルゲームのバックエンド、Unity を使った 3D ゲームの開発・運用
- 大手金融グループでブロックチェーンに関連したリサーチ
- 個人事業主（アメリカの仕事を日本で引受、Rust を利用した金融系のプロトコル開発に従事）
- シード期のスタートアップ
など色々な事をしてきました。個人事業主・小規模スタートアップ〜上場企業、バックエンド〜フロントエンド、プリセールス・実装・運用・リサーチなど様々な規模とフィールドを経験してきたので、カナリーではこれまでの経験を活かしてよりよい作り方を作っていければなと思っています。
我々の目指すところ
作り方を作るという意味ではやるべき事は多くありますが、今現在は開発組織のバリューをより多く・迅速に・高品質に生み出せる様なチームのあり方を目指して改善活動をしています。
前置きが長くなっても退屈ですので、ともかく我々が目指す姿をご紹介したいと思います。大きなトピックとしては2つあるかなと考えています。
- Team Topologies の体系を取り入れつつ構成
- ビジネスコンテキストをベースに Stream Aligned Team を構成
- Stream Aligned Team の自走力の強化を目的として Enabling Team を構成
- 共通的な負荷の低減を目的として Platform Team を構成
- Stream Aligned Team のメンバーは職能横断的なソフトウェアエンジニア
チームの構成
チームをどの様に構成するのかは古今東西様々な考え方があると思いますが、以下の様な観点があると思います。
- 階層
- 責務
- サイズ
- コミュニケーション手法
この様な要素をどの様に組み立てるのかによって全体としてのアウトプットの質・量・手法が変わってくると思います。例えば、階層がいくつも折り重なる様な形になっていて、かつ厳密な指揮系統の維持を重視する様な文化で、職能によって分断された組織だったとしたらどうなるでしょうか。何かを進めようとするといちいち確認作業が上層までいき、返ってきたと思ったら意思決定のための資料作りが始まり、提出しても一生確認作業が終わらず、よく見てみたら隣の職能チームでは全然別の方法を考えていた、どうにかこうにか調整を続けてやっと手を動かそうとしているけど作業をする段になると細分化されすぎており、「とりあえずこの仕様で API 作ってって言われたけど何に使うんだっけこれ…？なんかこの辺の仕様ユーザーからしたらイライラしそうだけど、どうしようかな。ウチのリーダーはいいって言ってるし、フロントエンドの人別チームだし…まぁいいや…」そんな事にもなり得ると思います。
その様な中で我々がどの様なスタンスを取るべきかと考えた時に、よく言われる様な事ではありますが、以下の様な考え方をベースとしたいと考えました。
- 可能な限り自律的である事
- 可能な限り階層は薄い事
- 職能横断的である事
この様な価値基準と照らし合わせた時、Team Topologies の考え方は非常にマッチがよいと考えました。ここでは Team Topologies がどういった考え方なのかは詳述しませんが、超ざっくり言えばこの様な事だと思っています。
- 顧客課題のセンシングからソリューションの提供まで一貫して担当するチームを構成
-
Stream Aligned Teamと呼ばれる - 多くて10名程度のチーム
- 職能横断的なチーム
-
-
Stream Aligned Teamが楽に・自律的に仕事ができる様にサポートチームを構成
結果、現在は以下の様なチーム構成になっています。
冒頭で弊社は主に二つの領域、お部屋探しのポータルサイト、不動産仲介の顧客管理（CRM）領域にプロダクトを提供していると書きましたが、その Value Stream をベースにチームを構成した形になります。実は、こうなる以前には以下の様な区切りがありました。
- Web チーム
- アプリチーム
- バックエンドチーム
しかし、この様なチーム分けは相応しくないと考えました。この様な形になると同じドメイン領域なのにチームが切れている事でコミュニケーションも分割されてしまいますし、同じ顧客課題に向き合っているという意識が生まれにくいためです。一般的には Stream Aligned Team を技術的レイヤーで分割するのは悪手と言われています。
一方でこの様な区切りにする事でややチームの人数としては多くなったという面もあり、このあたりは今後何らかの分割をしていく可能性があります。基本的にはドメイン領域をベースにしつつ、場合によっては別の節理面を検討するかもしれません。
Enabling Team
自律的である事、というのは非常に耳障りのよい響きです。チームが自主的に課題を捉え、意思決定し、解決していく。しかしこれを実際に実践した事がある方なら、それがどれだけ大変な事かは想像に難しくないでしょう。課題は常にあるし、その解決策を検討し、実装し、反応を見る、というフィードバックを高速に回すのは大変です。
日々そういった顧客課題に向き合っているとどうしても短期的なアウトプットに追われて新しいインプットは軽視されがちになってしまいます。しかし質の高いアウトプットをしていくためには「自分」という刀を常に研がなくてはいけません。一体いつその刀を研げるのか？という木こりのジレンマを解消していく事が必要です。
そこで、Enabling Team を構成して Stream Aligned Team の知識・スキルの獲得をサポートしていく事にしました。ここでは詳細は省きますが、短期的に効果が見込まれるボトムアップでの施策、中長期的に効果が見込まれるトップダウンの施策を検討しています。
Platform Team
Stream Aligned Team の自律性を担保するには、お互いに疎であり、フリクション（摩擦）が少ない状態を維持する事が重要です。
サービス間の過度な密結合が引き起こす問題は、コードの重複が起こす問題よりも悪質です。
参考：分散されたモノリスになってしまうマイクロサービス
という話もある様に、密結合になってしまうくらいなら完全に別にしてしまうのもアリなやり方ではあります。とは言え愚直にそこだけを実現してしまうと、プロダクトを完全にゼロから毎回構築するのか？という話になってしまいますし、シーンを選んでツールを提供するという程度は問題ないようにも思います。
そこで Platform Team では各プロダクトで都度対応する必要がなさそうなものをライブラリ、ツール、ドキュメントとして提供し、Stream Aligned Team の負荷を下げていく事にしました。これにより、Stream Aligned Team がより顧客価値にフォーカスした仕事ができる様にしていきたいと考えています。
ソフトウェアエンジニア
もっといい「当たり前」をつくる
カナリーは【もっといい「当たり前」をつくる】ことをミッションとしています。もっといい当たり前を作るにはユーザー・顧客の課題がどこにあるのかを考えどのように解決していくかという事を思考のアンカー⚓︎として、その UX を実現するためのソフトウェアエンジニアリングを行っていく必要があります。
そのためには、フロントエンドやバックエンドといった技術的レイヤーでエンジニアの責務を分割するよりも、 ユーザー・顧客の課題に挑戦するソフトウェアエンジニア として、UX 全体に責任を持てる様な関わり方をした方がよいと考えています。技術的レイヤーで責務を分解するとどうしても局所最適が起こりがちで、全体的な UX としてどうなのか、本当はどうあるべきなのか、という見方が薄れてしまうためです。
パラダイムの違うプログラミングに触れる事で引き出しが増え、エンジニアとしての成熟度も増すでしょう。そうすれば、何か問題があっても最適なレイヤーで最適な対処を行えるはずです。「自分の責務はここまでだから…」と、歪な形で問題を解決する様なことはないでしょう。全員がリードエンジニアレベルの視点を持ち、その様な対処ができる強いチームでありたいと考えています。最近では、いくつかの企業でこの様なエンジニアリングが行われている事を観測しています。
もちろん現状ではエンジニアには得意な領域にバラつきがありますし、パラダイムの違う領域に踏み込むには多少のキャッチアップが必要になります。このあたりは Enabling Team の働きでサポートしていく予定です。
一方で、「課題にフォーカスする」という事を強く意識しすぎると「いいよとりあえず動けば。ペイン解消したんだからコード汚くてもいいよ（鼻ほじー」となりがちです。しかし、それでは継続的なエンジニアリングが難しくなる事はみなさん体で理解しているところだと思います。どこをいじれば何が起きるのか分からない、何かをいじったら思いもよらない所でバグが生じた、何かをいじろうとしたら影響範囲が大きすぎて諦めた、どこに何があるのか分からない、似た様なものが色々なところにある、古いものや新しいものが混在していてどこをどういじればいいのか分からない、などなど。
そうならない様に、歯を食いしばってメンテナンス性を常に高く保ち続ける努力をする。これも顧客課題にフォーカスするのと同様にとても大事な事だと考えています。エンハンスができないシステムになってしまっては、そこで Value Stream が止まってしまうからです。
顧客に価値を生み出し続け、運用され続けるシステムを作るには目的志向と技術志向はお互いに欠かす事のできない両輪だと考えています。
実際にやってみて
ここで、実際に最近ソフトウェアエンジニアとしての関わり方を体現しているエンジニアに話を聞いてみたのでご紹介します🙌🏻 ここからは会話風にお楽しみください。
1人目、普段はアプリ開発をしながらバックエンドにも挑戦しはじめた中野さん。
🎤 今はどういった事に取り組んでいますか？
🙂 アプリの検索性を上げるための新規機能開発をしています。
🎤 チームのあり方が変わってお仕事の仕方はどう変わりましたか？
🙂 去年まではアプリメインで担当していましたが、今回バックエンド含めて担当しています。以前はバックエンドの方とコミュニケーションを取りつつ API を実装して頂いてアプリを実装するという形でしたが、今回はまるっと自分一人で担当しています。
🎤 その様な関わり方になってよかったと思うことを教えて下さい。
🙂 見える範囲が広がり、ポータルという事業への理解度が上がったと思います。コードを通してドメインへの理解も深まりましたし、今までは担当領域の「アプリ」という目線で見ていた Slack チャンネルのやり取りも見え方が変わりましたね。
🎤 バックエンドはこれまでご経験はあったんですか？
🙂 ありませんでした。今回初めてですね。
🎤 すごいですね、よくキャッチアップできましたね。
🙂 天才ですからね笑
🎤 笑
🙂 今回バックエンドに挑戦してみた事で改めてバックエンドの人たちすごいなーって思いましたね笑 今は全バックエンドエンジニアをリスペクトしています。
🎤 相互理解！
🎤 大変だったことはありますか？
🙂 天才とは言え、キャッチアップは大変でしたね。バックエンド自体が初めてだった事に加えて Go、Spanner、Elasticsearch など、必要な情報をインプットするのが大変でした。
🎤 どうやってインプットしていったんですか？
🙂 いったん自力でやれるところまでやってみて、どうしても詰まってしまうところや勘所が全くなく質問した方が早そうなところは質問していました。
🎤 ガーサスです。
🙂 また、最初はアーキテクチャを理解するのに苦労しました。説明は受けていたのですが、実際書いてみるまではやはり肌感を持って理解するのは難しかったです。
🎤 なるほどです。ありがとうございました。
2人目、普段はバックエンド開発をしながらフロントエンドにも挑戦しはじめた松尾さん。
🎤 今はどういった事に取り組んでいますか？
🙂 Canary Cloud の機能開発や保守・運用を行っています。最近では SMS の送信機能や、顧客への対応を促す様な機能の開発をしました。
🎤 チームのあり方が変わってお仕事の仕方はどう変わりましたか？
🙂 これまではバックエンド中心だったのですが、フロントエンドにも触れる機会が多くなりました。PdM とのやり取りも増えましたね。そのためか、「どうしたらもっといい機能になるだろうか」と考える事が多くなった様な気がします。
🎤 体験ベースで開発する様になったという事ですね。素晴らしい。
🎤 フロントエンドの経験はあったんですか？
🙂 個人開発で React を触っていたので hooks というものは知っているという程度でしたが、業務では初めてという感じでした。
🎤 中野さんよりは障壁は低そうですね。
🎤 よかった面を教えて下さい。
🙂 フロントエンドが元々好きなので、シンプルに開発していて楽しいですね。動くものを作るの楽しいです。
🎤 「作っている」感はより強く出そうですね。
🙂 フロントエンドもバックエンドも対応できるメンバーが増えたのでチームの人員の流動性も上がっていそうです。
🎤 プロジェクトマネジメントの面でもよさそうですね。
🙂 あとは、自分の市場価値も上がっていそうです笑
🎤 転職しないでくださいね笑
🎤 苦労している面を教えてください。
🙂 キャッチアップはやはり大変ですね。でも PR のレビューをとても丁寧にやって頂いたので助かりました。また、Canary Cloud は toB のサービスという事もあり納期が厳しい事もあるので、そのあたりは作業をうまく分担するなどは必要かなと思いました。
🎤 ベースのスキルとしては両方持って視野を広く持ちつつ、リソースは場合に応じて最適化していけるといいですね。ありがとうございました。
総じて、
- Pros
- プロダクト、ドメイン、事業への理解が深まる
- 体験ベースで考えられる様になる
- エンジニアリングリソースの流動性が上がる
- エンジニアの相互理解が進む
- スキルアップができる（それによって市場価値も上がる）
- 幅広く開発を楽しむ事ができる（人による）
- Cons
- キャッチアップが大変
といった印象でした。キャッチアップが大変、というのは「成長している」という事と裏表なので、一概に Cons とも言えないなと思います。もちろん過度に負荷がかからないか、あるいは新しいフィールドに挑戦する事でクオリティが著しく下がらないか、といった部分は懸念してはいますが現状ではレビューなど通して一定担保できていそうな印象です。この辺りは経過を見ながら改善をしていければと考えています。
終わりに
いかがでしたでしょうか。まだまだ始まったばかりの取り組みですので、これからも課題などは出てくると思いますが、よりよい作り方を目指して改善していければと思います。今後にもご期待ください😊
Discussion