前々からうわさには聞いていたのですが、Basecampの37Signalsが出している、「Getting Real」を読んでみました。
日本語に翻訳されているおかげで、すらすらよめます。まったく、ありがたい限りです。
Getting Realには、Basecampの37Signalsが考えている、ソフトウェア開発に関するさまざまなノウハウや考え方が記述されています。
耳の痛い内容、目からうろこの内容の宝庫なのですが、まずは、37Signalsのコンセプトでもある、
「シンプルさ」
について書いてみようと思います。
このGetting Realでは、一貫してソフトウェアを「シンプル」に作るよう書かれています。
私も彼らと同じで、インターネットサービスを保守・運用・開発している立場なのでよくわかります。
たとえば、ユーザや営業担当は「機能比較表」を本当に作りたがります。
ユーザは自分自身、正しいサービスを選んだのだと納得したい。
営業担当は、「機能的に多機能だから間違いない」とユーザに勧めたい。
だいたいそういう動機で機能比較表は作成されます。
そして、競合他社のよりもたくさんマルがつくように作成され、自社製品にバツがついている機能は、作るようにリクエストがくるものです。
ですが、一貫して「シンプル」を貫いているGetting Realにはこんなことが書いてあります。
→ムダがないほど変化しやすい
→危険を顧みずにコードを追加し続けてしまうと、気づかないうちに、恐怖の混乱(Big Ball of Mud：アンチパターンのひとつ；ス パゲッティーコード）を作り上げてしまいます。
→同じ土俵の上での優越の話をするのではなく、競合他社がまだ話をしていない、異なった視点からのアプローチが重要
→あなたの作ったアプリケーションを本当に必要としている人は誰かを知り、彼らに喜んでもらえるように。
詳しくは、Getting Realを読んでみることをお勧めします。
「機能競争をしない」こと、「むやみやたらに作らない」ことの大事さが分かると思います。
「猿真似をしない」「皆を喜ばせようとすると、誰も喜ばない」もすごく大事なこと。
でも、実際にこういうことをする本人はそう思っていないケースがほとんどなので、タチが悪いんですけどね。
最後に、Getting Realの「はじめに」に引用されている文章です。
<コラム> すばらしいソフトウェアを作るには…
素 晴らしい文章は無駄がない。文章に不要な言葉が入らず、段落にも不要な文章が無い。同じように、図面も無駄な線を極力なくし、機械にも無駄なパーツをつけ ないものである。これにより、作り手は、詳細を全て短くし、もしくは省いて、骨組みだけの形に仕上げるのではなく、全てを伝えることができるのだ。
—From “The Elements of Style” ウィリアム ストランクJr.
肥大化はもうたくさん
古いやり方：長すぎて、官僚的で、やるべきといわれたことをこなすだけのプロセス
→ありがちな結果：肥大化して、忘れられやすく、考えなしに崩されていくソフトウェア。なんてこった。
「すばらしいソフトウェア」に対するメタファとして「すばらしい文章」を当てはめるのは、とてもいい感じだと思いませんか？
また、安易な機能追加やカスタマイズは、ソフトウェアが「肥大化して崩されていく」ことにつながるということは、是非世の中に知らせたいですね。