■はじめに
皆さま、いかがお過ごしでしょうか。匠本舗はいよいよおせち販売予約の受付をスタートいたしました。
記事作成のネタはもう尽きるかなぁと思ったら、時事ネタや個人的に思うこともあって意外と尽きない
ものですね。
さて、物事を相手に伝えるときに皆さまはどのように伝えますか。内容によるかも知れませんが
書面で明示する、口頭で伝達するなど手段は違えど「わかりやすく」説明するのが基本だと思います。
ところが世には様々なシチュエーションがあって偶然なのか、ワザとなのか不明ですが「わかりにくく」
伝えるに留まらず、頭で考えている内容と説明する内容で違うケースもあります。
日常で関わりたくとは思いますが、もしも関わらざるを得ない場合にどうすればよいのか。
事態の悪化を防げる（もしくは損害をいかに少なくする）のかを本記事で紹介いたします。
■プロジェクトの姿－顧客が本当に必要だったもの
・・・とある界隈では有名な風刺イラストですね。私はこのイラストを見ると頭が痛くなります。笑
後ろ向きな気持ちになることが多く、精神衛生上よくありません。
「顧客が本当に必要だったもの」というイラストです。
大元の出典等は以下のサイト（引用元１）に詳しく書いてありますが、1970年代のアメリカ産業界で広まって
いたものが、段々と改変されて現在の形（引用元２）になったようです。
引用元１：
TREE SWING CARTOON PICTURES (EARLY VERSIONS)
https://www.businessballs.com/amusement-stress-relief/tree-swing-cartoon-pictures-early-versions/
引用元２：
ニコニコ大百科
https://dic.nicovideo.jp/a/顧客が本当に必要だったもの
1.顧客が説明した要件
2.プロジェクトリーダの理解
3.アナリストのデザイン
4.プログラマのコード
5.営業の表現、約束
6.プロジェクトの書類
7.実装された運用
8.顧客への請求金額
9.得られたサポート
10.顧客が本当に必要だったもの
各図には単一の正解はなく様々な解釈が存在します。実に酷いイラストです。
皆さまはこのイラストからどのような物事を連想したでしょうか。前向きな気持ちにはならないと思いますが。
記事作成のために改めて見ましたが、その日の夜は悪夢にうなされました。(´・д・｀)
翌日が休みだったのがもっけの幸い。
■顧客の要望を捉えることが如何に困難であるか
開発側の勝手な思い込みや都合の押し付けであれば、別の視点で要件定義をチェックすればよいだけです。
何故困難なのか、それは『最初に顧客が説明した要件』そのものがズレていることが往々にしてあるためです。
※顧客自身にも自分が必要とするものが分かっていない（要件が定まっていない）
あるべき姿としては
発注側が「顧客『に』本当に必要なもの」を正しく説明するのが最善です。
次善としては「顧客が本当に必要なもの」を正しく説明することです。
※開発側は「顧客が本当に必要なもの」と「顧客『に』本当に必要なもの」
でミスマッチや矛盾がないかを検証して開発していく
発注側も本当に必要なものの形がわからず（あるいは正しく伝えられず）、顧客の説明を聞いた開発側にも
わからない（引き出せない）ことが起きてしまうと、様々な乖離が生まれ、顧客が本当に必要だったものとは
ほど遠い成果物ができあがってしまうということが発生いたします。
■「顧客が本当に必要なもの」と「顧客に本当に必要なもの」
この２つが一致しているのが理想ですが、一致していないこともあります。
要件定義の段階で気づくことができると助かりますが、実際はある程度作業をすすめてから判明するものです。
『顧客が本当に必要なもの』の条件を満たすことで、かえって『顧客に本当に必要なもの』の条件を満たせなく
なるというのは決して珍しくありません。後の揉め事を避けるためにも、確認しておくのが望ましいです。
うーん、書いていて頭が痛くなってきました。（震え声）
■不幸な事態を避けるには
関係者の意思疎通をしっかりとする。本当に必要なものを事前にしっかりと分析して要件定義を作成する。
顧客と合意して、プロジェクト関係者の間で情報共有をすることです。
文字だけでなく、図解を用いて認識合わせをしましょう。
正しいゴールを設定して共有すれば、全ての関係者がゴールに向かって作業すれば良いのです。
「正しいゴール」を見極めるのが最も難しいですが。
下手すると全ての関係者が「誤ったゴール」に向けて進むなんてこともあり得ます。
特にプロジェクトに携わるメンバーが多いと意思疎通だけでも難易度があがります。
これは『スタッフぐでぐで』の私見ですが、次の心得を持って臨むと少しはマシになります。
１．実務経験の無い方が要件定義を決めない
実務経験の無い方が関わると実情に合わないものが完成します。
完成したけど使われないでは意味がありません。（完成できるとは言っていない）
２．適正の無い方が要件定義を決めない
事務処理が向いていない、進捗管理が向いていない、質問に対して回答がブレる、要件を定義しない方を
参画させると死の行進（デスマーチ）が発生します。誰も幸せになりません。
３．責任と権限はセットで与える
権限だけ与える、責任だけ与えるプロジェクトでまともな成功を収めた事例を私は知りません。
まともじゃない成功例は知っているが、褒められるやり方ではない。
４．締め切りが迫ってから大幅な要件定義の変更をしてはいけません
このような方に要件定義を任せてはなりません。それでも変更するなら納期も変更するべきです。
納期が変更できないなら、締め切りが迫ってからの要件定義の変更は不可。
上記の心得を持って臨めは事態の悪化を防げる（もしくは損害をいかに少なくする）が叶います。
■アジャイル開発とは
開発側も不毛なことは避けたいので、次のような開発手法が主流となっております。
機能単位で設計⇒開発⇒実装⇒試験を反復するのでリリースのタイミングが早く、不具合の修正も工数
を少なくすることができます。顧客と意思疎通を重ねてフィードバックを行うので、顧客ニーズを最大限に
反映できるのが利点です。顧客が必要としないシステムを作ってしまうリスクを低減できます。
一方で全体の進捗状況やスケジュールの把握が困難な点がデメリットとなるので、全体の納期管理ができる人を
中心に計画を立案しましょう。
■おわりに（どうしてこのテーマで記事を作ったのですか）
以前の職場の友人と「消費税を５％⇒８％に変更する」「消費税を８％と１０％の２パターンに変更する」際の
苦労話に花を咲かせたときに、様々な忌まわしき記憶が湧き出てきたので、供養のような意味も込めて本記事を
書いてみました。
「消費税を５％⇒８％に変更する」際に内税から外税に変更したり、「消費税を８％と１０％の２パターン
に変更する」際に勘定科目毎に税率をコントロールし、納品とリリース直前に「資産の貸付に係る経過措置」の
適用項目（リース）が組み込まれて、消費税５％でも算出するよう仕様変更が発生したときに見上げた夜空は
とっても綺麗でした。純粋無垢な気持ちに戻る感じでしたね。
・・・現実逃避はさておき
匠本舗では毎年８月からおせち料理の予約受付を開始しております。
また、当店はおせち以外にもカニを販売しております。
ネットショップ大賞『12年連続1位』の実績がありますので強くおススメいたします。
下記バナーよりお選びください。
おせちバナー（毎年８月から予約受付開始）早期割引実施中
カニバナー（通年で販売しております）
■おまけに
たまに旅人やっております。こちらのお写真は鳥取県の
鳥取砂丘（とっとりさきゅう）を訪ねた時のものです。
冬に訪ねましたが、砂嵐と日本海が絶妙にマッチして日常
とは異なる斬新な景色をみることができました。砂つながりで
すなば珈琲と砂の美術館も巡ってきました。砂ばっかり。
今回の記事を担当したのは↓
スタッフぐでぐで
匠本舗 ＣＳ商品部
ぐでたまを愛でる社会に疲れた生き物です。
ときどき、なが～い休みをとって
人のいない静かなところに旅立ちます。
