「スクラッチから書き直したくなるプログラマは、書き直したプログラムもまたスクラッチから書き直したくなる。」で参照したのがきっかけで、ジョエルテストで有名な Joel on Software を読んだ。
ソフトウェアプロジェクトマネージャー・ソフトウェア開発者必読書の1つだね。
扱っているテーマは幅広くどれも気になる記事ばかり。 ここではメモがてら興味深かった主要な記事をピックアップ。
3分でできるソフトウェアチームの良さを評価する有名なテスト。
仕様書についての章が何章か続く。仕様書について実践的なことが書かれているのでとても参考になる。
サンプル仕様書が用意されている。 何をどのように書くべきかについて参考になる。
そしてなぜ誰も読まないかといえば、仕様書があまりに退屈でつまらないからだ。p.79
これを読んでからできるだけ話を具体的に書くように心掛けている。 適当に外国人の名前をつけてシナリオを書くとなぜか皆喜んだ(同僚も外注も社長も)。
ルール5: テンプレートは有害である p.86
ソフトウェアプロジェクトマネジメントでうまくいかない事が多い筆頭がスケジュール。
「そのコードのスケジュールを立てられるのは、それを書くプログラマだけ」「タスクの粒度を細かくすること (それによって、その機能をデザインすることを強いられる)」「スケジュールにデバッグ・結合・バッファ・休暇・祝日その他のことのための項目を入れる」「決してマネージャにプログラマの見積もりを減らさせない」
あたりが参考になる。なおこの記事は Web でアップデートされている。
開発するソフトウェアの種類によって使える開発方法論が異なるのだから、自分のプロジェクトで適用できるかよく考えること。
抽象化ばかり考えて意味のないところまでいかないこと。
つい最近うちの会社でも表彰式があったばかりなんだけれども……。
マネージャは賞与の提案を上位に送り、それは完全に無視され、ほとんどランダムに賞与が支給される。p.188
多くの人は、自分が非常に良い仕事をしていると思っている (実際はそうでない場合でも)。p.189
一つのプロジェクトに専念したいね。
人々に同時に1つより多くの作業をさせるべきではない。p.202
→ スクラッチから書き直したくなるプログラマは、書き直したプログラムもまたスクラッチから書き直したくなる。
これを理解していないと何でも言うなりにソフトウェア化しようとして失敗する。
多くの人は自分が下っ端だと思ってモンモンとしている。
まずは不満を持つだけでなくて、個人ででも実行しようということ。
[ 読書ノート ] [ お薦めの本 ] [ ソフトウェアプロジェクトマネジメント ] [ マネージャー ]
先週ワークフロー改善内容についてレビューしたところ添付されていた仕様書フォーマットサンプルが Excel 方眼紙だったので、これを機会に止めましょうとお願いしておきました。 そうしたところ今日になってツッコミをいれた人と同じグループの別の人から「なぜ Excel 方眼仕様書だと駄目なのですか?」と質問されました。即答するとなんか適当なことを言ってしまいそうなのであとで回答しますねと答えておきました。
Excel 方眼仕様書をもらった時の嫌だなという感情は「ファイルでの管理だから」「Excel だから」「方眼スプレッドシートだから」など複数の混ざり合った理由からやってきます。
この中で「ファイルでの管理だから」「Excel だから」は環境によっては排除できない場合もあるし、ユースケースにあっている場合もあるので単純に良い悪いとはいえません。
しかしながら「方眼スプレッドシート」で書かれた仕様書というのはいつでも不便なので止めて欲しいです。書かれている文章の部分が論理的な入力になっていないのが一番嫌な点です。1文毎に別のセルに書くとか、字下げは次の列のセルからとか、箇条書き項目ごとに次の行のセルとか。仕様レビューや仕様変更での更新が非常にやりにくい。説明を書き足しにくい。
だからといってシート毎に大きな図形を貼ってその中にテキストを書けば良いといったものでもありません。それこそ方眼にする理由はないでしょう。
Naney (なにい) です。株式会社MIXIで SNS 事業の部長をしています。
※本サイトの内容は個人的見解であり所属組織とは関係ありません。