本ポストをXP祭り2017で発表したので、補足を含め要点のみを抽出してリライトしております。i2key.hateblo.jp本ポストはプロダクト開発における特定の文脈によるものなのですべてがそうだとは言っていませんのであしからず。バイモーダル戦略でいうところのSoE領域*1であり、学びによる改善サイクルをガンガン回していくようなモデル・フェーズを対象としております。TPSやLEANを現場で実践してる方々には今更なお話かと思いますが、DevOpsやアジャイル、リーンスタートアップを実践していく上で何周かしてまた原点の理解すると深みがますというかようやく、「ちょっとだけリーンわかる」ようになったので自分用のメモになります。共通の価値観としての「リードタイム」SoEライクな開発をしていると、仮説を立案し、そのための仮説を実証するための機能を実装し、リリースして計測、そして学びを得て仮説を補正する(別の案を試す)というサイクルをくるくる回すことになるかと思います。このようなときに開発チームとして目指すところは学びの回数を最大化することなのは自明かと思います。そのサイクル短くする、すなわちサイクル効率性を高めることが必要になります。サイクル効率には仮説の質等も影響も与えますが、今回はエンジニアが直接結果をコントロールしやすいサイクルタイム、言い換えるならば、学びまでのリードタイムを軸に考えていきます。スコープは学ぶまでのリードタイムであるため、Build部分のみにフォーカスするのではなく、Build-Measure-Learnの1回転をスコープとします。コードレビューで手戻りが頻発すればリードタイムが伸びますし、受け入れテストで受け入れられなければやりなおしになるのでリードタイムが伸びます。様々な活動は結果的にリードタイムに跳ね返ります。すごくラフですが以下のような開発プロセスのバリューストリームマッピングを例にします。LTはリードタイムを表しています。リードタイムとはプロセスが作業を受け付けてから、下流のプロセスに渡すまでの時間になります。PTはプロセスタイムで、作業者がひとつの作業項目を完了するのにかかる時間です。実際に価値が作り込まれているのがこのプロセスタイムになります。本当に価値を作っている時間はその一部になります。赤い部分が上記のBuild-Measure-LeanサイクルのBuild部分に相当します。エンジニアが直接結果をコントロールしやすい部分です。フロー効率性とリソース効率性の話あえて極端な例。A機能、B機能、C機能の実装それぞれ15人日かかる場合。複数のことを同時にやるとプロダクトが届くまでのリードタイムが長くなる。みんなに仕事が割り振られるためリソースの稼働率は高くなる。逆に、同時にやることを一つにすると、プロダクトが届くまでのリードタイムは短くなる。全員が同じことをやる場合、どうしても一時的に、手持ちがなくなる人が出て来るためリソースの稼働率は下がる。図ではCも3Weekのリードタイムで出してるが実際は、4週目とかにズレこむ感覚。ABCのリードタイムのトータルでは上側レーンよりは圧倒的に少ない。これはどちらが正解というわけではないです。この2つはQCDのようによくあるトレードオフの関係にあります。大規模開発のように大量のものを一括でドン!とリリースするような文脈だと、上記のリソース効率のパラダイムになります。そんな中でフロー効率性を高めるようなペアプログラミングを実施したいと提案しても、(リソース)効率落ちるだろと言われ却下されることは多いのではないでしょうか。逆にフロー効率性を高めて、学びまでのリードタイムを最小化しようとしているときに、偉い人が出てきて「リリース物は全部承認印が必要だ、だが、時間はあまりないので一括で見るからまとめて持ってきなさい」とかいわれると現場はフロー効率性を高めようとしているのにリソース効率性のノイズが入り、現場からはヘイトが高まるのではないでしょうか。ポイントとしては、タスクやデータ、物事の流れに着目し、それがうまく流れているかをカイゼンしていくことが大事です。一般的には、フロー効率性の目線で現場の課題を可視化していき、フロー効率性を高めると結果的にリソース効率性における課題も表出化され改善されることが多いです。ベースはフロー効率性を高める目線で活動しつつ、制約が現れたときにそれをコントロールの対象とするか、前提とおくかは重要(制約理論)です。Lean*2とかに詳しくは書いてあります。QCDのトレードオフなんて本当は無かったんだSoEライクな開発の座組において、QCDとScopeは「学びまでのリードタイム」という軸で見ると以下の意味を持つ。結論から言うとリードタイムという観点だとQCD全部大事。品質は悪いと基本的に手戻りを生むので速度に跳ね返る。手戻ってる時間は学びをうまない時間。品質を下げるという判断は学びの速度低下を許容するとこと。Quality:低下するとリードタイムを悪化させる(=品質下げるという選択肢がそもそも無い:固定)プロセス品質下げると手順ミス等により手戻りが発生しデリバリへのリードタイムが長くなる内部品質さげるとバグの発生、コードレビューの指摘、技術的負債による実装の複雑さなどにより手戻りや速度低下を招き、デリバリへのリードタイムが長くなる外部品質さげるとUXバグをうみ、本来検証したいことが検証できず学びまでのリードタイムが長くなる。跳ね返るが体制は基本的には固定であり頻繁に上下するものでないので固定になるケースが多い。学びまでのリードタイムの人件費と見るのであれば、少ないにこしたことはない。結果的にコストはリードタイムそのもの。Delivery:出来るだけ短縮したい(伸ばさない、短縮すべき対象)リードタイムそのものScope:一度にやる量を決めることでリードタイムが結果的に変わってくる大きくする(大きなバッチ)と、リソース効率性のバイアスがかかるため、一括でリリースは出来るが、デリバリまでのリードタイムは増える(前述の図の上側レーン)小さくする(1個流し)と、フロー効率性のバイアスがかかるため、小出しにはなるがデリバリまでのリードタイムは小さくなる(前述の図の下側レーン)QCDは調整ネジではなく、リソース効率性とフロー効率性が調整のネジこの文脈においてQCDは基本的に変数ではなく、ほぼ定数として扱うことになる。デリバリは早ければはやいほどいい。そこで調整ネジというか変数になってくるのがScopeで、一度に開発する(同時にリリースされる)対象の量とサイズがそれにあたる。それにより、リードタイムが上下する。調整ネジとは言え、学びへのリードタイムを短くしたいので、フロー効率性を高める選択をしたほうがよいのが本音。一度に開発する量が多い/サイズが大きいと、並行作業が発生する。チームメンバは担当する機能が割り当てられ、それぞれ別々の機能の開発をする。この時点で、チームは前述の以下の図の上側レーンを選択したことになる。プロダクトオーナーから起案された機能要望がとてつもなく大きいとかがこれにあたる。エンジニアは本能的に下記図で上側レーンのようにリードタイムが増えることを感じ、「もっと分割できないですか?」「必要最小限にできないですか?」ときいたりするが、「これ全部必要です。」といわれることが経験上あるはず。これに対して「エンジニアチームの生産性が悪い」「なかなかリリースされない」みたいな意見がでたりもする。この状況を作り上げている「1つ」の要因はバッチサイズの大きさである。これはチームがそうなることを選んだのである。POやプロダクトマネージャーはチームに大きな塊を渡した時点で、渡した側も何が起きるか、どういう選択をしたのかを把握しておく必要がある。P21にはリソース効率性に振り切っている状況を以下のような図で説明されている。なるように複数のフローユニット(タスク)に分割する。承認印が必要でなおかつ承認者が特定のタイミングでしか捕まらない。ここがボトルネックになってくるため、制約理論を活用することになる。【余談】最終的には改善していくとこの承認行為自体が不要になる場合もある(権限委譲等により)権限委譲については、いろいろなやり方がある。エンジニアリングにより、安全に失敗できるインフラを構築できればその枠内では権限委譲できる等。Toggleを用いて、社内のメンバのみに公開する設定で実装。ドックフーディングをして、問題なければユーザの10%に公開。そこで問題なければ全体公開等。これはエンジニアリング&インフラにより権限委譲を可能にするパターン。マイクロサービスアーキテクチャにて売上をあげている単位でマイクロサービス化(アーキテクチャレイヤ分割というよりは、ドメイン分割)。これにより売上責任を持ったクロスファンクショナルチームは、売上をあげる責任を持つと同時にプロセス権限が委譲される。一度に開発する量が少なく、サイズが小さい場合、チームは1つのことにフォーカスできる。1つの機能を全員で実装する。すると複数の機能を全員で実装していた場合よりも、とある1つの機能は学びまでのリードタイムが短くなる。チームへ渡される要件のスコープが小さければ小さいほど、チームの見積もりの確度は高まる。チームは自分たちの本来の適正な生産性で作業を実施できるようになる。P21には以下のような図で説明されている。1つのフローユニット(機能)にフォーカスして、その1つのフローユニットが受けられるリソース時間を最大化する。フロー効率性を向上させるプラクティスや事例カンバン(トヨタ生産方式)一個流し(トヨタ生産方式)WIP制限にて流す量を減らす(最適化する)WIP制限1にすることが目的ではない(最適な値にする)WIP制限を小さくすることのメリット・デメリットメリットフロー効率性に特化した改善が行いやすい。ボトルネックが可視化しやすい。デメリットWIPを1に制限すると生産ライン上のどこかでトラブルが起きた場合、後続ラインが全面停止する。デメリットではあるが、必ず異常事態を検知でき、後続に不良品が流れないと考えるとメリットでもある。ペアプログラミング二人で1つのことをするため、二人で別々のことをするよりも流れるものの数が半分&品質が上がる(副次効果で引き継ぎが不要になり、結果的に誰でもどんな作業もプル出来るようになる。こちらもフロー効率性に寄与する。FlagのコラボFeatureFlagを仕込んだプルリクのMasterマージで本番環境への自動デプロイ断片でのプッシュが可能になり、プルリクが小さくなる流れるもののサイズを小さくする効果(フロー効率性)対してGit-FlowはReleaseブランチが若干一括処理でありリソース効率性がある。早く間違いに気づく手戻りの最小化マルチタスクをやめるカンバンのWIP制限の話と同義バリューストリームマップバリューストリームマップにて、プロセスタイムとリードタイムを可視化。ムダを特定しフローを改善。クロスファンクショナルチーム他組織とのやりとりは基本的にバッチ処理になりがちであり、引き継ぎのムダが発生する。フルスタックエンジニアクロスファンクショナルチームの人バージョン。1人で全部できれば待ちのムダが省ける。フルスタックはある文脈では(笑)とされるが非常にフロー効率性が高い。etcまとめ仮説検証型でプロダクト開発を行う場合、学びまでのリードタイムを如何に短くするかが重要であるのはもう自明ではあり、目指す方向は「一個流し」(フロー効率性:高)である。「目指す」のであり「目的」ではないのがポイント。フロー効率性の極値である「一個流し」を目指すことで様々なムダが浮き彫りになり、それを解消していくと、結果的にリソース効率性も高まるのである。フロー効率性(流す量を減らす)をあげると、ライン上にタスクまちの人が増えて、何もしない人がうまれる。(リソース効率性悪化)リソース効率性(流す量を増やす)をあげると、ライン上に人まちのタスクが増えて、リードタイムが増える。(フロー効率性悪化)エンジニアリングに読み替えると、チームに渡される玉の量とサイズの大きさと、それを全員で一個を倒しに行くのか、ばらばらにそれぞれのタスクをこなすのか。)を調整ネジにすべき。結果的に、カンバンやスクラムがWIP制限だのプル型だのいっている理由やスコープで調整軸にするというあたりまえの話に結局戻ってしまったが、一周回って?基本を理解できたのでよかった。ツイートはてなブログをはじめよう!i2keyさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。