※この記事は個人の勉強ブログですが、本の紹介（アフィリエイト）リンクを含みます。
はじめに
『エンジニアじゃない人が欲しいシステムを手に入れるためにすべきこと』という本を読んだ。実践しようと思ったところや、印象に残ったところをまとめる。
今回読んだ本
『エンジニアじゃない人が欲しいシステムを手に入れるためにすべきこと』
- 細川 義洋 著
- 2024 年
著者は元々NECソリューションイノベータに在籍し、IBMでコンサルタントをされ、現在は東京地方裁判所でIT開発に係わる法的紛争の解決を支援しているとのこと。
概要
事業会社で、DXに取り組むメンバーの奮闘や学びを記載している。
主人公は、営業本部から DX 本部に異動することになった若手社員で、彼や周辺の個性の強いキャラクターが奮闘する様子を描く中で、著者の考える DX に必要な心構えを伝えている。
読むのにかかった時間
メモしながら3時間ほどで読み終わった。前述の通り物語形式のため、するすると読むことができる。
全体の感想
物語形式で非常に読みやすい上、システム企画において大切な心構えが綴られており勉強になった。全く新しい概念というよりは、「確かに」という点が多かった。
特にベンダーとの責任問題や、関係・モチベーションの構築については考えさせられる内容であった。IT担当の心構えや、要件定義のあり方についても改めて理解できた。
そのため、システム担当を名乗る我々もそうだが、システム企画・開発プロジェクトを始める前に、ビジネス部門にも読んでもらっても良さそうである。「要件定義って何ですか？」から始まり、だんだん哲学的な話になってきてしまってつらくなることも防げるかもしれない…
印象に残ったところ
IT 担当者の心構え
営業でうたつが上がらず、突然 DX 室に異動を命じられた主人公が「腹を括るまで」を描いている。
面倒事ばかり押し付けられているイメージで DX 室が描かれている。ビジネス部門からの嫌われ方がすごい。
とはいうものの、ビジネス部門の人と仕事をする機会も多いので、一人一人の顔を浮かべながら読んでいた。ビジネス部門の中にも、システムに詳しいテスト大好きなタイプと、ある種の拒否反応を示している（「システムのことはわからないので」と言いながら距離を取ってくる等）タイプがいて、それは仕方の無いところだと思うが、とにかくモチベーションを伝えられることは大事。
ITの楽しさはチームワークだと、先輩が 伝えるシーンがあり、非常に共感した。
「いつも誰かが苦労するけど、その分助け合い精神が生まれて、なんかこう充実感がある」
- 人の喜ぶ顔を考えながらワイワイ話したりするの、盛り上がるよ
- 障害対応の時に、助け合ってハードワークするのもいいもんだよ
障害対応の思い出話が飲み会で一番盛り上がるよね。
システム企画・業務フロー
業務フローと、その有効な使い方の説明。
- 書き方：
- アクター、業務（四角で囲む）、情報の入出力（矢印）
- データの蓄積が目的に含まれるのであればそれもアクターに追加してよい
- 既存のフローを書くにも、新しいシステム導入後のフローを書くにも使える。
- 業務フローを書いて終わりではない。フローをもとに、
ビジネス部門（本書内では、地域開発本部の人々）と話しあい、「こうしたい」「ここが課題」「これが懸念」など意見を出し合う
部分が重要。 - さらに、システム化の当初の目的にそぐわない意見は最後に切り落とすことも必要。
以前のシステム部門で一緒だった、ものすごく成果を出す部長のことを思い出した。
その人はビジネス部門を巻き込んで味方につけるのが上手いと有名だった。ビジネス部門を巻き込み、彼らと目標を共通にすることで、費用の工面といった点でも色々と有利になることも見ていた。 本書からも、いいシステムを作るにはビジネス部門（エンドユーザ）が検討に入ることが大事だという、当たり前でも忘れがちなこと再認識させられた。
本書におけるビジネス部門に、「DXなんてDX部が勝手にやってくれよ」と言う嫌なヤツが現れる。きっと世の中の"あるある"である。最終的には説得に応じて、ビジネス部門とDX部で集まって会議ができたようだった。
要件定義の書き方
本章以降は、上手くいかなったプロジェクトで、ベンダーと損害賠償で大揉めするストーリーが書かれることになる。自社にも問題あり・ベンダー側も「要件定義に書かれてないものは作れません」「ベンダーの仕事は要件通りにシステムを作ることでしょう？」という受け身100%の状態から始まる。（最後にどんな結末になるかはネタバレを伏せておく。）
要件定義は以下の種類がある。
- 業務要件：業務フローを細かく、業務の詳細を記載したもの。
- 入出力情報、前提条件、制約条件をもれなく
- システム要件：機能要件、非機能要件
要件定義をどのように書くかについて、デジタル・ガバメント推進標準ガイドライン実践ガイドブックを読むことが推奨されていた。
デジタル・ガバメント推進標準ガイドライン実践ガイドブック P193あたりから読むと良さそう。
ベンダーとの関係
ベンダーとの紛争
本書では特に「要件が不十分だったために、目的が達成できなかった」例が示されていた。
フィクションの事例が描かれたが、その際に判例として以下で紹介されている旅行会社とベンダーの裁判が取り上げられた。ソフトウェアに業務に必要な根幹機能が含まれておらず、最終的に旅行会社が勝訴したとのこと。
（引用元） 情報システム開発トラブル事例と対応法
※本書の著者の方が作成された資料のようです。
ユーザーは、航空券などの申し込みや決済などの機能を有するソフトウエア開発をベンダーに依頼した。プロジェクトは一応終了したが、開発したソフトウエアには、オペレーターがクライアントPCからサーバー上のデータベースを直接操作する「遠隔操作機能」が含まれていなかった。 ユーザーは、航空券の申し込みや決済を行う業務には、遠隔操作は不可欠の機能であり、本件ソフトウエアは業務に使用できないとベンダーへの支払いを拒んだ。しかしベンダーは、遠隔操作機能は契約内容に含まれておらず、また、ユーザーによる検収も済んでいることから、代金の支払いを求めて提訴した。
それぞれ以下のような義務があると理解した。
- 事業会社側
- 打合せに応じる義務
- ベンダーに必要な情報を提供する義務（インターフェース仕様等）
- ベンダー
- プロジェクト管理の義務（ユーザの行動が原因で遅れが出ているなら、お尻を叩く義務がある。要件変更があるなら、他の要件を落とす提案、スケジュールを伸ばす提案、追加費用を見積もる提案、中止の提案なども必要）
- 要件に書いていなくても、ユーザの業務に必要ということが業界の常識的に/旧システムの実装からわかるのであれば、実装することを提案する必要がある場合がある
確かに要件定義はユーザ（事業会社）の責任でありながら、システムの知識も無いと書けないという難しい部分…アジャイル開発も、このような紛争から身を守るためにベンダー側が考えた仕組みなのかな、と想像しながら読んだ。
モチベーション・信頼関係
ベンダーとのかかわり方について、大切にすべきことが記されている。個人的にも、反省すべき点が多々あるが、生かしたい点を記録しておく。
本書の著者は以下の主旨のことを述べている。（私の個人的解釈も含む）
「仕事だから当然やるべき」という単純な考えでは現場は回らず、どれだけ現場のメンバーがモチベーション高く、最低限の仕事の領域を"超えて"やれるかがプロジェクト成功の鍵になる。なぜなら、プロジェクトは先行きが見通せない要素が多く、契約の際に明らかになっていなかった部分をお互いに補完しながら進める必要があるからである。
意識したい点
- 会社同士の利害関係を開発現場に持ち込まないこと。あくまでパートナー、プロジェクトメンバーとして接せること。
- 担当者の名前を普段から呼ぶこと。
- 契約になかった"我慢"が、ある程度（お互いに）発生することを心に留めておくこと。
- 計画遅れや手戻りの際、ベンダーから納期の延長を提案されたときに、ユーザ企業からこそ問いかけるべき。「ユーザにできることはないか？」「妥協できること（ドキュメントの正式化を遅らせるとか）」はないか？
- ベンダー側の登場人物の「（失敗したプロジェクトの事業会社メンバーは）僕らのことを”業者”扱いなんです」というセリフは心に残った。「ベンダーではなくパートナーと呼びましょう」というお達しが社内で出たこともあり、今やどの会社でも気を付けているとは思うが根本の意識はどうなのか。社内でも、エンドユーザとシステム部門の関係でも同じようなことが言える。
高いお金払っているので、それなりのパフォーマンスを出してほしい、なめられても困るという気持ち(／社内の意見）もある一方で、業者扱いしたり、クレームを言いすぎてやる気をそぐことはしたくない。アウトソース先とのちょうどいい関係は正しいやり方が未だにわからずにいる。
本書にあったように、名前を普段から呼ぶことは意識したい。また、個人的にはSlackやTeamsの投稿にいちいち反応（「👍」や「❤️」）すると、お互い嬉しい気がしている。
人とのかかわり方について
マインド的な部分で印象に残った点を挙げる。
- 定量的管理のデータも大事だが、感情も大事。「仏作って魂入れず」はNG。相手の様子を気にかけ、一緒に頑張ろうという気持ちにさせることが大切。
- 厳しい作業（納期に間に合わせるためのハードワーク等）の際は、トップから指令を出すと余計なことを考えなくてよい効率が上がる場合が多い。
1点目について、個々人がリーダーシップを発揮することがDXで重要と言われるが、その際にはLeading without authority（権威なくしてリードする）能力が有用と上司が言っていたことがある。
以前より私個人としては「無理を通せる、感情を乗せて人を動かすことができる」との他者評価があり、論理の上に感情を入れるところは得意だったことがあるので、いい人であることや熱意を忘れないようにしたい。
一方で2点めについても、以前研修で聞いた説得の4要素
- Merit（メリット）
- Emotion（感情に訴える）
- Authority（権威を示す）
- Threat（脅す）※期間限定です、も一種の脅し
のAutorityに当たるので有効性がありそうである。
プロジェクトマネジメント
プロジェクトマネジメントは重要なスキルだと思うので、PMBOK等で改めて勉強していきたい。
- 計画は、「ずれたときに気持ち悪い」と感じさせて、是正のための動きを作らせる効果がある。計画書を眺めているだけでプロジェクト成功の道筋が見えることが大切。
- アーンドバリューマネジメント：価値ベースで見積もる手法。例えば20人日の作業があるとして、実際に何日分かかろうとも、半分終わったなら「10人日完了」とする
- プロジェクト計画書で定めるもの（ヒト、モノ、カネ＋情報、判断）：
- 組織の目的、目標達成までの方針、ロードマップ
- 要件
- スケジュール、役割と責任、要員計画、スキル育成計画
- 外部委託計画
- 開発ライフサイクル（ウォーターフォール等）
- 成果物一覧
- 品質計画（テストなど）
- 進捗管理方法、リスク管理方法、課題管理方法、変更管理方法、構成管理方法（成果物のバージョン管理など）、欠陥管理方法
まとめ
- IT業務には達成感がある
- 業務フローを上手く使って、ビジネス部門・エンドユーザと対話する
- ベンダーのモチベーション・ベンダーとの関係は大切。現場ではお互いを尊重する。
