はじめに
こんにちは。PharmaXでエンジニアリングマネージャーをしている古家(@enzerubank)です。
2024年10月31日、PharmaXはFindy Team+ Award 2024のSmall Divの部（エンジニア組織が50人未満）を受賞しました！この賞は開発生産性向上に関して優れた取り組みを行った企業に贈られるものです。
PharmaXでは去年の10月から1年近くの間、開発生産性の向上に取り組んできましたが、今改めて振り返ってみて「最初から知りたかったな」と感じたことを3つに絞ってまとめてみました。
その1: リソース効率性とフロー効率性について知る
リソース効率性と病院での時間の例
リソース効率性とはサービスにおいてサービスを提供する側のリソースの効率のことです。例えば胸のしこりを見つけた患者が最初に行った病院では結果が分からず、その後複数の病院を回って結果が出るまでに約1ヶ月かかったとします。
検査と検査の間の待ち時間に比べれば、実際に検査が行われていた時間は微々たるものですが、
これは各病院ができることに対してリソースを効率化しているために起こったことです。
フロー効率性と病院での時間の例
フロー効率性とはサービスにおいてサービスの提供を受ける側から見た時の効率のことです。先の病院の例でいうと、乳がんの有無を診断するという患者の需要に焦点をあてて様々な専門分野を一つに統合した病院であれば、1ストップで完了するというものです。
例の時間は仮のものですが、病院が分断されている場合は間の検査の結果を待つ時間がほとんどだったのに対し、後者では1時間で欲しかった診断結果を得ることができています。
こうしたケースをフロー効率性が高いサービスといいます。
フローユニット
リソース(人や機械)が価値を付加する対象のことをフローユニットと呼びます。前の例だと直接顧客にサービス提供するため、フローユニットは人でしたが、間接的にサービス提供を行う製造業やソフトウェア開発業の場合は物やデータになります。
- 病院
- リソース: 医療者など
- フローユニット: 患者
- 自動車開発
- リソース: スタッフ・機械など
- フローユニット: 車/部品
- ソフトウェア開発
- リソース: エンジニアなど
- フローユニット: プロダクト/機能
フロー効率性は価値ある時間の割合を高めること
フロー効率性が高いというのは、顧客が最終的に受け取りたい価値に対しての全体の流れの中で占める価値ある時間の割合が高いということです。
価値ある時間以外はムダだとすると、
- 前者は2.5時間/28日+2.5時間 = 0.004%
- 後者は1時間 / 1時間 = 100%
これは極端な例ですが、重要なのは最終価値までの全体の流れを把握して、ムダ（価値のない時間）を限りなく減らしていくことがフロー効率性を高めることだということです。
これは顧客中心のアプローチとも言いかえることができます。
システム境界とバリューストリーム
「顧客が最終的に受け取りたい価値に対しての全体の流れ」の範囲をどこまでにするか？というのをシステム境界と呼んだりもします。
そしてこの価値の全体の流れがバリューストリームであり、それを可視化するための手段としてバリューストリームマッピング（VSM）があります。
フロー効率性を高めていく上で、まず最初にシステム境界の定義とバリューストリームの可視化を行っていけると顧客への価値提供のボトルネックの特定がしやすくなります。
その2. Leanについて知る
Leanとは何か
Leanについては様々な本が出ていますが、「Leanとは何か」という問いに簡潔に答えている本としてはThis is Leanがオススメです。
本書ではLeanとは以下の2つの特徴を持つビジネス戦略を実行するためのオペレーション戦略のことであると定義しています。
・リソース効率性とフロー効率性のどちらも最高にある状態を目指すこと
・最初にフロー効率性を高め、その後にリソース効率性を高めるという順でアプローチすること
なぜLeanを学んでおくとよいのか？
まず会社のゴールというのは「お金を稼ぐこと」です。どんなに崇高なミッションやビジョンを掲げていたとしても、お金を永続的に稼ぐことができなければ会社は存続することができません。
このゴールを達成するために「自分たちは顧客にどんな価値を提供するのか」を決めるビジネス戦略があり、「ビジネス戦略をどのように実行するのか」を決めるためにオペレーション戦略があります。
Leanではリソース効率とフロー効率のバランスによって全ての業界の企業のオペレーション戦略を表すことができるとしています。Leanオペレーション戦略では、右上の最高の状態になることを目指して継続的改善を行っていきますが、企業のビジネス戦略によっては右下や左上のケースもあるとしています。
- 格安航空会社
- 低コスト戦略をとるため、フロー効率性よりも低価格に抑えるためのリソース効率性を重視する左上型のオペレーション戦略をとる
- 高級ホテル
- 高価格でサービスを売るための差別化戦略をとるため、フロー効率性を重視し、リソースに余裕を持たせ、いつでも柔軟なサービス提供をできるようにする右下型のオペレーション戦略をとる
実際のほとんどの会社はこの間のバランスをとることになると思いますが、どの場合でも左下の状態は最悪で、この状態は抜けるべきです。ただ多くの会社は左下になっていると This is Leanでは指摘されており、まずはこの状態から抜ける必要があるということを知るだけでも意味があります。
なぜLeanに取り組むとよいのか？
まず先に述べたように自分たちがリソース効率性・フロー効率性のどちらも中途半端な状態になっているということを認識することができます。
この記事を読んでくれている人はソフトウェア業界で働いている人が多いと思うので、極端な低価格戦略や高価格帯の戦略をとることは少ないんじゃないかと思います。顧客に大きな価値を感じてもらいつつ、リソースはいい感じに効率化したいという企業が多いのではないでしょうか。
Leanに従い、まずフロー効率性の向上に取り組むことで「顧客により早く価値を届けられる」ようになります。フロー効率性に取り組む過程で、システム境界の定義・バリューストリームの可視化・ムダの撤廃/短縮が行われていくことで、顧客に価値を届けること以外のムダな仕事が減っていくためです。
「顧客に早く価値を届けられる」状態になってから、内部のリソース効率化を行うのが良いでしょう。
Leanをどう実行していけばよいのか？
「ではどうLeanオペレーション戦略を実行していけばよいのか？」という問いに対しては実行するための手段は沢山存在するという答えになります。
そのための手段をThis is Leanでは4つのグループに分類しています。
・組織がどう"ふるまう"べきかを決める価値観
・組織がどう"考える"べきかを決める原則
・組織が何を"する"べきかを決めるメソッド
・組織が何を"もつ"べきかを決めるツール
Leanについて書かれた本や各社の事例はこの4つのグループについて語っているわけですが、それはその組織におけるLeanを実行するための手段であることを理解しておくことが重要です。
なぜその手段を選んだのかの一番抽象度が高いものが価値観であり、この価値観があるからこそ、その下の手段は選ばれていきます。そのため、自分たちの組織にLeanを取り入れていく場合、まずツールやメソッドから導入するとしても、その背景にある価値観・原則は何が良いのか？を推進者は考えていく必要があるでしょう。
この4つのグループが組織に浸透しなければ本当の意味で組織全体がLeanを実行しているとは言えません。まあこれはかなり険しい道のりなわけですが笑 それだけ険しい道のりを歩んでいるということを知っておくことは大切かなと思います。
その３ 初期から品質へ投資する重要性を知る
品質が低いとムダが増えて顧客への価値提供が遅くなる
フロー効率性を高めて顧客により早く価値を届けていくことが開発の目的になります。顧客に価値を届けること（デリバリー）をマネジメントするためにQCDSの観点で考えてみます。
- Quality: 品質が低下するとデリバリーが遅くなる
- プロセス品質(要件定義/設計/開発のやり方や手順の品質)を下げると要件漏れや内部品質の低下を生み、手戻りが発生することでデリバリーが遅くなる
- 内部品質(システム/コードの保守性や信頼性等の品質)を下げるとバグの発生・コードレビューの指摘・技術的負債による実装の複雑さなどによる手戻りや速度低下を招き、デリバリーが遅くなる
- 外部品質(ユーザーが製品を実際に使用した時に判断できる表面的な使いやすさ)を下げると、本来届けたかった価値が伝わらず、利用時の品質が下がる
- 利用時の品質(解決したかった課題に対しての有効性や満足度)を下げると、本来届けたかった価値が届かず、サービス離れを招き、ビジネスとしての価値が下がる
- Cost: ほとんど人件費。コストは固定で考えなければ予算を立てられないため、途中で増減はない前提で考える（できる限り減らすべき対象）
- 特にスタートアップの場合は人件費が残りのランウェイに直結するのと、一度採用すれば固定費としてのしかかることになるため、コストはそうやすやすと増やせない
- Delivery: リリースは早いにこしたことはない（伸ばさず、短縮すべき対象）
- 顧客への価値そのもの。伸ばすという手段は最終手段であり、固定もしくは短縮を目指す。
- Scope: 一度にやる量（スコープ）によってデリバリーの速度が変わってくる
- 一度に進めるバッチサイズを大きくすると、リソース効率性で進めるバイアスがかかるので、一括でリリースはできるものの、デリバリーまでの時間は遅くなる
- 1個流し(顧客にとって必要なものを1つずつ流す)にしてバッチサイズを小さくすると、小出しにはなるが、デリバリーまでの時間は短くなる
顧客により早く価値を届けていくには、Cost・Deliveryはできる限り縮小/短縮を目指すものであり、Quality(品質)は下げると速度に直結するので、これも固定になります。
結果速度を調整するネジはScope、つまりはリソース効率性とフロー効率性のバランスになるということです。複数のことを同時に進めようとすると、最終ゴールに到達していない仕掛品が大量に生まれ、最終的に価値を届けるデリバリーの時間は遅くなります。
このScopeの調整とQualityの基準担保が現場の開発リーダー1人で行えればよいのですが、大変なのでどちらかが疎かになっているなと感じたら、役割分担していかないと後々苦しむことになります。
エンジニアのモチベーション・パフォーマンス向上においても品質は重要
品質への拘りはフロー効率性の観点だけでなく、人のモチベーション・パフォーマンス向上・組織づくりの観点でも重要です。
高品質なものを作っているという感覚は自分たちが他の人達にはできない特別なことをしている、エリート感を醸成します。低品質でとりあえず動くだけのものであれば、素人でもできるわけで、そんな姿勢でもの作りをしているとエンジニアとしてのプロ意識が損なわれていきます。
高品質(ユーザーが喜んでくれて、バグも少なくて、保守性も高く開発もしやすい)なものを作るには一人の力だけではできません。チームが一丸となって高品質なものを顧客に届けようという意識で働くことで、実現できるものです。
こんな高品質主義な開発を行っているチームは一体感がありますし、その中で働くことでメンバーのモチベーションは上がり、パフォーマンスも上がり、スキルも伸びていきます。
品質を犠牲にするということはチーム殺しの術としてアンチパターンと言えるでしょう。
まとめ
今回は開発生産性に取り組む前に知りたかった3つのことを書いていきました。「開発生産性に関係なくない？」と疑問に思った人もいるかもしれません。
今回書いた話というのはLeanの手法の4つのグループでいうと「原則」に当たる話だと思っています。
開発生産性はより具体の「メソッド」であり、フロー効率性・Lean・品質向上といった原則を実践していく中で必要となる開発全体の状況の可視化・指標化・自動化を行っていく方法論だと理解しています。
なぜこれらが必要になるかというと、ソフトウェア開発は「見えない」からです。顧客中心でフロー効率性が高く、高品質なものを届けることができていると現場が思っていたとしても、それを外部の人たちが知る手立てはありません。これがラーメン屋のようにリアルなお店であれば、実際にお店にいけばサービス品質というものはわかります。でも、ソフトウェア開発は直接エンジニアを見ていても良い仕事をしているかなんてわかりませんよね笑
この不安を解消することが開発生産性のスタート地点であり、そこから一緒に顧客に早く価値を届け、会社のビジネスを成功させることを目指すようにしていくことが目的です。
開発生産性は決してエンジニアだけが嬉しいものではなく、組織が一体になって顧客中心に価値を届ける状態に進化していくための取り組みだと自分は考えています。
最後に
弊社はFindy Team+を活用して、この1年ほどで顧客へのデリバリーの速度(リードタイム)は1/10に削減され、本番へのリリース回数(デプロイ頻度)も10倍以上に増えました。変更失敗率も目標値だった5%未満は安定的に達成できており、スピードと質を両立した体制になっています。
今後もより顧客に価値を届けられる高品質なプロダクトを作っていきます！
▼詳しい取り組みはこちらから
またPharmaXでは特にエンジニアを積極的に採用しておりますので
少しでも弊社に興味を持っていただけましたらご応募お持ちしております！
参考にした本
PharmaXエンジニアチームのテックブログです。エンジニアメンバーが、PharmaXの事業を通じて得た技術的な知見や、チームマネジメントについての知見を共有します。 PharmaXエンジニアチームやメンバーの雰囲気が分かるような記事は、note（note.com/pharmax）もご覧ください。
Discussion