はじめに
こんにちは。代表の車です。 今回は「効率について」ですが、今自分で考えていることをつらつら書いていこうと思います。ある意味結論もなく、こんな事を考えていますよ的な話です。
効率をなぜ考えるのか？
会社では、ラボと開発に組織を分けて、組織的に研究についてもより進めていこうとしているところです。研究のテーマは、しばらくは「リモートでプロダクト開発をより効果的・効率的にできるようにすること」でやっていこうと思っています。
せっかくこれから色々と効率や効果を高めていこうと考えていくのであれば、まずは「効率的とは？」を検討して計測できるようにしたいなと思い、整理していました。
効率の基礎検討
効率の広がり
フロー効率の話が数年前話題になり、多くの開発チームの指標の1つになっているみたいですね。
フロー効率は、出荷スピード的な意味になっており、出荷時間/開発規模 や、付加価値されている時間/出荷までの時間（要は待ち時間を少なくする）と定義して利用されているチームが多いのかなと観察していました。
リソース効率100%にしていた違和感から、持ち上がってきた経緯になるのかなとも思っていたのですが、この話の示唆としては、効率というものが色々あるんだよというのを気づかせてくれたことなんじゃないかと思います。
そう考えると、そもそも効率ってどんなものがあるんだろう？と考えてくるようになりました。
そもそも、効率ってなんだ？
いつも通り、wikipediaで調べてみています。
効率性 経済学において、効率性（こうりつせい）とは、資源・財の配分について無駄のないことを意味する。 出典: https://ja.wikipedia.org/wiki/効率性
なるほど。ただ、物理だとエネルギー損失的な意味だなと思い、もう少し調べてみました。
効率 供給したエネルギーのうちで有効に使用されたエネルギーの割合をいい，通常はパーセントで表わされる。機械の効率は有効仕事量と供給エネルギーの比で与えられる。効率低下の主原因は摩擦による損失エネルギーで，歯車による伝達効率は約 80%である。電気機械の効率は電気的または力学的な出力エネルギーと力学的または電気的な入力エネルギーとの比で与えられる。水力発電機，電動機，変圧器では効率は一般に高く，90%以上もある。熱機関の効率は有効仕事量と供給熱量 (または燃料の発熱量) の比で与えられ，熱効率と呼ばれる。熱力学第二法則により，絶対温度 T1 の高温熱源と絶対温度 T2 の低温熱源 (冷却器) とをもつ熱機関の熱効率は最大値 (T1－T2)/T1 より小さいので，熱効率は一般に低い。効率は蒸気機関で 10～20%，内燃機関 30%，大型の火力発電機でも 50%程度である。 出典: https://kotobank.jp/word/効率-63356
ということで、投下したエネルギーのうち、効果的だったエネルギーの割合のことで、なんやかんやでロスするので、多くても90%とかそんなもんだよということを言っていますね。
物理的な単位はなく、割合で表現されるようです。ということで、無次元のエネルギー割合と考えて行こうかと思います。
7つのムダ
まずは、どんなものが考えられるのかなと思い、考えてみました。
ムダといえばトヨタ生産方式、ということで、トヨタ生産方式のムダの分類から自分たちに適用してみようかなと思いました。
自分も色々と耳が痛いところはありますね。
分類 | 解説 | 対応効率 | Web系回りとしての解釈 |
造りすぎのムダ | 造りすぎのムダは、７つのムダの中でも一番悪いと言われるムダで絶対に削減しなければいけない。タクトの設定や管理面の甘さから発生する。
造りすぎのムダが最悪のムダと言われる理由は、造りすぎが在庫のムダ・動作のムダ・運搬のムダを発生させてしまう。
更に、造りすぎている間は社員が忙しく動き続けるために、見かけ上は「手待ちのムダ」も隠れてしまう。
実際には、必要のないものを造ることを止めれば社員の手は空くことになり、「手待ちのムダ」を顕在化することができる。 | 投資効率 | 造らなくて良いものを作っているので、最もムダが大きいですよね。
一般的には、Leanの話がここに該当して、ラーニング型の戦略はこの効率を最大化しようとしていると解釈できますよね。YAGNIなんかもここに近い概念かもしれないです。
何をやるかがやっぱり一番重要。 |
在庫のムダ | 在庫は、材料、部品、仕掛品、完成品など全てが対象となる。
全ての在庫にはそこに存在する理由（目的）が必要であり、なぜ今そこに置いてあるのかを説明できない在庫は、全てムダな在庫と判断される。
なお、在庫により、問題が隠れてしまうことが一番注意しなければいけない。 | チケット管理効率 | 在庫の置き換えが難しいですよね。
開発できないチケット・リリースできない機能と考えて良いかもしれないですね。
チケットが増えていくと、チケット管理・整理にムダに時間がかかるので、このへんは粒度の設計が重要で、スクラムでいうと必要になったらプロダクトバックログからスプリントバックログに細かくするのは良い打ち手なのかもしれないですね。 |
加工のムダ | 加工のムダとは、標準が決まっていないことによる必要以上の仕上げ作業や、本来不要な検査等が該当する。
従来からのやり方だからと言って、本当に必要かどうか検討せず、本来必要の無い工程や作業が無いか、という視点でムダを探すことがポイント。 | フロー効率（工程設計） | ムダな工程、ムダなこだわり。そんなところでしょうか。自分が結構やりがちなやつな気がします。
逆に、工程数を減らしすぎると、不具合も増えたりするので、おそらく手直しのムダが増えるのかなと。 |
手直しのムダ | 不良・手直しのムダとは、不良品を廃棄、手直し、造り直しすることを言う。
条件管理の不備など、品質管理の甘さから発生する。
また、標準を守らなかったり、標準が決まっていないことでも発生する。
不良・手直しを発生させないために、自工程完結の考え方が大切。 | 不具合率（の逆） | レビューや試験、リリース後のユーザーからの連絡などで来る不具合対応系がこれですよね。
できるエンジニアの人のコードって不具合がホント少ないですよね。すごい。
|
運搬のムダ | 運搬のムダとは、必要以上のモノの移動、仮置き、積み替え等のことを言う。
工程のバランスが崩れていたり、モノの流れが決まっていない等のことから発生する。
特に、造りすぎのムダから発生する運搬のムダに要注意。 | 伝達効率 | デザイナーからエンジニアへの受け渡しなど、次のチームにパスするときのロスとして解釈すると良いですよね。
ある意味では引き渡しの方法などを設計することで対応できるかもしれないですね。 |
手待ちのムダ | 手待ちのムダとは、その名の通り、作業をすることが無く、手が待ち状態のことを言います。当然、手待ちは付加価値を生みません。気を付けたいことは、手待ちは作業者が作業スピードを調整することで簡単に隠れてしまうということです。1個流し等の標準作業をしっかりと構築し、まずは手待ちを顕在化させることが大切となります。 | リソース効率 | 従来型のリソース効率のことで分かりやすい。
リソース効率は作業スピードが遅い人の方がパツパツするので、これを追い出すと意味不明な話になってくるというのが、人月の神話なのかな。 |
動作のムダ | 動作のムダは、探す、しゃがむ、持ち替える、調べる等の人の動きの中で付加価値を生んでいない不要な動きのこと。
標準作業が誰でも同じように出来るようになっていない場合や訓練不足等で発生する。
常日頃から動作を観察し、付加価値を生んでいない動きがないか探していると、必ず動作の中にムダが存在していることに気付くはず。 | 作業効率 | これは開発者とか手を動かす時の話かもしれないですね。IT系の開発だと、完全に同じことを繰り返すわけではないので難しい面もあるのですが、教育的な話が多い項目かもしれないです。 |
業務プロセスと効率
ここまでの、トヨタ生産方式の話や物理的な次元の話を参考に、自分たちの業務プロセスと必要な効率を試しに定義してみます。
例として、プロダクト開発の業務プロセスを考えてみると、こんな感じでしょうか。
工程 | 手法 | |
プロダクト設計 | 情報集積 | 資料調査・実験・関係者/ユーザーヒアリング・利用データ収集 |
コンセプト設計/表出 | 情報整理・コンセプト構築・プロダクトバックログ/設計書/ワイヤーフレーム等の作成 | |
実装コスト算出 | システム化の方法検討・概算見積 | |
投資判断 | プロダクトバックログの順序付け | |
システム開発 | 開発基盤の整備 | 開発ルール構築・インフラ環境構築・初期アプリケーション整備 |
システム設計・開発 | 機能単位の開発 | |
システム試験・リリース | 最終試験・不具合があれば改修・リリース | |
プロダクト利用 | ユーザー利用 | ユーザーが実際に使ってくれる |
利用データ収集 | データ分析 |
プロダクト設計
- 主にシステム開発において、何に投資するかを担当する
- 「造りすぎのムダ」に該当する投資効率に責任を持つことになる
- もちろん、ここはかなり重要で、どんなにシステム開発を頑張っても、作っても意味ないことをやったら辛いよねという話になる
- やっぱり、Lean的な話がここに集中している
- 最近は、ここの精度を上げるために、プロトタイピングなんかも実施している
システム開発
- 決まったことをいかに効率よく作り、保守性が高いシステムが作れるかということを担当する
- 「加工のムダ」「手直しのムダ」などが該当し、フロー効率を高めつつ、不具合も少ないほうが良いよねという話だとは思う
- フロー効率の配下に、作業引継ぎ的な「運搬のムダ」、リソース効率的な「手待ちのムダ」、各メンバーレベルでの「動作のムダ」が入ると思う
ということで、これらの話をプロセスとセットでマッピングしてみました。
コストを日本円ではなくて、時間と解釈しなおして、時間で記載しています。
投資効果速度（認知価値 / 時間）
カテゴリ | 数値（Lv2） | 工程 | 数値（Lv1） |
プロダクト設計 | 設計速度（設計価値/設計時間） | 情報集積 | 情報集積速度（情報量/設計時間） |
コンセプト設計/表出 | 情報研磨効率（設計価値/情報量） | ||
実装コスト算出・投資判断 | 設計実現効率（開発価値/設計価値） | ||
システム開発 | 開発速度（製造価値/開発時間） | 開発基盤の整備 | フロー効率（作業時間/開発時間） |
システム設計・開発 | 作業速度（開発価値/作業時間） | ||
システム試験・リリース | 不具合率 | ||
プロダクト利用 | 価値伝達速度（認知価値/利用時間） | 集客・利用 | 認知効率（認知価値/開発価値） |
利用データ収集 | 情報収集速度（情報量/利用時間） |
こう考えていくと、効率だけではなく、速度なども重要になってくるなと改めて思いました。
計測と改善
後は実際に測っていく話になります。
各種効率は、大きく分けて4つの物理量の率で定義されているので、各種の物理量をどのように定量化していくかがポイントになると思っています。
まだ、これからなので、今のところこんな感じで考えていますというのを出してみます。
- 情報量
- 情報集積速度は学習的な進め方を行う場合の主要素になると思う
- まずはシンプルに情報がどれだけ表出化されているかを計測しようと思っている
- 例えば、Notionのブロック数などが身近だと良いかもしれない
- 価値
- 発想を事業化するイノベーション・ツールキット 等で価値指標が定義されている
- 提供価値の定義と、競合等との絡みでまずは理論的な価値を数値化しようと思う
- その価値を認知してもらえていたかや、実際狙い通りだったのかは利用時の計測としてFBしようと思う
- 時間
- 日単位レベルであれば、一番簡単
- 時間レベルまで分解能を上げると、途端に難しくなりそう
- CI/CD辺りと連動した計測から始めようかとも思う
- 不具合率
- 開発者本人・テスター・ユーザーと不具合が気がつくループサイズが大きくなればなるほど、色々と面倒なことが多いので
- 単なる不具合率というよりも、どのレベルで発見されたかも含めた数値にしたいとも思う
- 計測自体は規模と数で概ね出せるかなとも思う
まずは、ざっくりと計測して、理論式との兼ね合いを見てみたいなと思っています。
まとめ
効率について考えだすと、結局いろいろな計測の話になっていきましたが、定量化の最大のメリットは、狙いをシャープにしていけることだと思います。
何をどう測っていくのかは、会社のポリシーにも通じる話なので、試行錯誤しながらピタッと来る物理量を決めていきたいと思います。また、効率というと作業効率・リソース効率・フロー効率辺りが焦点になることが多いけど、投資効率の影響が一番大きいですよね。
会社で何に投資をして、どれだけ意味があるのかを考えるのは、自分の責任になるので、しっかり定量化して、客観的に評価されるべきだなとも思いました。
それではまた来月お会いいたしましょう。