nDiki : Joel on Software

Joel Spolsky 氏による、ソフトウェアプロジェクトマネジメント/ソフトウェア開発にまつわる諸問題についてを書いた Web サイトおよび書籍。

ジョエルテストが有名。

ソフトウェアプロジェクトマネージャ、ソフトウェア開発者必読書。

• Joen on Software

開発 仕様書の書き方 ノート 開発環境 ポイント 習慣 デザイン 東京 行列 ITS 機能仕様書 ソースコード 生産 目標 見積もり お薦めの本 駐車場 IVR 展示会 東京ビッグサイト 社長 リスク Google ドキュメント 自動車 リファクタリング デバッグ リグレッションテスト Web Google アカウント コラボレーション

■ スクラッチから書き直したくなるプログラマは、書き直したプログラムもまたスクラッチから書き直したくなる。

自分がプログラムをスクラッチから書き直したいと思った時、またスクラッチから書き直したいと言われた時のためにまとめておこう。

@ スクラッチから書き直したい理由

スクラッチから書き直したいと思う理由はだいたいこうだ。

• もっと良くできると思うから
  • 「もっと良いやり方がある」「自分ならもっとうまく書ける」
  • 「統一されていない」「もっと汎用的にできる」
  • 「今なら新しい開発環境(・新しい実行環境・新しいライブラリ・新しい言語)を使って簡単によりいいものが素早く作れる」
• よくわからないいから
  • 「何をやっているかわからない」「どう直していいかわからない」
  • 「もう直しようがない」
  • 「作り直した方がはやい」
• あいつのだから
  • 「あいつが書いたコードだから」

どんなプログラムでも開発が進み詳細がわかってくると、こうしておけば良かったと思う点がでてくるものだ。

さらに、他人が書いたプログラムだとよく分からない。

It's harder to read code than to write it. (プログラムというのは書くより読むほうが難しい。) -- Things You Should Never Do, Part I - Joel on Software

いっそ作り直してしまいたいと思うのはどの開発者でもあることだ。

@ スクラッチから書き直してはいけない理由

しかし多くの場合スクラッチから書き直すことはリスクとデメリットだらけだ。

• 今までの投資を失うから
  • 「そのプログラムには検討・不具合修正に膨大なエネルギーが投入されている」
  • 「ユーザは今のプログラムのために学習コストをかけている」
• 時間がかかるから
  • 「その新しいプログラムが今と同じレベルの価値を実現するまでは時間がかかりすぎる」
  • 「スクラッチし直してから投入したのでは、もはや価値を失っている可能性が高い」
• 前轍を踏むから
  • 「どう直していいかわからないと思う時は往々にして目標がわかっていない。目標がわからずに作ったものは結局またスクラッチから書き直したくなる」
  • 「あなたが連続的にプログラムを修正できないというのなら、どちらにせよ新しく作り直したプログラムもあなたは連続的にプログラムを修正できない」(リグレッションテストの習慣はあるの? リファクタリングスキルはあるの?)

ほとんどの場合は、漸進的に今のプログラムを修正・改良していった方が得策なのだ。

@ スクラッチから書き直してもいい場合

そうはいってももちろんスクラッチから書き直した方が合理的な場合もある(書き直してはいけない場合も書き直した方が合理的だと思ってしまうわけではあるが)。

それは次のような場合だろう。

• ソースコードがない場合 (ディスククラッシュした。利用する権利がなくなった)。
• もはや開発環境も実行環境も手に入らず、移植も困難な場合。
• 個人的な趣味のプログラムの場合。
• スクラッチから書き直したプログラムに対して、また「スクラッチから書き直したい」という欲求にかられない自信がある場合。

本当にスクラッチから書き直した方がよい場合は止める理由はない。

さてこの記事をスクラッチから書き直したいと思う時がきませんように。

@ 参考

• Joel on Software
  • Things You Should Never Do, Part I - Joel on Software
• はじめからやり直したい症候群
• 最上の日々 - なぜ最初から作り直したくなるのか
• [を] アホでマヌケな米国(アメリカ)ハイテク企業

[ ソフトウェアプロジェクトマネジメント ]

• Joel on Software - 必読書 (2008-08-14)
• ナノパーセント日 (2005-10-26)
• 今日のさえずり - 納豆にオリーブオイル+胡椒 (2008-08-02)
• 個人目標設定における課題 (2006-02-06)
• Module::Build でソースパッケージング (2005-08-24)

■ 今日のさえずり - 遊びに行くのか展示会のコンパニオンなのか区別がつかない

@ 2008年06月19日

• 11:26 スクラッチから書き直してはいけない理由を開発メンバの1人に説いた。 http://tinyurl.com/62qc7v
• 19:01 Joel on Software 買った。[mb]

@ 2008年06月21日

• 09:06 2008自動車部品生産システム展に向かっている。[mb]
• 09:15 りんかい線に乗っている派手めの女が、遊びに行くのか展示会のコンパニオンなのか区別がつかない。[mb]
• 09:33 東京ビッグサイトの駐車場、もう満車になってる。[mb]
• 11:02 [photo] Apollo13 http://tinyurl.com/6dbet3
• 11:46 弁当買って昼食中。DMS/IVR の時入出力比べて空いてるな。[mb]
• 12:14 東京おもちゃショー2008長い列なので、ケーブルテレビショーで手を打つべき。[mb]
• 12:32 [photo] 12:00 現在東京おもちゃショー2008 大行列 http://tinyurl.com/6am4s6
• 12:32 [photo] 東京おもちゃショー2008外まで行列 http://tinyurl.com/5kmgwd
• 13:17 自動車部品生産システム展、子連れ多すぎ。[mb]
• 15:08 水着のオネーチャンがいるというので、ケーブルテレビショーへ。[mb]
• 15:18 ケーブルテレビショーの中にあるアダルトゾーンが気になる。[mb]

• 2008自動車部品生産システム展 (2008-06-21)
• 今日のさえずり - 港区出身者とはニコニコ学園ネタで盛りあがる (2008-06-24)
• 今日のさえずり - 調整中って故障中だろ? (2008-06-27)
• 今日のさえずり - ささやかな気持ちDES (2008-11-07)
• エスカレータ (2004-01-26)

■ 社内で Google ドキュメントがブレイクし始めた

今年の春ごろから開発資料やミーティング資料などを Google ドキュメント上で作成して、適宜関係者に共有するようにしてみた。

当初はほとんど自分がオーナーのものばかりだったんだけれど

• Google アカウント作成が行き渡ってきた。
• あるソフトウェアの BTS がうまくまわっていなかったので、不具合リストを Google ドキュメントのスプレッドシートで作ってリリース前に集中的に共有してバグ潰しをした。この一件で便利さが伝わった。

あたりで利用するようになったのではと推測。

特にリスト系はスプレッドシートでコラボレーション(共同編集)できるのがやはり魅力的なんだと思う。 同時にアクセスしている人が表示され変更もリアルタイムに見えるためライブ感があり、「一緒にやっている」という感覚が味わえるのがポイントだ。

ちなみに Excel も共有ブック設定することで同時に編集できる(Joel on Software でもこの機能を「Excel についてあなたが知っておくべきこと」の1番目として紹介している)。

BTS/ITS は専用のシステムを使った方が tracking その他の点で機能的にはよいのだが、億劫で設置自体がなかなかされなかったり、使い方を覚える(思い出す)のが面倒で敬遠されるということも多い。

小規模なら共同編集可能なスプレッドシートでシンプルに運用するのもアリだと思う。 っていうか、シンプルでいいから最低限のことはやっておかないと。

• 今日のさえずり - 首なし犬 (2008-03-26)
• ソフトウェアかんばん「見えない化」 (2006-04-10)
• 自分が個人で開発したフリーソフトウェアを自社製品に組み込むとき (2005-05-16)
• 影舞プロジェクトテンプレートを作っておく (2005-05-26)
• Joel on Software - 必読書 (2008-08-14)

■ Joel on Software - 必読書

「スクラッチから書き直したくなるプログラマは、書き直したプログラムもまたスクラッチから書き直したくなる。」で参照したのがきっかけで、ジョエルテストで有名な Joel on Software を読んだ。

• Joen on Software

ソフトウェアプロジェクトマネージャ・ソフトウェア開発者必読書の1つだね。

扱っているテーマは幅広くどれも気になる記事ばかり。 ここではメモがてら興味深かった主要な記事をピックアップ。

@ 3章 ジョエルテスト

3分でできるソフトウェアチームの良さを評価する有名なテスト。

@ 5章 やさしい機能仕様 パート1: なぜわざわざ書く必要があるのか?

仕様書の最も重要な役割はプログラムをデザインすることだ。p.51

仕様書についての章が何章か続く。仕様書について実践的なことが書かれているのでとても参考になる。

@ 6章 やさしい機能仕様 パート2: 仕様書とはどんなものか?

サンプル仕様書が用意されている。 何をどのように書くべきかについて参考になる。

@ 8章 やさしい機能仕様 パート4: ヒント

そしてなぜ誰も読まないかといえば、仕様書があまりに退屈でつまらないからだ。p.79

これを読んでからできるだけ話を具体的に書くように心掛けている。 適当に外国人の名前をつけてシナリオを書くとなぜか皆喜んだ(同僚も外注も社長も)。

ルール5: テンプレートは有害である p.86

@ 9章 やさしいソフトウェアスケジュール

ソフトウェアプロジェクトマネジメントでうまくいかない事が多い筆頭がスケジュール。

「そのコードのスケジュールを立てられるのは、それを書くプログラマだけ」「タスクの粒度を細かくすること (それによって、その機能をデザインすることを強いられる)」「スケジュールにデバッグ・結合・バッファ・休暇・祝日その他のことのための項目を入れる」「決してマネージャにプログラマの見積もりを減らさせない」

あたりが参考になる。なおこの記事は Web でアップデートされている。

@ 12章 5つの世界

開発するソフトウェアの種類によって使える開発方法論が異なるのだから、自分のプロジェクトで適用できるかよく考えること。

@ 14章 アーキテクチャ宇宙飛行士たちに脅かされるな

抽象化ばかり考えて意味のないところまでいかないこと。

@ 21章 報奨金有害論

つい最近うちの会社でも表彰式があったばかりなんだけれども……。

マネージャは賞与の提案を上位に送り、それは完全に無視され、ほとんどランダムに賞与が支給される。p.188

多くの人は、自分が非常に良い仕事をしていると思っている (実際はそうでない場合でも)。p.189

@ 23章 人のタスク切り替えは有害であると考えられる

一つのプロジェクトに専念したいね。

人々に同時に1つより多くの作業をさせるべきではない。p.202

@ 24章 あなたが絶対すべきでないこと PART I

→ スクラッチから書き直したくなるプログラマは、書き直したプログラムもまたスクラッチから書き直したくなる。

@ 25章 氷山の秘密、明らかに

顧客は自分が何が欲しいか分かっていない。顧客が自分で何が欲しいか分かっていると期待するのはやめることだ。p.210

これを理解していないと何でも言うなりにソフトウェア化しようとして失敗する。

@ 31章 下っ端でも何かを成し遂げる方法

多くの人は自分が下っ端だと思ってモンモンとしている。

• 戦略1 実行あるのみ
• 戦略2 じわじわ広めていく
• 戦略3 優れた人間を作り出す
• 戦略4 間抜けを無力化する
• 戦略5 邪魔を避ける
• 戦略6 かげがえのない存在になる

まずは不満を持つだけでなくて、個人ででも実行しようということ。

[ 書評 ] [ お薦めの本 ] [ ソフトウェアプロジェクトマネジメント ]

• ソフトウエア開発 55の真実と10のウソ読了 (2004-06-08)
• ソフトウェアかんばん (2005-10-28)
• 仕事のヒント (2005-11-26)
• ソフト契約と見積りの基本がよ～くわかる本 (2005-10-14)
• ナノパーセント日 (2005-10-26)