勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

汎用的なデジタルリーダーシップ本としての「プロダクトマネージャーのしごと第２版」

Project Management Professional Engineer book

先日、オライリーのSNSキャンペーンで当選して「プロダクトマネージャーのしごと 第2版 ―1日目から使える実践ガイド」をプレゼントいただいた（皆さんも根気強く申し込みましょう）。自分は普段プロダクトマネジメントを仕事としているわけではない（サポートすることはある）のだけれども、どっこい本書はそんな私にも使える、というよりむしろデジタル仕事全般について役立ちそうな本であった。どうしてそう感じたのかを説明する。


「プロダクトマネージャーのしごと 第２版」の紹介

ソフトウェア業界におけるデジタルプロダクトのマネジメントをする人＝プロダクトマネージャーの「やるべき事」ではなく、「気をつけるべきこと」について書かれた本である。よって、プロダクトマネジメントの方法論ではないため、プロダクトマネジメントを行う人が一冊目に読む本ではないと思う。二冊目でもないかも。本の紹介は訳者のryuzeeさんのこのページがおすすめ→ 【資料公開】プロダクトマネージャーのしごと | Ryuzee.com

プロダクトマネージャーのしごと 第2版 ―1日目から使える実践ガイド

プロダクトマネージャーのしごと 第2版 ―1日目から使える実践ガイド

Amazon

汎用的なデジタルリーダーシップ本として読めるのでは？

本書の冒頭で語られるプロダクトマネージャの責任はこのようになっている。

  • チームメンバーのベストを引き出す
  • 自分と一緒に働く直接のインセンティブがないような、自分の直属のチーム以外の人と一緒に働く
  • 曖昧さに対処する

確かに、人に実際に価値を提供できるプロダクトを生み出すのは、プロダクトマネジメントにおける最も重要な側面の1つで、やりがいもあります！でも、こういったプロダクトを届けるための日々の仕事は、コミュニケーションやファシリテーション、支援の仕事のほうが多く、作るという仕事はそれより少ないのです。

これ、プロダクトは関係なく、デジタルに関連したITエンジニアと共同作業する全ての仕事に共通する話なのでは……

実際この後の本書の内容は、ソフトウェア開発のプロジェクトマネージャーだろうと、ソフトウェア開発組織のラインマネージャーであろうと共通的な仕事で考えるべき論点を多く取り扱っている本である。というわけでプロダクトマネジメントに関係ない人ももっと読んだ方がよい良書だというのがわたしの感想である。

お気に入りの（プロダクトマネジメントに関係なく）使えそうな内容の紹介

  • 1章　プロダクトマネジメントの実践
    • 「終わらせる必要があれば、それがあなたの仕事である」　ああ、そうだね（白目）
  • 4章　過剰コミュニケーションの技術
    • 「コミュニケーションはあなたの仕事。仕事をすることで謝罪してはいけない」　勇気をもらった
  • 5章　シニアステークホルダーと働く（ポーカーゲームをする）
    • 章タイトルだけで泣ける
    • 「警告なしで驚かさない」「社内政治の世界でユーザー中心主義を貫く」「シニアステークホルダーも人間だ」 グサグサくる
  • 7章　「ベストプラクティス」のワーストなところ
    • この章が一番好きです
    • 「フレームワークやモデルは有用なフィクション」 知ってる
  • 8章　アジャイルについての素晴らしくも残念な真実
  • 9章　ドキュメントは無限に時間を浪費する（そう、ロードマップもドキュメント）
    • ドキュメントを書くことの重要性と、一方で効率性に関することが述べられており有用な章。
    • 「メニューは食事ではない」　この言葉が重い
  • 11章　「データ、舵を取れ！」
    • 『本当のデータドリブンな手法を取り入れたいプロダクトマネージャーに「データという言葉を一切使わないでください」とよくアドバイスします』　神アドバイス
  • 12章　優先順位づけ：すべてのよりどころ
    • この章もいいことがいっぱい書かれていて悶絶する
  • 13章　おうちでやってみよう：リモートワークの試練と困難
    • 「さまざまな人たちからなるさまざまなチーム間で信頼関係を築くための唯一のレシピや戦術ハンドブックはありません」　気づいています

というわけで本書はとてもオススメである。
プレゼントでいただいた物理書籍はオフィスに置いて、電子版も買った（電子版はAmazonではなく、オライリーのサイトからの購入となる）。

実践要件定義入門

Requirement Developments

最近ネットを見ていると要件定義入門的な記事とか、あと要件定義は不要みたいな記事が目についたので思ったことを書いてみる記事その２。ITシステム開発における要件定義に関するあれこれ。本記事には前編があります。

目次

要件定義以前

要件定義というプロセスが本当に必要なのか、ということなどは以下の記事に書いたので省略。

要件定義の進め方

IPAユーザのための要件定義ガイドをベースにする

前編にも書いたが、わたしはIPAユーザのための要件定義ガイド（第２版）をリファレンスにすることをお勧めしている。これでいいんだよ。

ユーザのための要件定義ガイド第2版

ユーザのための要件定義ガイド第2版

Amazon
便宜的にAmazonのリンクを置いておくが、以下のサイトでPDF版のダウンロードも出来る。

決め過ぎない

要件定義でもっとも難しいのはこの「決め過ぎない」ということだ。要件定義が不十分であってもダメだが、やりすぎてもダメなのである。ただし、どこまでやれば良いかという基準があるわけでもない。要件定義のバイブルでもある「ソフトウェア要求　第3版」では以下のように書かれている。

要求分析の中で重要なのは、概要レベルの要求を分解して、それを明確化し具体化できるだけの詳細を明らかにすることである。「要求は、どこまで詳細であるべきか？」、これはよく聞かれる質問だが、唯一の正解はない。開発チームの知識と経験に基づいて、誤解されるリスクを最小化できる程度の詳細を提供する。要求の問題に関して継続的に話し合える機会が少ないほど、要求セットをより詳細に記録する必要がある。開発者が、要求を満たす方法をいくつか考えつき、そのすべてが受け入れ可能なら、具体度と詳細度はほぼ適切だと言える。以下の場合には、より詳細にしなければならない。

では、どの程度やれば、ちょうどよいのだろうか。だいたい、この程度が妥当と考えている。

  • 要件定義後の活動（一般的には設計など）の指針であって、指示にはなっていないこと
    • 前述の「ソフトウェア要求　第3版」の引用にあるように、開発者が要求実現方法を複数検討することが出来る程度の曖昧さが必要である
    • 具体的な仕様を決定しすぎてはいけない（なぜなら、システム開発を進めていく中で仕様は変化や進化していくことが多いからである。要件定義で具体的な仕様を記述しすぎてしまうと、後でより良い仕様が発見されても取り込まれなくなってしまう）
    • 要件定義の終了後、（要求の追加変更以外で）作成したドキュメント類の変更が出来る限り少なくなるように書かれた要件定義が、よい要件定義ともいえる（ほどほどに具体的で、ほどほどに抽象的）
  • 要件定義後の作業の規模がざっくり計画できる（見積もれる）程度には具体化されていること
    • 議論の余地がありそうだが、インターフェースの数（UI、レポート、API、その他）やバッチ処理等の概数、連携対象システム数などは明らかにしておきたい（ただし要件定義時点の試算であり確定としないほうがよい）
    • この表現はSIer臭が強いが「見積もれる程度には具体的に」「数えられるものが、数えられる程度に」

まあ、明確な基準は存在しないので最後は経験的に判断しなければならないだろう。やりすぎを防ぐためには「分析地獄」というアンチパターンを見ておくと良いかもしれない。

機能を定義するのではなく、機能要件を定義する

機能を定義するのは設計であり、要件定義では機能要件を定義するべきだ（ただし例外はある。後述する）。

  • いわゆるユースケース、またはユーザーストーリーという形式を取るべきだ
  • 例えば「ログイン画面」という機能について定義するのではなく「ログインする」という要求について定義しなければならない
    • どうして後者を取るべきなのかというと、機能（前者）はシステム／プロダクト中心の発想であるからダメなのだ。まだ存在しないシステムを中心に検討すると目的や利用者の視点が失われることがある
    • 機能要件（後者）であれば主語はユーザーとなる。ユーザーが何を成し遂げるべきか、それがすなわち要求である

なお例外はあって、ある種のシステム／プロダクトを分析する際にはこのアプローチはうまくいかない。またもや「ソフトウェア要求　第3版」から抜粋しておこう。

たとえば、バッチプロセス、計算集中型のシステム、業務分析、データウェアハウスなどのアプリケーションでは、ほんの少しのユースケースしか出ないだろう。この種のアプリケーションの複雑性は、実施する計算や、発見して使用するデータや、作成する報告書にあり、ユーザーとシステムの相互作用にあるのではない。　ユースケースやユーザーストーリーは、多くの組込みシステムやその他のリアルタイムシステムの仕様作成にも向いていない。

言い換えると、システムと人間がたくさんの相互作用を行うシステムだったら、ユースケース等を使って要件定義をしたほうが良いということになる。

関係者をすべて洗い出す

要件定義は利害関係者の要件を洗出して整理し定義するプロセスである（あたりまえだ）。ということは、利害関係者すべての要求を確認しなければならない。よって、関係者をすべて洗い出す必要がある。

  • 前項の「機能を定義するのではなく、機能要件を定義する」理由とも関係する。機能（例えば「ログイン画面」）のことばかり検討していると、利用者のことが軽視されることがある
    • ひとくくりにシステムの利用者を「ユーザー」とするのが一番まずい。「担当者」や「承認者」とか、「企画部門」とか「〇〇部署」などを分類しなければいけない。この分析を怠ると、要件の聞き忘れがおこる（そうすると、後でだいたいひどい目にあう）
  • 利害関係者を洗い出したら、「利害関係者の代弁者」も決定するとよい。そして、利害関係者または代弁者がすべて要件定義セッションに参加しないと、要件は漏れる。例えば経理部門が関係やであれば直接または「経理部門の代弁者」に話を聞かなければならないからだ

利用者マニュアルの目次が作れるようになっているか

良質な要件定義のアウトプットは、そのままマニュアルの目次に変換できる。そうなっていない要件定義はよろしくない。

《ダメな例》

  • ログイン機能
  • 一覧画面
  • 入力画面
  • 確認画面

《良い例》

  • ログインする
  • 登録内容の一覧を確認する
  • データを入力する
  • 入力したデータを確認する

おわかりいただけたであろうか……
なおマニュアルの目次が作れるということは、テストシナリオも作れるということでもある。

ビジネス要件定義

前提事項、制約事項とリスクを定義する

要件定義は（新しいことを考えるという意味で）本質的には愉しく、そして発見された要求について深掘り、詳細化する方向に向かいやすい。結果として前提事項や制約事項、リスクなどの洗出しが軽視されやすい。ここには大きな落とし穴がある。

  • ここでいう制約事項は法令、商慣習、予算や特定技術採用、技術人材、再利用素材などである。他にもあるかもしれない
  • 確定できない制約事項は仮決めを行うこととなり、それが前提事項となる
  • リスクは発生するかもしれない将来の予測である（なお、リスクに対しては対策も考えておくべきである）

前提事項、制約事項とリスクは全ての利害関係者に確認する必要がある。忘れないようにしよう

優先順位の決定を忘れずに

省略されがちであるが、要求に優先順位を付けることを漏らさないべきである。

要件定義において抽出されたすべての要求（手段）を実現することができるプロジェクトは稀である。膨らむ要求を限られた工期やコストの範囲に抑え込むためにも、要求には優先順位をつけて、効果の薄い要求や贅沢な要求は捨てる選択をしなければならない。また、昨今では、リーンスタート的な発想で、最低限必要な機能でまずリリースして使用してもらい、実績を評価して徐々に成長させていく（もしくは止める）手法のシステム開発を選択する場合もある。いずれにしても、どの要求は先送りできるのかを判断できるようにしておく必要がある。

要求に対する優先順位付けについては上記の通りであるが、優先順位を付けることは言葉通り以上の意味を持つということも理解しておくと良い。

要求に優先順位を付けると、目標が競合していることがわかったり、衝突を解決したり、段階的またはインクリメンタルな引き渡しを計画したり、スコープクリープをコントロールしたり、必要なトレードオフを決定したりするときに役立つ。

「全部が最優先」「全てマスト」と言いたい気持ちをぐっとこらえて、要求の順位付けについて考えよう。

システム化要件定義

不安定な要件を構造で支える

本質的に、ITシステムやソフトウェアの要件は不安定なものである（実体のある建築物やプロダクトに比べて、物理的制約を受けないため）。だから様々な工夫をしてこの不安定な要件を支える必要がある。様々な手法が存在するが、基本的には要件を構造的に強化しようとしているものだ。

  • ダイアグラムの利用
  • 複数の視点での要件の整理
    • （IPAユーザのための要件定義ガイドに即せば） プロセスの観点と、データの観点、その相互関係を整理することがビジネス要件の安定性を高めている。システム要件については機能要件とデータ要件をCRUD表で整理することで安定性を高めている
  • 機能要件と非機能要件の関係性も同じで、非機能要件によって機能要件の不安定さをカバーするのである

個人的に好きな組み合わせはユースケース記述（棒人間図ではなく文章で表現するもの）、フロー図、概念データモデル、ビジネスルールの4点の組み合わせだ。ただこれは手慣れたツールというだけで深い意味はない

  • 複数の機能要件（ユースケース）に登場する要件はビジネスルールにまとめる。これにより、機能要件間の一貫性を保ちやすくする
  • 機能要件間の連続性をフロー図で確保する。フロー図をなぞる事で全体の正しさが確認できるようになる
  • 機能要件とデータモデルの整合性を見ることによって、データ観点の見落としや矛盾を見つける

例えばこんなイメージ

とりあえず言いたいことを書いてみたが、だいぶ長くなってしまった。言いたい事は一通り書いたつもりだが、また何か思いついたら書こうと思う。
フィードバックやツッコミはX（旧Twitter）かはてなブックマークあたりでどうぞ。

おまけ：本記事の元ネタ

本記事の作成にあたっては、10年程前まで幹事をやっていた上流工程勉強会コミュニティで諸先輩からいただいた様々なコメント、あとは趣味的に読み続けている要件定義周辺の書籍を参考にしている。思い出せるものを列挙しておくが、古い本も多いので注意していただきたい。

おっさんエンジニアの放送大学教養学部に入学記録7（4年目前期終了）

Study

2020年4月から放送大学の教養学部「人間と文化コース」に入学して、これまで勉強してこなかった人文系の勉強を始めている。4年目前期が終わったので感想をまとめておく。

目次

もうすぐ50のオッサンが放送大学の全科履修生として気ままに授業を取っている。理系の大卒資格は取っているので卒業をゴールにはしていないのでペースはゆるめ。というわけで4年生だが特にあせりもない。なお、大学生として各種の学生割引は利用しているし、放送大学の図書館サービスを経由して論文や業界紙へのアクセスも可能なので割とお得な趣味である。授業はBSで放送もされているが入学すれば放送授業は全話ネットで視聴できるので好きなペースで進めることができる。

4年目前期に受講した科目

卒業を目標にしていないので、半期に2科目受講＋1科目聴講を目安にしている。放送大学に入学した目的は人文系の教養力アップなので、芸術系、哲学系、文化人類学系を中心に選ぶようにしている（が、最近は心理学系も気になっている）。この半年で受講した科目はこちら

より良い思考の技法（’２３）

より良い思考の技法: クリティカル シンキングへの招待 (放送大学教材)

より良い思考の技法: クリティカル シンキングへの招待 (放送大学教材)

Amazon

情報を的確に評価し、合理的に考えてより良い判断を下すための実践的な思考法が「クリティカル・シンキング（批判的思考）」である。これは相手を否定する「批判」ではなく、自分の推論を意識的に吟味する内省的・熟考的思考であり、また証拠にもとづく論理的で偏りのない思考法である。本講義では、さまざまな学問領域、市民生活、職業実践に共通する汎用的思考スキルとしてクリティカル・シンキングの基本を学び、さらに「実践」として現代社会の具体的な問題場面への適用を考えていく。

youtu.be

日本仏教を捉え直す（’１８）

日本仏教を捉え直す (放送大学教材)

日本仏教を捉え直す (放送大学教材)

Amazon

今日、仏教研究は次第に新しい進展を見せ、従来の常識は大きく書き換えられつつあるが、それらの研究成果が必ずしも広く共有されているわけではない。本講義では、３人の講師によって、日本仏教に関する最新の成果を披露し、常識的な理解を見直すことを目指す。頼住講師は、主要な日本の仏教者の思想を取り上げ、現代の場からこれらの思想の読み直しを迫る。大谷講師は、近年大きく進展した近代仏教研究の成果を披露し、現代につながる問題を考える。末木講師は日本仏教の深層の発想を捉え直して、それが今日どのような意味を持つか考える。３人の講師により異なる視点から照射することで、日本仏教の豊かな内容が立体的な視点から明らかにされるであろう。

  • ラジオ講義。基本的にはテキストに沿って進めていく形式である
  • もともと哲学に興味があって放送大学に入学し、これまで西洋哲学についていろいろ触れてきた。ここで東洋哲学にも触れたいとおもって選択した講座。身近だけれども知らなかった知識が多く、教養的な意味でも大変によい講義選択だった。
  • 前半は代表的な仏教思想（宗派）の概説。過去に日本史という枠組みで触れてきたかもしれない内容だが、仏教に絞って説明されると理解はし易い。日常的に観光でお寺に行くことはあるが、まったく何も自分は理解していなかったことを恥じる。解像度が上がることが楽しい。
  • 中盤は仏教の近代化、後半で現代におけるわれわれの生活と仏教の関係性などについて論じる。葬式や墓参りなどについても、そんなこと考えたことがなかったという話が多くて、たいへんに勉強になった。

新しい言語学（’１８）

新しい言語学: 心理と社会から見る人間の学 (放送大学教材)

新しい言語学: 心理と社会から見る人間の学 (放送大学教材)

Amazon

言語学の中でも比較的最近発展してきた領域と方法論を取り上げて講義する。なかでも、言語に対して心理や社会の観点からアプローチする認知言語学、言語習得論、談話分析、社会言語学に着目する。それらは、心理や社会という観点を通して人間にとって言語がどのような位置にあるのかを明らかにしてくれるだろう。

来期（4年目後期）の予定

以下を受講予定。

これまでの記録

受講の感想

  1. 若手が育たないとか言っている暇はもう無い - 勘と経験と読経
  2. コンフォートゾーン外の学びの為にエンジニアが放送大学に入学してみた - 勘と経験と読経
  3. アラフィフ理系が放送大学の教養学部に入った記録（1年目前期完了） - 勘と経験と読経
  4. おっさんエンジニアの放送大学教養学部に入学記録2（1年目後期終了） - 勘と経験と読経
  5. 教育心理学はソフトウェア開発に活用できるか（教育心理学特論を読み終えて） - 勘と経験と読経
  6. おっさんエンジニアの放送大学教養学部に入学記録3（2年目前期終了） - 勘と経験と読経
  7. おっさんエンジニアの放送大学教養学部に入学記録4（2年目後期終了） - 勘と経験と読経
  8. おっさんエンジニアの放送大学教養学部に入学記録5（3年目前期終了） - 勘と経験と読経
  9. おっさんエンジニアの放送大学教養学部に入学記録6（3年目後期終了） - 勘と経験と読経

これまで受講した科目

  1. 哲学・思想を今考える（’１８）：1年目前期
  2. 西洋芸術の歴史と理論（’１６）：1年目前期
  3. 総合人類学としてのヒト学（’１８）：1年目前期
  4. 博物館概論（’１９）：1年目後期
  5. 文学・芸術・武道にみる日本文化（’１９）：1年目後期
  6. 西洋哲学の起源（’１６）：1年目後期
  7. 教育心理学特論（’１８）：1年目後期 ※大学院科目の聴講
  8. 「人新世」時代の文化人類学（’２０）：2年目前期
  9. 日本美術史の近代とその外部（’１８）：2年目前期
  10. 現代フランス哲学に学ぶ（’１７）：2年目前期
  11. 記号論理学（'１４）：2年目後期
  12. 舞台芸術の魅力（'１７）：2年目後期
  13. 西洋音楽史（’２１）：3年目前期
  14. レジリエンスの諸相（’１８）：3年目前期
  15. 心理学概論（’１８）：3年目前期
  16. 現代の危機と哲学（’１８）：4年目前期
  17. アメリカの芸術と文化（’１９）：4年目前期
  18. 中高年の心理臨床（’２０）：4年目前期

「スタッフエンジニア マネジメントを超えるリーダーシップ」をマネジメントの観点で読んだ

book Professional Engineer

読むのがホネな技術書やビジネス書を取り上げて２週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第57回。同僚と読書期限を約束することによって積読が確実に減るという仕組み。過去記事はこちら。

さて、今回取り上げるのは界隈では有名な「スタッフエンジニア　マネジメントを超えるリーダーシップ」である。スタッフとは参謀の意で、超上級・幹部エンジニアに関する本である。

スタッフエンジニア　マネジメントを超えるリーダーシップ

スタッフエンジニア　マネジメントを超えるリーダーシップ

Amazon

なお本書は英語で良ければ以下のサイトで読むことができる

著者のWill Larsonさんは現在はStripeやUberでエンジニアリーダー等をされてきた人。本書以外では「An Elegant Puzzle: Systems of Engineering Management (English Edition)」というエンジニアリングマネージャーに関する本が有名だがこちらは未翻訳（そして未読）。iwashiさんの紹介スライドが詳しい。
来年「The Engineering Executive's Primer」 という本が出版予定で、さらに上位のエンジニアリング職について論じるようだ。

なぜこの本を読もうと思ったのか

自分は現在はマネージャー側の立場であり、本書のテーマである「スタッフエンジニア」を目指しているわけでもない。それでも本書に興味を持った理由は次のようなものだ。

  • 周囲のスタッフエンジニア的、または志向があるメンバーへのアドバイスをするため
  • 所属組織における今後の検討材料として。残念ながらベンチャー企業および外資系を除いて、日本の企業にはそもそも「スタッフエンジニア」的概念が現在はない。所属組織でも同様である。しかしいずれは、こういった議論が本格的に必要だと考えているのだ
  • あとは単純な興味本位

……という、割と不純な動機で手に取った本書であるが、想像以上のいろいろな刺激を受けることができた良い読書であった。

全体的な感想

類書としては「エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド」を以前に読んでいるのだけれども、同書は海外事例でありテックベンチャーで若くしてCTOやVPoEを目指すという内容であり、なかなか日本企業で参考にするのは厳しいと思っている。いっぽうで本書は想定としているビジネス規模も大きく、中大規模の組織におけるスタッフ（幹部）エンジニアのありかた、役割、周囲との関係性が深く掘り下げられているので参考になる点が多いと思った。

これは私のようなマネージャにとっても有益で、例えば以下のような悩みを解決するヒントが得られたような気がする。

  • スタッフ（幹部）エンジニアのモデルがイメージできるようになったので、何をまかせるべきかが明確になりやすい。
  • また評価の際の参考にもなる。（自分はあまり経験がないが）組織の中でもトップレベルのエンジニアの評価はけっこうな難しさがあるはずなので、本書のような基準があるのは会話の土台として良いはずだ。

なお本書の付録にズバリな項目もあるのがお得だった。

スタッフプラスエンジニアの管理
StaffEngへ送られてくるフィードバックのなかに、「もっとスタッフプラスエンジニアの管理に関するコンテンツを」という要望があった。この話題は本書──会社やマネジャーではなく、スタッフプラスエンジニアをテーマとした本──で扱うには適していないが、興味深いトピックなので、ここで付録として論じたいと思う。
スタッフエンジニア　マネジメントを超えるリーダーシップ、補章 より

この項目はマジで参考になる。

その他の気になったこと

「部屋」の話がおもしろくて参考になる

本書では、経営会議などトップマネジメントが会社の方針を決定する場所を「部屋」と呼んでいて、

  • 部屋への入りかた
  • 部屋にとどまる方法
    • 話し方
    • 追い出されない方法

などの説明は、スタッフエンジニアに限らず参考になる。

A・グローブの「HIGH OUTPUT MANAGEMENT」推しの人が複数いた

本書の後半は様々な企業のスタッフエンジニアへのインタビューで構成されているのだが、「HIGH OUTPUT MANAGEMENT」を推している人が複数おり、ちょっと驚いた。同書はかなり骨太のマネジメント論である。毎年読み返しているという人もいる。自分が本書を始めて読んだのは8年前。時々思い出したように少しだけ読み返すことはあるが、本格的な再読は行っていない。読み直すか～。

本書のオススメの読み方が巻末の「解説」に書かれている

最近このパターンが多いので、かならず監修・監訳者の解説がある場合にはそこを最初に読むようにしているのだが、本書も末尾の「解説」から読むのがお勧めである。

私のおすすめの読み方は、まず第５章のインタビューを２～３人分読んでから、第１部を読み進めることです。とくにある程度経験を積まれたエンジニアの方は、第５章に登場するスタッフエンジニアの具体的なエピソードに大いに共感されることと思います。その共感を胸に第１部を読むことで、スタッフエンジニアに求められる役割が自然と腑に落ちるのではないでしょうか。
スタッフエンジニア　マネジメントを超えるリーダーシップ、解説 より

参考

というわけで本書は読了。次は何を読もうか。最近気になっている本はこんな感じ。

実践要件定義入門以前

Requirement Developments

最近ネットを見ていると要件定義入門的な記事が目についたので思ったことを書いてみる記事。ITシステム開発における要件定義に関するあれこれ。

【2023/10/10追記】続編の記事を書きました。実践要件定義入門 - 勘と経験と読経

目次

要件定義に関するおすすめ書籍

この後に何度も引用することになると思うので、最初に要件定義のおすすめ書籍を紹介しておく。と言っても紹介するのは1つだけだ。

ユーザのための要件定義ガイド第2版

ユーザのための要件定義ガイド第2版

Amazon
便宜的にAmazonのリンクを置いておくが、本書のPDF版は無料でダウンロードできる。

本書をおすすめする理由はいくつかある

  • 単著ではない
    • システム開発の手法はいろいろあるのだが、特に要件定義のやり方は千差万別かつケースバイケースだ。要件定義の手法やアドバイスの書籍や情報はいろいろあるが、特に単著だと紹介されている手法があなたの要件定義にフィットしない場合に悲惨なことになる。その点で本書は複数の著者によって書かれているのでリスクが少ないと考えている
    • もちろん単著の要件定義ガイド的書籍がまずい、ということはない。ただし単著1冊だけで勝負するのはおすすめしない
  • エンジニア向けではなく、（一応）ユーザー企業向けに書かれており、わかりやすい
  • 2019年の発行ということで、十分に新しい
  • 無料

本書を読んでわからないことがあったら、本書で紹介されている参考情報などから広げていけば良いだろう。というわけで、まずはこの本を手に取っておこう。

さて、ここからが本題だ。

その要件定義は必要か

あなたが何らかのソフトウェアもしくはシステムを必要としていて、なんとなく要件定義をしようとしているのであればちょっと待って欲しい。その要件定義は本当に必要だろうか。
なぜ要件定義をしようとするのか。

要件は決められるのか

要件定義をするということは、字面通りに要件を定義するということだ。でも、ちょっと待ってほしい。あなたが作りたいソフトウェアの要件を今決めることはできるのだろうか。特に一般利用者向けのソフトウェアやウェブサイト、モバイルアプリケーションではざっくりとしたゴールは決められるが、細かい要件はまだ決められないという場合がある。

この場合は、要件定義とは異なるアプローチを取ることもできる。このあたりから始めるのがよさそう。

プロダクトマネジメントのすべて 事業戦略・IT開発・UXデザイン・マーケティングからチーム・組織運営まで

プロダクトマネジメントのすべて 事業戦略・IT開発・UXデザイン・マーケティングからチーム・組織運営まで

Amazon
作りたいもの（プロダクト）のミッション、ビジョンから初めて実現手段まで落とし込んでいく。そういうアプローチが必要な場合もある。そういったものに対して従来型の要件定義を実施してしまうと、早い段階で実現手段を固めてしまうことによって失敗してしまうこともあるのだ。

正しいものを正しくつくる　プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について

正しいものを正しくつくる　プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について

Amazon
こちらでは、不確実性が高い場合の要件定義アプローチの限界を提示しつつ、仮説検証型アジャイル開発アプローチを提言している。

要件定義をすることがルールで定められているから要件定義をする必要がある

社内ルールでプロセスが標準化されていて、要件定義をすることが必須という場合はある。
でもちょっと待て。とりあえず以前に完了したプロジェクトの要件定義を取り寄せるべきだ。あと、そのプロジェクトが成功したのかどうかも確認しよう（うまくいっていない事もある）。それを見て同じような事をやるべきか判断しよう。何か違うと思った場合は要件定義に入る前に、もうすこし自由度の高い「企画」とか「事前検討」で内容を煮詰めたほうがいい。

どうしてこのような事を言うのかというと、標準化ルールがアップデートされておらず古い場合があるからだ。ゼロ年代前後にソフトウェア開発の失敗が続き、作業プロセスの標準化がブームになったことがあった。その時に制定されたルールがそのままという場合がある。一方でビジネスやソフトウェアを取り巻く環境は常に変化をしている。特に業務の電子化（紙でやっていた仕事をコンピュータに入力できるようにする）だけを想定した古いルールをそのまま適用するのは危ない。ルールだからという理由で思考停止して要件定義をするのは避けよう。

要件定義は、決められた目次やテンプレートに沿って穴埋めのように行う作業ではない。

要件は定義できるのか

冒頭で「要件を決められるのか」という質問をしたのだけれども、あらためて問いたいのは要件がどこにあるのか、である。
要件を定義することは、どこかにある要件を取り出して明文化（文書化）するということである。

  • 要件はわたしの頭の中にある：問題ない。通ってよろしい
  • 要件は大まかには決まっているが、細かいところは担当者間で相談しながら決める：問題ない。通ってよし
  • 要件は業務マニュアルに書かれているはずだ：ちょっと待て。お前はこっちの部屋に来い
  • 要件は現行システムの中にある：お前はあっちの部屋だ。つべこべ言うな

現行の業務マニュアルをベースに要件定義をするつもりのあなたへ

要件定義では現在の業務（As-Is業務フロー）をベースにシステム化後の新業務を定義していくことになる。そのベースとして現行の業務マニュアルやフロー図があるのであれば、だいぶ心強い。
ただし、現行の業務マニュアルがきちんと整備されていれば、である。その点は大丈夫だろうか。

  • 現行の業務マニュアルは正しいか
  • 漏れているマニュアル外の業務はないか

このあたりを押さえておかないと、だいぶ厳しいことになる。現行業務をキレイにすることとシステム化の要件定義を同時並行でやるのは割と地獄だ。先に現行業務を整備しておこう。
IPAの要件定義ガイドだと、4.1.1 現状の把握(BR.1.1) あたりにより実践的なアドバイスが書かれている。

現行システムをベースに要件定義をするつもりのあなたへ

現行システムが魔窟の状態の場合、新システムも当然の如くに魔窟になる。ゴミ屋敷の引越しをイメージすると良い。掃除をせずに業者を使って引越しをしようとすると、ゴミも全部引っ越すことになるので、ものすごく高くつく。まずは掃除をしよう。ここで言う掃除とは

  • 不要な機能・帳票・インターフェースの廃止
  • ドキュメント等の更新

などである。

なお現行システムを元にシステムを構築することを「再構築」と呼ぶ。この種のプロジェクトについては前述の要件定義ガイドとは別に公開されている以下の文書も読むと良い。便宜的にAmazonのリンクを置いておくが、本書のPDF版も無料でダウンロードできる。

SECBOOKS システム再構築を成功に導くユーザガイド (SEC books)

SECBOOKS システム再構築を成功に導くユーザガイド (SEC books)

Amazon

また、上記サイトに掲載されている「デジタル変革に向けたITモダナイゼーション企画のポイント集」も重要だ。あわせてチェックしておこう。

外部業者を呼ぶ前に考えるべき事

どこから外注するかを考える

要件定義とひとことで言っても、大きく分けると前半戦と後半戦に分けられる。呼び方はいろいろあるのだけれども、ここでは「ビジネス要求定義」「システム化要求定義」と呼ぼう。
要件定義は大変なので、外部業者に委託したい気持ちはよくわかる。しかしちょっと待ってほしい。前半「ビジネス要求定義」は外注しにくいのだ。ここではIPAのユーザーのための要求定義ガイド第2版を基準として説明するが、前半戦で考えるのはたとえばこんな内容だ。

  • ビジネス要求の獲得（現状把握、問題や課題の抽出、ゴールの定義、達成手段の整理）
  • ビジネス要求の分析（体系化、優先順位付け）
  • ビジネス要求の文書化

これを外部から来た人がやれるだろうか。文書化くらいは手伝ってもらえるかもしれないが、それ以外は自分たちでやるしかないのだ。

要件定義の作業期間を見積もる

ところで要件定義をやるとしたら、どれくらいの期間でやるべきなのだろうか。
もちろん、やってみなければわからないが、それでもたたき台としての計画は必要だろう。

ソフトウェア開発プロジェクトの統計情報は例えばIPAなどでも公開されているが、IPAのデータだと要件定義などの上流工程に関する情報があまり充実していない（これはベンダー向けに情報を公開しているからだと思われる）。そこで役に立つのが、一般社団法人 日本情報システム・ユーザー協会（JUAS）のソフトウェアメトリック調査だ。

たとえば2020年版のメトリック調査を見ると、世間のソフトウェア開発プロジェクトがどの程度の期間、工数で要件定義を実施しているかがわかる。

プロジェクトごとの工期合計に対する、要件定義工期、設計～統合（結合）テスト工期、ユーザー総合テスト工期の内訳比率をみると、22.9：59.3：17.8≒2：6：2 となる
JUAS ソフトウェアメトリックス調査2020システム開発・保守調査　報告書、4.2 工期の評価 より

他の文献ではどうだろうか。要件定義に関する名著である「ソフトウェア要求　第3版」を見ると、偶然ではあるが同じような期間比が書かれている（ただし本書は訳書であり前提とするプロセスは日本の標準的なものとは異なる）。

電気通信および銀行業界の15のプロジェクトを調査した結果によると、最も成功したプロジェクトでは、要求の引き出し、モデリング、妥当性確認、および検証に、リソースの28％を使用していた（HofmannandLehner2001）。プロジェクトの平均では、工数の15.7％とスケジュールの38.6％を、要求工学に費やしていた。（中略）私たちは、プロジェクト全体の作業工数の約15％を、要求の作業に割り当てるべきであると考えている。この数値は、この節で前述した調査結果の割合と一致している。つまり、プロジェクトの全体工数の見積もりが1,000時間なら、要求開発の見積もりは150時間になる。もちろん、要求をもっとよく理解した後で、プロジェクト全体の見積もりが変わる可能性もある。
ソフトウェア要求　第3版、19.1 要求の工数見積り

個人的には、JUAS報告にある全体期間の20%を要件定義に充てるのが良いと考えている。

要件定義についてあれこれ書くつもりだったが、要件定義のことまでたどり着かなかったようだ。
長くなったのでしまったので、続きはまたこんど。
フィードバックやツッコミはX（旧Twitter）かはてなブックマークあたりでどうぞ。

ふりかえりツールとしての「失敗マンダラ」（「DX失敗学」の感想）

book Professional Engineer Postmortem

読むのがホネな技術書やビジネス書を取り上げて２週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第56回。同僚と読書期日を約束することによって消化が捗るという仕組み。過去記事はこちら。

さて、今回取り上げるのはちょっと気になっていた本「DX失敗学　なぜ成果を生まないのか」である。

DX失敗学　なぜ成果を生まないのか

DX失敗学　なぜ成果を生まないのか

Amazon

失敗学といえば畑村洋太郎先生が提唱している歴史あるものだが、本書の著者は畑村先生ではなく佐伯徹さん。畑村先生も参加していたNPO法人 失敗学会の理事でもあり、本書は正統的な失敗学の文脈でソフトウェア開発プロジェクトについて書かれた本である。

なお本書のエッセンスは現時点では、幻冬舎のサイトで一部記事化されている。本書に興味がある方はこちらから見ると良さそう。

失敗まんだらと、ITプロジェクト版失敗マンダラ

本書の最大のポイントは「ITプロジェクト版失敗マンダラ」である。これを核にした分析手法と、実際の事例を使った分析事例の紹介が中心となっている。
xtech.nikkei.com

この「ITプロジェクト版失敗マンダラ」であるが、ITプロジェクト版とある通りで、オリジナル版失敗まんだらが存在する。畑村先生の「失敗学実践講義 文庫増補版 (講談社文庫)」や以下のサイトが詳しい。

失敗学実践講義 文庫増補版 (講談社文庫)

失敗学実践講義 文庫増補版 (講談社文庫)

Amazon

本書では、各講義で取り上げる失敗事例に「失敗まんだら」を付けています。これは科学技術振興機構の「失敗知識データベース推進委員会」による失敗知識のデータベースづくりの中で生まれた、いわば失敗のシナリオが一目でわかる図のことです。　まんだら（曼荼羅）は、悟りの世界や仏の教えを示した仏教の図絵のことですが、失敗のシナリオを表現した図は、中心部分に全体を取りまとめている最上位の概念があり、そのまわりに次のレベルの概念を記すという表現方法がこれとよく似ているため、「失敗まんだら」という名前をつけることにしました。
失敗学実践講義 文庫増補版 (講談社文庫)、「失敗まんだら」について　より

「失敗学実践講義 文庫増補版 (講談社文庫)」の中では、2002年のみずほ銀行システム障害や、2005年の東証売買システム障害も事例として取り上げられている。その内容はとても興味深いのだけれども、一方でオリジナルの失敗まんだらは対象が大規模事故などであることから「ソフトウェアの分野ではちょっと使いにくいなぁ」という感想を持っていたのだった。そしてついに、ソフトウェア開発向けにアップデートされた「ITプロジェクト版失敗マンダラ」が登場したのである。では、これはどうだろう。

ITプロジェクト版失敗マンダラについて

ITプロジェクト版失敗マンダラについては本書を読んでいただくか前掲のWebサイトを見ていただくとして、ひとことで言えば「使ってみたい」ものになっている。以下細かい感想である。

  • シンプルに、原因マンダラのみとなった
    • オリジナルの失敗まんだらは3種類ある。「原因まんだら」「行動まんだら」「結果まんだら」である。分析対象の事故（例えば航空機のエンジンの故障）が起こった場合には原因だけでなく、その後の関係者の行動も論点となりえる。また結果の影響が大きいため、しっかりと分類されるような構成となっていた。
    • しかしソフトウェアシステムやサービスについては（場合によるが）人命に関わるような重大事故となる場合は少ない。その点で「原因」だけに着目しているのは使いやすいと感じる。
  • プロジェクト原因の追加
    • オリジナル版の失敗まんだらとITプロジェクト版失敗マンダラを対比させてみると、プロジェクト原因というカテゴリが追加されているのがわかる。これがオリジナル版には無いのが「使いにくそう」という印象の原因だったというのが改めてわかる。

ふりかえりツールとして「失敗マンダラ」は使えるのか

「使ってみたい」という感想を述べたが、どう使うかは悩ましいところである。
近年ではどのプロジェクトも（アジャイル開発かどうかに関わらず）ふりかえりを行うことが増えてきた。このマンダラはふりかえりに使えるだろうか。
わたしの意見は「ふりかえりツールにはふさわしくない」である。少なくともカジュアルに使うのは難しいのではないだろうか。
このマンダラは構造的に、根源的な組織や文化の問題に辿り着きやすく、その解決は少なくともチームで実施するようなものにはならないだろう。

よって、このマンダラはふりかえりツールというよりは、第三者評価であるとか組織課題検討など、プロジェクトとは距離を置いた形で取り扱うべきだと思う。
（あくまで印象なので、ちょっとどこかで実験をしてみたい。その結果はたぶん公開できないと思うが）

一方で、失敗に対する分析は必ずやるべきことである。

（引用註：工場や建設現場のケースでは）万一事故が発生した場合、できるだけ詳しい情報を素早くまとめて発表する必要がある。早く手を打たないと、影響が広がってしまう。
その後も事故がなぜ起こったのかを徹底的に検証する。事故につながった失敗の内容を後世に伝えるため、自社の敷地内に失敗に至った経緯を掲示している企業もある。
これに対し、DXをとりまくIT業界では失敗の原因を長い期間をかけて検証する習慣があまり根付いていない。新しい技術や製品、サービスが常に登場し続けているという事情もあり、それらを活用して企業の業績拡大などにつなげるほうを優先する傾向が強い。
DX失敗学　なぜ成果を生まないのか、第1章 失敗から学ぶための原因究明の方法、より

耳が痛い。この点はおおいに反省するべきではないだろうか。

というわけで、本書は完了。次は「スタッフエンジニア　マネジメントを超えるリーダーシップ」を読む予定。

「人が増えても速くならない」と素朴概念の問題

book Professional Engineer

読むのがホネな技術書やビジネス書を取り上げて２週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第55回。同僚と読書期日を約束することによって消化が捗るという仕組み。過去記事はこちら。

さて、今回取り上げるのは話題（？）の本「人が増えても速くならない ～変化を抱擁せよ～」である。

人が増えても速くならない ～変化を抱擁せよ～

人が増えても速くならない ～変化を抱擁せよ～

Amazon
非エンジニア（起業家、経営者、マネージャ）向けに、ソフトウェア開発でよく起こる誤解を解くという目的で書かれた本書である。結論から言うと良い本であった。一方でいくつか気になる点もある。そういった事を書いていく。

ソフトウェア開発における素朴概念との戦い

先ほど「ソフトウェア開発でよく起こる誤解を解く」と書いたが、最近勉強している心理学の用語でいうと、この誤解は素朴概念の一種であると言えるのではないかと最近考えている。

素朴概念とは、観察を通じて自然に獲得される知識体系のことである。これは科学や工学的な概念知識とはイコールではないことがある。わかりやすい例としては、地球が丸いという知識だ。現代人の多くは教育によって「地球は丸い」ということを理解しているが、教育を受けていない人にとっては理解することが難しい。素朴概念では「地球は平面」なのである。知識が無い状態で観察すれば、地面は平面としか見えない。

この「素朴概念」の問題がソフトウェア開発においては大きな課題になっていると考えている。ソフトウェア開発の実態と、（ソフトウェア開発の）知識をあまり持たない一般人の認識には極めて大きな乖離が見られるからだ。本書「人が増えても速くならない ～変化を抱擁せよ～」が相手にしているのは、まさにそういった誤解だ。例えば

  • 完成度の高いソフトウェアを作り出せば、そのままずっと使い続けることができる（実際には、できないことが多い）
  • 作業する人を増やせば、ソフトウェアの完成が早まる（実際には、早まらないことが多い）
  • まとめて大きなソフトウェアを作れば、得をする（実際には、損をすることが多い）

など（本書にはもっといろいろと書かれている）は全てソフトウェア開発においては誤解である。

こういった誤解はなぜ生まれるのか。私の予想では根本には、ものづくり、そのものについての理解の浅さがあるのだと思う。小学校教育などで学ぶ「製造業（工場）」の雑なイメージ、それ以降の人生における複数人での共同作業による「ものづくり」経験の少なさがあり、人はソフトウェア開発プロジェクトの困難さが想像できないのではないか。

加えて、ソフトウェア開発業界自体が素朴概念をミスリードしていったという経緯もある。

ソフトウェア開発業界が誤解を助長している

ソフトウェア開発における素朴概念の問題は、ソフトウェア開発業界の中にもある。そもそも、ソフトウェア開発を行っているエンジニアたちも誤解をしていたのだ。

人間が行うほとんどのことで、「もの」の製造、生産は難しい部分です。自動車、旅客機、携帯電話などは、設計でも労力と創意工夫が必要になりますが、最初のプロトタイプの設計とアイデアを大量生産できるところまで持ってくるためには、設計段階よりもはるかに大きなコストをかけて複雑な道のりをたどらなければなりません。少しでも効率ということを考えてものを作ろうとするときには、このことが特に当てはまります。このように、難しいのは生産段階であるため、工業化時代とその思考法の産物である私たちは、少しでも腰を据えて仕事をしようとすると、ほとんど何も考えすに自動的に製造、生産の心配をしてしまいます。
その結果、私たちはかなり一貫してソフトウェア産業にも同しように「製造現場の思考法」を応用しようとしてきました。
継続的デリバリーのソフトウェア工学　もっと早く、もっと良いソフトウェアを作るための秘訣　2.1 私たちにとって製造は問題ではない、より

エンジニア自身も勘違いをしていたし、さらにソフトウェア開発プロジェクトをリードする非エンジニアのマネージャーも勘違いをしていた（kawaguchiさんの言う「おじゃる様問題」を参照）。

何が言いたいのかと言えば、ソフトウェア開発プロジェクトが誤解されやすいのは非エンジニアであるユーザー（起業家、経営者、マネージャ）だけのせいではないということだ。

本書「人が増えても速くはならない」で誤解は解けるか

というわけで（やっと）「人が増えても速くならない ～変化を抱擁せよ～」の話に入る。
本書はSonicGarden 株式会社ソニックガーデンの創業者である倉貫さんが、顧客に対して延々と説明してきた「ソフトウェア開発プロジェクトの誤解」の集大成である。

「そのギャップを少しでも埋められたら、きっと世の中のビジネスもソフトウェアももっと良くなるし、ソフトウェアを必要とする人とソフトウェアを開発するエンジニアの双方が幸せになれるのでは」
人が増えても速くならない ～変化を抱擁せよ～　はじめに、より

非エンジニア向けに平易に書かれており、比喩も多くたいへんに読みやすく良い本というのが感想である。特に、以下の点が良いと思った。

  • 優れた比喩（メタファー）が多い
    • 著者がおそらくビジネスで大変苦労をしながら生み出していった「わかりやすく説明する」ための工夫が惜しげもなく公開されている
    • 同じような説明をしなければいけない立場として、とても参考になる
  • アジャイル／スクラムを扱っていない
    • 本書は（あとがきを除いて）アジャイルという単語が出てこない。
    • アジャイルという単語が出てくると胡散臭くなるというか説教くさくなる今日この頃、これらの単語が出てこないのは好感度が高い

というわけで、非エンジニア向けの本ではあるが学びの多い本だった。

本書を読む上での注意点

とはいえ本書については問題もある。
本書の冒頭でも語られる通り、本書は著者の経験を元にしたノウハウがまとめられたものである。
では著者の経験はというと、基本的にはSonicGarden 株式会社ソニックガーデンさんのお仕事であろう。よって本書のスコープは、あらゆるソフトウェア開発に適用できるわけではないという点には留意する必要がある。

ここは筆者の想像も入るが、ソニックガーデンさんとソフトウェア開発を行うということは、

  • ビジネス創業期などから段階的にソフトウェアを成長させていく
  • SIerなどに一括発注して開発リスクを軽減するのではなく、リスクを負って開発者とともに作る

ということになるのではないだろうか。

たとえば筆者はSIer的なビジネスに関与をしており、大規模（？）なソフトウェア開発プロジェクトに関与することもあるので「第7章 一度に大きく作れば得に見えて損をする」などは気掛かりな記述も多かった。私は経験が無いが、組み込みソフトウェア開発でも異なる違いがあるだろう。本書は優れた記述やメタファーに溢れているが、適用すべき対象（コンテキスト）を誤ってしまうとさらに誤解が増えてしまいそうだ。そういう点では、本書が想定しているコンテキストに関してもう少し説明があっても良かったのではないかという気がする。

とはいえ、ソフトウェア開発に関係する人すべてに一読を勧めたい本である。

というわけで、本書は完了。さて次はなにを読もうか。いま気になっている本は……

どれにしようかなぁ