エンジニア道場 はじめての上流工程をやり抜くための本―システム化企画から要件定義、基本設計まで

著者：三輪一郎
発売元：翔泳社

目次

第１章　上流工程とは
第２章　新業務を示せ―システム化の方向性検討と計画立案
第３章　ＩＴを位置づけろ―要件定義＆基本設計

感想

上流工程って、なんかよくわからないようなわかった気がしていたのですが、この本を読んだら、いろいろはっきりわかってきましたわ。

ちなみに上流工程とは

1. 経営戦略の策定
   経営者の意志と環境の認識に基づく、重要なリソース（ヒト・モノ・カネ）の傾斜配分方法の決定
2. システム化企画
   経営戦略の理解に基づく、方向性の検討、事業戦略の検討、IT、インフラの検討、計画の立案
3. 要件定義
   新業務の分割と分担の確認、業務内容の確認、実施方法のイメージ確認
4. 基本設計
   ジム手順の設計、ヒトと機械の分担の検討、外部仕様の検討

までを言うそうな。

で

上流工程を担当するSEには、開発に手間取ったかどうかよりも、「そのシステムが稼働することでユーザの事業にどんな価値をもたらしたのか」という視点でシステム開発を捉えることが求められます。

だとな。

そこで、システム化の３つの側面について考えることが重要なわけですよ。

その３つの局面とは

1. Why：なぜシステムに投資するのか？
2. What：何をシステム化するのか？
3. How：どうシステム化するのか？

なのですな。

コストと効果の両面を見積もってはじめて、「コスト・効果分析」ができ、システム化投資の「妥当性評価」が行えます。システム化投資の妥当性は、効果がコストを上回るかどうかを検証することです。

上流工程を担当するシステムエンジニアは、まず効果を見積もり、実現方法の大まかなコスト、および実行計画に展開した上で、各年度に投資可能な予算の上限を設定します。これにより、いくらまでならかけてもよいかを自分で示すのです。「ご予算はおいくらでしょうか」と尋ねるのではなく、「これくらいの金額までならかけてもよいでしょう」とアドバイスするのです。

で、効果はどうやって計測するかというと、徹底的に定量化するわけで、「円／年」換算するのが重要なわけですな。

で、正味現在価値を算出するのが重要になってくる、と。

正味現在価値、つまりNPVですな。

はじめての上流工程をやり抜くための本~システム化企画から要件定義、基本設計まで (エンジニア道場)

タイトル：はじめての上流工程をやり抜くための本
著者：三輪一郎
発売元：翔泳社
おすすめ度：☆☆☆（すごい本ですわ）

手戻りなしの要件定義実践マニュアル［増補改訂版］

著者：水谷哲郎
発売元：日経BP社

目次

【第1章】 要件定義を成功させるポイント
　　　　　＜ 1-1 ＞ 手戻りをなくすカギは要件定義
　　　　　＜ 1-2 ＞ 要件定義を成功させる進め方とスキル

【第2章】 業務分析の進め方 ～方針定め真の問題を特定する～
　　　　　＜ 2-1 ＞ ステップ 1：方針と実施計画の策定
　　　　　＜ 2-2 ＞ ステップ 2：現行業務と問題の把握
　　　　　＜ 2-3 ＞ ステップ 3：問題分析と課題の設定

【第3章】 業務設計の進め方 ～解決策を考え要件決める～
　　　　　＜ 3-1 ＞ ステップ 4：課題解決策の決定
　　　　　＜ 3-2 ＞ ステップ 5：システム要件の整理（前半）
　　　　　＜ 3-3 ＞ ステップ 5：システム要件の整理（後半）

【第4章】 既存システム改善における要件定義の進め方
　　　　　＜ 4-1 ＞ 既存システム改善を成功させるポイント
　　　　　＜ 4-2 ＞ 既存システム改善における要件定義の手順

【第5章】 情報を漏れなく集めるヒアリングのスキル
　　　　　＜ 5-1 ＞ ヒアリングの準備
　　　　　＜ 5-2 ＞ ヒアリングの実施
　　　　　＜ 5-3 ＞ ヒアリングのクロージング

【第6章】 全員が納得する合意形成のスキル
　　　　　＜ 6-1 ＞ 会議の準備
　　　　　＜ 6-2 ＞ 会議のオープニング
　　　　　＜ 6-3 ＞ 議論の進行（前半）
　　　　　＜ 6-4 ＞ 議論の進行（後半）
　　　　　＜ 6-5 ＞ 会議のクロージング

【第7章】 BABOK を実践する方法
　　　　　＜ 7-1 ＞ BABOKとは何か
　　　　　＜ 7-2 ＞ BABOKを活用する

感想

好きだわ、こういうマニアックな本。

著者は日立の人で、きっと様々なプロジェクトの要件定義を数多く行ってきたのでしょうね、ということがよくわかります。

それも、いろんな人と組んでね。

本の仕立てが若手に先輩が教えるって目線になっているからわかりやすいんだわさ。

要件定義というのは

1. システム化方針
2. 解決すべき課題
3. 課題解決策
4. 新しい業務の仕組み
5. システム要件
6. 後続作業決定

からなるのだそうな。

で、これらをミーティングベースで決めていくのだけれど、その時に重要になるのが「聞く力」と「合意形成術」なのだと。

ヒアリングや、インタビューで関係各者のやりたいことを聞き出して、それをまとめる力が必要ってことですな。

で、失敗してしまう要件定義の多くは「あいまいなままで終わってしまうシステム化方針の決定」なのだと。

まぁ、「営業業務の見直し」とか「基幹業務の見直し」とかいうザクッとした取り決めだと、そりゃうまくいかないでしょうって話ですわな。

で、このざっくりとしてしまう最初の方針検定を、しっかりしたものとするためにはヒアリングが重要となってくるわけですよ。

その５つのヒアリング内容とは
１）対象範囲
→システムを適用する事業、業務、部署
２）取り組みの背景
→システム化の背景となる好ましくない状況とその原因
３）目的－達成項目
→システム化の直接的な目的とシステムの概要
４）期待成果
→財務、顧客満足、業務プロセス、技術・ノウハウの観点による期待成果
５）制約条件
→時間、費用、技術・方式、改善条件の観点による成約

ここをもれなくしっかり、具体的に聞くことが重要なわけですよ。

できれば定性的でなく、定量的にな。
〇〇％を〇〇％に改善するとかね。

で、もちろんこれだけでは手戻りのない要件定義にはならないわけで、
著者はさらに追い打ちを掛けるように

1. システム化の目的にとって必要・有効な要件を明らかにする
2. システム活用の前提となる業務プロセスや組織、制度、設備・機器の条件を整理する
3. 定義した要件に対して利用部門から十分な合意を得る

ということが必要なのだそうな。

まぁ、そりゃそうだわね。

スコープがぎゅぎゅぎゅっとなってきたら、実際に新しく構築するシステムを使う人間にレビューを行って「そーじゃねーよ」とか「そーだよね」という意見を先にもらいましょうって話だわね。

で、要件定義の時にはインタビューとか、ヒアリングが重要になるのだけれど、いきなり「では・・・」なんてはじめていたら、その回は紛糾まちがいなしなわけですよ。

予めヒアリングの依頼状を送っておく必要があるわけだ。

その依頼状には

1. ヒアリングの目的
   プロジェクトの目的
   ヒアリングの役割
2. お聞きしたいこと
   情報を提供する立場
   情報の内容
   情報の量
3. ヒアリング時の留意点
   気をつけて欲しい点
   誤解を避けたい点
4. 日時・場所
5. ヒアリングまでのお願い事項
   考えておいてほしい意見

が完結にまとまっている必要があるのダワサな。

で、ヒアリングの時に、こちらから色々と質問をするわけですけれど、その質問には【オープン質問】と【クローズ質問】があるのだそうな。

それは何かってーと

【オープン質問】
What,Who,When,Where,Why,How,How toから始まる質問ですな。お客さんがそれぞれに対して、自分の言葉で答えることができるような質問。

【クローズ質問】
イエス・ノーでの回答や、選択肢から回答を求めるような質問のことを言うのですな。

オープン質問で始めつつ、反復質問をはさみ、意味を明確化させ、最後にクローズ質問で終えるというのが王道の流れなのだそうな。

で、ヒアリングを終えたら、すぐに

1. 議事録の作成
2. 議事録の送付
3. ヒアリング結果の整理

を行うのだと。

１）と２）はヒアリングを実施するたびに行い、３）はすべての対象者へのヒアリングが終了した時点で行うのだと。

で、要件定義にはヒアリング以外にも、合意形成という重要なタスクがあるわけでして、この合意形成を成功させるためには７つの技があると、著者は言っているのですよ。

その７つの技とは

1. 会場正面に立ち、発言者の方に移動する
2. 参加者の発言機会をできるかぎり均等にする
3. 発言の意味を全員がわかるように確認する
4. 進行役が自分の意見をいうのを控える
5. 意見が対立したら理由は根拠を確認する
6. 問題を指摘された側の意見を聞く
7. 議論が行き詰まったら休憩を入れる

のだと。

で、要件定義の知識・スキルを整理しながら磨いていく。そのことに役に立つ、ビジネス分析の知識体系「BABOK ( Business Analysis Body Of Knowledge )」というのがあるのだと。

BABOKには7つの知識エリアがあり、それは

1. エンタープライズアナリシス
   企業・組織レベルの視点で要求を分析し、プロジェクトの方向性・範囲を決める活動
2. 要求アナリシス
   利用部門から引き出した要求を分析し、要求の優先順位を評価する活動
3. ソリューションのアセスメントと妥当性確認
   要求の妥当性を評価し、それを実現するための体制・スケジュールなどを定義する活動
4. 引き出し
   利用部門のユーザーから個別に要求を引き出し、文章化する活動
5. 要求のマネジメントとコミュニケーション
   要求についてステークホルダーから合意を獲得し、成果物を作成・管理する活動
6. ビジネスアナリシスの計画とモニタリング
   ビジネス分析の実施計画を立案し、その実施状況を管理する活動
7. 基礎コンピテンシ
   ビジネス分析を実施する担当者に求められる基礎的な知識・能力

なのだと。

要件定義というものを、ここまで体系づけて教えてくれる本って、なかったわな。

すごいく助かった。

そして、この本、版元のサイトに行くと、「要件定義の成果物」をダウンロード出来たりする。

手戻りなしの要件定義実践マニュアル 増補改訂版

タイトル：手戻りなしの要件定義 実践マニュアル[増補改訂版]
著者：水谷哲郎
発売元：日経BP社
おすすめ度：☆☆☆☆☆（すごいわすごい）

Amazon DSP誕生

お買い物のプラットフォームとして成り立っているアマゾンに広告を出したら、そりゃ、効率いいですよね、と。

ヤフーニュースや、LINE、Facebookには「買い物しよう！」って息巻いてやってくる人は殆どいないですが、逆にアマゾンに「なにかおもしろいネタないかしら？」とザッピングついでにやってくる人はいないですからねぇ。

ということで、ワタシ、広告媒体としてのアマゾンを推していましす。

が、アマゾンの広告ってわかりにくい。。。

と思っていたら、来ましたよ、これ。

digiday.jp

Amazonサイト内に広告を掲載するAMSをはじめ、ここ日本でも少しずつ需要が高まりはじめていたAmazon広告だが、複数の広告商品それぞれの区別が付きにくく、なかなか実態が掴めないという声も聞かれていた。実際、同発表によると、Amazon自身もその現状を把握しており、以前から広告主の混乱を防ぐため、複雑さを解消する取り組みを検討してきたという。

現段階で発表されているのは、同社が提供する広告配信プラットフォームの名称変更だ。AAPの名を冠していた同サービスは、プログラマティックな特性がより伝わり易くなるようにという狙いのもと、「Amazon DSP」に変更される。

また、広告商品に関しても、キーワードと連動して広告を検索結果の上部に表示させる「ヘッドライン検索広告」は、今後「スポンサーブランド広告」に変更される。同商品は、AMSの傘下に紐づいており、国内外問わず利用が多い。こうした変更は、これから段階的に実施され、ホームページ上では、これらから数カ月間は従来のブランド名が混在することになる。

「買い物をしたい！」って気持ちを持ったユーザのトラフィックは圧倒的なので、EC系のクライアントにとっては、最高の媒体ですからね。

今後、どんなサービスが追加されるのか興味津々です。

日経ビジネス 2018.09.03

発行元：日経BP社

目次

大特集は「アマゾンは怖くない　選ばれる小売」
特集の中でジャスパー・チャンが語っているけれど、アマゾンはテクノロジー企業であり、顧客に対して世界で最も多い選択肢を提供しているだけなんだよね。
この土俵でECを作るから、負けてしまうんだよね。ってか、この発想でリアル店舗を作るから、だめなんだよね。
生き残りの突破口として紹介されている「モノを売るより、体験を売る」ことが、アマゾンに負けない小売の戦い方なんだと思うんだよね。

だって、アマゾンは「探しやすい検索体験」を提供することはできるけれど、リアルな購買体験は販売できないから。

その昔、少なくとも80年代まで、百貨店というのはアミューズメントスポットだったんだよ。月に一回、下手したら年に数回しか足を運べない場所。そこではお買い物をするだけでなく、「買わないけれど世界中から集まった素敵なもの」を見ることができ、美味しい食べ物を食べて、遊んで帰ってくる。

そういう場所だったんだよね。

それがいつの間にか、単なる買い物をする場所になっちゃった。
楽しくもなんともない。
品揃えもそこまでもない。

そりゃ、わざわざ、通わないよ。買い物をしないよ。

そんな今週号で面白かった他の記事。

「大倉忠司社長の　うぬぼれてなんぼ」
鳥貴族の秘密がここには書かれていましたよ。
効率化をするところはするけれど、効率化をしないところはしない。
鳥貴族はセントラルキッチンではなく、各店舗で焼き鳥の串打ちをしてるんだってな。
でも、炭火で焼くのではなく、グリルで焼く。
鶏肉は鮮度が命なので、鮮度が最も良くなるようなオペレーションを組んでいる。
そして、値引きや、キャンペーンは行わない。いつでもエブリディロープライス。そうしないと、鳥貴族の凄さが伝わらないしね。
で、大倉社長が考える「強い事業」の作り方で
・業界の「常識」を疑う
・「やること」よりも「やらないこと」を明確にする
・時流に左右されない「ベーシックな価値」を磨く
っていう考え方に、思いっきりうなずきますな。

失敗の本質―日本軍の組織論的研究

著者：戸部良一、寺本義也、鎌田伸一、杉乃尾孝生、村井友秀、中野郁次郎
発売元：中央公論社

目次

はしがき
序章　日本軍の失敗から何を学ぶか
一章　失敗の事例研究
　　　１　ノモンハン事件――失敗の序曲
　　　２　ミッドウェー作戦――海戦のターニング・ポイント
　　　３　ガダルカナル作戦――陸戦のターニング・ポイント
　　　４　インパール作戦――賭の失敗
　　　５　レイテ海戦――自己認識の失敗
　　　６　沖縄戦――終局段階での失敗
二章　失敗の本質――戦略・組織における日本軍の失敗の分析
三章　失敗の教訓――日本軍の失敗の本質と今日的課題

感想

やっぱ、名著だよなぁ。

名著。

日本的左翼な方々は、この本の存在すら認めたくないんだろうな。

そして、そのような思考回路こそが、すべての過ちであると、この本は教えてくれるのですよ。

マジで名著です。

その辺の話は24ページに

そして、多くの場合、それらの失敗の原因は当事者の誤判断といった個別的理由や、日本軍の物量的劣勢に求められた。しかしながら、問題はそのような誤判断を許容した日本軍の組織的特性、物量的劣勢のもとで非現実的かつ無理な作戦を敢行せしめた組織的欠陥にこそあるのであって、この問題はあまり顧みられることがなかった。否、むしろ、日本軍の組織的特性は、その欠陥を含めて、戦後の日本の組織一般のなかに概ね無批判のまま継承された、ということができるかもしれない。

そうなんですよな。

政府という組織ではなく、会社という組織にこの欠点というか欠陥はたくさん見受けられるのですよ。

また、105ページには

近代戦における情報の重要性を認識できなかった。米海軍情報部は多大の努力を払って、日本海軍の暗号読解に成功したのに対し、日本海軍は米海軍の暗号を解読できず、傍受した通信の解析を中心に状況判断を行っていたに過ぎない。情報収集力の不備を他の要因でカバーできると考えていたのであろうか。

これも、日本の会社という組織によく見られる話ですわな。

それも、営業という組織によく見られる話ですわ。

ま、データを集めるだけじゃないにもできないのですが、集めることすらしていない会社ばかりですからね。

で、なんで、そのようなことをしていないのかというと、「めんどくさいから」とか「そういうスキルがないから」というのではなく

目的が単純化されていないからなんですわな。

目的がはっきりしていないから、何のために情報を集めていいかすらわからない、と。

目的がはっきりしていないのであれば、目的をはっきりさせればいーじゃねーかって話になりそうですが、実はそう簡単には行かない。

331ページにもありますが

学生にとって、問題はたえず、教科書や教官から与えられるものであって、目的や目標自体を創造したり、変革することはほとんど求められていなかったし、また許容されてもいなかった。

そりゃ、目的の再設定なんて出来るわけないすよねって。

で、イノベーションというのは異質な人間や、考え、情報や、偶然を取り込んで生まれれるわけですから、同一均一的な人間が前例主義で仕事をしていたら、そりゃ革新的なことも、目標の再設定もできませんよねって話ですな。

失敗の本質―日本軍の組織論的研究 (中公文庫)

タイトル；失敗の本質　日本軍の組織論的研究
著者：戸部良一、寺本義也、鎌田伸一、杉乃尾孝生、村井友秀、中野郁次郎
発売元：中央公論社
おすすめ度：☆☆☆☆☆（名著。いわゆる「空気」じゃないところに引っかかった）