“チケット配られ待ち”じゃない自律型開発チームを作るには　自発的コミットメントが創出される仕組みづくり

最初はマーケティング部が「やるぞ！」と言ったものと不具合を粛々とやる部隊だった

新多真琴氏：じゃあ次は、組織・コミュニケーションの話をします。お待たせしました。

（スライドを示して）なにやら変な図を持ってきました。3人から始まったチームが、一番多くて11人ぐらいまで増えて、今は自分を入れて8人のフルタイムメンバーがいる感じです。

ざっくり振り返ってみた時に、3フェーズぐらいありました。直近のフェーズはめちゃくちゃ最近なんですが、こんな変遷をたどってきました。それぞれ軽くお話をしていこうと思います。

最初は開発本部がなかったので、マーケティング部の下にエンジニアとデザイナーが付いていました。マーケティング部が「やるぞ！」と言ったものと不具合を粛々とチケット消化していく部隊という印象を私は受けました（笑）。

そういう状態から、開発本部として切り出してチーミングをしていきましょうとなったのが2021年8月ぐらいです。

冒頭でお話ししたように、私たちはお店に商品を出品してもらって、それをユーザーに買ってもらうというシステムをやっています。なので、お店の人にとってもユーザーにとっても使いやすくないといけません。

どちらも大事だと思いますが、どうしてもユーザーのほうを向いた施策が優先されやすい感じになってしまっていました。「このへんも問題としてあるよね」という話を発足のタイミングではしていました。

「私たちはどういうチームです」と言えるようにした

なので、（スライドを示して）こんな感じで発足時にちょっとエモいことを書いて、うちの部署のバリューを作りました。

まず、「私たちはどういうチームです」と言えるようにしたんですね。「マーケ本部の下で開発をやっています」じゃなくて、「私たちは、こういうことに責任を持って開発をやるチームです」と言ってもらえる状態を目指しました。

メンバーとの対話もいろいろしていたのですが、組織やサービスに対してめちゃくちゃウィルがある状態ではなかったところに私は課題を感じていました。なので、「開発本部はこういうチームです。こういうところに責任を持ちます。こういうところに誇りを持ちます」みたいなことを、まずはとにかく私がブロードキャストする。そこをきっかけにみんなにも考える機会を持ってもらおうと思いました。

「to be」の部分をいろいろな場所で、いろいろな言葉でしゃべって、それを聞いてどう思ったかをそれぞれに話してもらう。そういうコミュニケーションの仕方をしていた気がしています。

良くない行動を取る人はあまりいなかったけれども、開発本部としていい行動、「こういう姿勢いいよね」みたいなことは、見つけ次第積極的に拾ってブロードキャストしていました。

向き合い先の部署の目標をどう解決するかに責任を持つ文化を作りたいと思った

（スライドを示して）これはハードの部分なので、「建て付けをどうしましたか？」というところです。先ほどちょっとお話しした部署ごとのタスクのバランシングをまずは目的としました。

関わりが多かったのが、加盟店に向き合っている部署とユーザーに向き合っている部署、マーケだったので、そこをまずはメインのカウンターパートとして据えて、リソースを分割しました。

じゃあ、自分たちがどういう目標を持っていたかというと、「向き合い先の部署の目標を、エンジニアリングでいかに達成させられるかをみんなで考えよう」と、言っていました。

これによって何をしたかったかというと、相手の、ひいては事業の、whyとwhatを理解して、how、どう解決するかに責任を持つ文化を作りたいと思っていました。

逆にそれまでの依頼では、「ここのこのタイトルをこういうふうに変えてください」みたいな、めちゃくちゃ具体的な修正指示をもらっていて、「どうなるかみたいなところを別に営業が気にしなくてよくない？」と思っていました。一番いいかたちをみんなで考えることは大事だと思うんです。けど、そこまでやらなきゃと思ってもらっていること自体、あまりいい状態ではないと思っています。なので、生煮えの状態からきちんと巻き込んでもらえる、そういう関係性を作ろうと考えてやっていた気がします。

チームで助け合いながら仕事を回すことの原型ができた

建て付けだと、1on1があまりやられていなかったのでやりました。目標とそれのレビューのサイクルを作りました。あと、今は週次で輪読会をやっているのですが、インプットとアウトプットのサイクルやディスカッションの土壌を作ろうとしました。

わりと、セルフマージ、ポチッみたいなものが横行していたので、無邪気に「レビューしようぜ」と言ってピアレビューを導入しました。それだけだと何をもってレビューしたかが人によってけっこう違ったので、ざっくりとしたガイドラインを作りました。

あとは、一応私が入る前からスプリントは導入されていたのですが、もう少しサイクルを安定させたかったので2週間にして、ふりかえりのサイクルまできちんと回そうということをやりました。

あとは、「Cake.jpの開発組織はこう」と、自分たちの言葉で語れるようになってもらいたいと思っていたので、採用の面接・面談に積極的にメンバーを巻き込むようにしました。という感じで、何が大事かをみんなで言語化することをとにかくやっていたような気がします。

どうなったかというと、これはまだまだではあるんですけど、開発本部として切り出されるとどうしても機能としてただの社内受託屋さんになりがちなんですね。「これをやってください」「わかりました」みたいな。それに甘んじない文化の種ができたと思っていて、個人プレイじゃなくてチームで助け合いながら仕事を回すことの原型ができたと思います。「こういうプロジェクトやろうと思うんですよ」と、ちょっと大きめの案件を打ち出した時に、「じゃあ、プロジェクトマネージャーをやります」とスッとやってくれるメンバーがいたりとか。

あとは、個人のふりかえりサイクルが、1on1だったりなんなりでできるようになったので、「2021年と比べて今、自分が思いがけないぐらい成長していることに驚いています」とうれしいコメントをもらったこともありました。マネージャーはそういうのを糧に生きていくしかないんでね（笑）。

ほかには、共通の価値観も生まれました。「ここのコード、いいよね、悪いよね」とか、「こういう設計、いいよね、悪いよね」などは、やはり実践をみんなで積み重ねていかないと、経験値や共通のナレッジとして溜まっていきません。そういうものが育まれました。一時期10人以上いましたが、一応スケールしたので悪くなかったと思っています。

本当に価値を届けたい先に届けられなくなってしまった

いいことだけでもないんですね。一方で課題もいっぱいあって……ちょっとこのペースだと間に合わないんで、めちゃくちゃ巻きますね（笑）。

（スライドを示して）こんな感じの課題があったんですが、開発タスクの優先順位の付け方がけっこうまずかったんですね。

先ほど、マーケと営業にリソースを振り分けました。「じゃあ、それ以外は？」みたいな。「自分たちの開発者生産性向上のためのタスクをどうやって混ぜ込んだらいいんですか？」という感じになっちゃって、なんかちょっと思っていたのと違うな、となりました。タスクの何を優先して何を優先しないか、それを私たちが決められない状態で、すごくバランスが悪い関係性になっちゃっていたんです。

向き合う先が部署だと、究極的には「隣の部署の何々さんが喜べばいいや」という感じになってしまいます。本当に価値を届けたい先は、そのもっと先だと思うんですが、そういうのができなくなっちゃったんです。これは伏線なんですけど。

あとは、ふりかえりのサイクルが「個人のサイクルはできたけど、じゃあチームだとどう？」というと、あまりできていませんでした。ほかには、「そもそもCake.jpというWebサービスがあるのに、そのWebサービス自体のto beを誰が決めて回していくんだっけ？」「あれ？　いなくない？」となったことが課題としてありました。

チームやめてみた期に突入

チームやめてみたという期に突入するわけですね。いないならやればいいじゃないということで、PdMをやってみることにしたんですけど、この話はまた別でやろうと思います。

そうすると、ある程度自分の裁量をもらうことでタスクの優先度をコントロールできるようになりました。会社として重点的に見たいテーマごとの大まかなリソース配分を決めて、メンバーの成長度合いも加味しながらそれに合わせてタスクを2週間に1回配る人をずっとやっていたのですが、ちょっとつらかったです。

つらかったんですが、成果としてはそれなりに出ました。プロダクトとしてこうしたいというところから逆算して、「こういう順番でこういうことをやっていきましょう」みたいなところができたり、ガバナンスを強化するための施策の優先度をきちんと上げられたり、いいこともありました。

でも、なんか大変だな、大変なわりにみんなあまり働きやすそうじゃないなということがけっこうあって、ここ最近はわりとずっと重い話をしていたんです。メンバーからも「このままでいいんですかね」という意見があって、「やっぱり、そう思う？」みたいな話をしました。

あと、メンバー間でレビューする時に、やっているタスクの背景をよく知らないままレビュアーとしてアサインされてしまって、「構造としては確からしく見えるが、これって本当に十分に検討された仕様なんだっけ？」みたいな突っ込みが始まって、そこからねじれていくみたいな話があったり、いろいろありました。

個人的に一番大きいと思っていたのが、ふりかえりのサイクルがチームでなく個人に閉じていることでした。「先ほど書いていた課題がまだ残ってた」ということがあって、これがないとみんなで集っている意味がけっこう薄くなっちゃうので、これはすごく課題だと思っていました。

ただ、すごくヤバい状態に聞こえますが、チームの雰囲気自体はすごく良かったです。それは救いというかありがたいというか、みんなポジティブに物事を捉えて進めてくれていたので、たぶん七転八倒していたのは私だけという状態だったと思うんですけど（笑）。

バリューの「ハッピートライアングル」を見た時に「あっ、これじゃん」と思った

チーム制に戻せば、そういうことが粗方解決することはわかっていたんですよ、わかっていたんですけど、その前に部署向き合いに失敗していたから、「じゃあ、なんの切り口で分けたらいいのかな？」という問いに長年答えが出ませんでした。

（スライドを示して）これは当社のバリューです。なかなかいい感じのバリューで、この中にハッピートライアングルというのがあります。

これは先ほどもお話ししたように、加盟店のみなさんから商品を出品していただいて、それをユーザーに買ってもらう。そうすると、私たちも加盟店さんもうれしいという、みんながうれしい三方よしの世界を作っていきましょうねというバリューなんですね。

これを見た時に、「あっ、これじゃん」と思いました。どういうことかというと、向き合い先は部署じゃなくて、その先の価値を届ける相手だということです。言ってみれば当たり前な感じなんですけど、やっとピッカンしました。

そのハッピートライアングルを回す起点はどこなのかというだけで、最終的に三方よしを作るのはみんな変わらないんだよ、と。でも、あくまでも起点であって、三方よしを実現するために、「どの部署と一緒に何をやっていくかを考えて動かす部署にしていきます」ということを言ったんですね。

これまでの癖で、ついつい「営業チームは」とか言っちゃうんですが、「それは駄目です」と。「営業に向き合って仕事をするのではなく、その先の加盟店さんに向き合って仕事をするんです、私たちは」と、最初のうちはちょっと口酸っぱく言っていました。

開発者生産性を向上させるための“タスクが回る仕組み”を作った

『チームトポロジー』という本があります。そこにストリームアラインドというチームの形態と、イネイブリングというチームの形態があります。よかったらググっていただければと思います（笑）。

その2つに分けて、開発者生産性を向上させるためのタスクがきちんと回る仕組みを作りました。あくまでも優先順位はこちら（ストリームアラインド）側に今はあると建て付けているので、うまくバランスを取るためにみんなを兼務というかたちにしました。（スライドを示して）この点線が付いているところですね。そういう感じで、うまくリソース配分も叶ったと思っています。