“OODAループ”“心理的安全性”“銀の弾丸などない”　「楽楽精算」のPMが大事にする3つのSaaS開発原則

SaaSを支える3つの開発原則

紀井美里氏：それでは「開発グループが開発チームになるまでの歩み」と題しましてお話しいたします。

まずは簡単に自己紹介いたします。私は紀井と申します。新卒で株式会社ラクスに入社しまして、入社してからずっと楽楽精算の開発に携わっています。一時期、子会社のラクスベトナムのメンバーと一緒に、オフショア開発をやっていた時期もあったのですが、現在は楽楽精算の国内開発チームで、PMのような役割を任されています。

そして本日お話しするのは、今日のRAKUS Meetupのテーマでもあります「SaaSを支える開発原則」で、私からはこの3つを取り上げたいと思っています。1つ目が「OODAループ」、2つ目が「心理的安全性」、3つ目が「銀の弾丸などない」。この3つの原則を含んで、人が集まっているだけでチームとして機能していなかった私たちが、2年間でチーム開発ができるようになった、そんな泥臭いお話をお届けします。

まずチーム開発をしていくそもそものきっかけなのですが、ありがたいことに楽楽精算がサービスとして成長しまして、ビジネスのスピードと開発量、サービス品質を求められるようになり、国内での開発をスケールアップすることになりました。

これがきっかけで、そこからチーム開発をするにあたってまずどうしたかと言うと、楽楽精算の開発内で、メンバーを砂肝、ぼんじり、なんこつと、3つのグループに分けたわけです。「なんで焼き鳥？」という話なのですが、グループ名を焼き鳥の名前にして、メンバーが焼き鳥のメインのお肉で、それを取りまとめる人を串と定義しました。このときに私はなんこつの串になったわけです。

標準化して属人化を排除

ここから本編に入るのですが、3つのステージになっています。Stage1、2ではそれぞれ課題に遭遇し、そして最後のStage3ではグループから脱却し、大躍進を遂げていくことになります。

まずStage1ですね。さっそくなんこつというグループが発足したわけなのですが、私がなんこつの串としてPMのような役割をしていて、当時のメンバー構成は、若手もいれば自分よりもキャリアがある人もいて、それをまとめなければいけないという状況でした。

そんな中で私がやったことは大きく2つあります。1つは進捗ミーティングは対面で顔を合わせて行うこと。そして1日のうち必ずメンバーとの時間を確保して課題をキャッチアップすることに注力しました。そうして出た課題は、一緒に解決していくと。そう意識していました。

あとはKPTでの振り返り。KPTにこだわっていたわけではないのですが、それまで振り返りという習慣がなかったので、開発案件ごとに振り返ってなんこつ内のノウハウを蓄積していこうと考えました。

そんな中で先ほど最初にお話ししたとおり、課題に遭遇するわけです。なんこつ発足時、メンバー層はそんなに厚くはなかったので、経験が長いメンバーや串の私に仕事が集中してしまうことがありました。「集中しているこの状況で排除できるものはないかな？」と考えたときに、第三者テストであれば属人化を排除できるのではないかと。そういうふうに排除していきました。

ここでのポイントは、なんこつ内でいろいろ標準化していったところです。

楽楽精算の在年数が長いメンバーと、いろいろと新しい施策に取り組んでいきました。今思えば、よき理解者や相談相手がいて、とても心強かったと思っています。あとは困ったことがあれば進捗ミーティングで相談できる環境を作ったり、属人化の排除。テスト項目書は、誰がテストしても同じ品質になるものを作って、なんこつのメンバーの状態に合わせて、いかに開発業務を分担していくかに注力しました。

取りまとめる立場として気をつけていたことは、新しい取り組みをしたいのであれば、言い出した人が先頭に立って動くということ。あとは「自分たちに合わなければ止めていいんだよ」というぐらいの気持ちで、とりあえずやってみようとメンバーを巻き込んでいくことを意識しました。

あとはなんこつ内で成果が出たものは、他のチームにも展開をしていく。その結果、現在の楽楽精算では、テスト項目書の作り方はなんこつで提案したものが定着して、それが定番となっています。

メンバー間のコミュニケーションという課題

そしてStage2で、メンバー間のコミュニケーションという課題に遭遇します。Stage2に入った途端に、メンバーの入れ替わりと増員というイベントが発生するわけです。ほとんどのメンバーが入れ替わって、ただ若手もいれば自分よりもキャリアのある人もまとめないといけないというのは、相変わらずでした。

メンバーが入れ替わった状況でも、結局やったことは、標準化です。Stage1で標準化したことはメンバーが切り替わっても継続しました。また、対面での進捗ミーティングや、課題を一緒に解決していくこと。困ったことがあれば、進捗ミーティングで相談できる環境があって、新卒でも困ったことがあれば質問する場が、ずっと継続されていきました。

あとはベテランメンバーのチームと若手メンバーのチームを分けたのですが、たまに若手メンバーをベテランチームに短期留学させて「ちょっといろいろ教えてもらってきなさい」みたいなことをやったりしました。それから、モブプロですね。モブプロをやって、新メンバーが増えたので、楽楽精算のコードの暗黙知を少しでも伝承できないかなと始めました。

これはベテランメンバーと若手メンバーが一緒にやったり、それぞれベテランだけ、若手だけなど何パターンかをやったりしていました。

そんな中で、Stage2でベテランメンバーチームでの出来事なんですが、個人能力が高くてスピードが速いメンバーが一時的に手空きになることが頻繁に起こってきました。その度に私がタスクの調整をしたりしていたのですが、この当時、メンバーにどのようにタスクを割り振っていたかというと、もちろんWBSを作ってタスクごとにメンバー一人ひとりをアサインしていました。

ここでの課題をきっかけに、個人個人の能力は高いのに、その能力を集結しても相乗効果が出てないような気がするな、と。こういう、モヤモヤを抱えるというか、何か引っかかるなと思っていくわけです。

ここからOODAループというのを使って問題解決をしていくわけなんですが、まず何をやったかと言うと、現状をよく観察するところから始めました。よく見るとメンバーごとのタスクの完了時期がまばら。そしてタスクには依存関係があるということがわかりました。よくあることですよね。

そんなこんなで観察を続けていると、あることに気づくわけです。何に気づいたかというと、同じ開発案件を分担しているにもかかわらず、メンバー間でほとんどコミュニケーションを取らない、と。個人個人がアサインされたものを黙々とやっている状況に気づくわけですね。隣の人がやっていることにやや無関心。無関心なのか自分のことに必死なのかその当時はわからなかったのですが、そういう状況でした。

1つのタスクを全員に割り当てる

そこで私は、あることを決めるわけです。依存関係を意識させて手空きにならない状態を回避するように、メンバー自ら判断して動いてもらおうと。そうすると必然とコミュニケーションを取ってくれるだろうと期待したわけです。

実際にやったこと。今まで一人ひとりにアサインしていた状態を、タスクを自ら取っていくシステムに変えていきました。具体的にやったことは、WBSはスケジュールなので作成するんですが、1つのタスクに対してメンバー全員をアサインします。3人いたら3人全員をアサインします。そのあとに、タスクを進めるにはそのアサインされたメンバー同士で話し合って決めるわけです。

なので、1つのタスクに対して全員を当事者にしてしまったというわけですね。

あとは、細かい判断は基本的にメンバーに一任しました。何をどうするという方法論であるHOWの部分はメンバーに一任すると。あとはタスクの優先度ですね。方向性は取りまとめである串が決めます。これをやっていったところ、ものの見事にコミュニケーションを取るようになりました。どう考えても取らざるを得ない仕組みではあるので、こうなっていったわけです。

このときのポイントは何なのかというと、方向性やゴールは示すのですが、手段はメンバーにお任せする。そして取りまとめる立場として、気をつけたのが、メンバーを気にしていないふりをして、気にしているがあえて動かない。ただひたすらメンバーが考えて動いているのを見ていると。これは非常に気をつけていました。

“グループ”から“チーム”へ

そしてStage3で、ついに大躍進をしていくわけですが、ここからグループから脱却してチームになっていきます。Stage2でコミュニケーションを取り始めて、私はだいぶ満足していて、そこから何かをやろうとは考えていませんでした。日々の進捗報告を受けるぐらいで、意識的に何かしてたというわけではないのですが、よくよく聞いてると、あることに気づくわけですね。

気付いたことは何なのかと言いますと、メンバー一人ひとりのスキルに特徴があること。しかもそれは被ってないし、非常にバランスがいいということに気づきます。3パターンあって、1人は多少取りこぼしはあるのですが、とてもスピードが速い。もう1人は慎重で丁寧なので、見過ごされた小さな違和感を拾います。そしてもう１人はこれまでの経験から楽楽精算を幅広く理解している。それぞれ特徴があるメンバーだなというところに気づくわけです。

そしてあることを決めます。新規案件に着手する一番初めだけ、タスクへのアサイン順をメンバーの特徴によって変えてみると。そうすることで、メンバーの特徴を活かして適材適所で相乗効果が出るのではないかと期待したわけです。

それで実際にやったことが、スピードが速いメンバーを最初に導入し、懸念点などを探索してもらって、不確実な部分を減らすこと。そして開発案件の大枠を捉えて難易度や工数の見積もりの整合性を図りました。

そのあとに、慎重で丁寧なメンバーを投入してセーフティネットのような役割を果たしてもらいました。そして最後にその2人のバランスを取るために全体を把握しているメンバーを投入する、こんな感じで戦略的に人を投入していったわけです。

そうすると適材適所で相乗効果を発揮していくわけなのですが、個々の集まりだったのが自ら状況を判断して動くというチームに変わっていきました。なので私が指示しなくてもメンバーの提案ベースでいろいろことが進んでいくわけです。あとは不確実な部分を最初にある程度洗い出せるので、見積もりが非常に正確で、期限も守れます。

あとはスケジュールや優先度の都合で見送った改善などがあった場合に、ちょっとした隙間にそういう改善活動をするようになりました。「あれってどうなったっけ？」「あぁ、終わりました」みたいな軽い感じでいろいろとんとん拍子に進んでいく状況になっていったわけです。

最後にまとめですが、これまでの話を「SaaSを支える開発原則」に当てはめてまとめますと、メンバーの行動を見ながら状況を判断する、決める、実行するを繰り返し、自分たちに合うところを見出していきました。チームは常に変化し続けることを前提に、合う感覚がなくなればいい塩梅に合うところを探していけばいいということで、OODAループを活用していろいろと試していきました。

そして串が取りまとめるメンバーや中心メンバーが他のメンバーの前で困っていることをさらけ出すことで、チームの中心メンバーの振る舞いがチームメンバーの心理的なハードルを下げていくのではないかと。任せると決めたことは最後まで任せる。そしてメンバーの提案を尊重する。このようなアクションを基に、心理的安全な環境を構築していきました。

そして物事がうまくいくときは、さまざまな要素が絡み合っています。その時々で一つひとつの課題に向き合って解消し、積み上げていく。その積み上げが一定以上超えたときに一気に目に見える成果となるのではないでしょうか。以上のことから「銀の弾丸などない」と言われているのではないかと思います。

そして最後にチーム作りにマニュアルなどないと、私は考えています。メンバー一人ひとりを見て、うまく合うところを見つけていくことが大切なのではないでしょうか。

ご清聴ありがとうございました。

質疑応答

司会者：はい、紀井さんありがとうございます。2年間の積み重ねということで盛りだくさんでした。本当にいい話だなと思います。チャットなどでもけっこう質問が来ています。

モデレーター：ちょっと拾いますね。1つは「1チームの人数は6名ぐらいですか？」と。

紀井：そうですね。ちょいちょい変わるのですが、だいたい6名。今はちょっと多いかなという感じはしますが、それぐらいですね。

モデレーター：はい。もう1つが「PMというのはプロジェクトマネージャーですか？　マネージャーであればPOというプロジェクトオーナーが別にいますか」という質問ですが、これはどちらかというと、楽楽精算の場合は紀井さんがPOをやっていて、全体をけっこうまとめているPMがいるという感じですか。

紀井：どうなんでしょうか？（笑）。

モデレーター：どちらも兼ねるような感じでしょうか。

紀井：私はオーナーではないんですが、プロジェクトは進めるので、そうですね。

モデレーター：では兼ねつつ、全員でやっているような感じですね。もう1つ質問がありまして、チームの分け方で。「ベテランと若手を分けたのはなぜでしょうか？」。

紀井：それはやっぱり、ただ単に経験値の違いですね。やっぱり経験値の差がありすぎるとお互い仕事をする上でしんどいと思うんですよね。

モデレーター：ということはベテランチームは、より難しいほうのタスクをやって若手は比較的簡単なタスクをやるというチームに分かれているということですか？

紀井：当時はそうでしたね。

モデレーター：なるほど。その中でお互いのチームの中でまずは切磋琢磨するという感じでしょうか。

紀井：はい。

モデレーター：ありがとうございます。もう1つ質問が……いっぱい来てますね（笑）。

（一同笑）

テレワーク系ですね。「テレワークで観察が難しくなったりしなかったでしょうか？」と。テレワーク中はどうですか？

紀井：テレワーク中は全然、そんな心配は1ミリもしていなかったです。

モデレーター：じゃあチャットやボイスでけっこう連絡は取れていたということでしょうか。

紀井：チャットでもそんなに……。もうある程度できあがっているのもあって。

モデレーター：自律したグループができあがっているから、放っておいても大丈夫なところまで来てしまったと。

紀井：そうですね。なのでテレワークだったから何か困ったかと言われると「普通だった」と（笑）。

モデレーター：なるほど。素晴らしいチームになったんですね。もう1つ質問しますね。「全員アサインで仕事を取っていくスタイルだと進行が流動的になりそうですが、スケジュールは何を基準に引いていましたか？」と。難しい質問ですね。

紀井：何を基準に決めていたか。ちょっと私の中ではピンときてないんですけど（笑）。

（一同笑）

司会者：うちの場合だと、自社サービスなのでわりと開発のエンドを自分たちで決められるところがあると思うので、作業量の全体量から人数で割ってみた感じだったりします。楽楽精算を担当したことがないので詳しいところはわからないのですが。

紀井：「スケジュールは何を基準にしているか」。

司会者：エンドはどこで決まるのか。

紀井：リリース日ですよね。

司会者：リリース日ありきで決まっていくみたいな話ですよね。

紀井：はい。

司会者：それに入る範囲の機能を開発するみたいな。

紀井：そうです。

司会者：なので「全体のこの範囲までやります」というボリュームが決まっていれば、その中でタスクが前後しても、あまり影響がない感じですね。

紀井：そうですね。なのでバージョンで全体のスケジュールが決まっているんですよ。リリースはいつって。そこから逆算で結合テストがいつでシステムテストはいつ、とかが全部決まっているので、開発する時期がここからここ。その中でまたスケジュールを引いて「お願いします」みたいな。

司会者：なるほど。これが回答になっているのか自信がないところがあるんですけど、回答になっていなかったらまた追加で質問をお願いします。順番に行きましょう。「スクラム開発に2週間くらいに区切って開発していますか？」という。

紀井：全然ですね。スクラム開発ではないんです。

司会者：スクラムではないんですね？だからタイムボックスみたいなものも切っていない。

紀井：切っていないです。

司会者：タスクベースで動いていくみたいな感じでしょうか。

紀井：はい。なので誰がどれだけやったかは別に測っていないです。私は終わればいいと思っているので（笑）。

（一同笑）

紀井：なのでそんなことは気にしていないです。

司会者：ありがとうございます。次は先ほどのPMの件ですかね。「PMがいわゆるプロジェクトマネージャーなのかプロダクトマネージャーなのか」。

紀井：プロジェクトですね。

司会者：次の質問で、「ぼんじり、なんこつ、砂肝の3チームはどういった分け方だったんでしょうか？」とありまして、これは何かエピソードはあるんですか？

紀井：いや全然単純です。スキルごとというか、最初は楽楽精算の在籍年数とスキルで、とりあえずなんとなく3分割したみたいな感じです。

司会者：スキルごととは言うけどある程度ざっくり「えいや！」で分けた感じですかね。

紀井：「えいや！」と。

モデレーター：でも偏らないようにみたいなところはありますよね。

紀井：はい。

司会者：最後の質問は「メンバーの得意分野を抽出するための着眼点はどのようにして身につけたのでしょうか？」難しい質問ですね。

紀井：どういう着眼点かというと、なんでしょう、比べないところでしょうか。スピードが速いメンバーがいて、慎重で丁寧なメンバーがいて、でもスピードという軸で比較してしまうと、やっぱり丁寧なメンバーは劣っているように見えるのですが、比較しなければ、それは特徴というかその人のよさという考え方ですね。

司会者：なるほど。ありがとうございました。