『Web APIの設計』を読んだ

3連休初日。めちゃくちゃ寒いし緊急事態宣言なので、引きこもって本を読んだ。 2020年は、技術書を読んでもブログに書くのをサボっていた。書く時間がムダという説もあるが、すぐに利用する領域でもないかぎり、読んだら次の日にはすべて忘れている。 なんらかアウトプットしておくと少なくともあとで見返せるし多少は整理できるので、久しぶりにメモをとりながら読んだ。ので、ブログに残す。

www.shoeisha.co.jp

社内向けの単機能なAPIとか、特定の外部サービスから叩く用のWebフックAPIはつくったことあるけど、もう少し広めのドメインかつ実環境に公開するWeb APIを0からつくったことがない。 そのため全体像がわかるような本はないかと思っていたところ、本書をみつけた。

感想

タイトルに偽りなく、Web APIの設計に関して包括的な情報が得られるようになっている。 想定したよりも既知の内容だったので自分の知識が致命的なほどダメでないことが確認できて安心したし、逆に知らなかった情報(プロトコルの現状やOAS周りなど)も得られて、未知と既知のバランスがちょうどよかった。

全体の構成としては、銀行の口座情報を管理するAPIを題材として、各章のテーマに添わせて実例を示している。 ソフトウェアあるいはユーザインターフェイス一般にいえる原則的な考え方から実際に使えるツールまで、Web APIの設計に関わる流れを一気に説明している。

また、以下の記述で端的に示されているように、理想的な設計を紹介しつつ、現実問題も適度に混ぜ合わせながら実用的な流れが説明されている点もよかった。

それはよいとして、この話が通用するのは理想の世界だけである。そして、ここは理想の世界ではない。(第9章より)

ただ、例および日本語での記述がわかりづらい部分もあった。これは、自分の中でわりと既知の内容っぽい箇所は例示の記述を飛ばしたことも多分に影響していると思われる。各章は独立しているほうが好みなので、今後の本選びの参考にしたい。

読んだあとにググってみたところ、どうやらWeb API設計界ではオライリーの以下本がバイブル的な位置づけっぽい。

www.oreilly.co.jp

目次を見たかぎりカバーする領域はほぼ同じようにみえる。いつか読んで比べてみたい、そんな気がする。

メモ

読みながら書いたメモを残す。引用ではない記述も多々あるので、信用しないように。

第1部 APIデザインの基礎

第1章 APIデザインとは何か

  • APIとは、2つのシステム、対象者、組織などが出会い、やり取りするポイントである
  • APIの目的は、人々がそれぞれの目標をできるだけ簡単に達成できるようにすることである

第2章 ユーザーを意識したAPIを設計する

  • ユーザが何をできるかに焦点を当てると、インターフェイスはシンプルになる
  • 組織・データ・コードの構造は実装に閉じ込める

第3章 プログラミングインターフェイスを設計する

  • HTTPは、WWWの通信の基盤となるプロトコルであり、リソースをやりとりする
  • REST APIは、HTTPプロトコルを利用してリソースをやりとりするAPIである
  • 分散システムに要求される性質として、効率性、拡張性、信頼性、再利用性がある
  • これらの性質をみたす状態をRESTfulといい、RESTfulなAPIをREST APIと呼ぶ
  • RESTfulであるためのアーキテクチャをRESTアーキテクチャスタイルと呼ぶ
  • RESTアーキテクチャスタイルは、クライアント・サーバ分離、ステートレス性、キャッシュ可能性、階層化システム、コードオンデマンド、統一インターフェイスの6つの制約に従う
  • API設計はユーザフレンドリ性と設計原則との妥協を探る必要がある

第4章 API記述ドキュメントを使ってAPIを記述する

  • OpenAPI Specification(OAS)は、REST API記述フォーマットである
  • OASドキュメントの記述には、対応したエディタを使うのがオススメである
  • OASにおいて再利用可能なコンポーネントを利用できる

第2部 ユーザブルなAPIの設計

第5章 単純明快なAPIを設計する

  • 単純明快な設計にする
  • ユーザがすぐに使える(意味のある)データを提供する
  • APIには、不正な形式のリクエストエラー、機能的エラー、サーバーエラーの3種類のエラーがある
  • 人々は、設計が全体的に統一されていることを求める(例:日付のフォーマット)
  • 命名・データ構造は、一度決めたら最後まで貫くべきである

第6章 予測可能なAPIを設計する

  • APIの振る舞いはAPIのゴールによって決定されるため、一貫性のあるゴールを設定するべきである
  • APIは、内部・組織・問題領域・そして世の中一般に対して一貫性を保つべきである
  • 世間一般の一貫性を保つには、標準や一般的な設計に従うことが効果的である
  • APIの適応性を保つため、HTTPであることを利用してコンテントネゴシエーションを利用するべきである
  • コンテントネゴシエーションは、単一のリソースに対してHTTPヘッダで表現形式を指定できる
  • コンテントネゴシエーションのヘッダにはContent-Typeレスポンスヘッダ、Acceptリクエストヘッダなどがある
  • Rangeヘッダはバイナリの一部を取得するために定義されているが、itemsのようなカスタム単位を用いてページングに利用することもできる

第7章 うまく整理された簡潔なAPIを設計する

  • リクエスト・レスポンスのデータ構造を整理する
  • APIの入力および出力のプロパティの数・深さは、その数値が問題なのではなく、機能的に妥当かどうかが焦点になる
  • 数は20、深さは3を超えないことを筆者が推奨している
  • APIを整理した結果、別のAPIに分割することもありうる

第3部 コンテキストに応じたAPIデザイン

第8章 セキュアなAPIを設計する

  • OAuth 2.0は認可フレームワークである
  • OpenID ConnectはOAuth 2.0に基づく認証プロトコルである
  • APIではアクセス制御だけでなく、そのデータを公開するべきかを考える必要がある
  • OAS 3.0ではスコープの記述をサポートしている
  • 公開するデータは必要最小限にする
  • 何をセンシティブなデータとみなすかは明確でない場合が多いため、他分野の専門家に相談する

第9章 APIの設計を進化させる

  • ベースとなるプロトコルを理解し、どのくらい信頼できるのかを把握する
  • 出力データを変更するもっとも安全な方法は、純粋かつ単純に新しい要素を追加することである
  • HTTPクライアントは、1桁目以降が未知のステータスコードをx00として解釈する(RFC7231)
  • APIに十分な数のユーザがいるとき、明示した仕様以外も誰かに依存する(ハイラムの法則)
  • APIのバージョニングはコントラクトに関する変更のみ新見があるため、セマンティックバージョニングにおけるパッチバージョンは存在しない
  • パスとドメインにバージョン番号を含める方法がもっとも一般的に使われている
  • クエリパラメータやContent-Typeを用いた方法もあるが、あまり使われない
  • REST APIでは、APIレベルのバージョニング以外に、リソースレベル、ゴールレベル、データ/メッセージレベルのバージョニングが可能である
  • ただし、結局は他のリソースやゴールとの互換性を考慮する必要があるため、推奨はされない
  • APIの破壊的変更はコンシューマにとって嬉しくはないため、嬉しい機能の追加とあわせるべきである
  • 破壊的変更のリスクをへらすためには、拡張性の高いAPIを設計することが重要である
  • レスポンスオブジェクトに関して、プロパティの型を慎重に選択し、自己記述的なデータにするべきである
  • 自分が行うことは保守的に、他人から受け取るものには寛容に。(ポステルの法則 - 堅牢性原則)
  • APIにあてはめると、レスポンスに一貫性をもたせ、エラーを包括的に処理する
  • APIが大きくなるとは快適変更のリスクが高まるため、適切なグループに分けて小さく分割すべきである

第10章 ネットワーク効率のよいAPIを設計する

  • APIの設計者は、ネットワーウ通信の課題を理解していなければならない
  • APIのネットワーク効率最適化は、まずプロトコルレベルで行うべきである
  • プロトコルレベルの最適化
    • データ圧縮、持続的接続、キャッシュ、条件付きリクエストがある
    • HTTP/2は、持続的接続、同時リクエスト、バイナリトランスポートをデフォルトでサポートしている
    • HTTPのキャッシュ機構
      • クライアントは、Cache-Controlヘッダで指定された期間を超えない場合、キャッシュを参照する
      • 超える場合、サーバに問い合わせる
      • E-Tagの一致するデータが更新されていない場合、キャッシュの有効期限を更新し、そのキャッシュを参照する(条件付きリクエスト)
      • 更新されている場合、サーバからデータを取得してE-Tagの値を更新し、キャッシュする
    • 更新されたかだけを知りたい場合は、GETではなくHEADを使えば良い
    • HTTPのキャッシュ機構を、通信フレームワークが常に利用できるとも限らない
      • gRPCはサポートしていない?
    • コンシューマに対してデータの有効な期限を伝えるため、TTLをデータとして返す場合もある
  • 設計レベルの最適化
    • データをフィルタする、必要なプロパティに絞ることで通信量を削減する
    • データを集約することでAPI呼び出し回数を削減する
    • ただし、(キャッシュを含めた)データのライフサイクルを意識するべきである
    • 柔軟な集約
      • コンテントネゴシエーションで取得するデータの詳細度を指定する
      • クエリパラメータでプロパティを指定する
        • GraphQL
  • ネットワーク効率が悪いということは、APIの設計がユーザのニーズを満たせていない兆候かもしれない

第11章 コンテキストに基づいてAPIを設計する

  • 処理に時間がかかる場合は、202を返し、非同期に処理する
    • ステータスを取得するゴールを提供する(ポーリング)
    • プロバイダからコンシューマのAPIを介して処理の完了を通知する(Webフック)
  • SSE(Server-Sent Event)
    • 株価のような変動的なデータをストリームとして取得するのに用いるデータフォーマットである
    • HTTPプロトコルをベースした、HTML5用の規格である
  • 双方向のイベント送信には、WebSocket(RFC6455)が用いられる
  • APIの設計においては、プロバイダだけでなくコンシューマの機能的・技術的制限を特定し、慎重に検討することが必要である
  • Web APIを簡単に要約すると、単体の同期型のリクエスト/レスポンス+REST+HTTP/1.1+JSON Web APIになる
  • APIスタイルは、コンテキストとニーズを分析して選択する
    • RESTはリソース指向であり、HTTPプロトコルを活用する
    • gRPCは関数指向であり、トランスポート層としてHTTPを活用する(セマンティクスは使わない)
    • GraphQLはデータ指向であり、プロトコルに依存しない(通常はHTTPが採用される)

第12章 APIを文書化する

  • ドキュメント作成も標準に従うほうがよく、ReDocというツールが有用である
  • リファレンスマニュアルは、基本的に設計時のドキュメントを参考にできるはずである
  • ただし、そのまま流用するのはプロバイダの視点が入り込まないよう、注意深く検討するべきである
  • 利用者に対して、ユースケースやセキュリティに関して記述したユーザガイドが必要である
  • 実装者に対して、データマッピングやエラーマッピングに関して記述したプロバイダ視点のドキュメントが必要である
  • 破壊的変更のあるなしに関わらず、変更はドキュメント化されるべきである
  • OASにおいて、パラメータ、ゴール、プロパティに対してdeprecatedフラグを適用できる

第13章 APIを成長させる

  • APIの一貫性は重要であり、そのために設計ガイドラインを定義すべきである
    • リファレンスガイドラインは、HTTPメソッドやヘッダ、コードなどをどの状況で利用すべきかや、共通のIDの定義などを説明する
    • ユースケースガイドラインは、APIの利用に関してどういう使い方がなされるべきかを説明する
    • 設計プロセスガイドラインは、設計者が把握すべき情報へのリンクなどを説明する
    • 最初は小さく正確に構築し、単独ではなく共同で、着実にメンテナンスしていく
  • APIの設計者には、自分の設計をあらゆる面から疑い、正当性を問い、調査・検証・分析を行う責任がある
  • 何よりもまず、ニーズの検証と分析を行わなければならない
  • 設計のレビューは、プロバイダとコンシューマそれぞれの視点でレビューする
  • 設計者は、自分の設計内容を共有し、コンシューマにレビューしてもらう必要がある

2020年の振り返り

気づいたら一年が経っていた。なにもやってなくてやばい。自戒のために毎年恒例の振り返り。

エンジニアリング

環境とか特に変わらず、レガシーシステムの改善ぽいことを中心にやってきた。変化としては、エディタを開いてコードを書く時間よりも、広くプロジェクトのことを考える時間の比重が徐々に増えてきた。開発組織としての体制が整いメンバーが拡充されていく中で、自分の役割が変化してきたというのもあるが、個人としてもコードレベルを抽象化していわゆる上位レイヤの段階でプロジェクトリスクを想定できるようにはなってきている感覚がある。それに付随して、ソフトウェアの設計のみでなくサービスとしての仕様や運用においても、意思決定する機会が少しずつ増えてきた。めちゃむずい。時間・予算という制約の中で、最適な意思決定をすること、また意思決定者に必要十分な情報が提供できるように精進したい。

シンプルにすること

この一年を通じて、物事をシンプルに扱いたいという欲求が、他者よりやや強めにあると実感した。ポリシーとかこだわりではなく、自分の能力的に複雑なことを理解できない。シンプルというのは例えばコード量が少ないとか、運用の手間が少ないとかそういう話ではなく、適切なモデル化とそれに準じたコンストラクションを志向するということである。

シンプルに保つということは事業価値につながると思っている。ソフトウェアや組織という系において、ほっておくとエントロピーは増大する。複雑なほうが安定するが、制御できなくなっていく。レガシーシステムを整理したりコードを消したりすることにモチベーションを覚えるのは、そのあたりにありそう。他の人がそうでないなら自分の強みであると思う。

www.christopherspenn.com

ひとつずつやること

ただでさえ少なめな思考力が、近年ずんずん落ちている感覚がある。特に今年は、複数のプロジェクトに同時に関わることが増えてきて、いわゆるコンテキストスイッチが追いつかず、おしごとの精度が劇落ちくんだった。例えばメンションされたときに、自分の意思とは関係なく反射的に不要なコンテキストスイッチを発生させているきらいがある。ひとつずつ精度と速度をもってつぶしていくのはもちろん有効だが、一朝一夕にはできない。つきつめるとタスクの粒度が粗く見積れてないのが原因でもある。すぐ飽きるし、ポモドーロみたいな一般的なメソッドは前世で1000回挫折している。やるならそれよりも前の段階、手を動かす前にゴールの解像度をあげることで、それ自体を訓練することです。つまり前項と同じ。直列おしごとやっていきます。

わからんということ

プルリクエストに十分な説明がないとか、Slackでポストされた日本語が読めない(主語が不明瞭、文法が間違っている、等)とかに対して「わからん」と跳ね返したり修正を依頼することがわりとある。リモートワークが前提になったことで、如実にその場面が増えた。細かいことを言っているつもりはなく、本当にわからないからそういっているのだが、どうやらみんなは雰囲気を読めるらしい。頭が良すぎる。

若いころからいまに至るまで、「何のためでしたっけ」とか「意味ありますか」みたいなことを空気を読まずに言ってしまう。完全にイタいやつ状態になることもあるが、議論の対象としている問題の認識が人々の間でズレていたり、そもそも問題が存在しなかったりすることが体感で6割くらいあった。超高度な経営上の意思決定でもないかぎり、「やってみないとわからない」ということは基本的にないはず。少なくとも、検証に値する仮説くらいはもっておかないと、労働時間に対して対価を受け取っている立場としての責務を果たせないとおもう。という理想論をもちながら、嫌われない程度にやっていきたい。

www.eijipress.co.jp

わかっていくこと

昨年末から年明けにかけて、おしごとに関連してPostgreSQLの通信プロトコルを調査する機会があった。理解のためシリアライザをつくり、それを題材にして3月のアンカンファレンスで発表した。シャ外へのアウトプットはこれとレガシーのブログとインタビュー記事くらいで、ほとんどなかった。

kyabatalian.hatenablog.com

最新の技術とかも関心が無いわけではないが、自分はどちらかというと、こういう基礎に興味があり、かつ「わかる」という感覚に充足感を覚えることを再確認した。もともと何かを習得するのに他者より時間がかかる自覚があるし、年齢や健康状態も相まって新しいことを学習し身につける能力が年々落ちていっている恐怖がある。それでも人生は続くので、PostgreSQLのプロトコルのように、必要なもの、関心にひっかかったものについてちゃんと手を動かし、ゆっくりでも積み上げていきたい。

健康

もっとも重要。昨年はわりと体調を崩しがちだったのだが、その頻度は減った。昨今の情勢にあわせて在宅勤務になり、予防策を講じるようになったことが効いていると思われる。ただ、露骨に疲れやすくなった。在宅勤務しながらも意識して散歩したり、たまに運動する機会を設けたりとしてみたが、あまり効果はなかった。また、精神的な落ち着かなさも増幅している。これは体調不良と同時に、社会動物としての根源的欲求が損なわれている、つまり「寂しい」という感情によるものが一因になっていそう。2021年は人間と関わりたい。みなさまどうか仲良くしてください。

体重を増やすことに失敗した。あぶらっこいものを取りすぎると胃の調子が悪くなって食べる量が減ってしまう。お菓子を食べすぎているのかもしれない。健康的に体重を増やすために、根源的な欲求に訴えかけること、つまり「美味しいものを食べる」ことなのではないかと思い、コンビニ等の既製品を避け、宅食やOisixなどを活用し始めている。間違っても不健康に太ろうとしてはいけない。

趣味

ステイホームという言い訳の名のもとに、今年もけっこうな数のマンガを読んだ。その中でも『阿・吽』というマンガがとりわけよかった。

csbs.shogakukan.co.jp

最澄と空海に関する史実をベースにした内容なのだけど、小説でも映像でもなくマンガでなければなし得ない表現やその迫力がめちゃくちゃすごい。作者のおかざき真里さんは『サプリ』や『&』を書いた方で、現代的な人間の心情の機微と相関する部分もおもしろい。

コテンラジオというポッドキャストで最澄と空海のシリーズをきいて、ちょうど興味が湧いていたタイミングだった。コテンラジオは最澄と空海以外にも、様々な歴史情勢いついておもしろく話してくれるので、こちらも超絶おもしろい。

cotenradio.fm

日常的にお笑いライブにいくおじさんとしての活動は、さすがにほぼ自粛となった。オンライン配信でもいくつかみたが、やっぱり生のおもしろさには及ばない。はやく平和な世の中になって、ライブをたくさんみにいきたい。M-1グランプリ2020ではウエストランドが決勝進出して感無量だった。M-1グランプリ2021では(決勝進出経験者を除くと)シシガシラ、黒帯、ランジャタイ、キュウ、ダイヤモンド、ダイタク、真空ジェシカ、モグライダー、ロングコードダディ、滝音、コウテイあたりが活躍しそうと予想しておく。

2021年に向けて

いろいろあるけど、たくましく生きていきたい。

f:id:kyabatalian:20201231175945j:plain

『プログラミングの心理学』を読んだ

在宅の日々、だいたいラジオをきいて過ごしている。radikoだけでは飽き足らず、この世のすべてのラジオアプリをインストールし、Podcastをダウンロードし、耳から注入している。

shop.nikkeibp.co.jp

先週読んだ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版』を読んだ

新型コロナウイルスも落ち着きつつあって、よさそう。そろそろ物理出社が怖くなってきた。というわけでぶっとい本を土日にガッと読んだ。

www.nikkeibp.co.jp

めっちゃ有名。「おすすめ技術書」みたいなウェッブ記事でだいたい挙がってくる、バイブル的なやつ。著者はSteve McConnell氏というかたで、Microsoft社やBoeing社に勤務された経歴あり、1993年に本書の初版を出版している。2003年にオブジェクト指向をとりいれた第2版が出版された。紙の本だと上下で1000ページ超えという鈍器のようなもの。

Amazonの履歴をみると3年前に購入していた。上下巻で出版されているが、自分はそれらがあわさった電子合本版をKindle半額セールで買った。そのときにも読んでいる(はずだ)が、当時から3年もたっているので、読みとる情報も違ってきそう。と思って再読した。何より、記憶がまったくない。

全体の感想としては、さすがバイブルに紹介されるだけあって、説明がわかりやすく、サンプルコードも豊富で読みやすい。ソフトウェアエンジニアが経験的に取得していく知識や考え方が綺麗にまとめられている印象を受けた。なんとなく考えていたことが明文化されているかんじ。自分の力だけで整理するには規模が大きすぎるため、本書はその助けになりそう。また、こういった本を読むと、力の入れどころがわかる、みたいなのがある。「見積もりってだれがやってもしんどいんだなあ」とか、「設計レビューでフルボッコにされたけど、だれも答えはわかってないんか」とか。経験がないとついネガティブな感情になりがちなところを、知識でフォローできる。

ただ、本書に限ったことではないが、やはり実感が伴わないと理解にはつながらないとおもう。3年前の自分もたぶんそうだったし、3年後の自分が再読すると、また同じことを感じるかもしれない。特定技術ではなくこういった網羅系の本は、自分にマッピングしながら読みすすめる、マッピングできない部分は未来の自分に託して読み飛ばす、くらいの読み方がいいのかもしれない。

参考文献が豊富に紹介されていて、ここからさらに理解を深めたい領域の本をたどっていくのも良さそう。Kindleで読みながらマーカをつけていたので、以降ではその中から引用して、感想をまとめている。引用末尾の数字は、Kindle上の位置。何年後かの自分に読まれたい。

第1部 基礎を固める

ソフトウェアプロジェクトをいくつかの工程にわけたとき、一般にプログラミングや開発と呼ばれる工程あるいは詳細設計などを、「コンストラクション」と読んでいる。これは建築のメタファである。そして、コンストラクションの前段階がプロジェクトの成否を決めると説明している。

ソフトウェア開発プロジェクトのリスクで最も目立つのは、準備不足とプロジェクト計画不足である。(1140)

ソフトウェア開発の工程は基本的に不確実性を減らしていく作業と理解している。不確実性はソフトウェアの完成が近づくにつれて減少していく。それをいかに早い段階で最小化できるか、という問題を解くのがプロジェクトマネジメントの能力だと思っている。コードを書く(というメタファの功罪であるが)作業は、不確実性が最小化された状態で行うべきであり、そのためにプロジェクトの前半に投資が必要となる。

この段階での手戻りは、後段のプログラミングの手戻りと比べると、比較にならないくらい被害が大きい。

コンストラクションを始める前に完了しなければならない最初の準備は、システムが解決するはずの課題を明記することである。(1331)

プロジェクトのスタートは「要件定義」ではなく、本質的には「課題定義」としている。何を解決するプロジェクトなのかを確実に言語化し、ステークホルダー間で合意しておくことが、まずスタートラインになる。これをやるのは開発担当者ではないケースは往々にしてあるが、少なくとも「課題は何か」と、次段階にあたる要件を満たせば、その課題が解決されることは、理解しておく必要がある。そもそも課題を解決する最適な手段が、ソフトウェア開発ではないかもしれない。

www.eijipress.co.jp

準備が不十分になる一般的な原因は、上流の作業を担当する開発者が、与えられた仕事をこなすための専門知識を持っていないことである。(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)

忘れがち。このあたりは、自分自身の生産性を最大化する意味でも課題になる。推薦書籍として以下がたびたび挙げられている。

shop.nikkeibp.co.jp

プログラミングを排除させない原動力となったのは、たとえ十分なツールのサポートがあったとしても、プログラミングが本質的に 難しい ことである。

10年前の本書でも、いまでも、プログラミングはいつかなくなるといわれているけど、いっこうにその気配がない。飯の種にはしばらく困らなさそう。本質的に複雑性への対処である。

コードを書くときには、あなたのプログラムを保守するだれかが、あなたの居場所を知っている凶暴な変質者であると心得よ。   ── 作者不詳 (10716)

ここまでではなくとも、将来の若者にdisられないように、怯えながらコードを書きましょう。そうでなくとも、人への優しさ、慈しみ、そういった心が大切です。

『第12回 PostgreSQLアンカンファレンス@オンライン』に参加した

もともと3月に開催が予定されていたのだが、新型コロナウイルスの影響で中止となっていた。この度、ユーザ会の方々がオンラインでの実施を企画してくれた。運営の皆様、本当にありがとうございます。

pgunconf.connpass.com

せっかくなので発表した。PostgreSQLのプロトコルを理解するために、シリアライザを実装して、実際にPostgreSQLと通信してみる、という内容。実装の雰囲気とか、簡易プロトコルと拡張プロトコルの比較などを紹介した。

speakerdeck.com

だいたい以下の記事の抜粋+デモというかんじ。

kyabatalian.hatenablog.com

絶妙に需要のなさそうな内容で不安だったが、普段意識することがないぶん、逆に関心を持ってくれたっぽい。常時100人強の方が視聴してくれていたらしい。オンライン勉強会は初めてだったのだが、聞く側としてはリラックスした環境で聞けるし、画面の文字やデモもみやすくて体験としてはとてもよかった。逆に話す側としては、反応がわからなくて、だれも聞いていないのではという不安があった(実際に途中で「いま聞こえてます?」と聞いてしまった)。今後自分が聞く側になるときは、どうでもいいことでもなるべくチャットで反応するようにしようと思った。

PostgreSQLのアンカンファレンスは、第8回に初めて参加して、そのときが人生初の勉強会登壇だった。それから2回に1回くらいは参加している。毎回ゆるい雰囲気で、発表するときは比較的気軽にできる仕組みになっている。今回もそのノリで何も考えずに発表枠で申し込んだのだが、自分以外の発表者がPostgreSQLのコミッタとか、PostgreSQLで銭を稼ぐレベルの方々で、若干の後悔をしていた。当日は場違い感を感じつつも、好意的な反応をいただけて自分としては満足している。感謝。

あまり空気を読まずに発表枠でやっていっても、みなさん優しいので受け入れてくれることを実証したともいえる。気にせずいきましょう。他の方の発表は例にもれずすごいレベルで、聞いていてたいへん興味深かった。ただし完全な理解にはほど遠いので、もったいない気持ちになった。理解して議論を楽しめるように精進していきたい。

前回参加したときは、何も準備せずにいって会場でスライドをつくって発表し、結果準備不足を露呈したり他の方の発表が聞けなかったりして、会に対して無礼をしたと猛省していた。それにくらべて今回は、もともとブログにしていたものをベースに発表をつくるだけだったし、前もって準備していたので、同じ過ちを繰り返さずにすんだ。何をするにしても人より時間がかかってしまうタイプの人間であることを忘れがち。

プログラミングあまり得意ではないけど嫌いではないので、ぼちぼち楽しくやっていきたい。ハッカーになれるようにがんばります。

PostgreSQLクエリプロトコル概観

コロナのせいにして引きこもってPostgreSQLと遊んでいたので、ブログにまとめてみる。

年末のPostgreSQLアドベントカレンダーで、PostgreSQLのプロトコルについてちょっと書いた。同僚や社外の人間など、話題に出して貰う機会があったが、「そもそも、簡易プロトコルと拡張プロトコルの2種類があることを知らなかった」という話を複数回聞いた。たしかに、普通にアプリケーションを開発する場合、プロトコルはクライアントインターフェイスに隠蔽されていて、意識することはない。せっかくなので、そのあたりもう少し雰囲気がわかるように書いてみようかなという気持ちになった。

続きを読む

『モチベーション3.0』を読んだ

あけましておめでとうございます。お正月休みに実家で読んだ。いまさら感&非技術書で書くほどのこともないけど、感想を晒す。

bookclub.kodansha.co.jp

いわゆるビジネス書の類でベストセラーになっているし、まずタイトルが胡散臭い。単純労働から創造的労働が主体となる社会において、モチベーションに対する考え方も変える必要がある、という話。著者によるTED動画があるのでみてみるとよいかも。

www.ted.com

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%を使って好きなことをやっていい、というやつ

*3:https://fs.blog/2015/03/carol-dweck-mindset/