濵本佳史のレビュー一覧
-
-
-
-
-
-
Posted by ブクログ
システムを”作らせる”（ユーザ企業側）目線で書かれた，
システム開発系PJ成功指南所．
かなり割愛して読んだが，後書きにあった最後の一文が痺れた．
"本当は「作らせる人」も、「作る人」もいない。いるのは「プロジェクトを成功させ、会社を良くしたい」ともがく人々だけだ"
ベンダーだろうがユーザだろうが，この信念を持てるかどうか．ベンダーであれば要求の洗い出しや整理などユーザ主体の活動であっても「ユーザの責任範囲なんで」と他人事で見ないこと．ユーザであればシステムのことはわからない（わかるつもりもない）とベンダーに丸投げしないこと．
すなわち，他責にならないことが大事．
相手に多少踏み込み過ぎ？と思われるくらいが丁度いいかもしれない．だって「プロジェクトを成功させ会社をよくする」ためにもがいているんだから．
・PJには100％確実なものは何もない
・ユーザは業務のプロであって要求定義のプロではない．ユーザからシステムへの要求や制約を引き出させるのもエンジニアの仕事
・プロジェクトを停滞させる一番の敵は、厄介な課題、チームや部署を跨いで議論しなければ解決できないような課題
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
他人への説得論法
why → How → What
私たちは世界をかえる〜→その手段は〜→だから◯◯を作った。
一般人はどうしてもwhatから考える。だからストーリーがつまらない。
こんなソリューションを使う(what)→ベンダーに作ってもらおう(how )
工場を◯◯にしたい→◯◯が必要だ→こんなシステムが必要だ
プロジェクトは曖昧さ100%から曖昧さ0％の着地に向かって進む、不確実性が減り具体的になる
→★確実な情報を持ってこい！は傲慢。曖昧さを減らすために対話して意思決定を積み重ねる。
要件定義の難しさ
・検討漏れの発生
・要件を詰め込みすぎる→ビジネスライクに必要性を判断
総論賛成各論反対
良いプロジェクトのゴール
以後の工程で使える価値尺度がはいっている
(現状維持>新規性)
地に足がついている
わかりやすい
whyがこめられている
プロジェクトは初めての活動
→こうすればよかったは必ず出る
→完璧を目指す姿勢そのものが間違っている。
要求定義
→システムを作らせる人のwant
要件定義
→システムを作る人が、システムに必要とされる性能や機能を明確にする作業
設計
→要件を実現するための技術的な方法を決める作業
要求定義作成の難しさ
・網羅的な洗い出しができない
・予算オーバーになるって
・立場によって要求が異なる
★著者の会社の要求定義の定義
"要求定義とは利害関係者の意見をまとめて、実現すること・実現しないことを揺るぐなく定めること"
★ユーザは業務のプロであって要求定義のプロではない
→引き出す、ナビゲートするのもエンジニアの仕事
★全て洗い出す→優先順位をつけてやるやらないを線引きするところまでの客と握る
→スコープ(やる・やらないの線引き )を明確にして、あとになって「これも必要」と言わせない。やらないと分かっていても端折ったり捻じ曲げたりしない。
★網羅的に検討したんだぞという訴求
★恣意的ではなく合理的に選択したんだぞという訴求
コミュニケーション計画
★プロジェクトを停滞させる一番の敵は、厄介な課題、チームや部署を跨いで議論しなければ解決できないような課題
ファンクショナルマトリクス
縦軸に大きな流れやmeceな構成要素
横軸には各行を一段落として分解したもの
セキュリティの例: 対策領域×IDDRR -
-
-
-
-
Posted by ブクログ
■現状の業務とシステムを棚卸しする９大フォーマット
業務系フォーマット
①現行業務フロー
②現行アクティブティ一覧
システム系フォーマット
③現行ファンクショナリティ・マトリクス
④現行システム一覧
⑤現行インターフェース一覧
⑥現行全体システム一覧
⑦現行システムの主要データ
⑧現行コード体系
共通フォーマット
⑨課題一覧
■将来業務フローを作成する６つのテクニック
①変化点を必ず書き出す
②まずはアナログで作る
③フォーマットを決める
④メインフローが先、イレギュラーが後
⑤詳細はとりあえず脇に置く
⑥１人で作らず、人を巻き込む
■システム要求の３大障壁
①完璧なリストアップができない
②常に予算オーバーになる
③立場が違えば、システムに求めるものが変わる
■システム構築スケジュールを精査する６つの視点
①MUSTな期限が守られているか
②業務繁忙期とシステム構築のピークは重なっていないか
③工程ごとのゴールが明確か
④成果物をチェックするマイルストーンはあるか
⑤各領域の整合が取れているか
⑥各フェーズの期間バランスが適切か
■良い開発チームを作る９原則
１．ユーザーが参加し続ける
２．保守をにらむ
３．エキスパートとのつながり
４．OneTeamにする
５．WhyやHowをきちんと伝える
６．言葉と進め方は明確に
７．ストレートに意見を言い合う
８．プロジェクトルームはできれば１つ
９．学び合う
■キーチャート７選
①ステータスマトリクス
②ステータス×操作可否
③機能×利用者権限
④BOMごとの管理情報
⑤採算管理における集計対象
⑥承認プロセスのキーチャート
⑦受注チャネルのバリエーション
2026/6/7
F章 システム要求 (What) を決めるプロセス
この章のレッスン
・システムを作る上で重要となるシステム要求定義の流れを理解する
・システム要求をまとめる上で難しい点を把握し、「なぜこのプロセス・成果物ならうまくいくか」がわかるようになる
これまでのフェーズでプロジェクトのWhyとHowが固まったので、ようやくWhat、つまり「どんなシステムを作るのか」を決める Scope フェーズを開始できる。一般的には要求定義、要件定義などと呼ばれる工程だ。 この章は要求定義の最初の章として、全体を俯瞰するための3点を説明する。
・要求定義とはなにか? (言葉の整理など)
・要求定義はなぜ難しいのか?
・要求定義(特に機能要求定義)のステップ
システム要求、要件、そして設計
要求定義と要件定義という言葉は一般に、「誰がその作業の主体か」に着目して、以下のように使い分けられる。そして設計はそれらに続く工程た。
要求定義
システムを作らせる人が、「システムはこんな風であってほしい」と、 システムに求めることを明確にする作業。システムに詳しくない人が定義するので、システム的な厳密性、網羅性には欠ける。
要件定義
システムを作る人が、システムに必要とされる性能や実装すべき機能などを明確にする作業。システムが果たすべき機能はすべて要件定義書に書かれるべきなので、例えば「どういうケースでエラー表示をするか?」の一覧表を作るプロジェクトもある。
設計
システムを作る人が、要件を実現する技術的な方法を決める作業。例えば「この機能は○○というソリューションを使う」 「データ構造はこうする」といった具合だ。ユーザーから目に見える画面レイアウトなどを固める設計を「外部設計」、目に見えない内部ロジックを考える「内部設計」 に分ける場合もある。
イメージしにくいと思うので、まずは住宅の例に当てはめてみよう。
要求
・キッチンは明るい方がいい
・トイレは2ついらない
・風通しの良さが重要
要件
・キッチンは2階に
・トイレは階段の下に作る。したがって天井は低くなる
・階段の上に、常時開けておける小さい窓を作る
設計
・実際の設計図
こう整理して書くと当たり前に見えるのだが、要求は家に住む人にしか言えない。トイレが2つあることが書斎よりも重要、という人も中にはいるだろう。どっちが正しいという話ではない。何を重視するか? という価値観で決めることだ。
そして要件は住む人と建築のプロとの共同作業になる。「キッチンは絶対に2階がいいんです!」と主張する施主もいるだろうし、「2階のキッチンは明るくて良いものですよ」とプロが提案し、それに施主が賛同する場合もあるだろう。
また、プロからの要件の提案を受けることで、施主が自覚していなかった要求が浮かび上がることもある。例えば「キッチンを2階にすると、子ども部屋に行くのにキッチンを通らない。思春期になったら親子の会話が減りそうでイヤ!」という具合だ。
それに対して、設計は完全にプロの領域だ。キッチンを2階に設置することで、水回りの配管をどう巡らせるべきか? といったことは専門家でなければわからない。それらを全て踏まえた上でベストな設計図を書く際に、中途半端に素人が口を出すとかえって悪くなるものだ。
ここで描いた施主とプロの建築家の関係は、そのままシステムを作らせる人と作る人の関係になぞらえることができる。要求/要件/設計それぞれについてシステム構築での例をあげると、
要求
・契約条件は同じ顧客との間では頻繁には変更されない。だから受注の際には条件を都度入力したくない
・上司は部下の職務経歴を自由に参照できるようにしたい
要件
・契約条件は契約マスターに登録する。受注の際には契約マスターから条件を自動で受注画面に表示することで、都度入力する手間を省 <
・上司が職務経歴を参照できる「部下」とは、同じ組織に属し、かつ職位が自分より低い社員のこと
設計
・受注データは契約データとリンクを張り、受注画面に条件を自動で表示できるようにする。ただし受注画面で条件を変更することもできる
・組織マスターの管理職情報と社員マスターの職位情報をプログラムが読み取り、参照権限を自動でコントロールする
といった感じになる。
設計について中途半端に素人が口を出すとかえって悪くなるのも、住宅と同じである。例えば「職務経歴を自由に参照できるように」を実装する方法は、何通りかあるかもしれない。その場合はITエンジニアが技術的なメリット/デメリットを踏まえてベストな方法を選ぶべきだ。ユーザーが良かれと思って「組織マスターの管理職情報を使え」と言うと、ITエンジニアは「使わなければならない」と捉え、足かせになってしまう。
まとめると、
「要求はお金を払うユーザーが出す。設計はプロのシステム開発者がやる」
となる。これが大原則だ。「システムを作らせる技術」をテーマとした本書で、要求定義について多くの章を割くのは、作らせる人が主役となる工程だからだ。作らせる技術のうち、要求定義はかなりの割合を占める。「欲しいシステムをもれなく、正確に表現する技術」と言ってもよい。