ちゅらデータアドベントカレンダーの3日目はたまーに社内で話をするTOCの話を少ししようかなと。
TOC知ってますか？
TOC知ってますか？
最近の人は知らない人が多いかもな。
すこし年いってる人は「あー、TheGoalっすよね？」って言ったり、一部の大きな会社だとほぼ必修みたいな感じになってるから、知ってたりするだろうか？
今日はそんな古の技術TOCを使って開発チームの業務改善をする話。
開発チームの目的はなんですか？
開発チームの目的は、新しい開発成果物を顧客に届けること。
違う？
…
違うわけ無いですよ！
…
そうですよね？
そう、リリースですよ。
たぶん動くからリリースしようぜ！のあれです。
単位時間あたりどれだけのリリースができるか。
それが開発チームのKPIですよね？
リリースを妨げるもの
それはレビューです。
…
おい、そこ、物を投げてくるな！
だって、レビュー待ちとかありません？レビューがあと1時間早ければ、リリースも1時間早くできません？
え、そうですよね？
…
そうですよ。
めっちゃくちゃ端折って言うとTOCというのはこういう全体のスループットを下げる部分をボトルネックって呼んで、そこを改善して全体のスループットをあげようという話です。
TheGoalという本だとボトルネックを制約と呼んで、それを制約理論(Theory of Constraints=TOC)と言うわけです。
よくあるリリースを妨げるやつら
（ここから啓発本のノリ）
業務改善するなら、最初にボトルネックを探そう。
たぶんたくさんWIPやPBIが溜まってるところが怪しい。
とはいえチームによって違うから、後で上げる例にばかり気を取られてはダメだ。
ボトルネックは予期しないところにあることも多い。
リリースを1秒でも早くできる何かを見つけたらそれはボトルネックかもしれない。
まぁ、だいたいボトルネックだ。
逆に「でも、これ早くしても、リリース早くならないよな？」っていうのはボトルネックじゃない。
頑張って見分けよう。
たとえば下記のようなところでボトルネックをよく見かける。
- 自動化されてないテスト … 毎回リリースするために人手でテストしてる。新機能のリリースは手動テスト待ち。
- 安全じゃないデプロイ … デプロイ怖いからいくつかの新機能をためてデプロイしよう。
- レビューする人がぜんぜんレビューしてくれない … リーダーは忙しい。レビュー対象のPRがどんどん溜まる。
- この機能はあの人しか作れない … キーマンはいつも忙しい。作りたい機能のPBIはどんどん溜まる。
対策は簡単だけど、難しい。
開発チームは業務改善をするために覚悟を決めて進まないといけない。
かっこいいな。
自動化されていないテスト
テストコード書け、今すぐ。
自動テスト組め、今すぐ。
安全じゃないデプロイ
誰でも気軽にデプロイしたり、戻したりできるようにしろ、今すぐ。
レビューする人がぜんぜんレビューしてくれない
これは色々やり方がある。
たとえばペアプロして、レビュー不要にしよう。
というかほんとにリーダーがレビューする必要あるのか？
レビューのために時間をさくんだ。レビューアーはレビューが本業だ。
いっそ、ビズサイドも巻き込んでモブワークしてWIP1のチームにしたら、ボトルネックはなくなるんじゃないか？
この機能はあの人しか作れない
トラックNo.1だこれ。ほっとくと別の意味でも不健全。
ナレッジトランスファーしよう。
そうして、開発チームは
ボトルネックを解消したり、逆にボトルネックを中心に業務を回すようになると、とてもリリースサイクルが上がる。
ハッピーだ。
とはいえ当たり前過ぎて、TOCを知らなくても、上記のような業務改善はできるかもしれない。
別のチームでは
さて、ではTOCを知らないチームの業務改善を見てみよう。
- テストは手でやるから大変なので、いくつかの機能をまとめてテストしよう！（よし！効率がいい！）
- ついでにデプロイもまとめてやったほうが効率が良いからそうしよう！（よし！効率がいい！）
- リーダーの承認がもらえるまでPRのマージは禁止だ！（よし！品質担保だ！）
- これ関係の機能は、あの人しか作れないから、月に3個までしかPBIを受け付けない！（なんだこれは？でもたまに見る）
うん、いまいちだな。
でも現実にはたまに見かける意思決定だ。
きっといろいろ事情があるのだろう。
ボトルネック以外の改善について
さて、ここで、悲しいお知らせ。
…
「ボトルネック以外の改善は無意味」
…
なぜなら改善してもリリース数が増えないからです。
さっき、業務改善をするなら、「最初にボトルネックを探そう」と言ったのはこれが理由。
たとえば部長の承認を待たなきゃいけないチームがいくらたくさんの機能を短時間に作れるようになったって、一日に部長が承認できる機能が1つまでだったら、それ以上多くの機能をリリースすることはできないだろ？
現実は無情だ。
だから、ボトルネックを探す。その後ボトルネックをどうにかする。
こういうムーブが正解で、改善対象がボトルネックじゃなかったら、意味があんまりない。
え？ボトルネックをどうにもできない？
…
よかったじゃないか、君のチームはこれ以上パフォーマンスを上げる必要がないところまで、改善しきっているんだ！
はりきって前向きな気持で次の職場を探そう！
さて、業務改善をバシバシやっていくと作業工程感の同期タイミングがシビアになって、チームにプレッシャーが漂うかもしれない。（はやくレビューしろよ！PR出したらすぐ連絡くれよ！などなど）
開発チームは工場の機械じゃないから、グルーミングは大事だとは私も思う。（プログラマはみんな猫みたいなものだから）
最近の研究ではこういう業務改善よりは、本質的な心理的安全性の高い率直な意見の飛び交う開発チームにしたほうが生産性が高いことがわかってきてるから、あくまでTOCベースの業務改善はツールの一つでしか無いのだろう。
さてCCPMを知っているか？
ちょっと上で書いた業務改善とは別なのだけど、TOCをベースにしたプロジェクトマネジメントの手法にCCPMというのがある。
これも工程間の同期についての知見や、プロジェクトバッファや合流バッファの採用、そしてボトルネックになるリソースに人を含めるアイデアなど、学ぶべきことが多い。
もしTOCに興味を持ったのなら、CCPMあたりから入門して、見るといいかもしれない。
おわりに
今日の小話は。
もう終わりです。
TOCいいですよ。
ちゅらデータでは相変わらずクレイジーな仲間を募集しています。
こういうTOCの知識を持ってお客様の業務を分析して改善に取り組んだりしたいなって人いたらぜひお声がけください。