システムを作らせる技術

著 : 白川克、濵本佳史

https://m.media-amazon.com/images/P/B099WCDCG6.01._SCLZZZZZZZ_SX500_.jpg

Amazon : https://amzn.to/3Hyxq4G

ケンブリッジ・テクノロジー・パートナーズというコンサルティング会社で使われている Cambridge RAD という IT システム開発の方法論を解説した書籍

A 章作る前に知っておくべきこと

1. 作らせるのは誰か？

経営と IT の関係は『会社の IT はエンジニアに任せるな！』参照

システムを使う業務部門

経営と業務部門と IT 部門を繋ぐプロジェクトリーダー

経営と業務部門のどちらかが他人事だと失敗する

2. システムより先に考えるべきことは？ : システムを手に入れて何をしたいのかを考えつくす

ゴールデンサークル

3. なぜこんなに計画がブレるのか？

不確実性コーン

B 章プロジェクト全体の進め方

システム構築の全体像

Concept Framing (ゴール明確化)

C 章ゴール (Why) を明らかにする

ゴールが明確でなければ成功裏に稼働までたどり着かない

nobuoka.icon アウトプットではなくアウトカムを、って話だ

良いゴールを作るコツ

以降の工程で使えるか？

地に足がついているか？

なんのためのプロジェクトかがゴールやコンセプトに含める

ゴールのわかりやすさにこだわる

Assessment (現状調査・分析)

D 章現状の棚卸しをする

現地現物主義は良いが、調査の目的が明確でない場合がある

課題発見をするのか、棚卸しをするのか

仮説ベースで深ぼるか、網羅性が大事か

現状の業務とシステムを棚卸しするための 9 大フォーマット

それをもとに分析する

課題の本質や、繰り返さないようにすべきことは何？

無謬性の原則

Business Model

E 章将来像 (How) を明らかにする

発生時点入力

現行システム構成図を見て、人間が情報を繋いでいる部分の改善

データを一元管理する

マーケティングオートメーション (MA)

将来業務フローを描いていく

Scope (要求定義)

F 章システム要求 (What) を決めるプロセス

要求定義や要件定義と呼ばれるプロセス

設計は、要件を実現する技術的な方法を決める作業

内部設計、外部設計

システム要求の本質的な難しさ

完璧な一覧化はできない

常に予算を超えてしまう

関係者全員の同意を取ることが難しい (立場によって求めるものが違う)

G 章機能を洗い出す 7 つの方法

要求定義の第一歩

ファンクショナリティ・マトリクス作成の最初の段階

H 章要求を FM にまとめる

ファンクショナリティ・マトリクスにどうまとめるか

開発着手前にスコープを決めることが大事 → アメリカでは Scope フェーズと呼んでいる

nobuoka.icon システム開発プロセスの国際標準とかを見ても Stakeholder Needs and Requirements Definition process とかになってて、Scope フェーズって聞いたことないや

とはいえスコープ明確化が重要という観点は大事だな

J 章優先順位の基準を決める

ケンブリッジ・テクノロジー・パートナーズでは、3 つの軸で評価

ビジネスベネフィット (ビジネス価値)

組織受入体制 (利用者側のコスト)

技術的容易性 (開発コスト)

それぞれ 3 段階で評価できるように、基準を明確化

K 章作る機能を決める

L 章 FM がシステム構築を成功に導く

M 章機能以外の要求を定義する

機能要求をファンクショナリティ・マトリクス (FM) に記載する以外に、以下 2 つを検討する必要

非機能要求

システムアーキテクチャ

PEW (パートナー選定)

スクラッチ開発ではなく汎用パッケージソフトを利用することが増えてきた

これまでにない IT サービスを作る業務を除くと、ほとんどの業務向けのパッケージが存在する

基幹業務 (経理、在庫管理など)、ナレッジマネジメント、社員コミュニケーション、顧客管理などなど

ケンブリッジ・テクノロジー・パートナーズでは、パッケージやベンダーを選ぶ工程を Partner Evaluation Workshop (PEW) と呼ぶ

N 章～ O 章

Partner Evaluation Workshop 参照

Q 章稼働までの計画を立てる

システム構築以外の作業も全体スケジュールに載せて管理する

ケンブリッジ・テクノロジー・パートナーズにおけるテスト工程の定義

R 章プロジェクトの投資決済を得る

費用対効果分析、システム投資決裁

ベンダーの予算見積りはプロジェクトの予算見積りとは異なることに注意 (ベンダーの見積りの対象範囲外のものもある)

不確実性コーン

IT 投資の 3 階層

BPP

S 章課題を先出しする

Business Process Prototyping (BPP)

業務のやり方自体を検証する

Design・Deployment

T 章開発チームの立ち上げ

プロジェクト全体のマネジメントは発注者が責任を持つ

OneTeam になるために

請負契約をやめて、フェーズごとの準委任契約に

率先して「プロジェクト最適」を言い続ける (自社の利益や都合を持ち出さない雰囲気づくり)

U 章キーチャート

キーチャートでファンクショナリティ・マトリクスを補完

V 章開発中の関与

監理できるプロの任命 → IT プロジェクトの監理

課題解決への参加

ファシリテーションも重要

利用者目線での確認

仕様ウォークスルーやシステムテスト (総合テスト) のシナリオ、受け入れテスト

ユーザー教育 : プロジェクトの意義、業務がどう変わるか、システムがどう変わるかを説明

W 章データ移行

データ移行

Rollout

X 章いよいよ新システムの稼働

コンティンジェンシープラン (コンティンジェンシー計画)

稼働後には振り返りが重要

補足

Y 章ベンチャーでのシステム構築

ステージを小さく区切る (スプリント)

Minimum Viable Product (MVP)

本書で説明している方法論は Cambridge RAD

Z 章 FM をシステム構築以外に応用する

組織変革・組織設計をする際に、必要な組織機能や役割をファンクショナリティ・マトリクス (FM) 風に表現

#書籍 #文献