はじめに
LITALICOの亀田です。
執行役員VPoEとしてプロダクト開発や組織づくりに携わっています。
- Qiita: @kamesennin
- X(Twitter): ka_me_sen_nin
この記事は、LITALICO Engineers Advent Calendar 2024 の8日目の記事です。
1日目の記事もぜひ！
何について書くか・なぜ書くか
この1年は様々な「レビュー」をすること、レビューの仕組みを作ることが多かったです。
エンジニアでは「コードレビューや設計レビュー」などが聞き覚え多いかと思いますが、本記事でレビューの対象としているものは
- ざっくり検討開始から6ヶ月以上かかる、プロダクトの機能開発（ex.新規プロダクト開発や大機能開発）やシステム導入（ex.業務システム導入や改変）に関する開発PJTのこと
です。
プロセスは「ウォーターフォールなのかアジャイルなのかスパイラルなのか」に制限はなく、「検討開始からユーザーに利用され、ビジネスとして成立する（ex. ローンチ後の販売/マーケティング開始できる状態、業務システムの正式入れ替え開始した状態）まで」を1つのPJT（投資単位）でくくっています。
一定足は長いPJTのレビューは、なんとなくのタイミングでしていると上手くいきません。フェーズによって見るべきポイントが異なるためです。強い目的意識を持って、組織運営のルール上、こういう手順で行うべきと定めなければワークしづらいものと思います。
実際私は試行錯誤しながら「組織運用上レビューのプロセス整備」を行っていった結果「全社の生産性向上、個別PJTの失敗数の減少」へと明確に繋がりました。
そこで「どういう問題があって、何にこだわってやって、どういう成果につながったのか」を改めてまとめて学びの棚卸しをしようと思い、本記事を書くことにしました。
本記事の前提
どんな会社でどんな経験をしている人が書くのかで前提が変わるので軽く紹介します。
事業概要
LITALICOの事業はかなり多種多様です。
障害福祉領域を中心に、子ども・成人・高齢者に向けて、学ぶ・働く・暮らすなど多様な観点からのサービスを提供しています。具体的には
- BtoC（障害のある方・ご家族向け）の店舗型の支援サービスやライフプランニングのサービス
- BtoC（障害のある方・ご家族・従事者向け）のマッチングプラットフォームやHR系のサービス
- BtoB（福祉事業所・介護事業所向け）のSaaS型のサービス
- BtoB（学校向け）のパッケージ型ソフトウェアサービス
です。最近はグループ会社の数も6~7つほどに増えました（2024年10月時点）。
海外（米国）にも進出しています。
参考： 2025年3月期第2四半期 決算説明資料 株式会社 LITALICO
全社のプロダクトやシステム
自社で開発・運用が必要かつ、責任持つには特定レベルの専門性が必要な単位を内製の1システムと定義した時に、システム単位では50~60あります。
更に、上記システムの組み合わせで構成される、かつユーザーへの提供価値や戦略を考えるべき単位を1プロダクトと定義したときに、15~20ほどのプロダクトがあります。
また、システムとは事業に紐づくプロダクト開発だけではありません。
- コーポレート組織（人事、採用、財務、経理、法務など）の生産性向上
- 自社福祉施設のDX化（ハードウェア整備など店舗IT化の支援）
- エンプロイーエクスペリエンス向上のITインフラ整備
など多岐にわたります。
全社の売上や利益
2024年3月期第2四半期の決算説明資料で公開している業績予想は以下です。
- FY2024の売上: 355億円
- FY2024の営利: 33億円
19期目。国内の障害福祉領域ではトップクラスに規模が大きいです。
組織
2024年10月時点で従業員は5,000名近くです。そのうち多くが店舗事業での支援者の方々で、弊社のコアであり、最大の強みと私は考えます。
全社の組織構造は以下3つの本部から構成されるマトリクス型組織です。
- 事業本部: 各事業運営を行う組織
- コーポレート本部: 財務管理や経理、採用や人事、などの管理部門組織
- プロダクト本部: エンジニア、デザイナー、PdMやマーケター、コンテンツ開発等の専門組織
エンジニアが所属するプロダクト本部は「個別事業やコーポレート組織を支えるプロダクトやシステム、マーケやコンテンツ開発を各組織に入り込んで推進」する役割だけでなく、
多様な事業ドメインによらず、共通で整備できる全社横断での「守るべきものを守る仕組み（情報セキュリティやリスクマネジメント、コンテンツ等の品質管理）」「成果最大化を狙う取り組み(相互送客のようなマーケティング施策、データ基盤やシステム共通化)」も担います。
私の役割
以下のような位置にいます。PdM、エンジニア、デザイナーの3職種の戦略全般、投資配分、PJT推進諸々の最終成果に責任を負うように、仕事に取り組んでいます。
上記のように、10近い事業と20以上の多様なプロダクトやPJTの全成果に責任を持つためには、各種成果に必要なタイミングでの「レビュー」が必須と考えています。
ただし、レビューがワークするためには、より頻度の高いモニタリングがベースあります。
モニタリングは過去以下記事でまとめていますので、気になる方はご覧ください。
200名を超えるエンジニアリング組織のヘルスチェックで三方良しの世界観を作りたい
以下本題です。
そもそも起きていた問題
上記モニタリングに関する記事にも記載していますが、20以上走るプロダクトやPJTのヘルスチェックをしていました。
その中で「PJTの大幅な遅れや体制再構築など、事業利益やリスク対策などへ影響が出ている/出そうで、詳細の報告が必要なもの」を"問題"と定義して、その発生率を半年単位で観測し、パフォーマンス指標の1つとしています。
その問題を減らすに大きく貢献したものが「レビュー」です。
- レビューの導入開始前は「問題発生率: 30~40%」
- レビュー導入から半年で「問題発生率: 0~10%」
という明確な成果がありました。
問題発生率30~40%という数値は、組織の急拡大（3年弱でエンジニア60名→200名）によってプロセスが整備されていないかつ、同時多発的に大きな機能開発や事業開発を行ったため、相当難易度の高いことをしてしまっていました（その判断は攻めすぎた点もあったと反省をしています）。その結果、問題発生数もかなり多かったです。
※参考: 採用プロセスのDX化で採用力の10Xを成し遂げられそうな話
レビューを整えると同時に開発組織のコミュニケーションや他プロセスの品質向上も大きく影響を与えていますが、大きな問題発生を防ぐという意味では、レビューが明確な効果でした。
レビューにかけるコストを割り引いても大きな生産性向上とみなしています。
ではそれらをどのように整えたのかを以下述べていきます。
中長期PJTにおけるレビューの目的、効果
レビューの目的
- PJT全体の開始から完了までの間で「後戻りした時の大きな開発コスト」「失敗した時の大きなリスク（低品質、技術負債、情報漏洩）」のこの2点の発生確率を最小化すること
- 結果PJTのゴールである「ユーザーの本質的な課題解決を行う価値提供、投資対効果の良い売上/利益創出、想定したシステムのQCDS」等を実現させること
レビューが必要となる問題の原因
PJT全体の開始から完了までの間で「後戻りした時の大きな開発コスト」「失敗した時の大きなリスク（低品質、技術負債、情報漏洩）」
という問題が発生する原因は
- プロダクト戦略
- マーケットの判断ミス、ユーザーの課題理解の誤り、市場動向や競合の不正確な理解
- コストとリターンの甘い見積もり、価格設定やビジネスモデルの設計ミス
- レベニュー・GTM戦略
- 事業計画やレベニュー組織がもつ製品への期待値のズレ
- 法令・セキュリティ
- 法令遵守する機能漏れ、契約やセキュリティ面の考慮不足による大前提の見直し
- チーム
- 即席で作った未成熟なチーム、不十分な体制（過小投資）、過剰投資による生産性低下
- プロジェクトマネジメント
- 本来あるトレードオフを考えずに理想を追求した結果実現不可能なPJTのゴール設定
- システム
- 誤ったアーキテクチャ選定や設計、非機能要件やシステム品質の定義や検討漏れ
- デザイン
- UX設計の考慮不足
など多様です。
ただ1つでもミスると結構な確率で問題は発生します。だから難しいと理解しています。
レビューの効果
「後戻りした時の大きな開発コスト」「失敗した時の大きなリスク（低品質、技術負債、情報漏洩）」の2点は後になればなるほど取り返す時間、お金、チームとお客様への負荷が高まります。
こういった状況が起きてしまう誤った判断や考慮不足を早期発見し、小さな手戻りに留められます。
レビュープロセスを作る際の考え方
上記効果を実現させるために、「大きな後戻りに繋がる判断が発生するポイント」をトリガーとして、プロジェクトを幾つかのフェーズに分けます。
これは、不確実性のコーンが近しい観点かと思います。（PJTの初期段階では不確実な要素が多いためゴールまでの見積もりは不確実で誤差が大きいが、PJTが進むと詳細が明確になり、見積もりの精度も向上するという考え方）
- 4倍（初期段階）：初期コンセプトの策定や課題設定
- 2倍（製品定義の承認）：PJTの成果物と開発範囲などの明確化
- 1.5倍（要求完了）：PJTの具体的な要求を定義、詳細の機能要件
のように不確実性のコーンで定義されているポイントが（策定時に厳密に意識したわけではないですが）、上記画像に示す「大きな後戻りに繋がる判断が発生するポイント」としています。
課題設定、ビジネスポテンシャル、UX、アーキテクチャ、法令などその制限や前提の上にソフトウェア開発は進みます。そこをミスるとちゃぶ台返しに合う可能性もあります。という観点はチェックポイントの設定上かなり重視しています。
それぞれのフェーズごとに「チェック観点」と「確認に必要な情報」の2点に対して、確からしさと不確かさらしさを議論し、考慮不足や判断ミスがないかを多職種の観点から考えます。
レビューの具体的プロセス
STEP① 課題設定・ビジネスの可能性
- 概要
- 事業やプロダクトの戦略。市場規模や市場の捉え方、対象となるユーザーの像や課題、現時点のソリューション、代替可能性、何を強みとして、どう届けるのか、などいわゆるリーンキャンバスに該当するものを見ます
- 少人数で行えるある程度のリサーチ結果を踏まえ、会社としてより人員を貼って大きく踏み込むべきPJTであるかどうかを判断します
- チェック観点
- マーケットのニーズの妥当性、打ち手の有効性
- ROI評価をもとに、事業単体として取り組む価値の確認
- 領域特有の法令や規制
- 確認に必要な情報
- PJT全体に取り組む背景、目的
- 顧客課題、実現したいこと
- 事業計画概算、投資概算上限、リターン概算など
- 体制、想定されるリスク
STEP② MVP+UX,ｱｰｷﾃｸﾁｬ,法令など重要論点
- 概要
- いわゆるMVP（Minimum Viable Product）の明確化。それに必要なアーキテクチャ、PJT全体の金額感やざっくりのスケジュール、大枠のUXや画面イメージ（モックレベルの画面数や機能概要）などです
- 不確実性が高い状態であるが、この後一気に物事が進む（多くの投資がなされる）ので、この時点で外さないことが極めて重要と考えます
- チェック観点
- 具体化された計画と①との差分
- QCDSとその優先度・バランス
- 進め方やマイルストーン設定の妥当性
- リスクやアーキテクチャやUXの妥当性
- 確認に必要な情報
- プロジェクトのゴールやマイルストーン
- 想定リスク、要求分析/要件定義、UX課題設定（USMなど）
- アーキテクチャ等の進捗、チーム体制と状況
STEP③ ゴールの明確化+リスク精査
- 概要
- 具体的にPJTの進捗状況・新たな課題やリスクを踏まえたローンチのタイミングや状態の明確化、他チーム（ex.セールス、CS、マーケ）との接続の洗い出し
- チェック観点
- UXやUIデザイン、システムやソフトウェア設計について、重要な不確実性要素の解消について必要性に応じてチェック
- 確認に必要な情報
- 要件やアーキテクチャの概ね方針確定後の具体内容
- 見積もりやQCDSの具体内容
- 新たに顕在化または増加したリスクの内容
STEP④ ローンチ前の最終チェックと準備
- 概要
- コンティンジェンシープランのチェック
- 発生しうる最大のリスクとその影響範囲
- 現時点の品質とその確からしさ
- チェック観点
- 機能/非機能要件の充足、UIやUXの最終確認
- 機能適合性/性能効率性/互換性/使用性/信頼性/セキュリティ/保守性/移植性など品質の妥当性、適法性
- リリース計画の妥当性、リスク発生時の対応方法
- 確認に必要な情報
- 品質レポート(機能/非機能要件、外部品質/内部品質)
- リリース計画/リスク/コンティンジェンシープラン
- プロダクトデモ
レビューする時のTIPS
レビューの参加者は関係する多様な職種を巻き込む
- レビュワーはエンジニア、プロダクトマネジメント、デザイン、など各職種の幹部や最終責任者はMUSTです
- レビューを持ち込む側もPdM、デザイナー、エンジニア、SRE、QAなど、多様なメンバーの参加が重要です
- レビュー当日に全員いなくても良いですが、事前検討ではSTEP②までに法務やセキュリティ、レベニュー組織や事業リーダーなど、上記記載の関係職種との要点の議論は済ませておくべきです
改めて資料まとめない、ありものを使う
- 改めて資料を作るのは、単純にコストがかかるだけでなく、リアルな現場を見えづらくします
- よって、リアルに現場で使っている資料が最も課題感や進捗がわかります（運用するドキュメントの共有が良いです）
進める際に大切にすべき点を言語化
- 行動指針まではいかず、その手前として、おさえるべきポイントを言語化しています
- 分量が多いので、何度もやって個とチームに染み込ませる以外ないと思っています
- よって言語化を行いレビュー時や振り返り時に確認するようにしています
※例
レビュワーの事前資料確認
- レビュー開始日の前日までに当日使う資料を共有してもらいます。そしてレビューをする人は事前に細部まで理解をすべきです。なぜなら中期開発PJTのため、観点が多様で論点も複雑になるためです
- レビューの目的を達成するためには「観点の漏れをなくす」ことが必須で、そのためには前提の状況理解は済ませて、議論に当日は時間を使えるようにすべきと思っています
- できれば気になる部分は質問を入れられると良いです
議事録は丁寧にとる
- 同時多発的にPJTは動くことが多く、レビューの間は一定期間空くものがほとんどなので過去のレビュー内容は忘れます
- いつどんな議論をその場で行ったかは口頭で終わらせずに、必ずテキストで残すことの徹底で、判断や評価を積み上げていけて、精度が上がると考えています
ナレッジ共有を行う
- レビュー起案者となる皆さんには横で資料を見える化できると良いです。弊社はGoogleDriveにフォルダ使ってまとめています
- このプロセスではどんな内容があって、どんなレビューがされたのか、各所で判断やレビューの品質が同時多発的に上がるのでおすすめです
PJT全体の振り返りもしっかり行う
- 単独のPJTのゴールはSTEP④までですが、PJT全体の判断や成果を振り返りし、チームの学びへとつなげることをSTEP⑤として入れています
- PJT全体の期間やコスト（想定と実績、ズレの分析）、効果の振り返り（定量/定性、発生した問題）、残対応や今後のプランニングを行います
- もっと上手く出来た点はないか、そのためにはPJT推進やレビュー上どこを意識するとよいか、仕組みを変えると良いかなどの学びを作り、チームだけでなく会社全体の学習につなげます
運営者が進捗を全体で管理する
- 今何がどういう状態でいつ頃どんなレビューあるかの可視化をレビュワー側が管理することが重要です
- PJT推進者はPJT推進に必死でレビューのタイミングは漏れるためです
- 詳しくはモニタリングの記事にと記載していますのでそちらもご覧ください
チームへの導入はやりながら一緒に
- レビューをする側もされる側も、フォーマットや観点用意されても、いきなり全部綺麗に出来ないです
- レビューを行いながら、自社やチームにあったやり方を皆で探して作っていくことで文化レベルにまで落とし込めると思います（我々も少しずつ浸透していっています）
その他参考情報
BIG THINGS どデカいことを成し遂げたヤツらはなにをしたのか？ という本はソフトウェア・ITに限らず、超大型PJTの成功・失敗の原因について書かれています。
- 「素早く考え、ゆっくり動く」のではなく「ゆっくり考え、素早く動く」ことが成功の要因。特にゆっくり考える「計画フェーズ」で目的を追求し、逆算的に変え、徹底的に調査・分析・検証された詳細の計画をつくること
- PJTの成功を阻害する要因として「心理：考案、判断、決定するのは人間で、思考と判断には楽観主義などの心理メカニズムが必ず作用する」「権力：人や組織が資源を求めて競争し、地位を求めて画策し、競争と画策には必ず権力が絡む。権力者は自身の気に入ったPJTを押し通す」の2つがあることを理解して進める
とされています。
本記事も上記記載の通り、レビュープロセス半分が実際に開発を進めるまでの計画部分を占めています。
阻害要因となり「心理と権力」は腰を据えて話すレビューの機会、多様な参加者によって、そうなっていないかを確認できる機会になっているとも言えます。（レビュワー側がPJT運営者にいては成立しづらいですが）
最後に
整理していくと、特に特殊なことはしておらず、そりゃそうだよねと感じる内容が多かったです。ただ、その当たり前を当たり前に行う事が大きな差分を生むのだと思います。
レビューに持って来てくださる方にも、レビューの時間が形式的な面倒なものではなく、意義のある、PJTの成功確率をあげ、自分たちが成長できる機会と思ってもらえる、実際そうなるものにするため、常にレビュワーの強い意識と準備が重要です。
何よりレビュワーにはナレッジがたまり成長する大いなる機会です。ただそれは皆に共有する責任もあります。
私も弊社も、まだまだ出来ていないことは多いですが、引き続き頑張ってまいります。
さて、こんな株式会社LITALICOですが、もしご興味もってくださったらぜひ一度お話しましょう。ご連絡ください。
X(旧Twitter): @ka_me_sen_nin
それでは、明日(9日目)のLITALICOのアドベントカレンダーは
- @eito_katagiri-litalico さん
- @yoco-k さん
- @marst_xx さん
- @iwafs さん
の皆さんです！大量！
まだまだ多様な記事が登場しますので、引き続きLITALICOのアドベントカレンダーをお楽しみください^-^