『受託開発の極意』読了まとめ

なぜ（客に）関心を持てないのか

この解について、

要はお客様と接する機会が少ないために関心が持てないのです。会ってもいない人に関心を持つことはできません。

てなわけで、打ち合わせの役割分担を明確にして、
・責任者（仕切る人）
・書記（記録する人）
・Ｑ＆Ａメンバー
をつくれと言う。

その後の、客ＶＳうちら、でなく、客＋うちらＶＳ問題・課題、にしろ、という話は自ずと導かれるわなと。

仕事の話を客とはしたいけど、飲み会はうんざりだからな。

提案にバリュエーションを持たせ、プラスαを見せろ

このあたりはコンサル交渉術の基礎の基礎ということなのかな。

見積もり

ユースケースポイント法か、ファンクションポイント法か、タスク分解法か。大事なのは、実績データを蓄積することだよね、と。これがまぁ難しいわけで。

システム要件とはなにか

忘れがちだが、
・機能性要件→システムで実現する機能を明らかにする。機能（画面・帳票）やユースケースの一覧は最低必要条件
・信頼性要件→復旧に要する時間など、障害が発生した場合に必要な要件を定義する
・効率性要件→「レスポンスタイムは１秒以内であること」など、システムの性能に関する要件を定義する
・使用性要件→「マウスなしでも利用できること」など、使い勝手における決まりや、デザインのガイドラインなどを定義する
・保守性要件→仕様やシステム環境に変更が生じた場合の、ソフトウェアの修正のしやすさに関する要件を定義する
・移植性要件→たとえば、リリース直後はWindowsで動作させ、その後Linuxでも動作させようとする場合、移植をどの程度の手間で可能とするか定義する

内部設計とか

説明用設計書なんかは、一覧＋図解＋Ｑ＆Ａでいいのかもな。
Excelの場合セル結合スンナという話は激しく同意するし、なるべく一行で、というのもそうなんだろうけどな。難しいけどな。

低レベル設計はテスト駆動で行う。デグレ調査で便利、という話は必要だと思うけどやったことないな。

「設定よりも規約」で保守性を向上させる

XMLの設定ファイル地獄はもろに経験した。むしろURLに埋め込めよと。激しく同意。

保守

やったことないけど、ドキュメント資産やテスト資産、リポジトリ管理資料が大切だというのだが、自分の経験に照らすと、信用できるのはサーバ上に落ちてるソースだけ、という感じだった。はぁ。分からん世界だ。