この記事は、 みらい翻訳 Advent Calendar 2021の15日目です。
みらい翻訳でEMをやってます、chika (@chika-mirai) です。
技術ブログを始めよう！と部内数名のメンバーと始めてはや4ヶ月経つのに初投稿ですみません。 Advent Calendarで尻を叩かれてようやく始めました。
この記事を書く動機
みらい翻訳の開発チームではリーンな開発を目指すという方針を掲げています。 その意図としては「ムダと過剰をなくしてリリース頻度を上げたい」というところにあります。
ただ、リーンな開発のために何をするか、何をすればリーンな開発になるのかといったことは「現場のみんなで考えようぜ！」という方針なので、日々のプロダクト開発で忙しい中、「リーンな開発に結びつく具体的なアクション」を生み出すのは難しいなぁという気持ちがあります。
もちろん、銀の弾丸はないので小さな改善を見つけて積み重ねていく、これに尽きるとは思うのですが、とはいえ長らく業界で語られてきた開発手法・考え方です。「明日から使えそうな、もうちょっと具体的なヤツ頼む」というのもどこかで本音としてはあります。
そもそもリーンな開発ってどんなものなのでしょうか。 EMの私が言うのも恥ずかしいのですが、自分の理解が乏しい自覚があるので、学ぶ必要性を感じていました。
そんな中、リーン開発の実際の事例を学べる書籍「リーン開発の現場」を読んで参考になりそうなところが何点か見つかったので、いくつかピックアップして、今の私たちの開発現場に活かせないかと考え書くことにしました。
リーン開発について
最初に、リーン開発とは何かということに一応触れておきます。
リーン開発（リーンソフトェア開発）とはリーン生産方式の考え方をソフトウェア製品に適用した開発手法で、 具体的なプラクティスやフレームワークではなく、「7つの原則」と、それを具体化する手助けとなる「22の思考ツール」として定義されています。
7つの原則は以下の通り。
原則1：ムダをなくす 原則2：品質を作り込む 原則3：知識を作り出す 原則4：決定を遅らせる 原則5：速く提供する 原則6：人を尊重する 原則7：全体を最適化する
さらに22の思考ツールは、これらの原則を具体化するための考え方・アイデアです。 中にはバリュー・ストリーム・マッピング（VSM）やリファクタリングのように広く普及している具体的な手法もありますが、 これらを考え方として理解しても、具体的な開発プロセスをイメージするのは難しいかと思います。
参考
リーンソフトウェア開発の７つの原則と22の思考ツールについて解説
書籍：リーン開発の現場について
そうすると、やはり具体的なプロジェクトの事例や現場で活用出来る実践的なプラクティスが欲しいなと思うのが正直な気持ち。 それにいくらかでも応えてくれそうな書籍がこちら。
発行されたのが2013年、取り上げられている事例が2010年前後のものなので、特にリモートワークが進みツールのデジタル化が一層進んだ今からするとやや懐かしい現場感もありますが、本質的な部分は変わらないので問題ありません。
今回はこちらからあくまで個人的に印象に残ったところや参考になりそうだと感じた部分をピックアップします。
プロジェクトの概要
最初に本書で取り上げられた事例について一言触れておくと、スウェーデンの国家警察機関でのPUSTと呼ばれるデジタル捜査報告システムの開発プロジェクトにてカンバン開発を適用したというお話です。
PUSTは現場での捜査報告を紙ベースから迅速にオンラインで行えるようにしたことで、現場警察官の働き方と事件処理時間の圧倒的な効率化をもたらした、今で言うこれぞDXのお手本というような改革プロジェクトです。
このプロジェクトでは開始から1年で最初のリリースを実現した上に、その後2ヶ月ごとにリリースするという、年単位で計画・実行される政府系の大規模プロジェクトでは到底考えられないスピードで開発が進んだということです。
チーム編成
チーム構成、人数規模はざっとこんな感じ。
- Prjメンバー30〜60人
- 5チーム（+α）
（出典：[8/14] スケールするプロジェクトと継続的改善 〜Kanban & Scrum & XP – Agile2012 現地レポート(18) *1 ）
上記構成から単純計算すると、各チームのメンバーは6〜12人。 10人を超えるとちょっと多いかもしれませんが、6-10人くらいと考えると理想的な人数です。
みらい翻訳の開発チームも最近チーム編成を変えたので、他企業のチーム構成の話がめっちゃ気になります。詳しい話は機会があれば別途取り上げますが、1チーム（グループと呼んでいます）人数がやや少なくグループ数が多いので、今後の参考にしたいです。
職能別チーム → 職能横断チーム
ただ、PUSTのチーム編成は最初から上記の構成だったわけでありません。
当初は担当する作業、すなわち要求分析、開発、テストの3フェーズでチームを分けていたのですが、チーム規模が大きくなるにつれて、こんな課題が顕在化しました。
- コミュニケーションコストが高くなり、チーム間で会話より文書を使いがち
- 問題の押し付け合い
- プロジェクト全体を見ずに自分たちの仕事だけ考えるため、前後プロセスに協力しなくなる
結果としてチーム間での連携が悪くなり、メンバー増加に対してスケールしなかったということです。
（出典：[8/14] スケールするプロジェクトと継続的改善 〜Kanban & Scrum & XP – Agile2012 現地レポート(18)）
これをスクラムのような職能横断型チームへ進化させることによって、コラボレーションの質が劇的に改善したということです。
また、職能横断型チームだけにするのではなく横断系チームはきちんと残し、機能開発チームに参加する役割と「システムの全体像」を見る役割を両方持たせることで、短期的な機能視点と長期プロダクト視点のバランスがとれ、うまくスケールしたとのことです。
この課題は作業フェーズでチームが分かれていると必ずと言っていいほど起きる問題なのでよく分かります。
みらい翻訳では「フルサイクルエンジニアリング」を目指しており、それはまさに各機能開発チームを自律的な職能横断型チームとして開発サイクルを回せるようにしようとする考え方なので、この小さな職能横断型チームを作ろうとした考えにはとても共感できます。
※リーン開発 と フルサイクルエンジニアリング（フルサイクル開発）はそれぞれ別の視点からチームづくりや開発プロセスの考え方を提唱した概念で、相反するものではありません。ややこしくてすみません。
一方、すべてを職能横断型チームにするのはサイロ化のもとにもなり「隣のチームで似たようなことをしている」といった車輪の再発明も起きやすくなります。ある程度の規模になると職能別チームを作ることのメリットも大きく、PUSTの事例で要求分析チームとシステムテストチームを残した理由がそれに該当します。HIGH OUTPUT MANAGEMENT でもハイブリッドな組織構造は不可避と言われていますが、結局、ハイブリッドなチームにした上で、そのバランスや連携の仕方をいかに工夫するかを考えるのが重要なのだと思います。
デイリーカクテルパーティー
毎朝、プロジェクトメンバーがあらゆるところでスタンドアップミーティングが行い、15分毎に組み合わせを変えて続いていく様子を表現してこう呼んだそうです（ネーミングがオシャレ！）。
ミーティングの構成は以下3段階です。
- 第1段階：機能開発チームのスタンドアップ
- 第2段階：スペシャリティ同期
- 第3段階：プロジェクト同期
- プロジェクトの全チームから1名参加してプロジェクト全体の状況を確認するMTG
- チーム間のコラボレーションに関する課題を早期に解決するのが目的
（出典：[8/14] スケールするプロジェクトと継続的改善 〜Kanban & Scrum & XP – Agile2012 現地レポート(18)）
こうすることで、縦（機能別）・横（職能別）の情報共有をそれぞれ行った上で全体で共有するという流れができます。
みらい翻訳の開発チームでは、毎朝全グループメンバーが集まる朝会を行っています（下記参照）。
全員での朝会はリモートワーク下での一体感の醸成としての目的のほうが強めなので最初に行っており、各グループでの朝会がその後に行われます。
ただ、グループ間の課題や情報連携のために都度ミーティングを設定するのが手間になっているのを感じていたのと、「隣のグループが何をやっているかがよく分からない」という声がメンバーからよく聞かれたので、チーム再編成を行ったのをきっかけに、上の「プロジェクト同期」を参考に2つのミーティングを設置することにしました。
- 各グループのリーダーで集まるミーティング（週1回）
- 全員で集まって各グループごとの開発状況やリリース内容などを共有するミーティング（隔週）
これらはデイリーで開くほどは必要ないですし、ミーティングをいたずらに増やしたくはないので、それぞれ必要最低限になるようにしています。
プロジェクトの進め方
PUSTのプロジェクトはカンバン方式と言いつつ以下のような進め方をしており、「スクラムに近い」という表現をしています。
スクラムと言っていないのは意図的にスクラムで始めていないことの他、2,3点目がスクラムの進め方と違うからだと思われます。
なお本番リリースが2ヶ月ごとなのは、ユーザーの受け入れテストが2ヶ月に1回のペースであるためで、プロジェクトのコントロール外であったということです。
みらい翻訳の開発チームではスクラムを採用しています。グループごとに2週間のスプリントを回していますが、リリースに関しては開発プロセスの課題やステークホルダーとの調整などが必要なことにより現状はまだ2週間で行えるようにはなっていないため、状況は違えど近しいものを感じます。
ワークフローの可視化
PUSTではプロジェクト全体のワークフローの状況は、長さ数メートルにもわたる巨大なプロジェクトボード（物理のカンバン）で可視化されていました。 ボードは、要求分析→開発→システムテスト→受け入れテスト→リリース のフローに沿った列（ステージ）で構成されていて、ボトルネックがあると誰の目にもわかるような工夫も色々されていたようです。
（出典：[8/14] スケールするプロジェクトと継続的改善 〜Kanban & Scrum & XP – Agile2012 現地レポート(18)）
物理カンバンのメリットはなんと言っても圧倒的な存在感と視認性で、プロジェクトメンバーはもちろんプロジェクト外の社内関係者にも状況が一目瞭然なので、特に炎上してるときにはよく使われるイメージがあります（笑）。
2021年現在では平常時のワークフロー管理をアナログで行うことのメリットが少なくなってきたことと、コロナ禍でリモートワークが進んだことにより、このような物理カンバンを使うケースはあまりないと思いますが、JIRAやMiroでボードを作って毎日朝会で全員見るようにする習慣を作ることで、チームで仕事をしている感は上がると思います。
技術課題はコツコツとさばく
技術課題＝技術的負債の返済と解釈してほぼ間違いないと思いますが、DBやライブラリのアップデート、コードのリファクタリング、昔作った機能に対するテスト自動化など、技術課題の取り組み方についても、PUSTではチームでプランニングする際に、「次に開発する10の機能」と「次に解決する5つの技術課題」を決めるようにし、機能開発と技術課題解決のバランスを取るようにしていたそうです。
ビジネス側の状況などからどうしても機能開発の方が先にスケジュールが切られてしまい、技術課題の優先度が上がりにくくバックログに停滞するというのはよくありますが、そうやって後回しになった技術課題は時間とともに1つ1つが重くなります。
限界を迎えたある日にプロジェクトを組成して一気に解決を図るというのもまたよくありますが、
- 一定期間リソースが技術課題解決にロックされ、機能開発がストップするためビジネス側の理解が得られにくい
- 楽しい作業になりにくいのでメンバーのモチベーションが下がる（最悪、離脱にもつながる）
という問題があるため、あまり良い解決策ではありません。
アーキテクチャのリプレイスなど、どうしても大きなプロジェクトになるケースもありますが（この場合はエンジニアは楽しい）、そうでない小さな技術課題については、こういったプラクティスを参考に日々の開発に取り入れていくのが大事だと改めて感じます。
なお、このプラクティスのキモはプランニングの際にタスクの一定割合に必ず技術課題を入れることですが、前提としてバックログにきちんと技術課題を着手可能な状態で整理しておくことが重要であることも読み取れます。
ちなみに、バグについても「次の5つの技術課題」と同様に「次の5つのバグ」として着手可能なものを選定し解決していくということです。 （もちろん、機能リリース可否を左右する致命的なものや、追加機能を開発するより修正が先決と判断されるものはプランニングに関わらず最優先で対応）
WIP制限
カンバンでは一般的なプラクティスではあるのですが、ボードの各ステージには1チームあたりの仕掛り作業（WIP）の制限を設けられていました。目的は以下の2点。
- 過剰なマルチタスクの回避
- 後続のプロセスに負荷をかけすぎない
なぜWIP制限が重要なのかはこちらに簡潔にまとめられています。
また、マルチタスクの問題は「リソース効率性」重視の考え方であり、「フロー効率性」を悪くすることになってしまいます（しかも現実問題としてリソース効率性がよくなるとも限らない）。
フロー効率性とリソース効率性については参考になる記事がたくさんありますが、ひとまずこちらを参考に。
厳密にどちらが良いかというのはケースバイケースではあるものの、結局のところリソース効率性重視のマルチタスクにより、リーンな開発を目指すにあたって「速く提供する」原則に反してしまうというわけです。
みらい翻訳の開発チームでは個人のマルチタスクを推奨することはまずありませんが、開発チーム全体で見た場合に、機能開発を行うグループの数だけ並行開発（マルチタスク）していることにはなるので、プロダクト全体でのフロー効率性を上げるために機能の優先順位付けをもっと意識する必要があります。
機能課題だけWIP制限する
これは、WIP制限をかけるのは機能課題だけで、技術課題とバグ修正にはWIP制限を適用しないルールです。
- バグ修正を制限外にする理由は緊急対処しなければならないことと、課題が小さいため。
- 技術課題を制限外にする理由は
(1) 機能開発がWIP制限いっぱいで取りかかれない時に技術課題に取り組んでもらうため
(2) ベロシティを計算する時に機能だけを含めているため
これは、私たちも今まで結果的にこのようにやっていたものだったりしますが、明文化されていないプラクティスでもあったので改めてチームで活用していきたいです。
カンバン開発のイメージ
WIPを踏まえたリーンなカンバン開発の流れをわかりやすく例示したものがこちらに掲載されています。独り言などがコミカルで現場の雰囲気が出ています。
5分で理解するリーンな「かんばん」leantrenches.wordpress.com
サイクルタイム計測
PUSTでは、ある機能が「次の10機能」から「受け入れテスト準備OK」に到着するまでの時間を計測していました。 本番リリースまでのサイクルタイムを計測しなかった理由は、先程も触れたように2ヶ月に一度のリリース日付ががっちり決められていて、リリース1,2週間前から受け入れテスト期間に入ってしまうため、「受け入れテスト準備OK」までしかコントロールできないからとのことです。
私たちのチームでもリリースタイミングがコントロール出来ない場合はありますが、基本的に自分たちでリリース時期を決めて調整していくことが多いので、リリースまでをサイクルタイムとして計測したいと考えています。いくつかの機能開発案件のふりかえりとしてVSMで各開発プロセスを可視化したところなかなか反響があったので、今後どうやって効率的にVSMを作っていくかを試行錯誤しているところです。
まとめ
本の感想を書くだけのつもりだったのに大変長くなってしまいました。
カンバンとスクラムでのお作法の違いなどは多少あるものの、普段のスクラム開発の進め方やルールについてはもちろん、組織作りとしても色々と参考になると感じさせてくれる内容でした。
ここまで読んでくださった方で日々スクラムやカンバンで開発を行っている方々はご自分のチームと比較していかがでしょうか。
「ウチではこうやっているよ！」という話をしていただける方などいましたら、ぜひカジュアル面談にお越しいただき、お話しいただけると嬉しいです。
みらい翻訳では、一緒に開発を進めてくれるエンジニアを募集しています！
ご興味のある方は、ぜひ下記リンクよりご応募・お問い合わせをお待ちしております。
*1:Agile2012で本書の著者Henrik Kniberg氏が行ったセッション「Lean from the Trenches: Managing Large Scale Projects with Kanban & Scrum & XP」の現地レポート記事で、掲載された画像の大元はセッションのスライド資料。
