こんにちは。BASE BANK 株式会社 Dev Division にて Manager をしている東口（@hgsgtk）です。

昨年 2020 年は本ブログにて個人の足し算ではなく掛け算で成果が出せるようなチームを目指したアジャイル開発の取り組みを継続して紹介してきました。

これらの考え方やプラクティスは全体の一部で、開発チームとしての組織ローカルなプラクティスを『BANK DEV 白書』として整理しています。『BANK DEV 白書』では次のような内容を整理しています。

一般的なアジャイル文脈のプラクティスで出てくる概念の実用の仕方
- ex.「ストーリーポイント」を用いるシーン・ポイントの付け方
オリジナルな開発プラクティス
- ex.「井戸端会議」・「TODO コメントのチケット化」

これらは主に振り返り（レトロスペクティブ）にて発見し、その結果をまとめることで積み上げてきました。本記事ではこのプラクティスをブログとして公開します。

知見の積み上げ『BANK DEV白書』

この取組が始まったのは、「なんでこの取組・プラクティスをやっているのか」という認識が人によってブレることを防ごうとしたことがきっかけです。

たとえば、「ペアプログラミング」という 1 つのプラクティスを手にとってもそれぞれ個人が感じる認識・温度感は違います。しかし、「私たちは設計等迷った際のコミュニケーションツールとしての意義に重きを置く」ということが言語化されていれば「ペアプログラミング」という語彙を会話の中で使いやすくなります¹。

最初は GitHub 内にドキュメントを作成し随時更新し続ける運用としていました。しかし、ドキュメントでの運用は文章を書く心理的ハードルが高いため、基本的に発起人の @hgsgtk が書記となって更新し続けていました。

その後、継続していくうちにチームの文化定着がうまくいき『アジャイルの「ライトウィング」と「レフトウィング」』でいうところの 協働でゴールに向かう「チーム環境」 であるレフトウィングがしっかり生えてきたという実感がでてきました。具体的には、レトロスペクティブなど対話の場のファシリテータを持ち回りでやるようになりました。意識の高い個人が引っ張る構図からチーム自身が自身を成長へ引っ張っていく構図へと変わってきました。

そのため、現在は共同編集をより促進できるよう、より更新の負荷が低く各プラクティス間の関係性も明示しやすい Miro に移行しました。

ロン・ジェフリーズ氏が XP を描いた図である「Circle of Life」のように、ビジネス・チーム・技術という 3 つのリングに分類するといったカテゴリライズの必要性は検討しましたが、現場ではビジネスから技術までかなり密接となっており、まだまだ洗練されきっていないため、あえてカテゴライズしていない選択をしました。

一方で Martin Fowler 氏が指摘するような、技術プラクティスが骨抜きにされた「FlaccidScrum（ヘロヘロスクラム）」となることを避ける必要があるため、リファクタリングなどといった技術プラクティスも内包されるよう努めています。

前提: BANKチームが目指すあり方・戦略

上の『BANK DEV 白書』と紹介した Miro の画像には中心が定義されていました。この中心が前提となり目指すあり方と戦略です。

『小さなチームが始めたアジャイル開発』という資料にて、アジャイル開発を何故始めたかについてまとめています。

BANK チームでの思考プロセスは『みんなでアジャイル――変化に対応できる顧客中心組織のつくりかた』という書籍の考え方に最も影響を受けていますが、そもそもの自分たちの課題分析から始まっています。いわゆる「アジャイルをやってみよう」という入り口で考えておらず、課題定義と未来の理想像の定義から逆算した結果「アジャイルだった」という思考をしています。これを明文化したのが下のマップです。

これは BANK チーム固有の価値観定義なので、軽くサマリーするのにとどめます。「生き生きとした開発とはなんだろうか ²」といった問いについて議論し、個々人の達成感（個人）と関係各所との約束を守る事（全体）を両方満たすバランスの取れた開発の仕方が必要だろうとなりました³。

また、BANK チームでは「技術戦略」と呼称した短期的計画に依存しないエンジニアリング組織としての戦略を定義しています。

ここでは「柔軟」という漢字 2 文字を現在定義しています。現在次のような意図を設定しています。

システムの変更可能性を維持・向上すること
運用・監視の効率性を上げることでグロースや新規サービスに割く時間を増やすこと
新規サービス開発の際の作業量を減らす開発効率向上に務めること
チーム内での人の動き方を柔軟に対応できるようにすること

この「技術戦略」は四半期計画やその場での現場の意思決定に用いる用途で設定されています。

四半期計画における運用方法は以下です。

まず PdM がプロダクトとしてやりたいこと・開発メンバが「プロダクトに対して間接的だが技術的な課題」を用意
それらを INPUT に個々人がやっていきたいことを「野望」として決める
- 「野望」では四半期レベルに収まらないものも含めて個人目標を設定します

『駆け出しマネジャーの成長論　７つの挑戦課題を「科学」する』では、メンバーが同じ船に乗って納得感を持つためには計画に自分の意思決定が適度に反映される「対話空間」を用意することの重要性について語っています。技術戦略は対話空間を設計するための目線合わせのためのツールとなります。

さて、少し前置きが長くなってしまいましたが、これらの前提を踏まえてもう一度プラクティス図の概要を説明します。

まず中心に添えられているのが、「北極星」と「技術戦略」となります。

これらを中心に派生していくのがプラクティス図となります。

プラクティスの紹介

さて、それでは具体的な各プラクティスについて特に積み上げが多いプラクティスについて紹介していきます。

ストーリーポイント

「ストーリーポイント」はアジャイル開発において一般的に知られるプラクティスです。ストーリーポイント自体を軽く説明しますと、相対見積りの考え方に基づいたものです。必要な作業・複雑さ・リスク等を鑑みてポイント設定します。ストーリーポイントの考え方について体系的に知りたい方は、『アジャイルな見積りと計画づくり～価値あるソフトウェアを育てる概念と技法～』がおすすめです。

BANK チームではストーリーポイントの運用を続けて次の内容について更に言語化しました。

大きさの構成要素
Our 1pt（私達の 1pt）
Issue 作成時のポイント付与有無判断基準
ポイントが付けられない時
タスクもストーリーポイントでの見積もりを行う

「見積り」がソフトウェア開発において難しいテーマであるがゆえに、BANKチームでもレトロスペクティブを通じた積み上げが一番多くなっています。

大きさの構成要素

大きさの構成要素として「複雑性」・「量的要素」・「検証ループの回しやすさ」という 3 点があるとしました。

複雑性
- （例）複数クラスにまたいで触る
- （例）リポジトリの数がさまざま分散している
量的要素: 作業量の多さ
- 同質なものをたくさん並べる
- （例）テストコードをたくさん書く
- （例）脳死してコピペするような「量」
検証ループの回しやすさ
- 通常の作業よりも速度が落ちる
- ハマったときのリスクがある
- （例）Terraform だと検証ループが回しにくい

Our 1pt

ストーリーポイントは相対見積の概念であると前述しましたが、相対の比較基準となるストーリーを用意します。Robert C. Martin 氏の『Clean Agile　基本に立ち戻れ』では、これをゴールデンストーリーという語彙で紹介しています。

BANK チームでは現在 1pt を比較基準としており「だいたい半日程度で終わる程度のユーザーストーリー」をピックアップしています。前提としてユーザーストーリーは時間と直接マッピングされる概念ではないので厳密に半日であることに重点を置いているわけではありません⁴。概ねのチーム内の基準の認識合わせのために「半日程度」というニュアンスを利用しています。

この基準に基づいて使うポイントはフィボナッチ数列内の 1pt・2pt・3pt・5pt・8pt・?pt としています。

Issue作成時のポイント付与有無判断基準

Issue 作成時にポイントを付けるか、Issue を受け取った人がポイントを付けるかの判断基準を整理しました。

課題に対して解決策(HOW)がわかっている場合は Issue 作成者がポイントを付けてしまうことにしています。一方で解決策(HOW)がわかっていない場合は Issue を受け取った人が後述する「スパイク」を利用したりして、ポイントをつけることにしました。

タスクもストーリーポイントでの見積もりを行う

BANK チームでは Issue に 3 つのバリエーションを現在設定しています。

Epic / ユーザーストーリー / タスクの 3 つです。これについて、特にタスクレベルの見積について組織によって運用が異なるかと思います。たとえば、場合によってはタスクレベルでは理想日（絶対値基準である時間・日にちを用いる見積手法）を使用するパターンも考えられます。現時点ではあえてここを分ける理由と必要性が出ていないため、タスクに対してもストーリーポイントをつけて運用しています。

ここで、そもそもタスクについて見積もりを行うことの意義として BANK チームでは 3 つの理由を言語化しました。

手空きのヘルプ時の状況把握
ブラックボックス化の回避
ゴール設定の意識

実際この運用によって、個人の作業のブラックボックス化・ゴールの曖昧化が防がれ、協働での開発がスムーズになっていると感じます。

スパイク

ユーザーストーリーやタスクに対して、技術的な懸念や不明点によってポイントがつけれない場合があります。これに対して「スパイク」という手法を利用します。『Ryuzee.com: スクラムにおける技術的スパイクの進め方』では、次のように説明している概念です。

リリース可能なプロダクトを作るのではなく、質問に答えたり情報を収集したりすることを目的とした作業。開発チームが技術的な質問や設計上の問題を解決するための実際の作業を行うまで、見積りができないようなプロダクトバックログ項目が出てくることがあります。解決策は、「スパイク」を行うことです。目的は、質問に対する回答やソリューションを見つけることです。

いわば、ストーリーを見積もりためのストーリーと言えます。具体的には次のようなフォーマットで Issue を作成することにして、ISSUE_TEMPLATE にも登録して運用しています。

「Xxx のストーリーの見積もりをするため、Xxx を（検証・調査・把握）する」

このスパイクの使い所として、BANK チームでは歴史的経緯がある気がしたらすぐにスパイクを打つという使い方をしています（「スパイクを打つ」というのはスパイク活用の際の言い回しです）。

長年稼働しているソフトウェアに機能追加する場合は歴史的経緯はどうしてもあり、その歴史的経緯の発覚によって大幅な手戻りが発生し見積が大幅に上振れるリスクがあります。実際にプロジェクト運営の中で歴史的経緯にハマってしまった事例がありチームのプラクティス活用術として定義しました。

井戸端会議

これはオリジナルのチームプラクティスです。次のようなシーンで活用します。

何らかの問題が発生しているが次の方向性・やることは決まっていない場合や、使用可能な道具が目の前にあるがその活用可能性・活躍のさせ方についてアイデアが得られていない際に、その課題に対して、大まかな見解を得るための対話(Dialogue)を行う。

井戸端会議で行われるコミュニケーションは「対話（dialogue）」であると定義しています。『問いのデザイン: 創造的対話のファシリテーション』では、対話を「自由な雰囲気のなかで行われる新たな意味付けをつくる話し合い」であると定義しています。この定義の通りざっくばらんにトピックについて話し、方針が「なんとなく」決めることを目指します。

これまで次のトピックで開催されました。

OneLogin の活用
- OneLogin を活用してできることはなんだろう？
Go らしさ・サーバーサイドアーキテクチャ
- Go を活用する際のチームの認識合わせ
- OOP を前提とした戦略・戦術とのバランスをどう取るか
- サーバーサイドアーキテクチャ
Logging
- New Relic の活用を始める中でどのようにロギングを考えるか ⁵
- 次の具体的なアクションはどうするか

Go に関する井戸端会議の Miro の様子を一部チラ見せするとこのような話題をざっくばらんに取り上げました。

Go 井戸端会議の中では、自分たちのコードベースではどのように「値オブジェクト」を定義するか、といった具体的な実装指針が決まるところまで至れました。

チームメンバーの感想は次のようなものでした。

雑な情報交換が出来た
事前準備がいらなかったのがよかった、しないくらいのが認識が固定化しなくていい
ゴール・やりたいことも見つかった！
リモートで欠落しがちなコミュニケーションが補える

実際井戸端会議で行われた内容は、物理的に同じ場所にいれば自然と行われていた会話でもあります。しかし、WFH のなかでお互いリモート同士となるとそういったコミュニケーションが欠落しがちな点を、井戸端会議はうまく補ってくれています。

リファクタリング

リファクタリングは技術プラクティスとして重要な活動であることは言及するまでもありません。Martin Fowler 氏は「FlaccidScrum（ヘロヘロスクラム）」にて、リファクタリングなどの技術プラクティスを欠いたことで、開発速度が低下していく現象を示しました。

BANK チームとしてのリファクタリングにおける具体的なプラクティスとして「TODO コメントのチケット化」というものがあります。これは BANK チームの@applepine1125さんが社内ドキュメントに投稿したエッセイから始まったプラクティスです。

代筆してサマリーすると

人は時間がない・タスク分割の一時的メモとして TODO/FIXME コメントを書く
TODO/FIXME は回収する仕組みができないとまずい
チケット化することでプランニング等棚卸しで管理しやすくなり、リファクタリングを組み込めるようになる
それにより、TODO/FIXME の回収可能性が高まる

TODO コメントのチケット化は、いわば意識的にリファクタリングを開発に組み込むための基盤となるものです。その後自然とチケットを作らず無意識にリファクタリングが組み込まれる未来が来ることを見据えた点についても語っています。

開発のスケジュールの中で意識的にリファクタリングを組み込む。というやり方を積み重ねていくことで、最終的にチケットなんて作らなくても日々のフィードバックをもとに自然と正しくあるべき箇所に手が入るようになると嬉しいね。 by @applepine1125

『エッセンシャルスクラム』の第 8 章「技術的負債」は技術的負債について非常に有名で示唆に富む内容を語っていますが、その中では技術的負債の発生の管理、可視化、返済の重要性と適用方法について語っています。当プラクティスはその中の「可視化」に一役買うものと言えます。

実際に、実践すると次のような効果が得られました。

特に他の人と協働する時に活用したほうが良いとわかった
PR のときに気をつけるようになった
TODO の寿命を短くするように意識するように

ペアオペ・ペアプロ・ライブコーディング

開発中ペアで作業することについて、これまでのレトロスペクティブで「よかった」という振り返りがあったのがペアオペ・ペアプロ・ライブコーディングでした。

これらは都度都度コミュニケーションツールとして活用する方針としています。組織によっては常時ペアオペ・モブプロするといったところもありますが、BANK チームでは必要に応じての活用にとどめています⁶。

レトロスペクティブ

紹介するプラクティスの最後は「レトロスペクティブ（振り返り）」です。

レトロスペクティブでは 3 つのワークを行っていました。１つ目は「Mad Glad Sad」ですが、こちらは『チーム開発の潜在的課題が見つかる振り返りワーク「Mad Glad Sad(喜、怒、哀)」』にて詳説しています。

２つ目は「見積り振り返り会」です。この取組は「自分たちの見積もりに対してフィードバックループが回せているだろうか」という課題感から始まったワークです。見積りに課題感を感じた Issue を取り上げて次のような問いを重ね、原因と取りうる ActionItem をチームで見つけ出していきます。

なぜ見積り精度が微妙だったか
何が原因で想定よりも大幅に労力が必要だったか
どういう属性のあるものだったか
タイムマシーンに乗って昔に戻るなら何をテコ入れするか
今後どうすればよいとおもうか

当ブログで述べている見積もりに関するプラクティスはこの「見積もり振り返り」の結果が得られたものがとても多いです。たとえば、ストーリーポイントの大きさの構成要素は、このワークから発見されたものです。

３つ目は「KPT」で、振り返りワークの中で最も一般的なものと言えるでしょう。

それぞれのワーク内で 「難しいね」で終わらせないファシリテート を心がけようとしています。EVP of Development の@fshinさんの『部下に対して「難しいね」で終わらせないマネジメント』で提示したマネジメントの注意事項を参考にしたものです。

仕事に難しいことがあるのは当たり前当たり前の言葉を言わない簡単だったら、そもそもあなたに相談しない

レトロスペクティブにおける話の進め方についても同様に、「難しい」話題はあがりますが、難しいで終わってしまうとそこでフィードバックループは止まってしまいます。

プラクティスの積み上げ方

組織に限らず「成長」するために必要不可欠なのはただ実践するだけでは足りないと思っています。たとえば、『エンジニアの知的生産術』では具体→抽象→応用という学びのサイクルを提示しています。

レトロスペクティブは上図の「抽象」のフェーズでありスプリント内で経験した「具体」を分析して次の「応用」を発見することに意義があると考えます。BANK チームではレトロスペクティブで「ActionItem」をまとめますが、その ActionItem がプラクティスになるという概念整理によってプラクティスの積み上げを試みています。

つまり、レトロスペクティブの中で得られたアイデアを ActionItem として実践し、プラクティスとして昇華していくというやり方をしています。

この思考方法が開発チームを洗練させることにつながるかは、2021 年終わりに開発プラクティスの集まりをどのように進化させていったかによって評価されることでしょう。

おわりに

BASE BANK の開発チームでは日々「どうすればより良いプロダクトを作れるか」といったことを考え、フィードバックループを自分たち自身に回し進化していけるよう業務に邁進しています。

open.talentio.com

現場の雰囲気に興味を持っていただいた方はお気軽にカジュアルなお話をしましょう。@hgsgtk宛に DM 頂いても構いません。

語彙を育てていくという考え方は、クリストファー・アレグザンダー氏の提唱した「パタン・ランゲージ」をプロジェクトで行なう際、個別プロジェクトで調整した「プロジェクト・ランゲージ」を作成するという中埜氏の解説にインスパイアドされたものです。詳しくは『パターン・ランゲージ: 創造的な未来をつくるための言語』の「第1章建築におけるパターン・ランゲージの誕生」をご覧ください。↩
「生き生きとした」という問いは、クリストファー・アレグザンダー氏の建築理論におけるテーマである「生き生きとした場所をもたらすこと」という目的感に影響を受けて設定しました。 https://speakerdeck.com/hgsgtk/design-pattern-usage-inspired-by-pattern-language?slide=11 ↩
『エクストリーム・プログラミング』（俗に言う「XP 白本」）では、『プログラマーの生活を良くし創造的にいきいきと働くために XP を体系化した』と語っています。彼らの考え方にも強く影響を受けて現在の試みを進めています。 https://speakerdeck.com/hgsgtk/xp-is-social-change-in-timeless-programming-way?slide=21 ↩
『アジャイルな見積りと計画づくり～価値あるソフトウェアを育てる概念と技法～』では、ストーリーポイントの優れた点は作業量の見積もりと期間の見積もりを分けたことだとしています。期間の見積もりは規模（ポイント全合計）/ ベロシティ（1 回のイテレーションで完了させたストーリポイントの合計）などの計算式が責務をもっています。↩
BASE 社では New Relic プラットフォームを用いた取り組みを開始しています。具体的には CTO @dmnlk さんのこちらの資料をご覧ください。 https://speakerdeck.com/dmnlk/phpcon2020jp-observability ↩
実際、『Clean Agile 基本に立ち戻れ』にて Robert C. Martin 氏は、ペアプログラミングについて、ペアになることは任意であり強制されるものではないし、常にペアになるわけではない点を説明しています。一人でコードを書きたいこともあるので、個人・チームがどのくらいの割合で行なうか決めればいいと。↩