[Project][memo]受託開発の極意

「受託開発の極意(岡島幸男[著]　技術評論社)」を読みました。

思ったことをメモ。
でもメモ意味ないかも。
手元に置いてふとしたときに手にとって読む。
自分やチームの仕事の仕方を振り返ってみる。
自分と役割が近い人、仕事で関わることが多い人と読み合わせて語り合ってみる。
それぐらいしたい本でした。
ここであえてふれていないColumnも役立つ情報多かったし！
なので
「購　読　す　る　こ　と　を　オ　ス　ス　メ　し　ま　す」

0章　受託開発を楽しむには
0.2　
「顧客満足の公式」
顧客満足はQCDからなる成果物に対する「結果」と、仕事を進めていく過程にたいする「感情」の両面からなるということ。
私も恩師から「お客さんは感動に対してお金を払う」といわれたことがあるので、この説明はとても納得。
(こまかく話すとちょっと違うんだけどね)

第1部　受託開発の手ほどき
第1章　お客様に関心をもつ
1.1
「7段階にもネストしたif文や～」
ごめん。それオレ(笑)。
正確に言うとExcelの関数でIF文の限界にチャレンジしてた。無知って恐ろしい。
1.2
「要はお客さまと接する機会が少ないため関心が持てないのです。会ってもいない人に関心を持つことはできません」
激しく同意！　ちなみに私はお客さまとお会いしないと仕事できないタイプ。
たまにお客さまの顔見ないで仕事する必要が発生しますが、なんかあってもちゃんと判断できないですよ。
情報が一方的に的になっちゃうから。
1.6
「お客さまの立場でプロジェクトを眺める」
仕事してるとついついこっち都合を優先しちゃったりするのですが、、、いかんですよね。
猛省です。

第2章
「サービスは見積りから始まっている」
スティーブ・マコネルの『ソフトウェア見積り』が引き合いに出されています。
タケも読みました！
マコネル最高ｗ　この本に書かれている見積もりに関する話は非常に奥が深い！

2.2
「お客さまは金額だけで発注先を決めるのではありません。見積もり期間におけるサービスの質も重視しましょう。」
うっすらわかっているようでいてちゃんとわかっていなかったこと。
言い換えると安易な価格勝負すんな！　と。
もし価格勝負をするために意図的にテスト期間を短くして品質を下げるようなことがあるなら、いかんですよね。
システムに関わるもののモラルの問題も含めて、見積もりはしっかりやらないと。
また「プラスα」はいままでまったくできてなかった。スキル不足と時間不足のせいにして。これもなんとかしたいなぁ。
2.4
「見積もり手法を身につける」
「オブジェクト倶楽部」のワークシートが紹介されていました(http://www.objectclub.jp/download/)。
今度、試してみよう♪
タケはそんなに見積もり手法を勉強した訳じゃないですけど、いろいろな手法を知ったり勉強したりすると見積もりに対する考え方に厚みがでる気がします。
日々勉強ですな。

第3章
3.1
「実質、要件は変わったのではなく、間違って定義されてしまっていることが多いのです。」
そうっすよね！
あとプロジェクトがキックオフするときに営業から開発へ情報伝達が上手く言ってない場合！
これもある意味、間違った要件定義。
話変わりますけど、RIA開発に関わっていると「デザイナとデベロッパの協業」についてよく議題にあがりますが、それ以上に営業と技術者の協業の方が問題な気がします。
炎上する原因てだいたいそれだよね。
3.2
手段ばかりに着目するのではなく何を何故作るのか！?　を考えなさいと。なんかもう御礼言いたいです。
3.4
「表3-1　システム要件で定義する内容」
これもきっちり認識する必要あり。
3.7
「丸投げドキュメントの読み方」
これは丸投げドキュメントに限らない気がするのですが、それってタケがいつも丸投げされている証拠？

第4章　保守性にこだわった設計・実装・テスト
4.4
単体テストが重要だというのは重々承知していたつもりですが、サンプルとして数値でだされるとその重要さをより認識することができます。
4.5
テスト計画の重要性、各フェーズで何を気をつけるべきかが書いてあります。品質をどこまで保証する、つまりどれくらいテストをしっかりやるか、どういった分担で行うのか、どういったアプローチをとるのかはプロジェクトを始める前にしっかり決めておかないといけないはずです。
またテストは私の知る限りでは必ずと言っていいほどクリティカルパスになります。
テストちょー重要！

第5章　運用が最上流
5.2
「お客さまとの信頼関係も保守する」
なんて良いことを言うんだろう。。。
5.3
「テスト資産を活かす」
なんだかんだ言って、同じテストを何度も何度もやることになることがあります。
そう考えたらテスト計画やテスト仕様書、結果はしっかり書かなきゃいけないし、ツールを使って自動化できるんだったらやっておいた方がいいかもしれません。

第6章　計画とスケジュールの管理
「計画がないプロジェクトはありえませんし、計画が頻繁に変わるからといって、まったく無秩序ではいけません。計画は管理・メンテナンスするものです。」
私の作るMSPがプロジェクト開始2週間でぐっちゃぐちゃになるのはMSPがダメなツールだからではなくて、プロジェクトの計画と実行と管理というのはそんなもんだからです。全然変わらない場合は「わーい♪」と喜んでないで潜在リスクがないか考えないと。
6.1
「3つのスケジュールを使い分ける」
これは目から鱗。。。
プロジェクトを進めていく内にだんだんブレイクダウンしていくことはありますが、明確に3つに分ける(違うものだと認識する)のは考えてなかった。。。
きっと当たり前なんだろうな。自分の無知がおそろすぃ。
6.3
「見積もりが外れる原因と対策」
私は個人的には下記のように考えています。ちなみにKKD法(笑)ね。
・経験
　→タスク洗い出し、アプリーチやプロセスの選択、プロジェクト基盤作成に必要なことや技術知識などなど。
・勘
　→潜在するリスクをあげること。ここは○○日じゃないだろう…とか、ここで詰まるだろう…とか。
・度胸
　→工数を「削る」のは度胸！　ここは○○日もいらないだろう…とか。超安全見積もりで仕事がとれるほど世の中そんなに甘くない！
　6.5
「プレッシャーを感じたままスケジュールや計画を立てると、手段の目的化が起きます。」
私はプロジェクトの計画を立てるのと見積もりを書くのは限りなく近い作業であると認識しているので、それを前提に話すと、見積もりを書くときに入ってくる情報が「参考値」なのか「制約条件」なのかはちゃんと切り分ける必要があります。
特に予算はね。書こうと思えば書けるんですよ。予算内で。やべーな、と思ってても。。。
ましてや見積もりを書く人間より、その情報をもってくる人が年長者だったり経験が豊富だったり組織内で権力もってたりすると、余計にやっかいです。そういうもんだって思っちゃうからね。

第7章　チームで成功を目指す
7.3
「表7-1　リーダーのカラー別の特徴」
これわ。。。「ボケボケ」型ってないんですか？　タケはボケボケ型だと思います。
7.4
「お客さまに対する陰口を止めてみる」
コラッ！
7.5
「交渉力」
勝ち過ぎない、っていうのはわりと意識してやってますね。
でもそれでつけ込まれて不利になることが多い気もします。。。さじ加減が難しい。

第2部　人と組織を変えること
8.5
「問題なのは相対評価を気にするあまり自信をなくし、自分が何を目指したいのかわからなくなってしまうことです。」
うーむ。確かにわからなくなっている気がしますなー
Column
「アムロとブライトさんのセリフ」
岡島さんとは美味い酒がのめそう(笑)。
タケはもう子供がいて30歳にもなったので「若さ故の過ちか…」と言えない感じです。