本日スペシャル・デー、日替わりセール対象 2タイトル！ 原田 隆史 『カリスマ体育教師の常勝教育』夏目 漱石『明暗 -まんがで読破-』
原田 隆史 『カリスマ体育教師の常勝教育』 ☆は、47件のカスタマーレビューで、5つ星のうち 4.6
夏目 漱石『明暗 -まんがで読破-』 ☆は、38件のカスタマーレビューで5つ星のうち 4.6
何でも漫画ですね。
Kindleストア 1周年謝恩セール 夢をかなえるゾウ、三国志全一冊合本版、クトゥルフ神話超入門
夢をかなえるゾウ ☆は、632件のカスタマーレビューで、5つ星のうち 4.3
評価の母数が多いのに高い評価。
☆は、12件のカスタマーレビューで、5つ星のうち 4.5
これ、紙の本で持っているけど合本版だとすごい厚さになるね。
ITエンジニア小説 高慢と偏見 ☆は、9件のカスタマーレビューで、5つ星のうち 3.8
存在を知らなかったんだけど。
ITエンジニア小説 高慢と偏見
posted with amazlet at 13.10.26
カラマゾフの兄弟 ☆は、18件のカスタマーレビューで、5つ星のうち 3.7
クトゥルフ神話超入門 ☆は、10件のカスタマーレビューで、5つ星のうち 4.0
超入門編のようですね。
☆は、30件のカスタマーレビューで、5つ星のうち 4.2
Kindleストアで“クトゥルフ神話”で検索したらこれが出てきたので置いておきますね。
iTunes 10月22日リリース
秋アニメのOP・EDが出てきましたね。
TVアニメ『アイカツ!』OP/EDテーマ「KIRA☆Power/オリジナルスター☆彡」 - Single
STAR☆ANIS
価格： 300円
posted with sticky on 2013.10.27
STAR☆ANIS
価格： 300円
posted with sticky on 2013.10.27
Girlish Party(俺の彼女と幼なじみが修羅場すぎる) - Single
自らを演出する乙女の会(赤崎・田村・金元・茅野)
価格： 250円
posted with sticky on 2013.10.27
自らを演出する乙女の会(赤崎・田村・金元・茅野)
価格： 250円
posted with sticky on 2013.10.27
要件定義で顧客に“欲しいもの”を訊いてはいけない
要件定義は難しいです。
でも、準備さえできていれば難しくありません。
プロジェクトの失敗は、ほとんどその失敗が発現するタイミングが遅かれ早かれ要件定義のようなものです。SIerが関わるプロジェクトのスタートが基本設計なら基本設計だし、詳細設計なら詳細設計に読み替えてもいいです。
つまり、システムを開発するSIerが請け負う最初のフェーズが肝心なんです。大体、実装するエンジニアのチームでなければ、これから作るシステムの子細まで考えが及ばないもの。
プロジェクトの実相を託す側は、はっきりとしたイメージを持っていません。だって、出来上がるであろうシステムを現物として見ていないのだから。だから、持てるはずがないんですね。
正しいソリューションを顧客に聞いてはいけない
システムの実相を託す側の顧客が自らの手で実装をするのであればこの限りではないですが、SIerのエンジニアに託すのであれば、託されたエンジニアは顧客に対して“正しいソリューション”を聞いてはいけないんです。
得てして、それを分からずに顧客に正しいソリューションを訊いてしまうからプロジェクトが最初の局面から迷走をし始めてしまうんです。
なぜか。だって、顧客は最終的に手に入れるシステムをまだ見たことも触れたこともないんですから。それなのに
「このシステムにはどんな機能が欲しいんですか。」
なんて、お伺いしてしまったらどうなるか。
顧客は、今その瞬間から考えますよ。“欲しいもの”を。“あったら良いな！”を。
顧客には“正しい『課題』”を説明してもらう
お見積りでは、何を、いつまでに、誰が、という切り口で契約していませんでしたか。顧客の課題を解決するためにその解決方法を“システム化”するんですよね。その“課題”を解決するしくみをシステム化して使い始める日はいつなら引き渡せるとお見積りしたのでしょうか。その“課題”を解決するにあたって、そのシステム化に掛かる作業は誰の所掌として担当するのでしょうか。お見積りしたSIerが単独ですべてを担うのでしょうか。課題は誰が説明するのでしょうか。だれが、その課題を解決できる仕様であるとオーソライズできるのでしょうか。
顧客には“正しい『課題』”を説明してもらわなければなりません。SIerのエンジニアは、顧客の“正しい課題”を理解してなければなりません。顧客は事業主管としてその事業の課題を解決しなければなりませんし、エンジニアは顧客の欲するしくみを届けなければなりません。
顧客は専門家ではないのでその解決方法はわかりませんし、分かる必要はありません。でも、事業の“課題”は正しく理解していなければなりません。
エンジニアは、顧客の正しい課題を尋ねなければなりません。顧客に「何が欲しいか。」と訊いた瞬間に、事業主管である顧客の組織の課題から、個人の関心にすり替わってしまうから、です。
だから、要件定義で“お伺い”してはいけないのです。顧客に尋ねるのは、お見積りで理解している“顧客の課題”の理解状況です。どういった顧客の課題をどこまで理解しているか、を話すのです。
同じ理解から始めることの意味
これで、スタートの立ち位置を確かめます。それは、エンジニアにとっても大切なことだし、顧客にとっても大事なことです。出会ったばかりでまだ挨拶くらいしかしていないかもしれないですけれど、契約した以上はプロジェクトとして進めなければなりません。でも、だからと言って顧客を置き去りにしたり、ずっと同じ場所にとどまっていてもいけません。
契約は結婚式のようなものです。どちらも事前交渉から始まり、契約書にサインをして契約を履行するのですから。お互いの契約を履行するに当たって相手が何を考えているか、くらいの当たりはつけておきたいたいものです。そうでなければ、たんとする責務を履行するために探り合いをするかお伺いをするか、でしょう。ある有限の期間であるが故、許容できる範囲のリソースで片付けたいと思うのも最もなことです。だから、省略できることは省略してある程度のコンテキストの世界を前提とした活動にしたいのです。
それを得るためのリソースも時間もセレモニーも怠ってしまうから、ギクシャクしたり、そんなことになっているとは思ってもみなかった、みたいなことになるのです。そうした行き違いをなくすためにもこちらが何を理解しているか、何をしようとしているかを場を設けて疎通しなければならないんです。それをして初めて、こちらの側の意思も判別できるようになるし、相手の意思も確認できるわけですから。
だから、
“一番最初のボタンをかけるときには一番手前のボタンから掛けなさい”
と言うのです。一番手前のボタンが一番見えているのですから。でも、一番手前でも掛違うこともあるのに、途中から掛けようとしたりとか、一番遠くから、なんて、間違えたくてやろうとしているようにしか思えないです。そんなのありえないでしょう。
結局、一度でもいいから一番最初だけは、同じ方向をみなさい、ってことです。そのためには、尋ねるのではなく、顧客がなさねばならないことを自分の言葉で理解したまま伝えるのです。
