久しぶりに本を書いてみようと思う。

ここ数年、ITシステム開発の完成品のレビューやアドバイザーなどを仕事で行ってきて、相変わらずシステム開発で失敗するケースが多いことに大きな問題意識を持っていた。 おそらく表には出しづらい ITシステム開発の失敗コスト は相当な額のぼるだろう。それだけ課題の度合いが高いと思っている。

どうにか失敗する確率を下げられないものかと思い、プロジェクトマネージャー向けの有料イベント開催や実際の現場で発注者に対して失敗リスクをなるべく減らす方法を伝えてきたが、それだけでは解決策として影響が弱いと感じていた。

そこでWebサービス前提でプロジェクトマネジメントツールのプロトタイプを作って顧客候補に見せたりもしたが、どうもしっくりこなかった。 ITシステム開発は、ある程度長期で様々な要因が絡み、実際のソフトウエア開発も複雑になりがち。それを単純化したツールだけ解決しようとするには足りない。

であれば、発注者自身が事前に最低限の知識を得ておき、プロジェクトを進める際に並走してあげるようなソリューションの提供の仕方が良いのだろう。

そうして行き着いたソリューション案の形態が 本 だった。

以下に本を執筆する際の企画書として方向性や概要を検討した結果と公開してみる。

読みたいと思われる方が実際いるのかどうか確認してみたい思いもあるので、コメントやSNSなどでフィードバックいただけると幸いです。

目的

日本におけるITシステム開発の失敗率は高い。 (日経コンピュータによる2017年の調査結果は約半数が何らかの点で失敗と回答されている。)

失敗によって損失した時間と資本は戻ってこない。 失敗したことは隠しておきたい、また社内秘扱いになりやすいので、失敗した内容は表に出てきづらい。 相当な金額にのぼるだろう。

「日本のITシステム開発で失敗確率を下げる。」ことを目的とする。

そのため目標として、具体的な手法の提示、その基本となる考え方を提示し、体系的かつ実践的に読者がプロジェクトを進める方法を体得できることとする。

ターゲット

ITシステムの開発と完成・リリースに責任を持つ発注者

• システムを完成させ運用しなくてはならない
• 非エンジニア
• 開発経験なし
• 予算あり(社内稟議済)、外注前提
• 予算執行権あり(予算の使い方の権限)
• プロジェクトの進め方がわからない
• 発注者としてやるべきことがわからない
• 予算の使い方がわからない
• 発注先の選定基準がわからない

どんな時に読むか

• プロジェクトが承認されてGoがかかった時
• 開発会社選定前
• 開発中なんとなくうまく行かないと感じた時
• これからマネジメントする時用の勉強

競合調査

Amazon でキーワード 「開発 発注」で検索。

情シス・IT担当者[必携] システム発注から導入までを成功させる90の鉄則

(日本語) 単行本（ソフトカバー） – 2017/4/11

ターゲット : 情シス・IT担当者 (ターゲットがこちらと違うかも)

紹介文

本書は、IT担当者、情報システム部門に向けた、システム発注~導入のノウハウ集です。 なぜシステムの発注~導入には失敗がつきまとうのでしょうか。 筆者は、「失敗の原因はユーザー企業の力量不足」と喝破します。 ユーザー企業は、少なからず何らかのシステム導入を経験しているものです。 であれば、経験はノウハウとして蓄積されているはずです。 しかし、プロジェクトは失敗してしまいます。 ノウハウに体系的なまとまりがないからです。 本書には、ITコンサルタントという立場だからこそ知りえた 筆者のノウハウが詰まっています。 〈本書の内容〉 第1章 システムの企画提案~ITベンダー選定までのルール 第2章 プロジェクト立ち上げ~要件定義までのルール 第3章 ユーザー受入テスト~システム検収までのルール 第4章 ユーザー教育~システム本稼働までのルール 第5章 システム運用/保守のルール

レビュー 4.5

5つ星のうち5.0 システム開発のプロジェクトに関わる人は必読！ 2020年5月16日に日本でレビュー済み 以前、ユーザー部門のシステム担当者として業務に従事していました。 久々に良書に出会いました。もっと早く出会いたかった！

情シス・IT担当者必携というタイトルは「嘘偽りなし」で正にその通りだと感じます。 システム化のプロジェクトなどにユーザー部門の担当者として従事する人、プロジェクトリーダーやオーナーは、 必ず本書を読んでからプロジェクトをスタートすることを勧めます。 90の法則として、各フェーズのトピックごとに（基本は）見開き2ページにまとめられており、 読みやすく、現場での「あるある」もまじえてわかりやすく説明されています。 各フェーズでの注意点や、ユーザー、ベンダーのそれぞれの立場で「かくあるべき」という”方向性”を提示してくれます。 現在進行しているプロジェクトがなかなかうまくいかないと感じている人、 すでに完了したプロジェクトを振り返りたいという人も読んで損はないです。

システムを「外注」するときに読む本

(日本語) 単行本（ソフトカバー） – 2017/6/15

ターゲット : 中小企業の発注者 (かぶりそう)

紹介文

パッケージであれ逸品もの開発であれ買収先とのシステム統合であれ、行きつくところは 『どういうシステムに仕上げて、どういう効果を上げるのが目的の開発なのか』が きちんと発注者側がイメージできていないと死なのであります」 「中小零細も大手も半年に一度は読み返して発注フローをチェックするべき」 第1章 システム作りは業務フローから〜「本当に役に立つシステム」を作るために、まずやるべきこと 第2章 発注者に最低限必要な知識〜自社の業務を「正確に」知っているか? 第3章 失敗しないベンダ選びのポイント〜プロジェクト管理能力の見極め方 第4章 社内の協力を得るために〜みんながシステム担当者に協力するしくみ作り 第5章 リスク管理で大切なこと〜「ベンダ側のリスク」の引き出し方 第6章 ベンダとの適切な役割分担〜発注者はどこまで「ワガママ」でいられるのか? 第7章 情報漏えいを起こしてしまったら〜ダメージを最小限に抑える対応法

レビュー 3.7

小説要素がいらない 2019年7月3日に日本でレビュー済み Amazonで購入 テクニカルな話はもちろんあるものの、全体を通して発注側が主体性をもって、積極的にプロジェクトに参加しましょう、というのがメインのメッセージ。 それだけだとページ数が少なくなるのか、もしドラのようになぜか小説パートにかなりの部分が割かれている。 臨場感のようなものを出したい気持ちはわかるが、あまりにも多すぎる。（しかも内容はBL・・・） 具体的なケースなどがもっと記載されていると思っていたため、ギャップが大きすぎるため低評価をつけました。

システム開発をより速く確実に 本当に使える開発プロセス

[改訂版] (日本語) 単行本 – 2018/6/21

ターゲット : プロジェクトマネージャー(といいつつエンジニア？)

紹介文

システム開発をどのように進めるかという「開発プロセス」の現実解を示した1冊です。 従来のウォーターフォール型の開発プロセスを改善し、アジャイル型をはじめ様々な実践項目(プラクティス)を取り込むテクニックを解説。 クラウドを利用した開発のほか、ALMやCI、TDD、BABOKなど最新のプラクティスも網羅しています。 本書は、以下のような状況にある方を対象としています。 ・新しい開発プロジェクトを企画しようとしている ・これからプロジェクト計画を策定しようとしている ・顧客に開発プロジェクトを提案しようとしている ・実施中のプロジェクトに不安を感じ、改善しようとしている ・組織の開発標準を策定しようとしている ・より良い開発の進め方を模索している ≪目次≫ 第1章 超実践 システム開発の進め方 1-1 システム企画(前編) 1-2 システム企画(後編) 1-3 要件定義 1-4 基本設計 1-5 詳細設計・プログラミング 1-6 テスト 第2章 クラウド対応 システム設計書の作り方 2-1 プラットフォーム概念図 2-2 要求仕様書 2-3 アーキテクチャー設計書 2-4 ユースケース仕様書 2-5 データベース設計書 2-6 システム連携の設計書 第3章 デジタル変革に効く 技術要求の分析法 3-1 多様化する非機能要求 3-2 技術リスクの識別

レビュー 4

予定通り進まないプロジェクトの進め方

(日本語) 単行本 – 2018/3/29

ターゲット : プロジェクトマネージャー

紹介文

本書では、SI開発やプラント建設といった 「狭義のプロジェクト」だけではなく ルーティンではない活動すべてをプロジェクトとしてとらえ 工学的なアプローチでそれを解明し、 成功に導くための方法を身につけます。 目次】 まえがき 第1章 なぜプロジェクトは失敗するか   1-1 そもそもプロジェクトとは何か   1-2 プロジェクトの種類   1-3 想定外は当たり前   1-4 コミュニケーションロス:要望、要求、要件、仕様、設計   1-5 まとめ 第2章 プロジェクトの道具箱   2-1 道具は適したものを使おう   2-2 PMBOK——プロジェクト推進の王道   2-3 定例会議——プロジェクトにおけるPDCAサイクル   2-4 フィット&ギャップ分析   2-5 ウォーターフォールか、アジャイルか、はたまたリーンアップか   2-6 まとめ 第3章 プロジェクト工学   3-1 プロジェクト工学概説   3-2 プロジェクト工学 3つの法則   3-3 まとめ 第4章 プロジェクト譜~プ譜を使ってみる~   4-1 プ譜を使ってプロジェクトを可視化する   4-2 プ譜の概要   4-3 プ譜を書いてみる   4-4 まとめ 第5章 プロジェクト・エディティングの技術   5-1 プ譜をさらにうまく使うために   5-2 当たり前の発想を飛び越え、連想を助けるもの   5-3 プロジェクトをよりよく理解し、膠着状態を打破するもの   5-4 態度、心構え 第6章 プロジェクトの感想戦   6-1 プロジェクトの感想戦   6-2 感想戦の着眼点   6-3 映画『シン・ゴジラ』を感想戦する   6-4 まとめ

レビュー 4

もう少し絞って深く解説が欲しい 2020年5月7日に日本でレビュー済み Amazonで購入 全体的に内容が表面的なところで終わっている。 プロジェクト譜というシンプルで網羅的な手法なので活用範囲は広い、自分の取っても新しい 手法であるので、コンテンツとしてはとても魅力的。 少し中身に入ったなと思ったら終わってしまった感じがするので、より手法に絞り、構成部位 や変化点時の実践を深堀してほしいところ

<ポイント＞ ・プロジェクト基礎条件を書き出す ・ゴール設定と共有を明確にする ・こだわらず定性的、Flexibleな変更を加え続ける

中小企業の「システム外注」はじめに読む本

(日本語) 単行本 – 2018/11/18 なにかのシリーズ物かな？

ターゲット : 発注者側の担当者(かぶる！ドンズバな印象)

紹介文

何の知識もなく、配置転換でIT部門に配属されたばかりの人が、会社の要望によってシステム構築やソフト開発の窓口を担当させられることも珍しくありません。 本書は、そうしたIT初心者がシステム開発やソフト開発を外注しなければならない時に、外注先であるコンピューター・メーカーやシステム・インテグレーター、ソフトハウスなどとのトラブルを回避し、スムーズにシステム構築案件を進める方法を解説するとともに、契約から案件の進め方、フェーズごとの確認事項、外注先との接し方などのほか、関連法規までをわかりやすく解説する1冊です。

レビュー 4.7

システム開発を深く正確に理解している人の頭の中はこのようになっているのか、と感じられる出版物です。 2019年9月21日に日本でレビュー済み システム開発を深く正確に理解している人の頭の中はこのようになっているのか、と感じられる出版物です。 ある専門領域について、よく知っている人に、素人が質問すると分かりやすく導入案内してくれます。一方で、同じ人に中級者、玄人が質問するとそれに合わせて返してくれる。つまり、初心者は導入から一定レベルまでのガイドとして、中級者・玄人は確認したいポイントに対する知識を高い確率で獲得できる。加えて、既に蓄えた知見の整理もできる。そのような書籍と感じました。 記載は構造化されていて、最上層は短文と対応した答え、挿絵や対比表も豊富です。掘り下げてみていくと筆者の経験から曖昧にすることなく意見を述べてくれており、多様なレベルの読者の参考になると思います。

試し読み 太文字は色つき、イラストはシンプルで図解も多め。わかりやすさのアピールになっている。 概念的で具体的に何をすれば良いのか分かりづらい RFPにまとめると書いてあるが書き方が説明されていないわからない UMLを紹介していたり結構やらなきゃいけない事が多い印象。でもここの作り方についてはあまり解説されていない。 DevOpsは開発側の手法であって発注側としては関係ないだろう ぱっと見た目はわかりやすく親切な印象だけど、内容は詰め込みすぎていてここの理解を促すようなスタンスが不足している。読者は消化不良になるのでは。新しい人が学ぶには情報が不足している。なんとなく概要理解が進むだけ。実践できるかどうか疑問。 そういう意味では「2時間でざっくりつかむ！」「はじめに読む本」という位置づけは間違ってはいない。

競合調査まとめ

Amazon.co.jp にて「開発 発注」のキーワードで外注前提で失敗をなくすための本は5冊だった。

出版日は2017, 2018年に集中している。今から2,3年前。

アマゾンがおすすめしている上位の本は2017年。3年前の情報はすでに古い。今(2020年)に出す意味・意義はありそう。

競合は最後の「中小企業の〜」が一番ターゲットがマッチしていると思う。 順に

1. 中小企業の〜
2. システムを外注する時に読む本
3. 情シス・IT担当者 必読
4. システム開発をより速く確実に 本当に使える開発プロセス
5. 予定通り進まないプロジェクトの進め方

競合は小難しさが解消されていない印象を受けた。また、実際にはどうやって進めたらよいかがわからなかった。

本書の競合との差異

対象システムは、Webシステムで絞る。スマホアプリと連携するサーバ開発含む。

ざっくり掴むだけでは具体的行動につながらない。ガイドブックのような実際にプロジェクトを読みながらすすめるような位置づけにしたい。

Running Lean のようなシンプルかつフローを進めていけるような内容の情報提供をしたい。

本書の概要案

読者に対して本書の目指すユースケースは、「これ一冊あればITシステム開発経験のない人でも、プロジェクトを失敗なく進め完成までこぎつけることができる。」こととする。

開発経験がないが立場上プロジェクト進める立場にある発注者に対して、プロジェクトを失敗させないための進め方や各段階で何に注意しどう進めるのかを具体的に説明する。また、失敗させないための進め方の根底にある考え方やITシステム開発そのものに対する認識を提示し、知識と認識を深めてもらう。

結果的に失敗しにくいプロジェクトマネジメントが実現できる。

期待できること

• システム開発の進め方が体得できた
• 失敗しなかった・失敗しづらくなった
• 自分の経歴にITシステム開発のプロジェクトオーナーと書ける
• ITシステム開発のプロジェクト推進ができるという実績を残す

どう活用されるか

本書は読者が実際にプロジェクトを進めながら、各段階ごとに何度も参照して利用するガイドブックのような利用イメージとする。

ターゲットが知りたいこと 想定

• 失敗が起きる仕組み
• 失敗の具体的ケース
• 失敗しないためのやり方
  • 予算の使い方
  • 契約
  • レビューの仕方
  • スケジュールの進め方
  • ミーティング、コミュニケーションの仕方
• 失敗しないための開発会社の見極め方
  • ポイント
  • チェックリスト

目次案

1. 本書執筆の背景
   1. 失敗率半数
   2. 数々の失敗プロジェクトの現状
2. 本書のガイドラインの方向性
   1. 想定システム
   2. アジャイル開発
   3. 予算の使い方
   4. 丸投げNG
   5. 不確実なものに対応する
3. 認識を改める
   1. 発注者の役割は大きい
   2. エンジニアはスーパーマンではない
   3. 丸投げした段階で失敗する
   4. 不確実性を受け入れる
   5. 最初の思いつきを100％再現しようとしない
   6. ソフトウエア開発は不確実な作業
4. 開発プロジェクトの大まかな流れ
   1. アジャイルベース
   2. 開発段階は開発、レビュー、修正の繰り返し
   3. いつでも修正できる、止められる
5. プロジェクト開始前の準備
   1. やりたいことを資料化する
6. 業者選定
   1. コストが全てではない
   2. コスト以外に重要なポイント
   3. 業者選定チェックリスト
7. 契約
   1. 中間納品
   2. 前払いNG
   3. 途中で辞められるように
8. プロジェクトスタート
   1. キックオフミーティング
   2. マイルストーンを作る
9. 開発
   1. 定例ミーティングの持ち方
   2. レビューの仕方
10. リリース
11. 運用・保守
    1. 運用方法について検討
    2. バグがあった場合は
    3. ソフトウエアメンテナンス
12. ありがちなトラブルと対処法

執筆アプローチ

目次の上位から書き始め小見出しごとにブログで公開。

フィードバックがあれば参考にして必要があれば修正する。 ブログは Github Pages なので、変更箇所は公開できる。

最終的に1冊の本として出版。電子書籍もあり。