リーンの哲学と現代的なエンジニアリングの知見を活用トヨタ生産方式から生まれたリーンの哲学と現代的なエンジニアリングの知見をソフトウェア開発に活用することで、エンジニアリングをより加速させるシンプルなアイデアです。開発プロセスでこんな課題に心当たりがある方が対象です開発が思った通りにすすまない開発プロセスを定量的に可視化できていないため、正しい現状認識が行えていない。開発プロセス内で問題が発生しても検知できておらず、リカバリーを行えていないので、開発後半に問題が発覚する。機能開発のリリースするのに時間がかかる一つ一つの開発対象の機能が大きかったり、リリースの頻度が低いため、機能開発に着手してからリリースされるまでに時間がかかっている。リリースのコストが高く、障害解決に時間がかかるリリース単位が大きい場合、リリースのコストが高かったり、障害が発生した場合に、リリースに含まれている機能を把握し、問題の切り分け等の必要が発生するので、復旧までに時間がかかります。まずは2つの開発スタイルを比べてみましょうエンジニアの稼働率を重視した開発%3Ciframe%20width%3D%22560%22%20height%3D%22315%22%20src%3D%22https%3A%2F%2Fwww.youtube.com%2Fembed%2FTg4tYmR3rF0%3Fsi%3DlBGUeOTNPHfMvKnl%26amp%3Bcontrols%3D0%22%20title%3D%22YouTube%20video%20player%22%20frameborder%3D%220%22%20allow%3D%22accelerometer%3B%20autoplay%3B%20clipboard-write%3B%20encrypted-media%3B%20gyroscope%3B%20picture-in-picture%3B%20web-share%22%20referrerpolicy%3D%22strict-origin-when-cross-origin%22%20allowfullscreen%3D%22%22%3E%3C%2Fiframe%3E稼働率を中心にしたリソース効率型の開発は、分業化によってすべてのリソースが無駄なく常に稼働している状態であり、一見すると効率が良いように思われます。しかし、一つひとつのタスクに注目すると、実は誰にも着手されずに積まれているだけの状態や開発中の時間が長くなり、リリースまでに時間がかかっていることがわかります。手戻りがあった場合はさらに待ち時間が増え、エンジニア間のコミュニケーションコストも高くなります。また、エンジニアが個別にタスクを持つことで、優先順位が曖昧になり、スタックしている状況が可視化されづらいという課題があります。フローを重視したリーン開発%3Ciframe%20width%3D%22560%22%20height%3D%22315%22%20src%3D%22https%3A%2F%2Fwww.youtube.com%2Fembed%2FxVR68VrGkPA%3Fsi%3DCfXqL_oIz2fQDBq7%26amp%3Bcontrols%3D0%22%20title%3D%22YouTube%20video%20player%22%20frameborder%3D%220%22%20allow%3D%22accelerometer%3B%20autoplay%3B%20clipboard-write%3B%20encrypted-media%3B%20gyroscope%3B%20picture-in-picture%3B%20web-share%22%20referrerpolicy%3D%22strict-origin-when-cross-origin%22%20allowfullscreen%3D%22%22%3E%3C%2Fiframe%3Eユニットを中心にしたリーン開発は、チームで一つのタスクに取り組むため、一見すると効率が悪いように思われます。しかし、一つひとつ機能開発は、着手されてからリリースするまでに無駄な時間が一切発生せず、完了までが迅速で、フロー効率が高い状態を作ることができます。また、常に同じタスクを扱っていることでエンジニア同士のコミュニケーションコストは低く、チーム全体でタスクを管理しているため、状況が把握しやすく、優先順位もつけやすいというメリットがあります。フロー効率を向上するためのリーン開発を支援できるのがHi-Outcomeです。どうしたらリーン開発を行えるのか？チームで一つのタスクに取り組むため、一つひとつのタスクにかける時間を最小にすることが重要です。そのために、以下の3点を徹底することが肝心です。開発のバッチサイズを小さくする並行作業を減らす可能な限りプロセスを自働化するこの3点を意識できるようにするために、Hi-Outcomeはユニットごとの「リードタイム」を可視化して、開発業務の改善を支援します。リーン開発を後押しするリードタイムの可視化「リードタイム」を可視化することで開発プロセスを透明化し、改善できるポイントを見つけていくことができます。ここで言う「リードタイム」とは、first commitからデプロイまでの時間である「変更のリードタイム」を指します。Hi-Outcomeは機能ごとの変更のリードタイムを可視化し、プロセス内のムダやボトルネックを特定及び原因分析を行こなえるサービスです。開発のボトルネックを明らかにし、施策の効果を判断することを支援します。リードタイムを縮め、開発スピードを向上させるポイントポイント1：バリューストリームを明らかにし、リードタイムを短くするバリューストリームとは、「機能や製品が顧客の手に渡るまでの、付加価値を与える一連のプロセス」のことです。顧客が本当に欲しいものは、顧客に使ってもらうまでわかりません。そのため、バリューストリーム全体が早く流れるようにすることで、顧客に早く機能を使ってもらい、フィードバックを得ることがとても重要です。例えば、変更リードタイムの中に以下のようなムダを特定することで、改善ができます。開発間の待ち時間プルリクエストを出してからレビューを受けるまでの待ち時間レビューを受けてからそれを反映させるまでの待ち時間QA依頼をしてからQAが着手するまでの待ち時間QA完了後から本番環境までにデプロイするまでの待ち時間プロセス上の「待ち」や「過負荷」を可視化し、タスクのサイズが大きすぎないか、並行作業が多すぎないか、自動化によってよりスムーズに開発を進められないか等を検討し、ムダやムリを一つずつ取り除いていきましょう。ポイント2：ボトルネックを特定し、解消していく「待ち」や「過負荷」として可視化された場所には、開発におけるボトルネックが隠されていることが多いです。全体のスピードを遅くさせ、ミスを生じさせるボトルネックを解消するためには、仕組み化や自働化が効果的です。過負荷を発見し、過負荷の解消にエンジニアリングリソースを投下することは質を上げるという観点で非常に重要です。質に投資することで、ムリなく安心してプロダクトがリリースできるようになります。CI / CDパイプラインやテストの自動化リリースフローを自動化することで、リリースコストが下がるので、小さくした開発単位のまま、リリースが行えるようになります。リリースコストが高いとどうしてもリリースの単位が大きくなります。リリースの単位が大きくなっていくと、開発の単位も大きくなるバイアスが働きます。また、繰り返し行う作業を自動化することで、もっと大切なことに時間を使えるようになります。スクラムやXPやDevOpsなどもこういった活動を支援するものになっています。ポイント3：より良いチームを組織しようフロントエンドチームやバックエンドチームなどのスキルでチームを分けていませんか？スキルやJobでチームを分けない「ストリームアラインドチーム」を組織しましょう。コミュニケーションコストを最小化し、迅速な意思決定を行い、バリューストリームが速く流れるようなチームを目指することができます。さあ、リーン開発をはじめようHi-Outcomeは、開発チームの規模が10-200名の企業の開発スピード向上を支援するサービス提供を行っております。開発に課題を感じられている方がいらっしゃったら、無料相談を受け付けておりますのでお気軽にお尋ねください。