2000年から2005年くらいに書かれたJoel Spolskyのエッセイをまとめた本、"Joel on Software"をこの年末に読みました。
尊敬する友人である荻野氏がプログラミングを仕事にするうえで一番学びがあった本として、2011年に教えてくれた本だけれど、なんでそのときに買って読まなかったのかと後悔するほど学びがあって、もっと早く知っておきたかったことが書かれていたのでメモと感想を書いておきます。
- 作者:Joel Spolsky
- 発売日: 2005/12/01
- メディア: 単行本
時代背景をさっぴいて読む必要はあるけれど、そのあとの歴史を知っている時代に読むと答え合わせができて楽しかったり次の未来予測に役立つかもしれません。
エクストリームプログラミングや、エリック・レイモンドのThe Art of UNIX Programmingへのコメントはそれらの名著の副読本としても鋭い指摘があるし、いまは意識する人の少なくなった文字コードやメモリ管理などプログラミングの重要なところにも触れられている。そして、プログラミングについてだけではなく、ソフトウェアビジネスの戦略として、のちにフリーミアム戦略や、プロダクトマネジメント、SaaS、カスタマーサクセスなどと名前がつけられた重要な概念のアイデアの核が詰まっている。
ソフトウェアビジネスの知見やプログラマの採用など経営やマーケなどいわゆるビジネスサイドの人が今読んでも得るものありそう。
著者のJoel Spolskyは1990年代、MicrosoftでExcelVBAの開発を仕切ったり、FogBugsというバグトラッカーやのちにTrelloを開発したスタートアップFogCreekを創業したり、9年間ほどStack Overflowという世界で一番開発者の問題を解決している（と思う）サービスのCEOもしていた。さらにプログラマになる前は実戦経験的に世界最強と思っているイスラエルの空挺部隊にもいたらしい。時代的にもてはやされたハッカーとはすこし毛色が違って（なにしろ彼はWindowsアプリケーションの開発を長くしていた）、彼はディベロッパーであって、ヒーロー。
ちなみにだいたい以下のJoelのWebサイトで原文を読めるので英語がわかる人は読みましょう。
はじめに
プログラミングでコンピュータをうまく使うよりも、人間をマネジメントしてソフトウェアをつくっていくことが難しい。 人間のチームをマネジメントしていると、C++のテンプレートさえまったく簡単なものに見えるようになる。
プログラミングも、もちろん難しいんだけれどそれとは質的な難しさが違う。
ソフトウェアプロジェクトのマネジメントというのは、あまりよく知られている技術ではない。誰もソフトウェアプロジェクトマネジメントの学位を持ってないし、このテーマに関する本も多くはない。 ごくわずかの非常に成功したソフトウェアプロジェクトに従事していた人々の多くは、金持ちになり、蓄積された経験を次世代に伝える前に引退してマス養殖場を始め、その他の多くの人々はただ燃え尽き、スラム街の悪ガキだちに英語補修の授業をするというような、もっとストレスの少ない仕事に転職した。
こういうジョークというかJoel節がたくさんあってよい。こういう言い回しできるようになりたい。
ジョエルテストについて
開発チームのクオリティを評価するためのテスト。
Yesの合計が点数。11点以上が健全とのことです。2000年に書かれたもので、いまだと当たり前のものもあるけれど、どうでしょうか。
１．ソース管理してる？
→ 今時していないチームはないと思うので省略。この本の次代はCVSが最先端だった。
２．ワンステップでビルドできる？
→ 同じく。
３．デイリービルドしてる？
→ CIの走りですね。
４．バグデータベースはある？
→ いまどきExcelでしか管理していないチームはないと思う。
５．新しいコードを書く前にバグを直している？
→ 特に、Webアプリと違って頻繁なリリースのできないパッケージタイプではバグを先に直すべき。バス修正にかかる時間は読みにくいけれど、新規機能開発は読みやすいはず。
６．アップデートされているスケジュールがある？
→ 「プログラマがスケジュールを立てたがらないのはよく知られている。彼らはビジネスの連中に向かって、「いつ出来上がるかって？そりゃ、出来上がったときさ！」と怒鳴る」。けれど、もちろんビジネスや他チーム連携のために重要です。
７．仕様書はある？
→ 後述
８．プログラマは静かな環境で作業している？
→ 重要。フローやゾーンと呼ばれる集中した状態は簡単に消されてしまうのでそれを減らすためにも必要。日本の小さな組織だとどうするべきなんだろう？常にいるというより、週何日かだけでも小部屋にいるとかいいのかも。
９．手に入る最高のツールを使っている？
→ ビルド時間を短縮するマシンだったり、ディスプレイだったり。
１０．テスタはいる？
→プログラマ2-3人につき最低でも1人の割合で専任のテスタがいないとバグだらけの製品をリリースするか、時給30ドルのテスタにできることを時給100ドルのプログラマにさせて金を無駄にする、とのこと。自分のチームではここをビジネスサイドの人にやってもらっている・・・
１１．採用面接のときにコードを書かせてる？
→ 最近は当たり前のようになってきていますが、どうでしょうか。
１２．ユーザビリティテストはしている？
→ 廊下で5人くらい捕まえて試してもらうとユーザビリティ上の問題の95%を明らかにできる、とのこと・・・
このテストは、チームの状態をマネージャが把握したり、会社に応募するときや投資するときに目安になったりする、とのこと。
仕様書について
仕様書はデンタルフロスのようなもので、みんな書かなきゃいけないとは思っているけれど、誰も書かない。
アジャイルソフトウェア開発宣言*1では「包括的なドキュメントよりも動くソフトウェアを」と書かれていることもあって、仕様書を軽視するプログラマは多いと思うけれどビジネスサイドと話を積めて安全効率的に開発するにはやっぱり必要。どのレベルのものか、が難しい。
Inspiredなどプロダクトマネジメントあたりでは、紙芝居のように動作する「ハイファイ・プロトタイプ」が仕様書としてよいのでは、とも言われているけれど、Joelの意見はちょっと違う。あまりにもデザインができすぎたものは、ビジネスサイドがほぼできていると勘違いしてしまうからよくないと、、これは、ハイファイ・プロトタイプが効くのはユーザの、利用者の、言葉にしにくいフィードバックが重要な、どちらかというとB2C向けなのかもしれないし、ちゃんと運用できるのはリテラシーの高いプロダクトマネジメントチームがいるときだけなのかもしれない。
必要な理由としては事前にビジネスや他チームと共有するためなのが大きいけれど、ほか気になったところをピックアップする。 まず、プログラマは、時間をかけて書いたコードが、仕様上どんなにまずいコードであっても、それに執着するようになるのでこれを避けるため。はい、心当たりがありますね。 次に、プログラマというのは「正しい答え」ではなくかれらがコードとして書いたことに即して質問に答える傾向があるから。これは自分もやりがちです。
仕様書の中身について、ユーザ観点でどう動くかを記述する「機能仕様書」と内部の実装についての「技術仕様書」があって、Joelのいう仕様書は前者、内容は具体例がおもしろいので読んでほしいけれど、ユースケースのシナリオや対象、簡単なフローチャート、画面が紹介されていて、「カタログ」のようなものだと感じました。あいだに未解決の問題やテクニカルノートが挟まっている。テンプレートは使うべきではない。
そして、仕様書は1人の人間によって書かれ、所有されるべき。重要なのは仕様書がアップデートされてその差分がわかるようになっていること。
そんな仕様書を書いて価値あるソフトウェアをつくっていきたいです。
この、バージョン差分を分かりやすくてだれでも使いやすいドキュメント管理システムはないだろうか・・・
プログラムマネージャについて
プログラムマネージャという、いまプロダクトマネージャーとして知見が積み重ねられているものの前身と思われる役割にも紙幅が割かれている。 プログラムマネージャーはコーディング以外のあらゆることをやり、会社の「ビッグピクチャー」を心に抱いていることが期待され、要求を集めて仕様をつくり、外交 手腕。マーケットに対する意識、ユーザ理解、良いUIデザインをつくる。コーディングへの理解も欠かせない。
重要なのは
・コーダーをプログラムマネージャに昇進させないこと。
・マーケティングの人間をプログラムマネージャにしないこと。
・コーダをプログラムマネージャの監督下におかないこと。
難しいですね・・・正しい資質のある人を採用するなり抜擢する必要がある。
このあたりは、最近2版が出たInspiredを読むのがよいと思う。
INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント
- 作者:マーティ・ケーガン
- 発売日: 2019/11/01
- メディア: 単行本
5つの世界
いろんなひとがさまざまな文脈でソフトウェア開発についての知見を語るけれど、たいていの人はその人の知っているソフトウェア開発を念頭においているので、話を聞くときは、どの世界のことを話しているのか気にしましょう、というはなし。
5つの世界とは、
・パッケージ
・インターナル・・・特定の組織内で使われるもの
・組み込み
・ゲーム
・使い捨て
それぞれ求められる品質や基準が違う。
いまネットで多数の記事があって人々が働いているwebアプリケーションは、多数のブラウザで使われるという点でパッケージの変異として分類されているけれど、今なら独立させてもよさそう。B2CかB2Bかで分けてもいいかもしれない。
ただ、Joelはユーザが1000万人いるかどうかで区別はしていたので、特に自分のような凡百の開発者とは桁が違うことだけご留意を・・・。
使い捨てプログラムはすぐにインターナルソフトウェアへと変化し、さらにMBAがそれを見つけて「これを使って新しいビジネスをスピンオフできるぞ」と言うと、ジャジャーン！ひ弱な「エンタープライズソリューション」を提供するコンサルティングウェア会社が生まれる。
ある・・・
Amazonを目指すのかBen&Jerry's を目指すのか
Ben&Jerrysは東京とかデパ地下とかで売ってる高いアイスクリーム屋。2000年にユニリーバに買収された会社。
スタートアップは急成長を目指すという点でスモールビジネスと違う、と思っていたけれど、その中でもAmazonスタイルともうちょっとゆっくりなBen&Jerry'sモデルがあるのうまく区別できていなかった。
競合がいるかどうかや資本が必要かどうか、ネットワーク効果の有無、損益分岐点の近さ、リスクなどが違うなどなど（それぞれどちらのモデルかはわかるよね）。
ひとつ自分が意識できていなかったのは、Amazonモデルでは企業文化（を維持していくのは）不可能だということ。そして最悪なのはAmazon型の会社にならなければと思いつつお、Ben&Jerry's型のように行動すること。どちらか決め切れているでしょうか。
Joelによれば、MicrosoftはBen&Jerry's型のもっともよいモデルとのことで、Ben&Jerry's型が巨大化しないわけではないけれど、もう時代は違うかもしれない。
その他
アーキテクチャ宇宙飛行士を雇わないこと
アーキテクチャ宇宙飛行士とは、アーキテクチャや抽象的なことがらについて議論するばかりでなにも生み出さない人間のこと、らしい。 類似性を見つけて抽象化をすすめていくの、楽しいけれど、解くのが楽しい問題ではなく、解く価値がある問題を解決したいものです。
デザインというのは、コストを増やすよりも早く価値を追加することができる、漠然とした領域のことをさす。 たしかに漠然とした領域・・・。とか言いようがないのかも。
プログラマの評価について
逆効果になることが多く、するべきではないと書かれている。
評価が高くても、それが生産性につながらず、評価が低い人のモチベーションを下げるだけ、華々しい成果を出していなくとも目立たぬところで重要な役割を担っている人を評価するのが難しい、ということもある。
それは、わかるんだけれど、適切にストレッチさせるためにどうなのかは気になる。なんらかの目標管理的なものは必要なのかどうか、ちょっと悩ましい。
などなど。
Joelのブログはまだまだ続いているので2020年は英語をがんばって読めるようにしていこうと思う。
