はじめに：『Joel on Software』とその著者について
こんにちは、readline.fmです。 readline.fmは、つんどくが趣味の2人が、何かの本を読んだ感想を雑談するポッドラストです。
ハッシュタグは、ハッシュリードラインFMです。 Mixi2にreadline.fmのコミュニティもありますので、そちらでワイワイ、感想お待ちしております。
ホスト役は、げんえいさんときんじょうです。 それではげんえいさん、よろしくお願いします。
よろしくお願いします。
はい、というわけで、また21世紀の本ですね。
そうですね。
初ですね、この著者。
そうですね、今回が初ですね、この著者は。多分このポッドキャストの中でも、一度も名前を出してないんじゃないかな。
出てないかな。出てるかもしれん、出てないかもしれんって感じるぐらいには、なんていうか、近しい本ですね、いつもと。
我々が今まで読んできた人たちの名前もめちゃくちゃ厳重されてる気がする。
というわけで、ジョエルオンソフトウェアという本ですね。
はい、今回はジョエルスポルスキーのジョエルオンソフトウェアですね。
オウム社出版。
なんかすごい、なんていうか、親近感があるというか、知ってる出版社って感じだな。
なんか古い本読んでると、なんか全然、最近聞かない出版社の名前だったり、なくなっちゃってたりするのもあったりするんで、なんかすごい最近だなっていう気持ちになりますね。
そうですね。これしかもあれですね、思ったより翻訳というか日本語版が出たのも早かったんですね。あんまりラグがないというか。
もともとが2004年で、日本語版が出たのが2005年で、実際のエッセイが、これもともとジョエルオンソフトウェアっていうサイトで書いてたエッセイを本にしましたってやつで、
そのエッセイも書いたのは2000年から2004年っていうふうにどっかに記載があったんで、割と日本で読むにしても、そんなにラグがない中で読めてるはずっていう感じでしたね。
割と出てくる話が、なんか開発とか仕事の現場みたいなのは、当事者として体験してるわけじゃないけど、世間話としては全然知ってる時代感だなみたいな。
というのと、あれじゃないですか。我々的にありがたいのが、役者序文で年表がついてるという。
面白いですよね。役者序文でまさかのジョエル・スポルスキーとIT業界の動きみたいなものの年表が載ってて、1981年から載ってるんですけど、
なるほど、だいたいこういう時代背景感なんだねっていうのが、分かるような分からないような。
分かるような分からないような。年表を見ててExcel 4.0、Excel 5.0とか書いてあって、なんでこんな日なこと書いてあるのと思ったら、めちゃくちゃ重要でしたね、Excelの話超出てくるという。
特定のエッセイでやったら出てくるゾーンがありましたよね。
そうですね。この著者についてちょっとだけ触れておくと、Excelを作ってた人なんですよね。
そうですね。
なのでExcelにはすごい詳しいというところで、Excel作ってた時の話だったりとかで、いろいろ喋っているというのがあって、
あとちょっと面白かったのが、Excel作ってた人なんだなと思って、その後どんなことやってたのかなとかって見ていると、
多分皆さん知っているタスク管理ツールトレロとか、一番有名なのはスタックオーバーフローを共同創業した人だそうです。
そうなの?知らなかった。
しかもスタックオーバーフローのCEOを2010年から2019年までやってたそうです。
すごい。えー。なるほど。なんか急に、なんていうんだ。
いや、あれじゃないですか。デマルコとかワインバーグの仕事面での話っていまいちピンとこなかったりするじゃないですか。
IBMで何かやってたんですねみたいな。急に知ってるサービスだみたいな感がすごい湧いてくる。
この本が出た当時、もちろんトレロとかスタックオーバーフローを作る前なんで、Excelの話がいっぱい書いてあって、
マイクロソフトにいた人なんだなとかって思うんですけど、一気にトレロとかスタックオーバーフローって言われると本当に親近感が湧くというか、
この人ちゃんと遠い過去にいるすごいプログラマーっていうか、全然現代のすごいプログラマーやんけみたいな。
なんならビジネスCEOまで勤めるんかすごいなみたいな気持ちになりましたね。
ウィキペディア見てもスタックオーバーフローの項目の設立者にジョエル・スポルスキーって書いてあります。
まあそれ書いてあるんですけど。この本、ビジネスっぽい話もすごい多かったですね。
そうですね。扱ってるのが最初はプログラマーのための本というかプログラマーのエッセイなんで、
こんなひどいことがあったんだぜとか、こんな作業してると割り込みがあってつらいぜみたいな話とか多いのかなと思ったら、
結構採用の話だったりとか、ビジネスの話だったりとか、もちろんプログラミングの話も出てくるし、
結構いろんな視点で視野で物を見ている人なんだなっていうのがすごいわかるような感じで、結構扱ってる話題も多いですね。
ジョエルテスト：良い開発プラクティスを測る12の質問
あの帯とか見ると、ゲイさん本の帯ありました?
ありました。
マネジメントの世界へようこそって書いてあるんですよね。
僕は割とマネジメントより、いわゆる大好きな行動各仕事から離れ行く皆さんへみたいな感じの話なのかなって最初想像してたんですよ。
で、だからマネジメントとか、ソフトスキルよりのチャリアっぽい話、どうやってサバイブしていくかみたいな話を中心に取り扱ってる本なのかなって印象を先にじて思ってたんですけど、なんか全然ですね、めちゃくちゃいろいろ書いてる。
本当にエッセイだなっていう、別に体系的に何かを書こうと思ったっていうよりは、考えてたことをいろいろサイトに載っけていて、それを出版するにあたってまとめたっていう感じでしたね。
技術者採用についての話は、この人それだけで一冊本出してたりがするので、そこら辺の話は得意というか十分扱えるんだなっていう印象はあったんですけど、
いやー、なんかパート5は古くか、4部立てになってて、すごいですよね。そこの見るだけでもなかなか、一体何の本なんだという感じがするというか。
パート1がプログラミングのプラクティスで、パート2が開発者のマネジメントで、パート3がそれほどランダムでもないトピックに関するランダムな考察っていう何でもありなパートがあって、第4、パート4がドットネットについての少し行き過ぎた論評っていう。
なんかいろいろ思うことがあったんだな、わざわざここに載っけるってことだと思いながら。
これ本を作るときにエッセイ選んでるってことですもんね。これも載せましょうって言って。
そうそうそう。
なんか言いたいんだろうなーみたいな。っていうような感じですけど、まあ本編入ってきますか。
そうですね、そうですね。
で、ページ数が思ったよりというか多い感じはするので、300、まあ付録まで入れると370兆やるのかな。
そうですね。
なので、なんか全部舐めるというわけにはいかないんですけど、まあ頭の方から気になったエッセイというか、記事というか、読んでいきますか。
読んでいきましょう。
どこらへんからいきますかね、最初。まあパート1のさっき言った通り、ここがプログラミングのプラクティスというところですが。
やっぱジョエルテストじゃないですか。
第三章、ジョエルテスト。
ジョエルテストっていうものは何かっていうと、良いプログラムへの12ステップっていうので、自分たちの現場が今どういうプラクティスをやっているか、このジョエルが考える良いプラクティスみたいなものをちゃんとやってるっていうことをテストする、
計るための12個の質問があるんだよっていうのをやっていて、これはちょっと面白かったですねっていうので、12個紹介すると、
1個目がソース管理してる、2個目がワンステップでビルドできる、3番目がデイリービルドしてる、4番目がバグデータベースはある、5番目が新しいコードを書く前にバグを直している、
6番目がアップデートされているスケジュールがある、7は使用書はある、8がプログラマーは静かな環境で作業している、9が手に入る最高のツールを使っている、
10がテスターはいる、11が採用面接の時にコードを書かせてる、最後12番がユーザビリティテストはしてるっていうふうな質問ですね。
こう見るともう現代では当たり前だよねみたいな感覚のものもあるし、言うてでもまだ本当にできてるって聞かれると、うんってやつとかもありそうだなとか思って、
意外と現代までこのテストは通じてるかもしれないなっていう思うところもありましたね。
そうですね、この本あれなんですよね、エントリーが書かれた日付が各章ごとに入っていて、
JOELテストでいうと2000年8月9日ってなってるんで、散々擦ってますけど、ちょうどアジャイルマニフェストが出てきたりする、
軽量開発プロセスがどんどん広がっていこうとしてるぐらいのタイミングにはなりますよね。
そうですね。
そうすると、デイリービルドしてるとか、バグデータベースはあるとか、そこら辺の感覚が今とは少し変わってきてるかもしれない。
ビルドしたりとか、デイリービルドとか、ソース管理とかって当たり前になってるのはなってると思うんですけど、
Git以外のものを使うっていうのはあんまり現代においてなくなっちゃったかもしれないけど、
デイリービルドとかの仕組みを、働いてる現場では誰かが既に作ってくれてて、ただそれに乗っかって開発しますよってことはたぶんいっぱいあると思うので、
ちゃんと構築できるとか、率先してそれをやるぞとかって、後回しにせずちゃんとやるとかっていうことがみんなどれぐらいできるかなとかっていうのは、
結構若い人とかだともしかしたら、会社にそういう仕組みが入ってたんで、これが当たり前だと思ってますっていう感じだったりするだろうし、
その辺とかちょっと考えると面白いかもなーとか、
あとワンステップでビルドできるみたいなところも、ある種ちゃんと手順書を書いて、それをどう実動化するかとか、
メイクコマンドにまとめるとか、そういうちょっとした工夫みたいなこととかをいろいろやるとかっていうのは、
やれと言われるともしかしたらあれこれどうやるんだっけみたいなこととかは出てくるかもなーとか思ったりしましたね。
ワンステップでビルドできるは、そもそもあれですけどね、僕たち二人で言うとあんまりビルドをするような言語じゃないので、またちょっと違うんですけど、
例えば新しく、今やっているプロジェクトに新しい人が入ってきて、じゃあ環境を構築しましょうって言ったときに、
本当にワンクリックとかワンコマンドでしっかりローカル環境立ち上がるかなっていうとこまでできてますかっていうと、
意外と怪しかったりしますもんね。環境構築自体はそんなに毎日何回もやるわけじゃないから、
どこまでコストかけるんだっけって話はあるんですけど、必ずみんなが踏む時代が除去されてないみたいな。
それは先にこっちのレポジトリクローンしてからじゃないと動かない必要とかっていうのを放置されてませんかっていうと、
ちょっと今どうなってるかなみたいなのありますよね。
そうそう。しかも周りの人がやってくれるとね、どんどんやり方を忘れていくっていうのもあったりするし。
やり方を忘れるし、自分ができるようになっちゃうというか、自分の環境ではもう動けますってなっちゃうと。
なんかそんなにモチベーション上がらないからいっかみたいな。
わかる、わかる。
っていうのと、あれですよね、ジョエルテストの最初の1から5番ぐらいが結構開発者の生活習慣というか、
態度みたいな話になってて、その後6番、7番であれじゃないですか、
プロダクトっぽい話とかプロジェクトマネジメントっぽい話にちゃんと入ってくるっていうのも、
なんかこれが1個特徴あるなっていう気がしましたね。
そうですね。しかもどんどん後ろの方に行くにつれて採用の話が出てきたりとか、
手に入る最高のツール使ってるっていうのは、無料で使えるものとかの範囲はいいかもしれないけども、
お金を払わないといけないようなツールとかになってくると、
じゃあどうやってマネージャーが決済を通すのかとか、
そういうふうなマネージメントの方向にも行くよなっていう気は見ながらしてましたね。
広いですね。手に入る最高のツールを使っているっていう9番目の項目見てみると、
コンパイルにかかるのがたとえ15秒であっても、プログラマーはコンパイル中に退屈してザ・オニオンを見始めてみたいな。
みんなプッシュして試合走ったらツイッター見てる可能性あるからね。
15秒あるから他のことやろうって思えるぐらいのいいスペックのパソコンを提供されている。
いやでも違うから別に仕事用のマシンでとは言ってないか。
そうですね。確かに。
ザ・オニオンってサイト僕は知らなかったんですけど。
いや自分も知らなかったですね。今で言う勝手にredditとかそういう感じなのかなと思って読み替えてましたけど。
アメリカンズファインストーニュースソースって書いてあるんで、ヤフトピーじゃないですか?2000年の日本で言うと。
確かに。
いいですね。ちょうど開いたらトレンディングでNBAの話してる。確かに見るなこれは。
社内でもNBAの話聞いたからな。盛り上がってるっぽいんだよな。
オールスターが近いんですよね。オールスターが盛り上がってるかどうか毎年諸説あるんですけど。
あと河森由紀がすごい頑張ってるんで。それはいい話で。
ジョエルテストなんか他の項目どうでした?
プログラマー静かな環境で作業しているとかっていうのを見て、ピープルウェアの話だなと思いながらめくったらピープルウェアの話がちょうど出て。
そう、ピープルウェアちらほら厳重されてる。
2000年当時のオフィスと今のオフィスって全然違うよなっていうのが何となく漠然と頭の中には思ってて。
そしてみんなオフィスに金をかけるようになったよなっていうのと、一方でリモートワークになった結果集中しやすい環境が。
これは多分住んでる家に寄ってとか家族構成とかによって変わっちゃうかもしれないですけど。
少なくとも一人の部屋が取れるような人は集中して好きな道具を置いて作業ができるようになった時代だよなとかって思うと、
だいぶ状況が変わってきてるけど、落ち着いた場所で生産性、パフォーマンスが出せるような環境を用意するっていうのは今でも変わらないしずっと求められるよなっていうのをちょっと思ったりしてましたね。
そうですね。アメリカと日本の違いもあるんですかね。
集中力を害するほどけたたましいオフィスそんなにあったんですかねっていう気がしちゃうけど。
そこは個人差ももちろんあるんでしょうけど、別に同じフロアで営業の人が電話かけてますとかでも普通にやってたしなーとか思いながら。
でなんかこう、今もう言われないかもしれないけど一昔前だったの職場でイヤホンokみたいなのが、なんかその求人のところの働き方みたいなところに書いてあったことが昔あったなって今ちょっと思い出しましたけど。
確かにな。僕働いてたところはいつもokだったから。なんかあれなんですよね。かじめんでも面接でもそれ聞いていいのかどうか微妙な感じなんですよね。聞いて悪いことはないんでしょうけど。聞いて悪いことはないけどいやあんまりそうでもないですねって言われたら自分入らなそうなのみたいな気がしちゃう。
なんか今思うとあれは何だったんだろうかって思うけど、まあでも確かにそういうのがイヤホンができないってなったらまあ確かにちょっとゾーンに入りにくいとか集中しにくいみたいな。
隣でこれ不具合かもとかなんか、え?え?え?とかって言われたら確かにちょっと作業しにくいっていうのはあるかもしれないな。
あとあれですよね。うるさいよりもため息とか拾っていくこと多い人も気になっちゃうな。
とか喧嘩してるとかね。
喧嘩は気になりますね。喧嘩してる人いたな前。今の会社とか全職じゃないですけどね。ずっと前の話ですけど。やっとるなやっとるなと思って。
だんだんね、いつもの光景だなみたいなことが起きると、普通にそのまま放置されて、新しい帰ってきた人たちがこれ大丈夫なのかなみたいなすごい不安な顔をするっていう光景とか。
これ架空の話ですけど、まあそういう光景をちょっと思い浮かべましたね。
あとなんかチームの外から見るとすごいちょっと論争っぽい感じ、感じられますみたいなフィードバックがあるな。プログラム開発チームちょっと喧嘩してないみたいな言われましたよって。ちょっと気をつけましょうねって言われたことがある。
当人たちは別に喧嘩してるわけじゃないけど、周りが不安になってるっていうのは。
そういうのを含め静かな環境というか集中できる環境で作業しているのかっていう話なのかな。
難しいですね。出社した方が話しやすいよねとか、自分は割と人と話しながら仕事するのすごい好きだから、それはそれでいいけど、やっぱり集中したい。
ブロックされたくない人に声かけられて、ちょっと作業が止まっちゃうの嫌なんだよなって思う人は、リモートワークの方がやりやすいとかなるのかなとか、ちょっといろいろ時代的なところも含め考えちゃいますね。
周りに集中して個人作業をしてる人が大半を占めてるオフィスとかが喜ばれやすいのかな。
人それぞれですね。人それぞれだし、どんな仕事今やってるタスクなんですかって話もあるし、あと体調とか機嫌とかにもよると思うので一概に言えないけど。
ジャイルテストとか類似の本で同じようなこと言ってる時に言われるのは、ゾーンにいかにゾーンとかフロー状態入れるかっていうのが大事だし、それを妨害されてなるものかみたいな話が主題ですかね、ここらへんは。
集中できる環境とフロー状態：現代の開発現場における課題
そうですね。
そうだよな、こっちはクソうるせえ老人性がいる予備校の自習室で生き抜いてきたんやみたいな気持ちがあるからな。
ちょっとそれに関連してもうちょいその話深掘りというか、ちょっと聞いてみたいなと思うんですけど、どっかにも同じような話がフローに入るって話があって、でもだんだん近所さんとか自分とか経験レンスをたまっていくと人に頼られることも多かったりすると思うんで。
でも僕は今最ジュニアなんで。
じゃあ今の現場より前の現場でちょっと考えてもらっていいんですけど、結局作業フローに入りたいと思っても、それが許されない環境みたいな場合もあるじゃないですか。
例えばマネージャーになったらいろんな人と話をしないといけないとか。
そうですね。
ちょっとこれで困ってるんですけどみたいなことが突然飛んでくるとか。
テックリードとかだとしてもやっぱり設計も相談ちょっとしたいんですけどとか、ちょっとこのコードレビューのところいろいろ話したいんですけどみたいなことがいろいろ積み重なって、
フロー状態に入るっていうことがいいのはわかるが、しかし現実的にそれができるのか。
そしてじゃあ入れないんだったら入れないなりの工夫の仕事の仕方をしたほうがいいのではみたいなことをちょっといろいろ考えたりするんですけど、
近所さんってその辺どんなふうに考えてますみたいなちょっと聞いてみたいなと思いました。
でもボブおじさんがプログラマーがフローに入ってる状態で書いたコードはクソでしょ、泣かないからやめろって言ってましたからね。
なるほど。
原文がほぼそのぐらいのトーンで言ってたから、クリーンクラフトマンシップ呼んでいただいて。
後ろにアナウンスがかかるよって。
全職僕そもそもマネージャーだったのでコードを書いてないし、テックリーバーの時にチームでみんなで開発やろうねー的な結構ゴリゴリ自分がやってるチームにいたことはありますけど、
自分がそのチームにいたときは自分がコードを書くっていうよりかはみんなでスウォーミング、モブプロじゃないですけど普通に話しながらやるみたいなプラクティスを割と実験的に取り入れてたりしてた時代だったりもしたし、
マネージャーになってからは人と喋ってるしてなんだ、僕のところに相談に来るときって別に今目の前のコードどうしようって相談来なかったんですよ、マネージャーの時に。
なるほど。 それがチームの人でどうにかしてるよねとか、もうちょい今すぐこの場でってよりかは少しじっくり考えた上で深い解決をしたいみたいな時だったから、それはあらかじめもうカレンダー押さえてもらってみたいなパターンのコミュニケーションが多かったし、
だからそれより前ですよね、なんかジュニアとミドルの中間ぐらいの時に普通に1プレイヤーとして集中しながらコード書きたいなっていうジョブだったときはどうしてたんですかね、でも周りが同じレベルだったからな別に。
自分が仕事を止めてるっていうよりかはどうしてんすかね、スラッグはなるからな。
そうそうそう。しかも組織が大きくなるといっぱい通知が飛んでくるし、なんかみんなどうしてんのかなって思いながら、自分が全職とかでも意識的にやってたのはもう中段は絶対入るし、
他の人のブロッカーにならないように、仕事が早く進むように、フロー効率が、別にその時フロー効率って言葉知らなかったけどもフロー効率が良くなるようにっていうことを頭で考えてて、
自分のやる仕事は集中しなくてもいいぐらいにもうタスクを分解しておいて、一個一個のサイズがちっちゃいんですぐ終わるようになってて、すぐ終わったらその間で来た依頼に対応して、その後またすぐ戻るみたいな。
なんかそういう働き方をしてたなぁみたいなのを、なんか今となってこう振り返って思ったりとかして、ってなるとじゃあフローに入るって一体何なんだろうなぁと思いながら、必要なのかなとかさっきの坊主さんの話なんだけど、フローに入ってすごい集中してたら読めるコードが出来上がりました。
ただしその普通の先には知らずではわかりませんみたいな、そうなってもそれはそれで良くないなっていうのを思ったりとかして。
なんかありますよね、徹夜とか2日余裕の状態でも読めるコードにしなさいみたいな話たまにありますもんね。
あるある。だからフロー状態に入ることはもちろんいいことだと思うんですけどね、仕事が進みやすくなると思うんですけど、
なんか本当にそれが良いことなのかなぁみたいなのはこう、まあピープルウェアしかりこの本しかり色々言及されてて思ったりとかして、あれ夜中の人たちはみんなどうしてんだろうなっていうのはちょっと気になっちゃいましたね。
いやあれか、それで言うと朝3時どうしてたな。だいたい7時とか8時ぐらいに仕事始めれば、周りの人動いてないんで。
あとその間はなんていうか、連絡を1時間2時間放置しててもそんなに怒られない。
そうすると2時間分のガチ集中ゾーンが確保できるんで。
それだいたいマネージャーとかEMとかになった人が定時が終わると自分の時間が取れるみたいなやつですね。
マネージャーやってからはそんなやってないけど、プレイヤーの時やってたの。日中は全部コードレビューして、よし10時半からが本番だみたいな。
なぜか12時半から取り行き先の人がチケットレス来るみたいな。どういうこと?って。面白かった。
面白おかしくそういう話を昔はよく聞いたなっていう感じはありますね。
だからゾーンに入るぐらいのディープワークまでいかなくても、自速120キロまで乗らなくてもとりあえず30キロ40キロまで通常の速度が出るまでのラグを短くするみたいなのは、
そっちの方が大事な気がするんですよね。特にテックリードとかマネージャーとかになっていると、コマ切りの時間が多くなるじゃないですか。
ミーティングやって1時間仕事したらまた次のミーティングあったりとか、ブロックしてたはずの時間だけど声かけられたりとかあると思うんで。
だから与えられている時間が30分しかないのに、普通の自速30キロぐらいのスピードまで乗るとか、さっきとか昨日何やってたっけなーっていうのを思い出すのにかかる時間が5分とか10分とかになっちゃうと、すごいロスが大きいので。
なんか不老状態とか云々じゃなくて普通に歩き出すまでを速くするとか、再起動を速くするみたいなやつの方が大事じゃねえかなっていう気はしていて。
それはあれですよね、本当に紙の風船をパンって貼っておいたりとか。僕は風船は使ってないですけど、ノートに今これやってるっていうのをバーって書いて開いたまま置いとくとか。
あとスラックにエンター押さないで戻ってきたらこれをやるっていう自分当てのメンションじゃないですけど書いておくとか。
っていうそこら辺は細かいティップスというか、小細工がある気がするなってちょっと思いました。
確かにな。今言われて自分の中で順調づけができないぐらいパニックになったときはトレロを作ってトレロにひたすら優先順位が高いものを一回並べてJaviからやるぞみたいなのをやったりとか。
やっぱそうなっていくよなみたいなこういう気持ちになりました。
あとあれか最近だとGitのブランチを行ったり来たりすることが多いので、絶対にプッシュするなっていうコミットメッセージでtoodoo.m2をあえてコミットしておくっていうのはやりますね。
ちゃんとGitHookでプッシュされないようにするみたいな。
それいいっすね。
すごいすごいちょっとこれだけで盛り上がってしまった。やばい。
確かに。
次の話題へ：優しい機能仕様
じゃあ次の記事という回数に行きますか。
何があったっけな第一部。
優しい機能仕様パート1からパート4まで。
