『プログラミングの心理学』を読んだ
在宅の日々、だいたいラジオをきいて過ごしている。radikoだけでは飽き足らず、この世のすべてのラジオアプリをインストールし、Podcastをダウンロードし、耳から注入している。
先週読んだCode Completeにおいて、複数の章で参考図書として紹介されていた。著者はGerald Weinberg氏で、ソフトウェア界における偉人の一人。著作では『ライト、ついてますか』も有名っぽい。
初版はなんと1971年。磁気テープを用いた開発や、プロジェクト例などは歴史を感じさせる。本筋であるプログラマの心理面の問題意識や実験結果、考察は、いま読んでも古さを感じない。そのこと自体が、本書のテーマが本質的な問題であることを示唆している。一方、プロとアマチュア、マネージャとプログラマ、また（職業人としての）男性と女性を区別した記述がやや軽薄に感じた。これは著者の不足ではなく、プログラミングに関わる、あるいは一般に人間の心理という領域が、当時の状況や著者が想定したよりもはるかに複雑だった、ということなのだとおもう。
本書の重要な目的はただひとつ。新しい研究分野を切り開くきっかけを作ることだ。(204)
プログラミングの心理学という領域を切り開きたい、ということだが、前述のとおり、現状をみるとその領域はまだまだ問題を解決するには至っていないと感じる。当時はおそらく「プログラマを人間として扱う」という発想自体が新しかったのかもしれない。
第1部 人の活動としてのプログラミング
プログラムに対するあらゆる要求の中で、何よりも重要なのは「正しい」ことである。(p.19)
プログラムが「動く」というのは、「コンパイルできて実行時にエラーにならない」ということではなく、「正しい」ということである。他のあらゆる要求、例えばパフォーマンスやコードの綺麗さは、正しいという前提の上に追求されるべきものである。当たり前のことのようだけど、認知的不協和の観点からも、しばしば正しさよりもそれ以外がプログラマの時間を消費する。
私は長年かけて、本章の事例を一般化した品質の定義にたどり着いた。品質とは、誰かにとっての価値である。(p.30)
要求を満たした上で品質を追求するのだけど、だれにとっても価値のない、あるいは勝ちを決める人にとって価値のないことは、品質の向上に寄与しない。きれいなコードを書くことが自己満足と揶揄されるのは、このあたりの不理解により起こる。ある人からみると「きれいなコード」は将来の開発生産性に寄与することを想定しているが、他の人からみると、その意識がないかもしれない。「なぜそうするのか、そうするべきだと思うのか」を言語化するのが大事っぽい。その合意なく、立場や性格の差異により非難されたり修正を強制されるのは、一番ダメ。
第2部 社会活動としてのプログラミング
25 年前と同じく、個人差はプロジェクトの予測可能性にとって大きな障害である。(p.52)
まさに『人月の神話』というかんじ。個人差が生まれないということは実質ありえない。予測可能性は経験から導くしかない。対策があるとするなら、それがプログラミングの社会的素養、つまりチームを組成することだと思う。人間を交換可能なリソースとしてではなく、ここの人格として理解を深め、その前提で計画をたてる。
人間の目には、見たくないものを見ないという無限の能力が備わっているのだ。(p.67)
コードを書いた人間と、それをテストする人間は、可能な限りの努力を持って分離すべき。同一人物がやる場合は、疎結合にしておく。典型手法として、テストを事前に書く、あるいはテストの項目を作り、他者のレビューをとおす。自分が人間であり、そういった性質を持っていると自覚することが重要。
どのような人が有力なリーダーになれるのだろうか。前にも述べたように、それはチームに要求される仕事による。(p.107)
プログラマと同様にリーダーもまた人間であり、個人差がある。プロジェクトの要求が「多少品質が悪くても早く完成させること」なのか、「最高品質で完成させること」なのか、その間なのかで、そのプロジェクトをリードするべき人間の性質は変わってくる。要求を見極めアサインすることはもちろんだが、アサインされたリーダーがその要求を理解し、自身をフィットさせていく、その領域を学ぶと明示的に意識することも、同様に重要にかんじる。
長期にわたって安定したプロジェクトを完遂するには、マネジャーはプロジェクトを一種のプログラマー加工工場のように機能させなければならない。(p.122)
プログラマは自分の知識を駆使したいという欲求が生まれる。別の問題、あるいはより高レベルの問題を解決したいと思うようになる。同一のプロジェクトに特定のプログラマを留まらせることは、その欲求に反することになる。また、その知識を必要としている他のプロジェクトにとっても機会損失になる。このあとにもでてくるが、そもそもプログラマを「選別」するのではなく、「学習」に主眼を置くべきである。
第3部 個人の活動としてのプログラミング
「プログラミング」は、「恋」と同じように、限りなく多様な活動を意味する言葉である。(p.149)
急にロマンティック。その経験がない人間からみると、プログラミングという行為が、「キーボードを通じて画面に文字を打ち込む作業」を意味すると取られかねない。実際にその作業をしているのは、体感で1割以下だったりする。また、プログラミングをして価値を生み出しているつもりでも、その前段の要件や設計が的外れで、価値が無に帰すこともある。そのあたりも恋と等価である。
パーキンソンが「仕事量は与えられた時間いっぱいまで増大する」と言ったのは、スケジュール目標の存在そのものが仕事の速さに影響するということを私たちに気づかせようとしたのだ。(p.160)
いわゆるパーキンソンの法則というやつで、いまでも健在であり、普遍的な課題であることがわかる。計画ギリギリになる人は、仮にその計画がゆるめに設定されていたとしても、変わらずギリギリになる。通常、「キツめの計画で少しオーバーする」よりも「ゆるめの計画でまにあう」ほうが1億倍評価されるので、計画をたてる側としては、なるべくゆとりをもちたい。管理側としては、はやくしてほしい。利害が衝突するのはしょうがない。その計画が結果的にどうだったかに関わらず、計画時点で合意していることが最も重要そう。
それぞれのプログラマーに、 最も 苦手 な部分のスペシャリストになるよう指示すると、学習の速度は最大化する。(p.164)
この発想はあまりなかった。ソフトウェアを開発する工程における不確実性を前提にすると、そもそも苦手としている部分が、本当に苦手かどうかがあやしい。コミュニケーションが苦手、と言っている人は、単にコミュニケーションの技術を学習してきていない、その方法を知らないだけかもしれない。それはもったいない。パレートの法則しかり、100点を目指すよりは能力の標準偏差を下げるほうが、少なくとも組織における価値を最大化する有効な戦略だとおもう。そのためには、まず何が苦手かを知る必要がある。ここでも前述のとおり「人間は見たくないものを見ない」ので、周囲からのフィードバックや、客観的な自己評価をがんばる。
求職者に、プログラミングが 好き かとたずねることを考えたことがある人はいるだろうか。(p.188)
これもわりと盲点だった。プログラミングの適正があるかどいうかを、あの手この手の試験や心理テストで判断しようとするより、本人に聞けばよい。説得力を持った説明を提供してくれること自体が、その資質といってもいい。
私の生徒になりたいと希望する学生に対するテストで私が知るかぎり最も強力な方法は、母国語を完全にマスターしているかどうかを見ることだ。それには、学生の話を聞くだけでよい。(p.210)
ダイクストラ氏のお言葉。母国語と完全にマスターしているというと、簡単そうだが、実際にこれ以上高いハードルはないとおもう。論理をマスターしていると同義であって、ダイクストラ氏に対して論理的に筋のとおったスキのない話をすることができれば、またそれが判断できれば。いまリモートワークをしていて、実オフィスにいるとき以上に、説明能力が浮き彫りになっていると日々かんじている。伝えるべき情報を任意の言語で伝えることができる能力が要求される。
第4部 プログラミングの道具
何かを学ぶ方法を学ぶための第一歩は、自分の資産と負債を学ぶこと、「汝自身を知る」ことである。(p.227)
現在の上司にあたる人物が、3年くらい前に、「自分のことを優秀とは思わないが、自分ができることとできないことはわかっている」と言っていたのが強く印象に残っている。自分というリソースを最適に活用する方法を考えている、という話だったのだと思う。
プログラミングは数学の分派ではなく、人間が積極的な役割を担い、コンピュータが時に受動的な役割を担う独自のコミュニケーション形式である。(p.285)
プログラミングは確かに言語表現であるが、一般に人と人とのコミュニケーションとは性質が異なる。例えば、我々はプログラミング言語を用いてコンピュータに情報を伝えるが、コンピュータはその言語を用いて我々に語りかけない。つまり双方向ではない。ただ、本書とは時代背景が異なり、プログラミングは同僚や未来の同僚、あるいは未来の自分という人間に対して情報を伝える、より人間同士のコミュニケーションに近い様相を呈してきていると思う。
第5部 エピローグ
あなた がコンピュータで行っていることは、やる価値のあることだろうか。(p.324)
本質 of 本質。著者は、自身の本を参考に非倫理的な動物実験が行われた（可能性がある）、ということを知った。各位は、日々プログラミングをしている目的について自覚し、その価値を説明できるだろうか。
『Code Complete 第2版』を読んだ
新型コロナウイルスも落ち着きつつあって、よさそう。そろそろ物理出社が怖くなってきた。というわけでぶっとい本を土日にガッと読んだ。
めっちゃ有名。「おすすめ技術書」みたいなｳｪｯﾌﾞ記事でだいたい挙がってくる、バイブル的なやつ。著者はSteve McConnell氏というかたで、Microsoft社やBoeing社に勤務された経歴あり、1993年に本書の初版を出版している。2003年にオブジェクト指向をとりいれた第2版が出版された。紙の本だと上下で1000ページ超えという鈍器のようなもの。
Amazonの履歴をみると3年前に購入していた。上下巻で出版されているが、自分はそれらがあわさった電子合本版をKindle半額セールで買った。そのときにも読んでいる（はずだ）が、当時から3年もたっているので、読みとる情報も違ってきそう。と思って再読した。何より、記憶がまったくない。
全体の感想としては、さすがバイブルに紹介されるだけあって、説明がわかりやすく、サンプルコードも豊富で読みやすい。ソフトウェアエンジニアが経験的に取得していく知識や考え方が綺麗にまとめられている印象を受けた。なんとなく考えていたことが明文化されているかんじ。自分の力だけで整理するには規模が大きすぎるため、本書はその助けになりそう。また、こういった本を読むと、力の入れどころがわかる、みたいなのがある。「見積もりってだれがやってもしんどいんだなあ」とか、「設計レビューでフルボッコにされたけど、だれも答えはわかってないんか」とか。経験がないとついネガティブな感情になりがちなところを、知識でフォローできる。
ただ、本書に限ったことではないが、やはり実感が伴わないと理解にはつながらないとおもう。3年前の自分もたぶんそうだったし、3年後の自分が再読すると、また同じことを感じるかもしれない。特定技術ではなくこういった網羅系の本は、自分にマッピングしながら読みすすめる、マッピングできない部分は未来の自分に託して読み飛ばす、くらいの読み方がいいのかもしれない。
参考文献が豊富に紹介されていて、ここからさらに理解を深めたい領域の本をたどっていくのも良さそう。Kindleで読みながらマーカをつけていたので、以降ではその中から引用して、感想をまとめている。引用末尾の数字は、Kindle上の位置。何年後かの自分に読まれたい。
第1部 基礎を固める
ソフトウェアプロジェクトをいくつかの工程にわけたとき、一般にプログラミングや開発と呼ばれる工程あるいは詳細設計などを、「コンストラクション」と読んでいる。これは建築のメタファである。そして、コンストラクションの前段階がプロジェクトの成否を決めると説明している。
ソフトウェア開発プロジェクトのリスクで最も目立つのは、準備不足とプロジェクト計画不足である。(1140)
ソフトウェア開発の工程は基本的に不確実性を減らしていく作業と理解している。不確実性はソフトウェアの完成が近づくにつれて減少していく。それをいかに早い段階で最小化できるか、という問題を解くのがプロジェクトマネジメントの能力だと思っている。コードを書く（というメタファの功罪であるが）作業は、不確実性が最小化された状態で行うべきであり、そのためにプロジェクトの前半に投資が必要となる。
この段階での手戻りは、後段のプログラミングの手戻りと比べると、比較にならないくらい被害が大きい。
コンストラクションを始める前に完了しなければならない最初の準備は、システムが解決するはずの課題を明記することである。(1331)
プロジェクトのスタートは「要件定義」ではなく、本質的には「課題定義」としている。何を解決するプロジェクトなのかを確実に言語化し、ステークホルダー間で合意しておくことが、まずスタートラインになる。これをやるのは開発担当者ではないケースは往々にしてあるが、少なくとも「課題は何か」と、次段階にあたる要件を満たせば、その課題が解決されることは、理解しておく必要がある。そもそも課題を解決する最適な手段が、ソフトウェア開発ではないかもしれない。
準備が不十分になる一般的な原因は、上流の作業を担当する開発者が、与えられた仕事をこなすための専門知識を持っていないことである。(1148)
不確実性、つまり「やってみないとわからない」をなるべく減らす上で、知識は比較的潰しやすい領域である。ただ、すべてを把握することは難しいので、かけられる時間を制約として、プロジェクトを計画する上で最低限必要な知識を得るための最適な行動を、戦略的に考える必要がある。自分の経験としては、知識以前に、検討を詰め切れていないというケースもやらかす。これは知識不足よりもさらにもったいない。
コンストラクションの準備を最終的に左右するのは、まずそのプロジェクトに適したコンストラクションの準備とは何かを判断することだ。(1323)
さらにメタな視点で、コンストラクションの準備、ひいてはプロジェクト全体の成否を決める上で、「何を決めるか」を決める、というのが最も重要になる。象徴的な例としては、「プロジェクトがどうなったら成功で、どうなったら失敗なのか」を定義しておく。極端にいうと、顧客の課題は解決できたけど予算は大幅にオーバーしました、というのは、とても成功とはいえない。個人的には「制約」という考え方が重要であり、明確な言語化がサボられがちだと感じる。課題と制約を明らかにした上で、それらをみたす要件を定義し、設計、計画を構築する。
第2部 高品質なコードの作成
第1部のテーマだった「コンストラクション」に対し、ここではコードの作成を区別し、それらの設計からその方法論を述べている。
SapirとWhorfの仮説によると、物事を考える能力は、その考えを表現できる言葉を知っているかどうかにかかっている。言葉を知らなければ考えを表現することはできないし、系統立てて説明することはなおさらできないだろう（Whorf 1956）。(2002)
知らないことを考えることはできない。知っていることから組み上げて、思考を導出するべき。たまに知らない領域で、「考えがでてこない」みたいな感覚に陥ることがあるが、たいていは前提となる知識が足りていない。何が足りないのか、どうしたらうまるのかを考えるところから素地を作っていく必要がある。
設計とは、要求をコーディングやデバッグと結び付けるアクティビティである。(2248)
要求から即コーディングに入ると、だいたいうまくいかない。その間には、想像以上の距離がある。経験豊かな人は手を動かしながら考えるけど、それは脳内で設計ができているだけ。規模が大きくなれば立ち行かなくなる。要求を実現する手段として何が最適か、戦略を立てて意思決定をする、という段階を「設計フェーズ」として確実に進めるほうがいい。
プロジェクトの失敗の原因が主に技術的なものであるとしたら、その多くは、複雑さを野放しにしたことが原因である。(2358)
プロジェクトが失敗する（予算が上振れする、計画が遅れるなどを含む）原因は、控えめに言ってほとんどが要求や計画の不備である。これは十二分に体感している。というか、論理の世界において技術的な問題で無理でした、というケースが想像つかない。
例えば「プログラミングの知識不足で想定より時間がかかりました」というのは、計画のミスでしかないし、「このフレームワークではこの設計は実現できませんでした」というのは、設計（技術選定を含む）のミスでしかない。本文にある複雑さの例にしても、その複雑さを想定していない計画のズレでしかない、と思う。そうなってくると、技術力とはなにか？みたいな話になってきて難しい。
設計は反復的なプロセスである。(3150)
これ本書（少なくとも上巻）で繰り返し述べられている、象徴的なテーマと言ってもいい。設計は非決定論的であり、ヒューリスティックである。したがってある時点で答えが出ることはなく、繰り返し改善をされているべきプロセスになる。設計のする、ということではなく、設計という反復作業をいかに効率よくイテレートするかを戦略的に考えることが、プロジェクト成否を分けそう。
私たちは、プロジェクトの最後に十分な時間が残るように、設計プロセスをさっさと片付けて、問題を解決しようとする。しかし、その残った時間は、設計プロセスを急いだために生じたエラーを発見するために使われる。 ─ Glenford Myers (3284)
はい。
プログラムには必ず問題があり、プログラムは変更されるものであり、賢いプログラマはそれを踏まえてコードを開発する(5017)
プログラミングは本質的に製造のプロセスではなく（便宜上「開発」と呼ばれるが）設計のプロセスであって、前述の設計原則は変わらず適用される。反復的に行われるべき。コードレビューよりもセルフレビューのほうが圧倒的にコストが低いため、その段階で一定レベルまで改善できる力が、すなわちプログラミングというレイヤにおいて知識以外の技術力のひとつなのかもしれない。
そこにおいて、本書にある「擬似コード」というプロセスをもう少し明示的にやってみようと思った。日本語のコメントで処理内容を説明するやりかた。要求とプログラミングをつなぐために設計があり、さらに絵設計とプログラミングをつなぐために、擬似コードは有効な手段だと感じる。レビューも擬似コードとその実装をわけるとレビュアーの負荷は軽減されそう。
「あともう1回コンパイルすれば、きっと決着がつくだろう」という「あともう1回だけコンパイル」症候群は、エラーの原因となる軽率な変更を促し、長い目で見れば余計に時間がかかる。(5942)
「あともう1回だけコンパイル」症候群の重篤患者であるぼくとしては身につまされる一文だった。完全に理解していないコードをコンパイラに渡してはいけない。たまたま動いてしまったときの被害が、コストに見合わない。簡単にコンパイル・実行できる環境や、スケジュールに追われる状況において、いかに思考を続けるかが品質を決めるし、脳の可塑性を信じてトレーニングに精進したい。
第3部 変数
第2部と第4部もそうだったが、このあたりの具体的 なプログラミングのプロセスは、さすがに知らないということはほぼなかった。「読みやすいコード」「シンプルなコード」などを志向していると、自ずと考えられる。
犬とその名前は別々のものだが、変数とその名前は本質的に一体である。(9640)
ここだけ最初、よくわからなかった。「太郎」というのは一般に人間の名前だが、それを犬につけてもいい。ただし、ある家庭において、太郎という犬と、太郎という人間が同時に所属している場合、それは望ましい命名ではない。これは、変数名のスコープと等価のはず。
変数名は、そのポインタが指すメモリ上のアドレスに存在するバイト列に対して名前をつけているのであって、それが変更されることはない。犬の例でいうと、犬が生成された瞬間（＝生まれた瞬間）に割り振られ、以降は変わることはない。それが「本質的に一体」という意味だと理解した。
第4部 ステートメント
要求、要件、基本設計、クラス設計、変数・ステートメント、と具体化されてきて、第3部と第4部が本書の最下層。特に本部では、ループの使いわけ、みたいな、そうとう具体的なプログラミングの方針を説明されている。
有能なプログラマは、頭の中でシミュレーションし、電卓で計算する。(8976)
第2部でもあったが、コンパイラに渡すのは製造工程であって、開発工程では明確に品質を保証すべき。ステートメントが常に正しい振る舞いをすること、なぜそうなるのかを言葉で説明できることを、プログラマは責務として負っている。本質的にめちゃくちゃ脳に負荷がかかる。がんばりたい。
有能なプログラマは自分の脳みそがほんのちょっとしかないことを十分承知している。だから、とても謙虚な姿勢でプログラミングにのぞむ」（Dijkstra 1972）。(10256)
そういうこと。
第5部 コードの改良
「品質とはなにか」という話から始まり、テスト、ペアプロ、リファクタリング、チューニングについて。
プログラマは指定された目標に取り組むが、それには、目標が何かを知らされていなければならない。(12166)
品質には様々な特性があるが、どれに取り組むかは明示するべき。例えば、正当性と堅牢性はときに相反することがある。それぞれを目的にした場合、エンジニアはその目的に沿った開発をする。ひとくちに「品質を高く」とはいっても、何をどれだけ高くするか、そのために使えるコストはどれくらいなのかが曖昧だと、望むアウトプットは得られない。
コードに問題があっても当事者には見えないことがある。このような盲点は人によって異なるので、だれかに自分のコードを見てもらうことは開発者にとって有益である(12379)
文法上の問題はコンパイラ、仕様上の問題はテストで検出できたりするが、それ以外の問題や、テストの不備は、人間にしか検出できない。しかも、それを書いた当人にとっては見えにくい。そのため、コードレビューによる問題発見は効果的であるとしている。また、人に見られるということ自体が、コードの品質を向上させる。さらに、コードレビューは技術知識を組織に浸透させるような効果もある。本書にはないがいまはGitHubというツールがあり、コードレビューを通じたコラボレーティブな開発が容易にできている。
テストの量を増やしてソフトウェアの品質を改善しようとするのは、痩せたくて体重計に乗る回数を増やすようなものだ。(12936)
あくまでテストは問題発見のアクティビティでしかないということをいっている。品質を向上するのは開発のプロセスであり、問題を解消するのはデバッグのプロセスである。それらは明確に区別されるべきと思った。テストは「問題がない」ことを確認する（証明はできない）ために使うべきで、その段階で品質は保証されてしかるべき。「テストでみつかったらなおそう」というのはその役割を誤解している。
他の何よりもコンピューティングにおいて罪深き行為は、（それを達成する必要もないのに）効率という名のもとに行われている。 ── W. A. Wulf (15009)
可読性を落とすチューニングは、果たして本当に必要なのか？という話。そのチューニングの結果を求めている人は本当に存在するのか。そもそもアーキテクチャや設計のレベルで解決すべき（それはたいてい可読性を「上げる」）では。
第6部 システムの考察
プロジェクトの規模が大きくなると、通常は要求や設計のミスによるエラーの割合が高くなる (16152)
ほとんどの方法論のポイントは、コミュニケーションの問題を軽減することである。(16340)
コンストラクションの目的が複雑性への対処である、としているのと相似的に、方法論の目的はコミュニケーションへの対処になる。その過程で、ドキュメントや開発プロセスの整備、コーディング規約の策定などが行われる。「生産性が下がる」といわれる原因のほとんどはコミュニケーションにありそう。
ソフトウェア開発に反復が無駄になる領域はほとんどない。見積もりは反復が役立つ領域の1つである。(16653)
見積もりについても言及されている。エンジニアリング自体が複雑性への対処であって、そのプロセスは常に非決定論的である、ということが本書のいたるところから読み取れる。その結果、反復的なプロセスが役立つ。スケジュールの半分の期日で最低限のアウトプットを出し、残りの期間で改善する、というやり方で、だいたいギリギリうまくいく。体感としても。
第7部 ソフトウェア職人気質とは
プログラマは人間である (16819)
忘れがち。このあたりは、自分自身の生産性を最大化する意味でも課題になる。推薦書籍として以下がたびたび挙げられている。
プログラミングを排除させない原動力となったのは、たとえ十分なツールのサポートがあったとしても、プログラミングが本質的に 難しい ことである。
10年前の本書でも、いまでも、プログラミングはいつかなくなるといわれているけど、いっこうにその気配がない。飯の種にはしばらく困らなさそう。本質的に複雑性への対処である。
コードを書くときには、あなたのプログラムを保守するだれかが、あなたの居場所を知っている凶暴な変質者であると心得よ。 ── 作者不詳 (10716)
ここまでではなくとも、将来の若者にdisられないように、怯えながらコードを書きましょう。そうでなくとも、人への優しさ、慈しみ、そういった心が大切です。
『第12回 PostgreSQLアンカンファレンス@オンライン』に参加した
もともと3月に開催が予定されていたのだが、新型コロナウイルスの影響で中止となっていた。この度、ユーザ会の方々がオンラインでの実施を企画してくれた。運営の皆様、本当にありがとうございます。
せっかくなので発表した。PostgreSQLのプロトコルを理解するために、シリアライザを実装して、実際にPostgreSQLと通信してみる、という内容。実装の雰囲気とか、簡易プロトコルと拡張プロトコルの比較などを紹介した。
だいたい以下の記事の抜粋＋デモというかんじ。
絶妙に需要のなさそうな内容で不安だったが、普段意識することがないぶん、逆に関心を持ってくれたっぽい。常時100人強の方が視聴してくれていたらしい。オンライン勉強会は初めてだったのだが、聞く側としてはリラックスした環境で聞けるし、画面の文字やデモもみやすくて体験としてはとてもよかった。逆に話す側としては、反応がわからなくて、だれも聞いていないのではという不安があった（実際に途中で「いま聞こえてます？」と聞いてしまった）。今後自分が聞く側になるときは、どうでもいいことでもなるべくチャットで反応するようにしようと思った。
PostgreSQLのアンカンファレンスは、第8回に初めて参加して、そのときが人生初の勉強会登壇だった。それから2回に1回くらいは参加している。毎回ゆるい雰囲気で、発表するときは比較的気軽にできる仕組みになっている。今回もそのノリで何も考えずに発表枠で申し込んだのだが、自分以外の発表者がPostgreSQLのコミッタとか、PostgreSQLで銭を稼ぐレベルの方々で、若干の後悔をしていた。当日は場違い感を感じつつも、好意的な反応をいただけて自分としては満足している。感謝。
簡易クエリ・拡張クエリは意識したことなかった！こんなに違うもんなんだ #pgunconf
— ester@VFR1200F (@ester41) April 24, 2020
クエリプロトコル、とても面白い。MySQLでも似たような話を聞いた気がする。 #pgunconf
— こば（右）- Koba as a DB engineer (@tzkb) April 24, 2020
メッセージのやり取りの間の時間とかも添えたら、詰まっている部分とか分かって(例えばBindフェーズが遅い、とか)デバッグが捗りそう... #pgunconf
— Kasahara Tatsuhito (@kasa_zip) April 24, 2020
@kabaome describing a pretty convenient visualizer for PG wire protocol message exchange
— Amit Langote (@amitlan) April 24, 2020
あまり空気を読まずに発表枠でやっていっても、みなさん優しいので受け入れてくれることを実証したともいえる。気にせずいきましょう。他の方の発表は例にもれずすごいレベルで、聞いていてたいへん興味深かった。ただし完全な理解にはほど遠いので、もったいない気持ちになった。理解して議論を楽しめるように精進していきたい。
前回参加したときは、何も準備せずにいって会場でスライドをつくって発表し、結果準備不足を露呈したり他の方の発表が聞けなかったりして、会に対して無礼をしたと猛省していた。それにくらべて今回は、もともとブログにしていたものをベースに発表をつくるだけだったし、前もって準備していたので、同じ過ちを繰り返さずにすんだ。何をするにしても人より時間がかかってしまうタイプの人間であることを忘れがち。
#pgunconf の @kabaome さんの「アプリケーションエンジニアなのだから抽象化のその先を知るために自分でソフトウェアを作って調べる（そしてpostgresqlのプロトコルを調べる）」って本当にハッカーって感じでかっこよくて面白くて僕の中で今日のベストトークだった。
— そーだい@初代ALF (@soudai1025) April 24, 2020
プログラミングあまり得意ではないけど嫌いではないので、ぼちぼち楽しくやっていきたい。ハッカーになれるようにがんばります。
PostgreSQLクエリプロトコル概観
コロナのせいにして引きこもってPostgreSQLと遊んでいたので、ブログにまとめてみる。
年末のPostgreSQLアドベントカレンダーで、PostgreSQLのプロトコルについてちょっと書いた。同僚や社外の人間など、話題に出して貰う機会があったが、「そもそも、簡易プロトコルと拡張プロトコルの2種類があることを知らなかった」という話を複数回聞いた。たしかに、普通にアプリケーションを開発する場合、プロトコルはクライアントインターフェイスに隠蔽されていて、意識することはない。せっかくなので、そのあたりもう少し雰囲気がわかるように書いてみようかなという気持ちになった。
続きを読む『モチベーション3.0』を読んだ
あけましておめでとうございます。お正月休みに実家で読んだ。いまさら感＆非技術書で書くほどのこともないけど、感想を晒す。
いわゆるビジネス書の類でベストセラーになっているし、まずタイトルが胡散臭い。単純労働から創造的労働が主体となる社会において、モチベーションに対する考え方も変える必要がある、という話。著者によるTED動画があるのでみてみるとよいかも。
TEDでも本書でも語られているが、創造的労働としてソフトウェアエンジニアが挙げられており、Google社やAttrassian社を例に紹介している。また本書はGitHub社でも参考にされているらしい*1。自分の立場から感想を書いてみる。
内発的動機づけ
モチベーション1.0を「生存や安心に基づく動機づけ」、2.0を「アメとムチに駆り立てられる動機づけ」と定義している。近代社会は2.0に基づいて設計されており一定の成果を上げてきたが、社会の変容により不整合が起きている。具体的には、報酬と制約によるマネジメントは、単純労働には向いているが、創造性のある労働には適合しない。例えば、一定の水準を超えた報酬は、モチベーションの向上に寄与しない。「成果が出れば給料を上げる」とマネージャから言われたからがんばる、というのは、外発的動機づけと呼ばれる。自分以外のところにモチベーションの源泉がある状態。これに対し、本人の内部から発生する内発的動機づけが必要だと述べている。
内発的動機づけは、曲解すると、「やりたいからやる」という状態。報酬はこれを阻害する可能性がある。例えば、自分はマンガを読むのが好きだが、「マンガを読むと1冊あたり100円を与える」と言われると、読みたくなくなる。らしい。たしかに短期的には喜んで読むかもしれないが、長期的にはそれを強いられると苦痛になりそう。読みたくて読んでいるからこそ、いつまでも読んでいられる（と感じる）。コードを書くのも、趣味だと楽しいのに仕事だと楽しくない、ということは往々にしてあるが、これはその内容だけでなく、（給与にかぎらず評価や称賛などの）報酬によって内発的動機づけが阻害されている可能性がある。
特にソフトウェアエンジニアリングは、おそらく他の職種と比して平均的に創造性のある労働に分類される。ソフトウェアエンジニアにとってだいたいの仕事は未知である。自分も同僚も、過去にやったことがないことをやる。そのため、内発的動機づけが重要になる。
自律性・熟達・目的
内発的動機づけのために必要な、三大要素的なやつ。まず「自律性」とは、何をやるか、いつやるか、どうやってやるか、だれとやるかなど、仕事に対して自分が決定権を持つこと。わかりやすくは、20％ルール*2というのがあり、実際にここから独創的な発想が生まれ、主力プロダクトになるケースも聞かれる。オーナーシップという言葉と似ているのかも。
次の「熟達」は、なにか価値のあることを上達させたいという欲求。体感としても一致していて、仕事の中で必要な情報を調べたり考えたりして、結論「わかった」という状態になったときが一番気持ちいい。「できた」とか「評価が上がった」ということに対しては、客観的にみて嬉しいという感情はあるけど、内発的な感動はない。ドゥエックは、人の信念が熟達の内容を決定づけると主張し、これを自己理論と呼んでいる。自己理論において、「知能は存在する分しか存在しない」という固定知能観と、その反対の拡張知能観に分かれる*3。熟達に必要なのは後者のマインドセット。脳科学領域における可塑性は一般に認められている。脳が気持ちいいと思うことをやっていきたい。
自律性をもって熟達を目指す人間は、「目的」をもつとさらに大きな成果をあげるらしい。外部から目的を与えればよいということではなく、あくまで内発的に目的を保つ必要がある。組織にいる以上は組織の目的が前提にあり、それと自身の目的が紐づく状況を作るとよさそう。そう考えると、OKRのようなツールがでてくるのも理解できる。ソフトウェアエンジニアにとっては、コードを書くのが楽しいから続ける、というだけではなく、それが組織の目的に合致して結果的に貢献できることは、評価とフィードバックに結びつき、中長期的には強い動機づけになりそう。
まとめ
報酬による画一的な動機づけだけでは、自分も含めてソフトウェアエンジニアのモチベーションを保てない。やりたいからやるという状態を、本人も環境も作っていかないといく必要がある。ただし、報酬は低くてもいいということではなく、市場や他社との比較も含めて「気にする必要がない」くらいには与えられる前提であり、本書はその先のレベルの話である。つまり給与は1000倍にしてほしい。とはいえ、ｼｬの仕組みとか偉い人たちの主張について、多少は理解が進んだかもしれない。
ビジネス書は普段あまり読まないし、読んだとしてもブログには書いていなかった。今後は、おもしろかったら書いてみようかという気持ちになった。本を読むのも、それ自体が目的になっていいし、熟達に向かう快感がある。コードを書くのもそうで、別に勉強のための勉強でもいいと思う。熟達に向けてコードを書こう。
*1:https://speakerdeck.com/schacon/robots-beer-and-maslow?slide=122
*2:業務時間のうち20%を使って好きなことをやっていい、というやつ
2019年の振り返り
年末年始、帰省している。昨日まで暖かかったのに、今日はすごく寒い。冬かもしれない。昨年も振り返りをしていたので、今年も書いてみる。
エンジニアリング
ｼｬでは、レガシーに始まりレガシーに終わった一年だった。CI周りからフロントエンドのパッケージ管理、データアクセスのライブラリまで、いろんな領域のレガシーに触れた。問題にぶつかり続けてかなり消耗したが、幸いにも周囲に助けられながら進めてくることができた。できてない。
レガシーという言葉を使ってきているが、自分の感覚としては広くソフトウェア自身が抱える課題の解決である。新規機能の開発プロジェクトとの違いは、顧客に価値が届く時間でしかない。2020年もレガシー改善をやることになりそうだし、よりソフトウェアにとってクリティカルな課題を解決できるとよさそう。
いわゆる上流工程にあたる要件定義、計画、設計の重要さ・難しさを改めて痛感したし、そこにおいても基礎的な技術知識の不足をかんじた。技術力に関しては長年の悩みであり劣等感すらあったが、いいかげん自分の限界はなんとなくわかってきた気がする。スーパーエンジニアにはなれないし、周囲の人間と比して、ある側面で劣る部分も受け入れつつある。この人間を活かすにはどうするべきか、2020年は仮説検証してみたい。
ひとつあげると、他者に共有すること、あるいはそれに向けて情報を整理する過程は、自分にとって技術面の向上という意味で一定の効果があるように思える。昨年末に書いたｼｬブログをきっかけに京都ｵﾋｽでイベントをやったし、2019年版のｼｬブログも書いた。曖昧な部分も言語化するし、正しい情報を伝えるために改めて学習する。自分にとってかなりエネルギーを消費するが、これ自体もトレーニングだと思って、2020年は継続してみる。
採用・評価・コーチング
ポジションとして何か大きな役割を持っているわけではないが、メインの開発業務以外も地味にやっていた。新卒採用の一次面接官を3年くらいやってきて、何かがうまくできるようになったという感覚は皆無だが、つまるところ一次面接官の判断基準は、一エンジニアとして「一緒に働きたいかどうか」に集約されるといってもいいかもしれない。
今年の後半には評価に一部関わる機会があった。全員がやる360°評価的なやつとは別に、いわゆる職能に関わる評価において、第三者的・客観的視点を提供する役割だった。人間が人間を評価すること自体に無理があるというのは置いておいて、やるだけのことはやった気がする。同時に、自分より年次の低い他チームの同僚に対して、コーチング的に接する機会もあった。1on1をやるのか、成果・成長につながるのかは難しい問題ではあるが、できることをやるのがサラリーマンの務め。どうしても目に見える効果が出づらいぶん、自分には苦手な領域である。今後ももし機会があるなら、せっかくやるならば、エンジニアリングと同じく、言語化して伝えられるくらいには理解したい。
健康
2019年最大の目標だったが、満足のいく結果は残念ながら得られなかった。どうも近年は不定愁訴的な趣があり、運動や食生活などいろいろ試してはみたが、改善には至らなかった。自身の状態を観測するのが苦手らしい。30代の身体は一種のレガシーシステムであり、単発の対処療法ではなく、継続的な改善あるいは自律的にそれがなされる環境を構築する必要がある。さしあたり、体調の良し悪しを計測したい。開発生産性よりは計測しやすいかもしれない。
不定愁訴の一要因として、脳疲労と呼ばれる状態を自覚することが増えた。単に会社を休むとか体を休めるのとは違って、積極的休養が必要に感じる。そもそも自覚できるようになったことが進歩であり、2020年は改善に向けて計測と施策を講じたい。この類はインターネッツも書籍もエセ医学が蔓延していて、しんどいものがある。知見をお持ちの方は教えてください。
改善点を挙げるなら、昨年の扁桃切除手術により、風邪で喉がやられる回数は劇的に改善し無になった。乾燥に怯えることがなくなったぶん、精神的な負担も激減した。また、健康診断においてアレルギー検査をしたところ、ハウスダストアレルギーが発覚した。空気清浄機を導入し、毛布を廃止するなど対策を講じたところ、劇的に改善した。逆に、今までなぜやらなかったのかと考えると、やはり明示的に検査結果が出たというのが大きい。お金で解決できることは解決する。
海外旅行
昨年の振り返りに書いていた、海外旅行に行くことができた。人生で初めて国境を越え、オーストラリアのパースという土地にいった。初海外旅行にしてはニッチなところらしく、いい意味で観光地感がなかった。別世界の日常に入り込むかんじが楽しかった。
これを機に、2020年もまたどこかにいってみたい。海外の技術カンファレンスとかもよさそう。英語はまったくわからんけど。
趣味
とりたててツイートなどしていないが、例年どおりそこそこな数のお笑いライブにいった。唯一の趣味といってもいいかもしれない。とはいえ一時期に比べるとだいぶ回数は減った。なんとなくこのあたりの熱量も、年齢を経るにつれ減少していく気がする。2020年はさらに減るかもしれない。寂しい。
進捗としては、今年はライブに行ったことのない友人を連れて行くことにも成功した。今後行ってみたいという方は気軽にお声がけください。
2020年に向けて
何かを考えているふりしてなにも考えていないダメ人間の典型なので、年が明けたころにはだいたい忘れて、また年末に同じ振り返りをしているはず。というか、結局のところ健康が第一。あらゆる活動のボトルネックになる。にもかかわらず、近視眼的な対策ではどうにもならないことが今年を通じてわかった。2020年は戦略的に取り組む。まずは体重を増やしたい。
関わってくれたみなさま、ありがとうございました。よいお年を。すべて感謝。般若。
壁 Advent Calendar 2019の総括
壁 Advent Calendar 2019 25日目の記事です。
なぜか隔年で実施している壁カレンダーだが、今回で第3回となった。今年は絶対に開催せずしれっとなかったことにしようと目論んでいたが、気づいたら発生していた。制作者かつ最終日ということで、僭越ながら各記事の感想を書く。
感想
1〜5・7・8日目
全7回に渡る長編、最後に物理壁をぶち壊す話。東大ロールモデルであらせられるひぐ様が、東大ロールモデルに至る軌跡を記した伝記の一部。
で「そういえばこれから私の研究室の出身者、金沢工大から東大に来てMSRのインターンに行ったりしながら学位を取り東大特任講師だったのを辞めてPFNに移る傍らビール醸造会社を始めたのでその試飲会に行くんです」と言ったら「そうまさにそういう人材！」となり樋口君が東大ロールモデルになりました🤗
— Jun Rekimoto : 暦本純一 (@rkmt) 2019年12月8日
おそらく後世にはこの記事がまとめられ、「ひぐ力」みたいなタイトルで新書として出版される可能性が高い。ちなみにひぐ様と会ったのは2回くらいで、こういうノリが許される関係性なのかすら忘れた状態でこれを書いている。美味しいビールをいただくのを楽しみにしています。
6日目
ボルダリングの壁。壁カレンダーの起源は発起人である私がボルダリングにハマっていたことであり、初回の壁カレンダーは半数がボルダリングの記事だった。それを蹂躙され、いまの多様性を許容する形式となった。そんな中でボルダリングの記事を書いてくれた。唯一の良心。今後もボルダリングをしっかりやっていってほしいし、京都に帰った際にはぜひセッションしたい。
9日目
中古住宅を購入してリフォームした話。この段階で壁との関連性はかなり薄まってきた。私からみると学生時代の研究室の先輩にあたる。ちょうど先日おじゃました際には、おもしろ社内システムを鑑賞したり、ヒロシちゃんねるを鑑賞したりした。
今日は友人達を自宅に呼んでクリスマスパーティをします。 pic.twitter.com/VmC3S3YhVK
— わたあめQ太郎 (@q_tarou) December 22, 2019
最高の家だったし、よくよく聞くとリフォームの過程で壁をぶち抜いていたため、本カレンダーにふさわしい。
10日目
リングフィットの壁。他に類をみない有益記事であり、壁カレンダー以外の然るべき場所で発表されていれば、ｲﾝﾀｰﾈｯﾂで大いに評価されたに違いない。リングフィットアドベンチャー自体、同僚の間でもめちゃくちゃ流行っており気にはなっていたため、雰囲気がすごくわかった。センサの精度とかゲームとしてのおもしろさに関しては、顧客が本当に欲しかったものみたいなかんじで、ものづくりの観点で良さみを感じた。
11日目
シンガポールの壁。というか、シンガポールのビアバーが紹介されている。ビールのことはまったくわからないので、このあたりをさらに深堀りした解説を、プロであるひぐ様に書いてほしい。はやめに。
12〜14・21日目
— ガッキーのプライベートアカウント (@azaazarashi) December 13, 2019
タルトタタン、アイスクリーム、フィナンシェ、マドレーヌの作り方。どうがんばっても壁には結びつかない。手書きメモをツイしURLを貼り付けるという超絶手抜き。ガッキーだから許される。ちなみに9日目の中古住宅におじゃました際に持ってきてくれたのでいただいた。美味かった。スイーツで一旗あげ、第二のロールモデルを目指して邁進してほしい。
15日目
自宅をホームシアターにする話。めちゃくちゃ有益。ホームシアター化を画策する一人暮らし人間におかれましては、ｲﾝﾀｰﾈｯﾂに巣食うｱﾌｨﾌﾞﾛｶﾞｰの記事をくぐり抜け、この記事にたどり着くことを願うばかりである。
16〜19日目
ある意味で、壁カレンダーを象徴する作品。16日目のラップは圧巻だし、最終日にはゲームが用意されているので、ぜひ挑戦してみてほしい。感想とかはうまく言語化できない。もうわけがわからん。
20日目
ドイツ語の壁。ドイツ語だけでもまったくわからんのに、さらに派生（？）であるSwiss Germanという、フランス語Remixみたいな言語について紹介されている。著者のブログには他にもチューリヒ長期滞在についての有益実体験記事があるので、チューリヒ長期滞在予定の方は参考にされたい。
22日目
天井裏の配管が破裂して水漏れした話。いいかんじに破裂しビチャビチャになったとのことで、本当に心から良かったと思っている。ポタポタとかそういうレベルではない様子がよくわかる。本当に良かった。
23日目
次元の壁を超えようとした話。かっこよすぎ。これについて私が何かを言うのはおごがましい。ただ最高。
24日目
23日目の挙式の参加者が、当日の写真たっぷりに紹介した記事。ガチ感が本当に最高。現時点で「追記予定」となっているが、すでに最高みが溢れている。
総括
シンプルに各記事がおもしろく、とても楽しめた。それ以上の感想は正直ない。ほとんどなにも考えてない。各自が思い思いの「壁」について文章を生成しており、人間の多様性が垣間見える。ちなみに参加者は自分の知る限り（知らない人もいる）自分以外はほぼ研究者であり、これは従来どおり。ただ所属が変わっている人が多く、人生ってかんじがある。
いまどきｲﾝﾀｰﾈｯﾂ界隈でもアドベントカレンダーの慣習はこなれてきて、技術やキャリアのまじめなやつや、定番のやつが目立つ。わけのわからんやつはだいたい個人の思いつきで、カレンダーが埋まらず終了しているものがほとんど。そんな中で、壁カレンダーは自由の文化を維持しつつ隔年で3回、全日程を埋めて完成している。再来年はどうなるかわからないが、今度こそ絶対に途絶えさせたい。
