今回は白川克氏・濱本佳史共著の「システムを作らせる技術」を要約します。主にエンジニアではない人向けにシステム開発・導入プロセスにおける要諦を時系列順にフレームやテンプレートと共に解説・体系化を試みた本です。社内SEをメインターゲットとしてプロダクトマネージャー・事業企画・UXデザイナーなどにも通じる考え方が詰まっています。顧客起点で開発をリードし、成果とビジネスストーリーをアップデートするための基本動作を学びたいと考えこのタイミングで本書をチョイスしました。
「システムを作らせる技術」
■ジャンル：開発管理・IT
■読破難易度：中（関連業務を一度でも行っていると非常に納得できる内容となっております。プロジェクトマネジメントやエンジニアリングに関する本を1冊でいいので事前に読んでおくとイメージがわきやすいかと。）
■対象者：・横断型組織をリードする役割に従事する方全般
・開発プロセスについて興味関心のある方
≪参考文献≫
■プロダクトマネージャーのしごと
■要約≪プロダクトマネージャーのしごと≫ - 雑感 (hatenablog.com)
■アート・オブ・プロジェクトマネジメント
■要約≪アート・オブ・プロジェクトマネジメント 前編≫ - 雑感 (hatenablog.com)
■要約≪アート・オブ・プロジェクトマネジメント 後編≫ - 雑感 (hatenablog.com)
■アジャイルサムライ
■要約≪アジャイルサムライ≫ - 雑感 (hatenablog.com)
【要約】
■Concept Framing
・システムを作らせる側と一口にいってもプロジェクトリーダー・経営者・業務部門と3つの視点・利害関係が存在します。一般的なプロジェクトのステップは「ゴール明確化→現状調査/分析→構想想定→要求定義→製品・ベンター選定→プロトタイプ検証→設計・開発→稼働」を経て、平均で約1年程度かけてシステム開発・導入をしていくのが基本とされます。課題設定・構造特定を粗粗にすると筋の悪い問題を解いて最悪手戻りになります。要求定義の段階で要求コントロール・合意形成をできるかがシステム開発の成功を大きく左右します。
・システムに関する無理難題や細かい要望はシステムへの理解不足に加えて、不確実性に対しての処理能力の乏しさから来る防衛本能やリスク回避など様々な感情や利害を含んでいるということを意識して対応しないといけません。「何を目指しているのか」・「何を大切にするのか」という道標は優先順位付けやコミュニケーションのリソース配分や生産性に大きくヒットするもので、面倒でも初期に網羅的に検討する・ステークホルダーを総動員して議論・疑義出しを仕切るというのが大切です。
■Assessment
・システム開発の前段には業務とシステムがどのような状態・フローを経ていて何が得意・何が苦手/問題であるの分析・あたりをつけるということをしていくことが大切になり、ユーザーインタビュー・観察・定量測定など様々な手法で調査をしていきます。既存の業務フローのバラエティや関係性を把握するということは打ち手設計や重要な問題特定の上で絶対に避けて通れないですし、現場承認を仰ぐ際の大きな武器になります。業務フローとステークホルダーを図示化する・関連するビジネス指標の現在地を測定しておくとシステム開発のインパクトや論点を導きやすくなります。
■Business Model
・・具体的なシステム開発をする前に、システム開発をしたらどんな世界が待っていて具体的に何が変わるのかの言語化・方向性をすり合わせることに時間を割くのがシステム開発の生産性や成果物に大きく寄与します。システム開発には業務プロセスや役割分担・指示命令系統の変容が付きまとうものであり、事前にその影響度合いと予測をステークホルダーと対話しておかないとシステム開発後の利用フェーズにおける負を生んでしまうリスクが発生します。具体的には「何を変えるのか」・「それはなぜか」・「何が良くなるのか」の問いに対する解の言語化です。
・システム開発はシステム間・業務間・データの兌換性・一貫性を促進する論点が常につきまとい、投資判断はこうした経済合理とトレードオフになります。目先の流行に飛びつくようなシステム開発はビルドトラップの源泉にしかならないですが、「元々やりたくて出来ていないことをシステムの力で簡便化・安定化する」などは最もビジネス成果に寄与する合理性のあるシステム開発目的になります。
■SCOPE
・要求定義と要件定義は似て非なるものであり、誰目線のものか・何が大変かの違いがあります。
・要求を洗い出し、優先順位の基準を決定して開発する機能の優先順位を定めて実際の機能役割・効果を言語化していくというのが基本的なシステム開発のプロセスです。要求定義をする際の機能の洗い出しは後で優先順位付けすることも含めてとにかく網羅的に洗い出しをすることに専念するということが大事な感覚になり、ワークフロー毎・ステークホルダー毎などのマトリックスを組成して洗い出すのが良いとされます。現状と将来の業務フローの変化を可視化することで「システム開発のポイント」・「何がどのように変わるのか」・「それはなぜか」の言語化・可視化をすることは導入後含めて効果的なコミュニケーション促進・システム開発がビジネス成果にヒットするようにマネジメントするためのミソになります。
・要求が洗い出せたら俯瞰して全部を見通せるようにファンクショナル・マトリクス（以下FM）にまとめるのが基本とされます。業務フローや目的とそれに対応する要求機能という形で可視化していくと優先順位付けが出来るようになります。構造化・因数分解・漏れなくダブりなく・俯瞰して見渡すが出来るように情報をわかりやすくまとめるのは絶対感覚です。後の優先順位付け・合意形成プロセスにおいて効力を発揮するFMは運用に堪えうるものになるように事前の判断基準や標準ワークフローの洗い出しが欠かせないのです。
・機能を洗い出したあとは非機能要求と呼ばれる可用性（システムはいつ使えるか）・性能拡張性・運用保守性・移行性・セキュリティ・システム環境エコロジー（設置場所の環境）の6つの切り口でシステムを考慮しベンダーに依頼するのは必要なプロセスとされます。計画的な停止期間・停止できる期間はどれくらいか（顧客価値に毀損しないのはいつか）などを考慮することが大切です。また、「システムの処理スペックはどれくらい耐えられるのか」なども大事な考慮するべきポイントとなります。データ移行コストやセキュリティのレベルなどシステム機能だけでなく、それが実際に活用される際の影響力を見積もるというのは避けて通れない観点とされます。品質における許容ラインの定義と利用難易度の最小化などは作って終わりにしないシステム開発の為の考慮すべき原理原則です。
・尚、システム開発とSaaSは競合するものであり、パッケージベースでない手弁当で作る開発工程をスクラッチ開発と呼びます。システム間の関係性や連動をマネジメントしていくのも利活用フェーズまで踏み込んだシステム開発においては考慮すべき視点となります。ビジネス全体のステークホルダーやワークフローをマッピングして因果関係や構造を捉えるというのはプロダクトマネジメントでも鉄板の技法です。
■パートナー選定・BRP
・ベンダー候補の洗い出しは様々な軸で評価していくのがよく、製品特徴・導入実績・費用・提供方法（オンプレミス・クラウド）などを洗い出していくことであたりをつけるのが良いとされます。合い見積もりしかり、合意形成プロセスを精緻に行う必要があるということがスタッフワークの定めです。評価軸は必須条件を見たいているか・コスト・機能カバー範囲・ベンダーやパッケージ企業そのものの評価という4つの軸でベンダーの方向性を選定していくのが一般的です。ベンダーへの見積もりを依頼する際にはプロジェクト背景・現業→未来の業務フロー・スコープイメージや制約条件などを言語化して提案の材料にしてもらうというのが発注側の御作法です。信号モデルのような判断軸や論点を明確にして取捨選択・意思決定していくというプロセスを踏むことが利害関係や専門性の異なるチームでの仕事をする上では必須です。
・開発工程では後工程で問題が見つかったほうが手間や影響範囲は広くなり、早期に問題検知・状態把握できるようにするのが生産性のカギとなります。システムを作る人と作らせる人が共同で行う工程がBRP（Business Process Prototyping）とされ、これをしないとユーザーテストまで発注側が現状を把握・要望できないことになります。模型のようなものを作り、要求の優先順位や具体化などをしていくことでイメージをすり合わせるということは設計・見積もりをした後に改めてやるのが良いとされます。プロトタイピングにはセオリーがあり、対象シナリオ選定→シナリオの準備→確認ポイントの明確化→プロトタイプを用意する→データ準備→プロトタイプセッション当日→課題をつぶすの7工程です。標準ワークフローを洗い出し、現行踏襲と現行と大きく変化する所を洗い出し、インパクトや論点がないかを精査するというのがよくあるプロセスです。何が致命傷か・それぞれのチェックポイント・項目・品質基準の定義などを双方で対話していくという工程を経て認識すり合わせしていくのが具体的なプロセスです。
■Design・Deployment
・ITベンダーはプロジェクトの成功やユーザーストーリーに関しては大した関心やコミットメントは払わないです。その前提でシステムを作らせる人がリーダーシップを発揮したり、方針決めにて高い影響力を発揮していくことが必要とされます。開発工程になっても基準やスコープ・優先順位・戦略等に関してはこちら側でコントロールしてデリバリーコミットするようにしていく姿勢が欠かせないです。
・開発工程におけるプロジェクト成功の原則はある程度決まっており、「ユーザーが参加し続ける」・「保守をにらむ」・「エキスパートとのつながり」・「OneTeamにする」・「WhyやHOWをきちんと伝える」・「言葉と進み方は明示的に」・「ストレートに意見を言い合う」・「プロジェクトルームはできれば一つに」・「学び合う」の9つです。業務担当者（ユーザー）・システム発注主・システム開発者（エンジニア）が業務フローやシステム要件について可視化・構造化されたツールにて認識を共にするというのは非常に大切なステップであり、部分最適ではなくコラボレーティブ・全体最適的な考えを進めていくことを推進することが絶対感覚です。
・エンジニアの納品物については実際にユーザーに使ってもらい、前後の導線や遷移プロセスが想定の範囲内に収まるかどうかを見るというプロセスが重要であり、スクラムなどはこれをスプリント単位でレビューするということで素早く改善していくこと・学習しながら開発するといった組織文化に大きく作用します。システム開発・リニューアルの場合はWhyを何度も伝えてどのように乗り越えていくのか・それはなぜかというストーリーや背景を言語化・会話していくことを欠かさないのがミソになります。この現象は視座視界の低さというよりも関心の度合いや責任範囲の違いであると認識せよと推奨されます。
・データ移行はシステム開発の周辺に発生する重要業務であり、現行システムのデータ抽出プログラム→データ変換プログラム→データ移行プログラムを用いる3ステップを経ることが多いです。システム開発プロジェクトは作るのと同じくらい引っ越し作業が大変であるとされます。データ移行の際は現行と新プログラムにおけるデータ分類・整理のロジックが異なるケースも多数存在し、それを適当に扱うとシステムが意味をなさなくなります。項目の適切な階層での抽出・網羅的な選定などをしていくことが馬鹿にならず、時に適切な情報を捨てることが必要になります。
■Roll Out
・旧システムと新システムを並列に走らせて実稼働するというのがシステムの原則であり、デュアルシステムと呼ばれます。バトンタッチ型並行稼働と業務テスト型並行稼働の2種類が存在します。業務とシステムの切り替えはプロジェクトの最大の関門であり、事前説明をして理解を得ていた・テストでリスクを検知できていたとしても必ず障害が発生するもので、従属関係のある工程なので部分の遅延が全体に波及するという構図になります。
・「作ったのに使われない・理解されない」というのは最悪のシステムであり、そうならないように価値観や従属関係を顧客部門とヒアリングしてすり合わせる・活用推進の体制を構築するなどしていくことが欠かせないです。これは開発・システム発注側のマネジメント的にも必要です。
【所感】
・主に社内業務用ではありますが、類似案件を発注者側・開発河いずれも経験したこともあり、自身の当時の振舞い方の可否も鑑みながらかみしめるように読みました。顧客価値・ビジネス成果へのヒットと開発工程における不確実性・QCDのマネジメントのバランスをとることが生産性のカギであり、最も難しいということを改めて思い知らされる内容でした。フレームワーク（時系列に沿いワークフローを可視化する・マトリックス形式で比較検討する・信号モデルなど）や可視化→合意形成プロセスというのは教科書通りに行い、やりきることが最も効果的で楽であるということを実感した直後でしたので、非常に考えさせられました。
・全ての開発は投資行為であり、シビアに投資対効果を見られ続ける宿命にある・従属関係や不確実性からは避けられないといった当たり前ですが普遍的な要諦を再認識させられ、これからも理論⇔実践の行き来を繰り返しながら鍛錬していこうと思った次第でした。本書のシステム開発・導入プロセスは業務用システム、主にWFを想定したものでしたが派生形として自社製品・アジャイルなどの形式の際の急所についてもしっかり言及があり、プロダクトマネジメントに従事する方にも大変参考になる内容だなと感じました。何度か触れていますが、当該分野は教科書や理論に忠実に実践していく、そもそもの要諦を抑えられているか（≒知っているか）が成果の大半のカギを握るということに思えて記憶を塗り重ね実践しながら継続学習していこうと感じました。より影響範囲や不確実性の高い案件をリードし、非連続の成長・変革を牽引するロールになれるよう努めたいと奮い立たされる内容でした。
以上となります！
