asken テックブログ

askenエンジニアが日々どんなことに取り組み、どんな「学び」を得ているか、よもやま話も織り交ぜつつ綴っていきます。 皆さまにも一緒に学びを楽しんでいただけたら幸いです!

リーンな垂直アプローチで価値を届け続ける

こんにちは。システム部の藤原です。

国内版あすけんのエンジニアリング・マネジメントを担当しています。

初投稿でドキドキしていますが、何かご参考になれば幸いです。

みなさまは「リーン」「垂直アプローチ」と聞くと、どの様なコトを思い浮かべますか?

僕自身の思いを書き出してみます。

リーン: Watch the baton, not the runners.

フロー効率とリソース効率という言葉があるかと思いますが、リーンでは前者「価値のバトンが止まらない」ことを目指します。

「作業バッチを小さく、1個流し(並行作業しない)、無駄を省く」などのプラクティスはあると思いますが、マインドセットも重要です。

  • Continuous Improvement - 継続的なカイゼン
  • Respect for People - 人の尊重
  • challenge everything - すべてに挑戦
  • embrace change - 変化を受け入れる

参考: LeSS - Principles > Lean Thinking (Copyright © 2014 ~ 2022 The LeSS Company B.V. All Rights Reserved)

これらは、自分のコンフォートゾーンから脱し、本質的な価値提供をする為の羅針盤になっていきます。

垂直アプローチ

次に、垂直アプローチですが、これを言語化するために「水平」と対比してみます。

水平 = 価値提供のレイヤーを1枚ずつクリアしていく

f:id:techaskeninc:20220412130448p:plain:w320

これは自分の職能のレイヤーを突き詰めていくようなイメージです。

確かに大事だと思います。

ただ、「既存のコード全てにE2Eテストを作成しよう」って、いつ終わるのでしょうか。

そして、それによって得られるアウトカムの量は不明ですし、投資効果には大きな疑問が残ります。

そのアプローチが悪いとは言いませんが、投資判断はどうすれば良いでしょうか。

これは考えても答えは出ないし、何が正解なのかも分かりません。

不確実性が高く、大きい作業に対して「とりあえずやってみよう」とは、僕は言いたくありません。

垂直 = スコープを絞り、薄切りで縦にゴールに向かう

f:id:techaskeninc:20220412130452p:plain:w320

これは自分の職能だけじゃなく、他のレイヤーも含めてアプローチするイメージです。

これは、いわゆる「越境」で、クロスファンクショナルなチームでスクラムしていく様なイメージです。

水平と比べてハードルは高いですが、ゴールまで一気通貫で経験する事により、課題の全体像を掴み易く、ゴールへの到達が短いです。

不確実性が高く、大きい作業に対して「とりあえず薄切りでやってみよう」ならば、投資としての安心感が増します。

リーン+垂直アプローチ=?

ここまでの前提を踏まえ、自分なりの解釈を書き出してみます。

リーンな垂直アプローチとは
相互リスペクトしつつ、相互に越境し、全レイヤーを一気通貫でゴールへ向かい
薄切りのスコープかつフロー効率を重視する事で短リードタイムで結果を得て
具体化した課題の全体像から、更に同様の経験学習サイクルを回す事で
不確実な状況における素早く継続的で経済的なカイゼンを実現すること。

つまり、「不確実な状況でも、素早く的確に価値を提供したい」という事です。

以下、幾つかの文脈にて思考実験をしてみます。

ソフトウェア開発

プロダクトを構成する技術要素は、インフラストラクチャ、サーバーアプリケーション、モバイルアプリケーションなど様々あると思います。

f:id:techaskeninc:20220412130455p:plain:w320

自分の職能がAndroidエンジニアのならば、「水平=Android開発」、「垂直=他のノード」です。

自分の職能のタスクだけではなく、ユーザーを知り、サーバーを知り、全体最適で要点/要件が分かれば、何が技術面でのコアなのか分かります。

コア以外の部分を削ぎ落とし、越境して全体俯瞰な設計する事で、リーンで持続可能な形で価値へのコミットメントができると考えます。

プロダクト仮説検証

以下は「仮説のミルフィーユ」ですが、価値仮説はCore、Why、What、Howから構成されます。

f:id:techaskeninc:20220412130503p:plain:w640

参考:及川卓也, 小城久美子, 曽根原春樹. 「プロダクトマネジメントのすべて 事業戦略・IT開発・UXデザイン・マーケティングからチーム・組織運営まで」. 翔泳社. (2021).

自分の職能がエンジニアの場合、「Why = 誰をどんな状態にしたいのか」、「What = 狙う体験と機能イメージの全体像」を知る事で、何が価値仮説のコアなのか分かります。

コアを知っていれば、それを達成できる別のリーズナブルな手段を提案できますので、より早く最適にリーンな仮説検証ができます。

チームビルディング

「ユーザーにとって何が価値であり、どうやって構築すれば良いのか、組織、チーム、ユーザーとの情報は対称になっているか」

プロダクトマネジメントは、不確実性との対峙でもあります。

  • 目的不確実性 = 何が価値なのか
  • 方法不確実性 = どうやって構築し、いつリリースできるのか
  • 通信不確実性 = クロスファンクションの職能が意思疎通とれているのか

正解はないし、考えても答えが出ない。

とても不安になりますよね。

f:id:techaskeninc:20220412130459p:plain:w320

参考:広木大地. 「エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング」. 技術評論社. (2018).

不安になるほど、ヒトはコントローラブルな領域に固執しはじめ、他のことが頭に入らなくなります。

エンジニアであれば、「目的はマーケティングに任せた。俺たちは方法の事だけ任せろ」というサイロへの逃げ込み、思考停止が容易に発生するでしょう。

もし、マーケティング担当が手段をいとわずに目的に固執し始めると、両者は「限定合理性 = 自分が見えている範囲の正義への固着」に陥り、ポジショントークでしか対話ができなくなります。

「みんな熱意を持って頑張っているのに、誰も噛み合わない」

なんて悲しい構造なんでしょうか...。

価値のバトンは、完全に止まってしまいます。

チームがバラバラにならない為に、サイロから飛び出し、一歩を踏み出す必要があります。

自分の職能がエンジニアの場合、「目的不確実性 = 何が価値なのかの探求」までをプロフェッショナルとして出来る様になる必要はないかも知れません。

しかし、目的を追求する役割の人たちを理解することはできるはずです。

理解した結果、相互に言いたい事がきちんと伝わる様になり、価値のバトンが止まらぬフロー効率で、リードタイムの短いデリバリーが可能なチームになれるのだと考えます。

おわりに

ここまで書いたことは、THE・言うは易し😅ですね。。

僕自身、まだまだ出来ていない事も多くあり、今後の課題だと自己認識しています。

リーンな垂直アプローチで価値を提供し、今後も、あすけんユーザーの皆様の自己実現をサポートさせて頂ければと思います。

参考

お知らせ

askenでは、一緒に働いてくれるエンジニアを募集しています!

www.wantedly.com