読んだ理由
昨年とは違い、コードを書いてシステムを作る側から要件定義と設計をして実装依頼をする側に自分の役割がシフトしてきた。
依然としてエンジニアではあるものの、仕事におけるビジネスサイドの比重が増えてきたのでビジネスサイドからみたシステム構築に興味が湧いた。
BizとDevの架け橋的なものになれるヒントがありそうと思い購入。
メモ
ITプロジェクトにかかわる4つの関係者
経営者
現場の担当者では判断がつかない（判断すべきではない）レベルの意思決定を下す。
常にPJに張り付いてかかわる必要はないが、キャッチアップはしておく必要がある。
- セキュリティレベルを1あげるのに1億円かかる。投資すべきか。
- 営業部と経理部の利害が対立する際に、どう落とし所を見つけるのか。
業務部門
システムを使う人。
システム構築においてここをどう巻き込んでいくかが肝。
PL（プロジェクトリーダー）
経営者、業務部門、IT部門を仲介し、PJを進める。
上記3者はそれぞれ立場や価値観、話す言葉（用語）も違う。
全体を俯瞰した上で、今何に注力すべきなのか、優先順位はどうなのかを決め、関係者を巻き込んで議論していく。
PLは業務部門でもIT部門の人間でもよいが、両方経験した人材がベスト。
IT部門
システムを作る。
システムを作らせるのはだれか
- 経営者
- 業務部門
- PL
経営と業務部門のどちらかが人任せモードだとシステム構築は失敗する。
だれかが意を決してPLに立つ必要もある。
各々が当事者の自覚を持つことが大切。
システム構築のWhy→How→What
システム構築は「Why→How→What」の順で考える。
ダメな例
What：このソリューションがすごいらしい。わが社にも導入しよう。
↓
How：このベンダーに作らせよう。ユーザーにはこのように使わせよう。
何を実現したいのかわからない誰も使わないゴミシステムの完成。
よい例
Why：工場ごとにばらばらな業務を標準化/統合し、1つの会社として運営すべきだ。
↓
How：統合後の業務プロセスはこうしたい。ガバナンスはこうあるべきだ。
↓
What：そのためにはこういうシステムを作ろう。こんな機能が必要になる。
プロジェクトゴール作りのポイント
- 以降の工程で使えるゴールにする
- 地に足ついたゴールにする
- 何のためのPJかゴールに込める
- ゴールはわかりやすく
完璧な要件定義はできない
どんなに時間をかけて、調査、検討したとしても完璧な要件定義はできない。
結局PJ終盤になってもっとこうすべきだったということになる。
むしろそれが普通。
調査や要件定義はほどほどにして後の工程で不完全さをカバーする方法で進めていくしかない。
システム要求、要件
要求定義
システムを作らせる人がシステムはこうあってほしいと、システムに求めるものを明確にする作業。
網羅性にかける。
要求
・キッチンは明るい方がいい
・トイレは2ついらない
・風通しのよさが重要
要件定義
システムを作る人がシステムに必要とされる性能や機能を明確にする作業。
要件
・キッチンは2階に
・トイレは階段の下に作る。（したがって天井は低くなる）
・階段の上に常時開けておける小さな窓を作る
システム要求の3大障壁
完璧なリストアップができない
リストアップ作業は現場ユーザーだが、システムに明るくないので網羅性、正確性にかける。
家を建てる前に、「私たち家族はこんな家が欲しいのです」と網羅的で矛盾のない要求を伝えられる家族がどれだけいるか。
常に予算オーバー
要求を洗い出した時点ではだいたい予算オーバー。
優先順位をつける。
立場が違えば、システムに求めるものも変わる
PJ関係者の利害はしばしば食い違う。
意見が矛盾していることもざらにある。
要求定義とは
利害関係者の意見をまとめて、実現すること/実現しないことを揺ぎなく定めること。
要求定義は現場ユーザー主導だが、彼らは要求を正しく定義する訓練は受けていない。
ITエンジニアが何を定義してほしいのかを提示し、リードしてあげる。
優先順位の基準を決める
- ビジネスベネフィット
- 組織受入態勢
- 技術的容易性
の3つをHigh、Middle、Lowで評価。
ビジネスベネフィット
この機能がビジネス上どれほど価値があるのかを測る。
| H | M | L | |
|---|---|---|---|
| ビジネスベネフィット | ・10人月以上の削減効果が期待できる ・サービス品質向上を目指せる ・コンプライアンス上必要不可欠 | ・5人月程度の削減効果が期待できる ・現状のサービス維持に必要不可欠 | ・あれば便利な機能 ・代替手段がある ・利用頻度が少ない |
組織受入態勢
この機能を現場が使いこなすのはどれだけ簡単かを測る。
| H | M | L | |
|---|---|---|---|
| 組織受入態勢 | ・簡単なトレーニングで受入可能 ・運用ルールや既定の変更が少ない | ・運用ルールの見直しが必要 ・複数部門間の調整や役割分担の見直しが必要 | ・組織変更など全社的に影響がある ・社外交渉が必要 |
技術的容易性
どれだけ簡単につくれるか、実装コストが低いかを測る。
| H | M | L | |
|---|---|---|---|
| 技術的容易性 | ・自社特有の特殊機能ではない ・パッケージ標準機能で実現可能 | ・自社特有の独自機能 ・カスタマイズが必要な機能 | ・ゼロベースで新規開発が必要 ・事例が少なく、実現手段が不明確な機能 |
非機能要求の切り口
可用性
システムはいつ使えるのか。
いつどのくらい止まるのか。
性能/拡張性
レスポンスの速さや、同時に何人のユーザが利用できるかなど。
運用/保守性
運用・保守がしやすいか、またコストはどれだけかかるか。
移行性
前のシステムからどのデータをもってくるのか。
持ってこれるのか。
セキュリティ
セキュリティをどれだけ担保できるか
システム環境/エコロジー
環境負荷はどうか。
SaaSにおける非機能要件
パッケージなので提供ベンダーが目標値を設定しているため、こちらで議論することが少ない。
拡張性や稼働率などは確保済みがほとんど。
非機能要件を詳細に検討する能力がない場合は、こういったサービスに乗っかるのが手っ取り早い。
IT投資の3階層
戦略投資
全く新しい市場やビジネスモデルの創造
ROI投資
既存事業の継続・強化による収益増
事業継続投資
売り上げに直接貢献しないが、事業継続上、法令順守やコミュニケーションなどで必要
投資対効果が黒字化するわけではないので投資決裁を通すにはポイントを抑える。
- ビジョン・理念に訴える
- 他社劣後を訴える
- 事業継続の土台であることを理解いただく
プロトタイピング
プロトタイピングは、システムの画面だけでなく業務のやり方自体を検証すること。
シナリオ作成し、確認ポイント名確認した上でプロトタイプを使用してユーザーにレビューしてもらう。
画面を見て操作しやすそうかの確認だけでは意味がない。
新しいシステム・機能を使って業務を回すイメージを持ってもらう。
シナリオ作成が肝。
つまり業務フロー。
これはプロトタイピング前に現場に提供してもらう。
ユーザー教育
業務担当が担ったほうがよい。
以下を伝える。
- プロジェクトの意義（Why）
- 業務がどう変わるか（How）
- システムがどう変わるか（What）
前の機能はないのか？前の方が使いやすそうなど必ずネガティブな意見がでる。
そのため必ずWhyから説明する。
現場はプロジェクトメンバーと違ってずっとシステムのことを考えているわけでないのですぐ忘れる。
ヘルプデスクの設置
稼働後のコミュニケーション窓口を用意。
稼働後の利用をチェック
システム稼働後はちゃんと利用されているか定期的にチェック。
これをどうやっていくか。
レポートなでデータ入力をウォッチするとか？
コメント