見出し画像

リーン開発で開発効率を飛躍的に向上させる


はじめに

私達は、製造業で生まれたリーンの哲学と現代的なエンジニアリングの知見を、日本のソフトウェア産業に根付かせ、日本のソフトウェア産業の生産性に高めるために貢献したいと考えています。
そして、エンジニアリングをより加速させるシンプルなアイデアと実践方法をお伝えします。

現状

以下のような状況の企業をたくさん見てきました。

  • 多くのまたは大きな機能要望が開発チームに投げられ、開発チームが疲弊している。

  • エンジニアが大規模の機能開発を行い、QA等のテストで不具合が見つかり手戻りが発生したり、QAチームが逼迫している。

問題点

その結果、以下のような問題が多くの企業で起こっています。

  • 機能追加等に時間がかかる。

  • 障害が多い。リリースの4回に1回程度障害が起きる。

  • QAやリリースのコストが高い

そして、上記の問題がさらに問題が問題を生んでいきます。

  • エンジニア組織の疲弊・退職の増加(問題点の結果)

  • エンジニアチームとビジネスチームの対立(問題点の結果)

理想

事業の目的は、顧客に価値を継続的に提供し続けることです。
そのために、できるだけ小さな単位で早く顧客に商品を届け続けることが必要です。
そうした状態を作るためには、以下のことを意識し、実践していく必要があります。

  • プロセスのどこかで発生するトラブルは、全体の責任と捉え専門性の枠を超え解消に努めること

  • それぞれの部署・部門が顧客に価値を与える流れ全体に意識を向けること

  • より小さな単位で早く仮説検証できる環境に投資をすること

上記の高いレベルで実践され、顧客に多くの価値が早く提供され続けている状態が理想といえると考えています。

バリューストリームについて

前述の理想の状態は、これらはバリューストリームと呼ばれる概念に通じています。
バリューストリームとは、機能や製品が顧客の手に渡るまでの、付加価値を与える一連のプロセスを指します。
顧客が真に欲しいものは顧客が使うまでわかりません。なので、自身の仕事を早く流すことに加えて、バリューストリーム全体が早く流れるようにすることで、顧客に早く機能を使ってもらい、フィードバックを得ることがとても重要です。

原因

ではなぜ、バリューを早く・安全に流すことができないのでしょうか?
それは、バリューストリームをエンジニアリングプロセスに限定した場合でも可視化がうまくできていないところに大きな原因があると考えています。
つまり、プロセス上の待ちや過負荷が可視化できていないのです。
つまり、ムダやムリが発生してしまっているのです。

待ちとは

例えば、開発プロセス上では以下のような待ちがあります。
プルリクエストを出してからレビューを受けるまでの待ち時間
レビューを受けてからそれを反映させるまでの待ち時間
QA依頼をしてからQAが着手するまでの待ち時間
QA完了後から本番環境までにデプロイするまでの待ち時間

どうして待ちがよくないのか?

一言でいうと付加価値を生んでいない時間だからです。
また、待ちが発生しているということは、フローがうまく流れていないボトルネックがあり、そのボトルネックの付近では過負荷が発生し、誰かがムリをしているからです。

待ちが多くなる要因

  • 並行開発をしている

  • WIPが多い

  • バッチサイズが大きい

  • チーム間コミュニケーションに溝がある

開発上のムリとは

バリューが速く流れるようにするためには、バリューストリーム全体でボトルネックを作らないことが大切です。
なぜなら、ボトルネックは全体のスピードを遅くさせてしまうからです。また、プロセス上のボトルネックでは過負荷が発生するため、そこでミスが発生してしまうことが多いためです。
また往々にして、そういった箇所は自動化ができるにもかかわらず、自動化できていないことが多いです。
過負荷を発見し、過負荷の解消にエンジニアリングリソースを投下することは質を上げるという観点で非常に重要です。
質に投資することで、ムリなく安心して製品がリリースできるようになります。
つまり、質に投資することはスピードに投資することでもあるのです。

解決策

リードタイムを可視化することと持続的にリードタイムが短くなるようにリソースを投下することです。ここでのリードタイムとは、開発時のFirst CommitからProduction環境にデプロイされるまでの時間である変更のリードタイムを指しています。

実際に問題を解消していく手順としては、以下になります。

  1. バリューストリームの可視化

  2. バリューストリームにマッピングにしたリードタイムの可視化

  3. その中でのボトルネック特定

  4. ボトルネックの無駄を排除

バリューストリームの可視化

まず、バリューストリームを可視化しましょう。
バリューストリームを可視化するには、最終地点から逆算して行っている作業を図化していくのがやりやすいと思います。
まずは、開発の最終工程であるProduction環境へのリリースに至るまでのDevOpsのパイプラインを整理し、その中でどういうことを行っているか書いていくとわかりやすいと思います。

リードタイムの可視化

開発機能単位でバリューストリームに沿って、どの工程に何時間かかっているを可視化しましょう。また、ある工程が終了して、次の工程に進むまでかかっている待ち時間も可視化しましょう。
イメージとしては以下のような形になります。(より細分化できればなお良いです)

どうやってリードタイムを短くする?

リードタイムは、基本的には前述の可視化を通じて、目標の削減時間に到達するまで、以下のプロセスを繰り返すことであり、これに銀の弾丸はありません。

  1. ボトルネックを特定する

  2. ボトルネックを解消する

  3. 1に戻る

その中でも、普遍的かつ基本となる手法や考え方を以下に紹介します。
リードタイムを短くする行為というのは、バリューストリーム上に存在している時間を短くすることです。
私達でいうと、開発に着手してから、顧客に届ける(Production環境にリリースする)までの時間をできるだけ短くすることです。
ですので、根幹となるのは、開発の単位を小さくし、小さなものを一つ一つできる限り、バリューストリームの上を流れていくことです。

バッチサイズを小さくする

バッチサイズを小さくするという観点から、リーンスタートアップの概念を取り入れることが非常に有効です。
特に、「MVP(Minimum Viable Product)」というアプローチは注目に値します。
MVPとは、最小限の機能を持った製品を速やかに市場に投入し、ユーザーのフィードバックを基に改善を重ねていく方法です。
仮説検証に足る必要最小限の機能を定義し、リソースをそこに集中させることが重要です。
これにより、開発のバッチサイズそのものを小さくすることができます。

WIPを制限する

基本的には、並行処理することは、バッチサイズを大きくしているのと同義なので、小さいものを早く一つ一つ流していきましょう。そのためには、優先順位を明確化し、チームが焦点を絞って作業できるようにし、優先順位の高いものから順に終わらせていきましょう。

CI/CDパイプラインやテストの自動化

リリースフローを自動化することで、リリースコストが下がるので、小さくした開発単位のまま、リリースが行えるようになります。リリースコストが高いとどうしてもリリースの単位が大きくなります。リリースの単位が大きくなっていくと、開発の単位も大きくなるバイアスが働きます。
また、繰り返し行う作業を自動化することで、もっと大切なことに時間を使えるようになります。
スクラムやXPやDevOpsなどもこういった活動を支援するものになっています。

ストリームアラインドチームを組成する

デザイナー・フロントエンド・バックエンドなどの専門領域・Jobでチームをわけない
コミュニケーションコストを最小化し迅速な意思決定を行い、バリューストリームが速く流れるようなチームを組成する。

持続性に投資する

リードタイムを短期的な目線で短くすることには意味がありません。
リードタイムが持続的に短くなるようにエンジニアリングリソースを投下する必要があります。
それはすなわち、種々の自動化に投資していくことに他なりません。
自動化の本質は異常の検知です。
自動化したものが異常を告げない限り、正しく動くものとして認識しなければなりません。
一方で自動化したものが問題を検知した時には、それを修正し・仕組み化によって解決することで質の高いソフトウェアを形作ることができます。
例えば、以下のような自動化に投資をしていくことがリードタイムを持続的に短くする上で効果的です。

テストの自動化

これは、ユニットテストだけでなくE2Eテストも含みます。
QAの行うテストをできる限り自動化し、負荷を小さくすることでバリューが速く流れるようにします。
どうしても自動化できないテスト、どうしても状況によって落ちたりするテストに関しては人によるテストを介在させます。

デプロイの自動化

GoogleのSREチームによると、自社の障害の約70%が製品のリリース周りで起きていたとのことです。
デプロイの自動化とデプロイ後に異常を検知・ロールバックする仕組みへ投資することで安心してリリースすることが可能になります。
デプロイが安心してできるようになれば、小さく機能開発を行うことができるためリードタイムを持続的に短くすることに繋がります。

終わりに

この記事で記載できたのは、開発効率向上の概要になります。
自分たちの会社に適用するのに、具体的なアクションがイメージしづらい場合は、気軽にご連絡ください。
私たち、HiOutcomeは開発チームの規模が5-50名の複数社の開発支援を行っております。
支援内容としては、本文のリーン開発を促進し、開発効率と事業成長の貢献のために必要なことを全て対象としております。

開発にお悩みの方がいましたら、是非お気軽にお問い合わせください。
開発スピード向上サービス: https://corp.hi-outcome.com/
開発の予測精度向上サービス: https://corp.hi-outcome.com/inspection