自己紹介
どうも、やまざき＠サーバーサイド開発部でございます。ご無沙汰しております。 Chatwork社員の中でちょっとだけ自転車が好きっぽい社員のうちの１人です。
自転車部員にとっては当然ではございますが新型SHIMANOコンポの12速化の話を延々としようとしたのですが、開発チームメンバーに諫められ、燃えたぎるコンポ論にいては、やむなく、まさに断腸の思いでここで中断いたします。
ところで読者のみなさまは、当方やまざきを認知済みとは思いますが、非常にごく稀によくある希有な事例として、やまざきを認知していない方のために過去のやまざきの記事をはっておきます。 creators-note.chatwork.com
さて、導入がてら多少口触りのよい詭弁を弄したところで、個人的な本題に入っていきたいと思います。 Chatworkでは組織開発、開発体制の将来像についてはこちらの記事で公開させていただきました。 creators-note.chatwork.com 一方で、やまざきが１人の開発メンバーとして地に足のついたスクラムを回してみようと、PHPの現場で右往左往してきた話と、今後どのようにチームを成長させていけばいいのか、という個人的なまとめを紹介させていただきます。
Chatwork入社以前
やまざきは、開発チームメンバーとして3年ほどスクラムを経験しました。
毎回のコミットメント未達、カイゼンアクションの飽和状態とアクション未達。各イベントのタイムボックス超過。正直なところ、上手く回っていないチームでした。
しかし今になって思えば『貴重な失敗経験』だったと思っています。
その失敗をもとにチームの働き方を変えていこうという気持ちはあったのですが、 その現場を離れChatworkで働くこととなりました。
機能チームへのチャレンジ時代
やまざきがChatworkにジョインした2018年当初は、開発組織改編が進められていました。
開発チームとインフラチームという分け方から、機能ごとのユニットというチームをつくってそこで開発運用を回していくという分け方にチャレンジしていました。
たとえば、APIユニット（Chatwork公式APIを担当）、アドミンユニット（ユーザー管理画面）、チャットユニット（チャットメッセージ周り担当）などを含む5つのチームに再編されました。
やまざきはアドミンユニットにジョインすることになりました。
アドミンユニットの現場
メンバー構成
チームはやまざきと、エキスパート2名とマネージャーとして部署のエンジニアマネージャー（兼任）の4人でした。 またリーダーとなるエンジニアマネージャーはプロジェクトマネージャーを兼務することもしばしばありました。
メンバーは東京と大阪での多拠点リモート開発です。
開発フレームワーク
スプリント1週間、スクラムイベントでのファシリテーターは持ち回り、バックログリファインメントなし、スプリントレビューなしという形式でした。 とはいっても、プロジェクトによってはチームメンバーが招集されてしまい、協働するということは少なかったと思います。
入社後に感じたギャップ
当時にアドミンユニットはチームではなくグループでした。
エンジニアが3人いて、各人の進捗を管理するマネージャーがいます。グループメンバー間で関係するのはレビューをお願いするときぐらい。 ステークホルダーから依頼されたチケットと、自分たちがやりたいチケットを効率的に消化していくチケット駆動開発というのが実体だったように思います。
また、ジョインしたてのやまざきは、ドメイン知識を一切もってない上に、10年ものの巨大モノリスを相手にすることになり少なからず圧倒されていました。
最初は時間はかかるがコードを読めば良いし、徐々にコードリーディングも早くなっていくだろうし、修正、改善も効率があがっていくだろうと考えてはいたのですが、と同時に何かが違うという違和感を飲み込んでいました。 このような働き方がChatworkにジョインしてやりかったことだろうか？ と自分が考えていることに気づきました。
Chatworkに入社したら、
「チャレンジングでイノベーティブなプロダクト開発をチームで成長しながら実現していく。仕事がエキサイティングになったらプライベートも充実してきました。人生がこんなにすばらしいなんてChatworkに入社しなかったら分からなかった！ 最終的にはプロフェッショナル 仕事の流儀に出演するほどになってロクロでも回しながら、『違う、実ははまだ60%しか力を出してない』などと青臭い虚勢をはっては、Chatwork新時代の幕開け始まったなと世間をざわつかせるエンジニアになる」
とやまざきは幻想を抱いていたのです。
自分のギャップを意識して、少しでも上述の馬鹿げた人生花畑状態にむけたアクションを起こしてみることにしました。
スクラムっぽいことに一歩踏み出す
やまざきとしては、『個人開発』は公私ともにお腹いっぱいだったので、チーム開発に向かいたい、とこっそり思っていました。その基盤としてスクラムがあったらよさそうかなと感じていました。
まずは「ふりかえり」をカイゼンできないかと思って、チームに提案してみることにした。
スクラムでもっとも大事なのは「ふりかえり」という認識でそこをまず整えたかった。継続的変化の起点は「ふりかえり」になると考えていたからです。 まずは「型」をこなしてこなれてきたところで、カスタマイズしていければ、という思いがありました。いわゆる、守破離の「守」からはじめようと。
しかしこの試みはうまくいきません。
ふりかえりは盛り上がらず、「困ったこと」はチーム外のステークホルダーとのコミュニケーション、連携に関わる部分、アドミンユニットの機能を越えたモジュール部分などのトピックが多い印象でした。 「良かったこと」「より伸ばしたいところ」もあまりでない。ポジティブイベントをお祝いもできないので、チーム感もでてこないということが続きます。
この結果を今さらながらふりかえってみると、スクラム、アジャイルの理解が不十分のまま、ふりかえりという「型」で整頓しようとしたアプローチが的外れだったことが原因だと思っています。
先輩エンジニア2人はすでにアドミンユニットでのエキスパートであり、1人で十分タスクをこなすことができました。コーディング、テスト、リリースのプロセスを回すことができていました。一方、チームとして何か変わっていく必要がある、という漠然とした不安や期待はあったと勝手に想像していますが、それを動機づけるような明確なゴールがアドミンユニットには設定されていなかったのです。
スクラムは経験主義に立脚しているのだから、まず型どおりのスクラムもやってみませんか？ というやまざきの提案は順序が違っていました。
スクラム、アジャイルはどういった背景をもとに出てきた考え方で何を解決し、何を解決しないのか、という最低限の説明の上、「とりあえずやってみませんか？」と提案すべきだったと考えています。もし、アドミンユニットメンバーだったころの自分にアドバイスできるなら、スクラムやアジャルの背景にあるものを（必要な限り何度も）説明しなければならないと忠告すると思います。
ただ少しだけ自己擁護させてもらうと、チケット消化に疲れていて「変化」を渇望していた時でした。新しいプロセスさえ始まってしまえば自分がスクラムの魅力を伝えていけるという過信がありました。
一方的な期待を押しつけても、互いに期待のギャップにストレスを感じてしまうだけなのだ、とやまざきが知るのはもう少し後の事です。興味があることに関しては手を動かすこと（経験）で洞察や発見は得られるけれど、興味がないことで手を動かしても、それらは得られないのです。
開発言語によるチームの時代
やまざきの入社後1年と少し。ユニット制での開発には課題が多く、2019年なかごろに開発言語ごとのサーバーサイド組織に再編されなおされることになります。
ユニット横断的な開発ができずにユニットに完結した部分最適にとどまってしまい、プロダクトの全体最適ができていなかったというのが最大の組織課題でした。
そこでPHP、Scala の開発言語ごとの組織に再編し、プロジェクトごとにチームをつくって開発を行うという形式に変わっていきました。
消費税増税プロジェクト
2019年10月に消費税率は8%から10％へと上がる。これにともなって各種料金を対応するプロジェクトです。プロジェクトは発足は同年6月ころ、少し時をおいてプロジェクトの開発チームが結成されました。
メンバー構成
ビジネスサイドのプロダクトマネージャー、PHP開発チームは4名（内、料金のドメインエキスパート1名、プロジェクトマネージャー1名兼務）となりました。
ただし、 プロダクトマネージャーは組織的に人員が不足しているためメインの業務と兼務の形となりました。東京大阪のリモート多拠点開発。
組織の属人性を下げる
プロジェクト外の要求として、料金周りのドメインエキスパートが少なすぎる、という課題があり、本件プロジェクトをドメインエキスパート＋PHPメンバー3人というチームにしてドメイン知識の属人性を低減する取り組みも並行して行われました。
知識移管のための多少のオーバーヘッドは許容したうえで、組織の『バス係数』（＝プロジェクトメンバーが何人バスに轢かれたらそのプロジェクトが破たんするか」という数値）を低下させることが目的です。
ドメイン領域の深さに圧倒される
料金周りのコードは過去10年の価格改訂、プランの追加、廃止、統合によって複雑になっていました。歴史的レジェンドコードが鎮座している一方、DDD的にリファクタされているコードも並存しています。 どういったユースケースがありどういった機能を提供されているか、というコードベースの一貫したアーキテクチャは曖昧な状態でした。 また本プロジェクトのスコープは、プラン、料金、会計にまでにおよび、それらを説明する用語はやまざきにとってﾁﾝﾌﾟﾝｶﾝﾌﾟﾝでした。
ドキュメントは他のドメイン領域にくらべて良く整備されていましたが、最新化されていない部分もあり、実装仕様とドキュメントの仕様が常に同期が取られているわけではありません。過去数百年に渡ってダークウェブ界のドキュメント魔と言われ、すぐに魔が差して図表をつかったドキュメントを残して可視化された形式知を闇雲に残してしまうやまざきとして誤解のないように言っておくと、ドキュメントはまだ絶対的に必要だと思います。
本題ではないので自分の考えていることを一言で言うと、「常に最新化され動くドキュメントとしてのソースコード（テストケースを含む）」が理想で、原理的に説明不可能な部分をドキュメントに残してメンテナンスし続ければかなり効率的だと思いますが、それは人類には早すぎると思っています。（個人の感想）
初めてのリモートモブワーク
開発チームのドメイン知識が大きく断絶している対策として、チームはモブワークを取り入れるというチャレンジをすることにしました。
当時、Chatworkのプロダクト開発はエンジニアのリソース効率で決定されていました。「◯◯◯さんが空いたからこのプロジェクトをやってもらいましょう」という意思決定がされていました。皮肉なことですが、当時のChatworkエンジニアがエキスパートすぎたのです。たとえ、開発エンジニアが1人でもプロジェクトを完遂できる能力を持っているが為に、私たちは特定の知識は特定のエンジニアにのみ集積されその知識は極端な偏っていたのです。そしてそれがプロダクトの価値向上のボトルネックになっていることに気づくのが遅れてしまっていたのです。
消費税増税プロジェクトではモブワークを採用したい、という開発チームの提案自体を受け入れてもらえたことは本当に大きかった。開発チームは新しい開発手法へのチャレンジに期待を持っていたし、新しい領域の開発を行えることにみんなワクワクしていたように思います。
モブワークは設計フェーズから開始しました。そもそも最初はスプリントプランニングすら混乱を極めました。Chatworkとて消費増税はこれまでにも何度か経験している、だからすぐにできるだろう、みたいな予測は「歴史的経緯」というレジェンド的壁によって簡単に覆される。プランニングポーカーであそこまでストーリーポイントが乖離したのは、やまざき人生史上初かもしれません。個人的にはプランニングポーカーで差異が出るのが楽しいです。その差異の分だけの学びをえるタイミングでもあると考えているからです。
その一方でこれは料金周り未経験メンバーにとっては最速でドメイン知識を吸収することができたと強く実感しています。ここでは未経験エンジニアの動機付けは一貫していて、歴史的経緯すらも解決したいという気持ちはどのエンジニアも変わりなかったからです。エンジニアは「イケてない」ものを「イケてる」ようにすることに関して異常なまでに長けています。偏執的といって差し支えない。また課題を正しくとらえるためにドメインエキスパートと一緒に用語集（≒ユビキタス言語）をつくれたことで、チームが同じ用語で話せるようになり、曖昧さがへったことでコミュニケーションが効率化しました。むしろ、用語が作れたからこそ、正しい実装に向けてモブプロができたと思っています。用語は前提だったのかもしれません。
そしてリモートのモブプログラミングの良さも感じました。リモートなりの難しさはやはりありますが、より品質の高いものをつくるためのモブプロとフロー効率、との評判に個人的実体験として納得できました。 リアルタイムでレビューが進む。レビュー待ちはない。なぜ、それが必要なのか？ こうしてみてはどう？ と現前にあるコードを前に問いかけるかけることができる。もし、モブプロではなく質問や疑問をプルリクエスト内でやったら、変更差分よりコメントが上回るだろう。それだけの学びのチャンスとよりよいモノをつくる提案が簡単にできたのです。
ドメインエキスパートというボトルネックから脱却し変化に強くなる
知識の同期やコード品質は申し分ない、だが開発チームは予定より作業が遅れはじめていました。 消費税増税というずらせない期日もありますし、かといってプロジェクトのスコープを小さくするにも限界があります。
そこでモブワークチームを複数に分割することにしました。ペアワーク、ソロワークをタスクの特徴にあわせてアサインし属人性を許容し開発速度重視の布陣を敷くことにしたのです。 これは、これまでのモブワークで知識を得たからとりえた布陣でした。 プロダクトを成長させるなら非凡なスーパープログラマではなく、愚直に正しい理解をするドメインエキスパートなのかもしれません。
消費税増税プロジェクトはスケジュールなど全体においてはカイゼンすべき点は多かったのですが、開発チームの働き方として新しい発見を得たプロジェクトでした。
当時、このドメイン領域ではドメインエキスパート起因のクリティカルパスによってプロジェクト期間の調整が困難になることが少なからずありました。短い期間のモブワークで、ある特定領域ならばタスク分割して工期を短縮するという選択肢が選べるようになった、というのは開発チームメンバーも感動していたのではないかと思います。
プロジェクト全体のふりかえりにおいて、開発チームメンバーがモブワークが良かったというポジティブ体験を共有してくれたのも、とても嬉しく感じました。
SuperNovaチームの結成
やまざきはそのあとも、料金周りのプロジェクトにかかわったり、すったもんだがあったり、ゆっくりしながら細々と開発を続けました。
そこで2020年後半、サーバーサイド開発部PHP部に新チーム結成の機運となります。 これまでの経験からやまざきのスクラム熱がどんどんと上がってきて、チームビルディングやらなんやらいろいろやった話はこちらにまとまっていますので、ご覧ください。
さてさて、SuperNova も結成から1年が経ちました。
残念ながら、故あってやまざき は現在 SuperNova から一時離脱していますが、SuperNova は今も元気です。きっと、この記事の call and response として、SuperNova メンバーがその後の顛末を記事にしてくれるんじゃないかと強く確信しています。（知らんけど
個人的Chatworkでの開発ふりかえり
自己組織化チームによるハイパフォーマンスでプロダクトをアップデートし続けていく、というやまざきのカイゼン活動はまだ道半ばです。 そんな中、個人的に難しいなと改めて思うことがあります。それはチームの心理的安全性です。組織パターンでいうところの「信頼で結ばれた共同体」といえるかもしれません。組織パターンでは「信頼で結ばれた共同体」はあらゆる組織の前提といっています。当然、スクラムチームも例外ではありません。
Chatworkではコロナ禍以前から他拠点開発でしたから「オンラインにおける信頼構築」を実現できる空気感は持っていました。とはいっても、拠点単位での対面によるメンバー内交流、拠点横断での対面プロジェクトチームのキックオフ、半期ごとの部署合宿、全社合宿という効果的な信頼関係構築の場が、「オンラインにおける信頼構築」を支えていたようにも思います。コロナ禍以降、Chatworkでは基本フルリモート勤務となり、いまではリアルで対面したことがない社員の方が多くなったような気がします。（コロナ禍以降、入社された方が多いというのもありますが）
そんな状況のなか思うのは、コロナ禍という変化もチームが成長する機会ととらえたいな、ということです。全員がフルリモートになったことで信頼関係が希薄になったとするなら、チームビルディングイベントをより高頻度にしてもいいし、ふりかえりを長くしてふりかえり手法を毎回かえる代わりに時間をいつもよりのばしてもいいかもしれないし、ハンガーフライトを週一開催してもいいかもしれないし、読書会を増やしても良いかもしれないし、単純にモブワークの休憩時間をふやして雑談を増やしても良いかもしれないし、チーム間の成果交流会を行っても良いかもしれない。
何にせよ、リアル対面よりも質が劣るのだから、なんらかムリのない範囲でその代替案を試していくしかないということです。
もっとチームが成長していくために
今現在、Chatworkの開発組織は変化への柔軟性が求められています。モノリスからマイクロサービスへ、フィーチャーチームへ、PHPからScalaへ。大きな変化のためにチームメンバーも流動的になります。
ある人がぬければチームは機能期から一気に混沌期にまで下落することもあります。そこからいかに回復するかもチーム力といっていいのだと思いますし、継続して成長し成果を出す、とはそういうことなのだと思います。そして正直なところ、Chatworkではそんなチームはまだ少数かもしれません。
最後にやまざきはチーム内でスクラムを推進しようとしたときに「スクラムはシンプルで難しくない」といってしまったことについて反省するところがあります。
そこで「スクラムはシンプルで難しくない」というのはルールが明確だからです。スクラムイベント、タイムボックス、プロダクトオーナー／スクラムマスター／開発チーム… でも、これらの用語の WHY を掘り出すと延々と続くソフトウェア開発組織の難しさが見えてくる。そこには表面的な解釈ではなく、メンバー全員の発言や行動、振る舞いを含めた洞察が必要なのではないかと思います。
そこで、チームに寄り添うきちんと専任のスクラムマスターをお迎えしたいと熱望しております。
消費増税プロジェクトで用いたモブワーク／モブプロのチャレンジは現在、開発言語をこえて社内開発チームでの開発手法の選択肢として認知されました。「リソース効率悪いからモププロはなし」というマネージャーは誰もいません。継続的にプロダクトを向上させるのに有効であるという共通認識が生まれたのだと思います。リソース効率からフロー効率へとシフトしたブレークスルーだったと思います。
次はスクラムマスターという支援を得てスクラムチームが自己組織化チームに飛躍する瞬間を目の当たりにしたいなと思っています。
さてそんなことをのたまってきましたが、Chatworkではすべてのスクラムチームの現場に専任のスクラムマスターを配置できていません。やまざきのいたチームでもスクラムマスターがいたら、客観的に相談できて知見を得ることができのかもと思ったりします。
Chatwork では Scala各開発チーム、PHP各開発チーム、フロントエンド各開発チームで、一緒にChatworkの成長を加速させてくれるスクラムマスターのみなさまをお待ちしております！
