勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

システム設計の現実に触れる「SYSTEM DESIGN INTERVIEW」を読んだ

book Professional Engineer

読むのがホネな技術書やビジネス書を取り上げて２週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第59回。同僚と読書期限を約束することによって積読が確実に減るという仕組み。過去記事はこちら。

さて、今回読んだのは「システム設計の面接試験」である。微妙なタイトル。原著のSYSTEM DESIGN INTERVIEWの方が有名な気がする。

システム設計の面接試験

システム設計の面接試験

Amazon

先に言っておく

Amazonのレビューにも書かれているが、日本語翻訳の品質には課題がある。わたしは許容範囲だった。試し読みを推奨する。気になる場合は原著を購入するか、オリジナルのオンラインコンテンツを購読すれば良いだろう。

システムデザイン・インタビューとは何か

システムデザイン・インタビューとは、ビッグテックを中心にエンジニアの採用試験で課される課題の一種である。抽象的なシステム仕様に関する質疑応答の中で、どのようなソフトウェアを構築するかを答える形式が一般的のようである。その存在を最初に知ったときは「本当にそんなことをやっているのだろうか」と疑問をもったものだが、実際に海外にいる知り合いが遭遇したという話も聞いたので、実際にやっているのだろう。

というわけで本書「システム設計の面接試験」はその面接対策の本である。全てではないが、各章では候補者と面接官のやりとりなども紹介されていて興味深い。たとえばこんな感じである。

候補者：これはモバイルアプリですか、それとも Web アプリですか、それとも両方ですか？
面接官：両方です。
候補者：製品において最も重要な機能は何ですか？
面接官：投稿できること、友だちのニュースフィードが見られることです。
候補者：ニュースフィードの並び順は、逆時系列純ですか、それとも特定の順序ですか？
面接官：シンプルにするため、フィードは逆時系列でソ ー トされていると仮定しましょう。

こういうやりとりをしながら、システム設計について答えていくのだ。難しい！けど、面白そう！

結果として面白い本になっている

というわけで本書はシステムデザイン・インタビュー対策本として

  • 代表的な課題（例えばWebクローラとか、URL短縮サービス、デカいものであればYouTube）に対し
  • 課題の整理
  • おおまかな設計
  • さらなる深掘り
  • 関連する情報リンク

が提示されるという構成となっている。

英語版だが、チャットシステムの章の内容が公開されているので興味があれば見てみると良い。

この構成が本書の面白味になっている、というのが本書の感想である。

  • よく知られている大規模サービスの大まかな設計イメージが理解できる
  • 様々なアーキテクチャの課題、ハマりどころについてわかる
  • おおまかな見積もりの方法を知れる
  • 実際のプロダクトやコードまでは突っ込まないので、各章の読み味は軽い

というわけで自分としてはだいぶ楽しい本であった。

これはエンジニア教育にも活用できるのでは

と思ったら、いろいろとすでに実践されている方がいた。参考にしたい。

ネット上にはアーキテクチャパターンに関する情報が大量に存在するので、時間をかけて検討調査すればそれなりのシステムデザインを考えることはできるだろう。一方で、白紙の状態で行う最初のディスカッションが重要である。瞬発力というか、構想力を鍛えるためには本書で紹介されているレビューのアプローチは有用ではないだろうか。

関連情報

というわけで本書は読了。次は何を読もうか。最近気になっている本はこんな感じ。

2023/11/14 Findyのイベントで要件定義に関して話します

Requirement Developments

先日公開した「実践要件定義入門以前」と「実戦要件定義入門」の記事からお声がけいただき、少し時間を貰って話をすることになった。X（旧：Twitter）がいろいろと壊れているので、ここでも告知しておく。

findy.connpass.com

先の記事で書かなかった（うまく文章化できなかった）ことを紹介する予定。興味があればご参加いただきたい。

「Gitlabを学ぶ」を読んだ

book Professional Engineer

読むのがホネな技術書やビジネス書を取り上げて２週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第58回。同僚と読書期限を約束することによって積読が確実に減るという仕組み。過去記事はこちら。

さて、今回取り上げるのは有名な「GitLabに学ぶ 世界最先端のリモート組織のつくりかた ドキュメントの活用でオフィスなしでも最大の成果を出すグローバル企業のしくみ」である。フルリモートで有名なGitlab社について惚れ込んだ著者が同社の働き方を日本企業向けに紹介するという本である（監修にGitlabで働いている方も参加している）。

GitLabに学ぶ 世界最先端のリモート組織のつくりかた ドキュメントの活用でオフィスなしでも最大の成果を出すグローバル企業のしくみ

GitLabに学ぶ 世界最先端のリモート組織のつくりかた ドキュメントの活用でオフィスなしでも最大の成果を出すグローバル企業のしくみ

Amazon

なぜこの本を読もうと思ったのか

Gitlabは先進的な働き方をしている企業として有名で、日本では例えばデブサミで2022年に行われた以下の講演なども話題になっている。

codezine.jp


わたしもこの講演はチェックしていて、いろいろ刺激も受けている。
そしてGitlabはこういった働き方等について、オープンに文書を公開している……のだけれども、内容が膨大なのでパラ読はしたが「あとで読む」状態のまま、ほったらかしにしていたのが実情である。

というわけで、読むのが骨なGitlabのHandbookを見どころを中心に紹介してくれる本書は、大変にありがたい。

全体的な感想

本書の著者の千田さんは、現在はLAPRASという会社で人事責任者をされているそうだ。自社でもGitlab Handbookを参考にした改革を推進されているとのこと。実際に同社もGitlabにならってハンドブックを公開している。

本書はそんな著者が自組織にGitlab的な考え方を導入するにあたって調べまくった（だろう）内容が惜しげなく共有されているという意味で、とても良い本となっている。
ただ、残念な点は 技術者視点がほとんど入っていない というところだろう。目次を見てもわかるが、Gitlab Handbookの中のエンジニアリングの章はほとんど紹介されていないのだ。

とはいえ、足りない観点は自分でGitlab Handbookを読めばいいわけで、まずは読むとっかかりとして本書を足がかりにすればいいんだろう。

Single Source of Truth を日本企業で持てるか

Gitlabでは、Handbookを信頼できる唯一の情報源（Single Source of Truth：SSoT）として全ての情報をHandbookにまとめ、あらゆる判断に利用しているそうだ。実際に著者の企業でも試行中のようだし、他にもテック企業では開発部門などで試行している事例はあるようだ（どこかにまとまってませんかね）

とはいえ、こういった試みが成立しそうなのは小規模な企業とか若い企業に限定されるような気もする。
トラディショナルな日本企業であれば一般的に職務規定や就業規則が必ず存在すると思うのだが、これらはGitlab Handbookとは真逆の存在だ。従業員でも頻繁に閲覧せず、クローズドで、ハイコンテキストなものになっている。ここから転換（反転）してオープンで明確なSSoTを基準としたしごとのしかたを実現するのは、だいぶ難しそう。そういう意味では先ほど紹介した事例のように、まずはエンジニアリング組織を中心にトライしていくのが早道かもしれない。

というわけで本書は読了。次は何を読もうか。最近気になっている本はこんな感じ。

汎用的なデジタルリーダーシップ本としての「プロダクトマネージャーのしごと第２版」

Project Management Professional Engineer book

先日、オライリーのSNSキャンペーンで当選して「プロダクトマネージャーのしごと 第2版 ―1日目から使える実践ガイド」をプレゼントいただいた（皆さんも根気強く申し込みましょう）。自分は普段プロダクトマネジメントを仕事としているわけではない（サポートすることはある）のだけれども、どっこい本書はそんな私にも使える、というよりむしろデジタル仕事全般について役立ちそうな本であった。どうしてそう感じたのかを説明する。


「プロダクトマネージャーのしごと 第２版」の紹介

ソフトウェア業界におけるデジタルプロダクトのマネジメントをする人＝プロダクトマネージャーの「やるべき事」ではなく、「気をつけるべきこと」について書かれた本である。よって、プロダクトマネジメントの方法論ではないため、プロダクトマネジメントを行う人が一冊目に読む本ではないと思う。二冊目でもないかも。本の紹介は訳者のryuzeeさんのこのページがおすすめ→ 【資料公開】プロダクトマネージャーのしごと | Ryuzee.com

プロダクトマネージャーのしごと 第2版 ―1日目から使える実践ガイド

プロダクトマネージャーのしごと 第2版 ―1日目から使える実践ガイド

Amazon

汎用的なデジタルリーダーシップ本として読めるのでは？

本書の冒頭で語られるプロダクトマネージャの責任はこのようになっている。

  • チームメンバーのベストを引き出す
  • 自分と一緒に働く直接のインセンティブがないような、自分の直属のチーム以外の人と一緒に働く
  • 曖昧さに対処する

確かに、人に実際に価値を提供できるプロダクトを生み出すのは、プロダクトマネジメントにおける最も重要な側面の1つで、やりがいもあります！でも、こういったプロダクトを届けるための日々の仕事は、コミュニケーションやファシリテーション、支援の仕事のほうが多く、作るという仕事はそれより少ないのです。

これ、プロダクトは関係なく、デジタルに関連したITエンジニアと共同作業する全ての仕事に共通する話なのでは……

実際この後の本書の内容は、ソフトウェア開発のプロジェクトマネージャーだろうと、ソフトウェア開発組織のラインマネージャーであろうと共通的な仕事で考えるべき論点を多く取り扱っている本である。というわけでプロダクトマネジメントに関係ない人ももっと読んだ方がよい良書だというのがわたしの感想である。

お気に入りの（プロダクトマネジメントに関係なく）使えそうな内容の紹介

  • 1章　プロダクトマネジメントの実践
    • 「終わらせる必要があれば、それがあなたの仕事である」　ああ、そうだね（白目）
  • 4章　過剰コミュニケーションの技術
    • 「コミュニケーションはあなたの仕事。仕事をすることで謝罪してはいけない」　勇気をもらった
  • 5章　シニアステークホルダーと働く（ポーカーゲームをする）
    • 章タイトルだけで泣ける
    • 「警告なしで驚かさない」「社内政治の世界でユーザー中心主義を貫く」「シニアステークホルダーも人間だ」 グサグサくる
  • 7章　「ベストプラクティス」のワーストなところ
    • この章が一番好きです
    • 「フレームワークやモデルは有用なフィクション」 知ってる
  • 8章　アジャイルについての素晴らしくも残念な真実
  • 9章　ドキュメントは無限に時間を浪費する（そう、ロードマップもドキュメント）
    • ドキュメントを書くことの重要性と、一方で効率性に関することが述べられており有用な章。
    • 「メニューは食事ではない」　この言葉が重い
  • 11章　「データ、舵を取れ！」
    • 『本当のデータドリブンな手法を取り入れたいプロダクトマネージャーに「データという言葉を一切使わないでください」とよくアドバイスします』　神アドバイス
  • 12章　優先順位づけ：すべてのよりどころ
    • この章もいいことがいっぱい書かれていて悶絶する
  • 13章　おうちでやってみよう：リモートワークの試練と困難
    • 「さまざまな人たちからなるさまざまなチーム間で信頼関係を築くための唯一のレシピや戦術ハンドブックはありません」　気づいています

というわけで本書はとてもオススメである。
プレゼントでいただいた物理書籍はオフィスに置いて、電子版も買った（電子版はAmazonではなく、オライリーのサイトからの購入となる）。

実践要件定義入門

Requirement Developments

最近ネットを見ていると要件定義入門的な記事とか、あと要件定義は不要みたいな記事が目についたので思ったことを書いてみる記事その２。ITシステム開発における要件定義に関するあれこれ。本記事には前編があります。

目次

要件定義以前

要件定義というプロセスが本当に必要なのか、ということなどは以下の記事に書いたので省略。

要件定義の進め方

IPAユーザのための要件定義ガイドをベースにする

前編にも書いたが、わたしはIPAユーザのための要件定義ガイド（第２版）をリファレンスにすることをお勧めしている。これでいいんだよ。

ユーザのための要件定義ガイド第2版

ユーザのための要件定義ガイド第2版

Amazon
便宜的にAmazonのリンクを置いておくが、以下のサイトでPDF版のダウンロードも出来る。

決め過ぎない

要件定義でもっとも難しいのはこの「決め過ぎない」ということだ。要件定義が不十分であってもダメだが、やりすぎてもダメなのである。ただし、どこまでやれば良いかという基準があるわけでもない。要件定義のバイブルでもある「ソフトウェア要求　第3版」では以下のように書かれている。

要求分析の中で重要なのは、概要レベルの要求を分解して、それを明確化し具体化できるだけの詳細を明らかにすることである。「要求は、どこまで詳細であるべきか？」、これはよく聞かれる質問だが、唯一の正解はない。開発チームの知識と経験に基づいて、誤解されるリスクを最小化できる程度の詳細を提供する。要求の問題に関して継続的に話し合える機会が少ないほど、要求セットをより詳細に記録する必要がある。開発者が、要求を満たす方法をいくつか考えつき、そのすべてが受け入れ可能なら、具体度と詳細度はほぼ適切だと言える。以下の場合には、より詳細にしなければならない。

では、どの程度やれば、ちょうどよいのだろうか。だいたい、この程度が妥当と考えている。

  • 要件定義後の活動（一般的には設計など）の指針であって、指示にはなっていないこと
    • 前述の「ソフトウェア要求　第3版」の引用にあるように、開発者が要求実現方法を複数検討することが出来る程度の曖昧さが必要である
    • 具体的な仕様を決定しすぎてはいけない（なぜなら、システム開発を進めていく中で仕様は変化や進化していくことが多いからである。要件定義で具体的な仕様を記述しすぎてしまうと、後でより良い仕様が発見されても取り込まれなくなってしまう）
    • 要件定義の終了後、（要求の追加変更以外で）作成したドキュメント類の変更が出来る限り少なくなるように書かれた要件定義が、よい要件定義ともいえる（ほどほどに具体的で、ほどほどに抽象的）
  • 要件定義後の作業の規模がざっくり計画できる（見積もれる）程度には具体化されていること
    • 議論の余地がありそうだが、インターフェースの数（UI、レポート、API、その他）やバッチ処理等の概数、連携対象システム数などは明らかにしておきたい（ただし要件定義時点の試算であり確定としないほうがよい）
    • この表現はSIer臭が強いが「見積もれる程度には具体的に」「数えられるものが、数えられる程度に」

まあ、明確な基準は存在しないので最後は経験的に判断しなければならないだろう。やりすぎを防ぐためには「分析地獄」というアンチパターンを見ておくと良いかもしれない。

機能を定義するのではなく、機能要件を定義する

機能を定義するのは設計であり、要件定義では機能要件を定義するべきだ（ただし例外はある。後述する）。

  • いわゆるユースケース、またはユーザーストーリーという形式を取るべきだ
  • 例えば「ログイン画面」という機能について定義するのではなく「ログインする」という要求について定義しなければならない
    • どうして後者を取るべきなのかというと、機能（前者）はシステム／プロダクト中心の発想であるからダメなのだ。まだ存在しないシステムを中心に検討すると目的や利用者の視点が失われることがある
    • 機能要件（後者）であれば主語はユーザーとなる。ユーザーが何を成し遂げるべきか、それがすなわち要求である

なお例外はあって、ある種のシステム／プロダクトを分析する際にはこのアプローチはうまくいかない。またもや「ソフトウェア要求　第3版」から抜粋しておこう。

たとえば、バッチプロセス、計算集中型のシステム、業務分析、データウェアハウスなどのアプリケーションでは、ほんの少しのユースケースしか出ないだろう。この種のアプリケーションの複雑性は、実施する計算や、発見して使用するデータや、作成する報告書にあり、ユーザーとシステムの相互作用にあるのではない。　ユースケースやユーザーストーリーは、多くの組込みシステムやその他のリアルタイムシステムの仕様作成にも向いていない。

言い換えると、システムと人間がたくさんの相互作用を行うシステムだったら、ユースケース等を使って要件定義をしたほうが良いということになる。

関係者をすべて洗い出す

要件定義は利害関係者の要件を洗出して整理し定義するプロセスである（あたりまえだ）。ということは、利害関係者すべての要求を確認しなければならない。よって、関係者をすべて洗い出す必要がある。

  • 前項の「機能を定義するのではなく、機能要件を定義する」理由とも関係する。機能（例えば「ログイン画面」）のことばかり検討していると、利用者のことが軽視されることがある
    • ひとくくりにシステムの利用者を「ユーザー」とするのが一番まずい。「担当者」や「承認者」とか、「企画部門」とか「〇〇部署」などを分類しなければいけない。この分析を怠ると、要件の聞き忘れがおこる（そうすると、後でだいたいひどい目にあう）
  • 利害関係者を洗い出したら、「利害関係者の代弁者」も決定するとよい。そして、利害関係者または代弁者がすべて要件定義セッションに参加しないと、要件は漏れる。例えば経理部門が関係やであれば直接または「経理部門の代弁者」に話を聞かなければならないからだ

利用者マニュアルの目次が作れるようになっているか

良質な要件定義のアウトプットは、そのままマニュアルの目次に変換できる。そうなっていない要件定義はよろしくない。

《ダメな例》

  • ログイン機能
  • 一覧画面
  • 入力画面
  • 確認画面

《良い例》

  • ログインする
  • 登録内容の一覧を確認する
  • データを入力する
  • 入力したデータを確認する

おわかりいただけたであろうか……
なおマニュアルの目次が作れるということは、テストシナリオも作れるということでもある。

ビジネス要件定義

前提事項、制約事項とリスクを定義する

要件定義は（新しいことを考えるという意味で）本質的には愉しく、そして発見された要求について深掘り、詳細化する方向に向かいやすい。結果として前提事項や制約事項、リスクなどの洗出しが軽視されやすい。ここには大きな落とし穴がある。

  • ここでいう制約事項は法令、商慣習、予算や特定技術採用、技術人材、再利用素材などである。他にもあるかもしれない
  • 確定できない制約事項は仮決めを行うこととなり、それが前提事項となる
  • リスクは発生するかもしれない将来の予測である（なお、リスクに対しては対策も考えておくべきである）

前提事項、制約事項とリスクは全ての利害関係者に確認する必要がある。忘れないようにしよう

優先順位の決定を忘れずに

省略されがちであるが、要求に優先順位を付けることを漏らさないべきである。

要件定義において抽出されたすべての要求（手段）を実現することができるプロジェクトは稀である。膨らむ要求を限られた工期やコストの範囲に抑え込むためにも、要求には優先順位をつけて、効果の薄い要求や贅沢な要求は捨てる選択をしなければならない。また、昨今では、リーンスタート的な発想で、最低限必要な機能でまずリリースして使用してもらい、実績を評価して徐々に成長させていく（もしくは止める）手法のシステム開発を選択する場合もある。いずれにしても、どの要求は先送りできるのかを判断できるようにしておく必要がある。

要求に対する優先順位付けについては上記の通りであるが、優先順位を付けることは言葉通り以上の意味を持つということも理解しておくと良い。

要求に優先順位を付けると、目標が競合していることがわかったり、衝突を解決したり、段階的またはインクリメンタルな引き渡しを計画したり、スコープクリープをコントロールしたり、必要なトレードオフを決定したりするときに役立つ。

「全部が最優先」「全てマスト」と言いたい気持ちをぐっとこらえて、要求の順位付けについて考えよう。

システム化要件定義

不安定な要件を構造で支える

本質的に、ITシステムやソフトウェアの要件は不安定なものである（実体のある建築物やプロダクトに比べて、物理的制約を受けないため）。だから様々な工夫をしてこの不安定な要件を支える必要がある。様々な手法が存在するが、基本的には要件を構造的に強化しようとしているものだ。

  • ダイアグラムの利用
  • 複数の視点での要件の整理
    • （IPAユーザのための要件定義ガイドに即せば） プロセスの観点と、データの観点、その相互関係を整理することがビジネス要件の安定性を高めている。システム要件については機能要件とデータ要件をCRUD表で整理することで安定性を高めている
  • 機能要件と非機能要件の関係性も同じで、非機能要件によって機能要件の不安定さをカバーするのである

個人的に好きな組み合わせはユースケース記述（棒人間図ではなく文章で表現するもの）、フロー図、概念データモデル、ビジネスルールの4点の組み合わせだ。ただこれは手慣れたツールというだけで深い意味はない

  • 複数の機能要件（ユースケース）に登場する要件はビジネスルールにまとめる。これにより、機能要件間の一貫性を保ちやすくする
  • 機能要件間の連続性をフロー図で確保する。フロー図をなぞる事で全体の正しさが確認できるようになる
  • 機能要件とデータモデルの整合性を見ることによって、データ観点の見落としや矛盾を見つける

例えばこんなイメージ

とりあえず言いたいことを書いてみたが、だいぶ長くなってしまった。言いたい事は一通り書いたつもりだが、また何か思いついたら書こうと思う。
フィードバックやツッコミはX（旧Twitter）かはてなブックマークあたりでどうぞ。

おまけ：本記事の元ネタ

本記事の作成にあたっては、10年程前まで幹事をやっていた上流工程勉強会コミュニティで諸先輩からいただいた様々なコメント、あとは趣味的に読み続けている要件定義周辺の書籍を参考にしている。思い出せるものを列挙しておくが、古い本も多いので注意していただきたい。

おっさんエンジニアの放送大学教養学部に入学記録7（4年目前期終了）

Study

2020年4月から放送大学の教養学部「人間と文化コース」に入学して、これまで勉強してこなかった人文系の勉強を始めている。4年目前期が終わったので感想をまとめておく。

目次

もうすぐ50のオッサンが放送大学の全科履修生として気ままに授業を取っている。理系の大卒資格は取っているので卒業をゴールにはしていないのでペースはゆるめ。というわけで4年生だが特にあせりもない。なお、大学生として各種の学生割引は利用しているし、放送大学の図書館サービスを経由して論文や業界紙へのアクセスも可能なので割とお得な趣味である。授業はBSで放送もされているが入学すれば放送授業は全話ネットで視聴できるので好きなペースで進めることができる。

4年目前期に受講した科目

卒業を目標にしていないので、半期に2科目受講＋1科目聴講を目安にしている。放送大学に入学した目的は人文系の教養力アップなので、芸術系、哲学系、文化人類学系を中心に選ぶようにしている（が、最近は心理学系も気になっている）。この半年で受講した科目はこちら

より良い思考の技法（’２３）

より良い思考の技法: クリティカル シンキングへの招待 (放送大学教材)

より良い思考の技法: クリティカル シンキングへの招待 (放送大学教材)

Amazon

情報を的確に評価し、合理的に考えてより良い判断を下すための実践的な思考法が「クリティカル・シンキング（批判的思考）」である。これは相手を否定する「批判」ではなく、自分の推論を意識的に吟味する内省的・熟考的思考であり、また証拠にもとづく論理的で偏りのない思考法である。本講義では、さまざまな学問領域、市民生活、職業実践に共通する汎用的思考スキルとしてクリティカル・シンキングの基本を学び、さらに「実践」として現代社会の具体的な問題場面への適用を考えていく。

youtu.be

日本仏教を捉え直す（’１８）

日本仏教を捉え直す (放送大学教材)

日本仏教を捉え直す (放送大学教材)

Amazon

今日、仏教研究は次第に新しい進展を見せ、従来の常識は大きく書き換えられつつあるが、それらの研究成果が必ずしも広く共有されているわけではない。本講義では、３人の講師によって、日本仏教に関する最新の成果を披露し、常識的な理解を見直すことを目指す。頼住講師は、主要な日本の仏教者の思想を取り上げ、現代の場からこれらの思想の読み直しを迫る。大谷講師は、近年大きく進展した近代仏教研究の成果を披露し、現代につながる問題を考える。末木講師は日本仏教の深層の発想を捉え直して、それが今日どのような意味を持つか考える。３人の講師により異なる視点から照射することで、日本仏教の豊かな内容が立体的な視点から明らかにされるであろう。

  • ラジオ講義。基本的にはテキストに沿って進めていく形式である
  • もともと哲学に興味があって放送大学に入学し、これまで西洋哲学についていろいろ触れてきた。ここで東洋哲学にも触れたいとおもって選択した講座。身近だけれども知らなかった知識が多く、教養的な意味でも大変によい講義選択だった。
  • 前半は代表的な仏教思想（宗派）の概説。過去に日本史という枠組みで触れてきたかもしれない内容だが、仏教に絞って説明されると理解はし易い。日常的に観光でお寺に行くことはあるが、まったく何も自分は理解していなかったことを恥じる。解像度が上がることが楽しい。
  • 中盤は仏教の近代化、後半で現代におけるわれわれの生活と仏教の関係性などについて論じる。葬式や墓参りなどについても、そんなこと考えたことがなかったという話が多くて、たいへんに勉強になった。

新しい言語学（’１８）

新しい言語学: 心理と社会から見る人間の学 (放送大学教材)

新しい言語学: 心理と社会から見る人間の学 (放送大学教材)

Amazon

言語学の中でも比較的最近発展してきた領域と方法論を取り上げて講義する。なかでも、言語に対して心理や社会の観点からアプローチする認知言語学、言語習得論、談話分析、社会言語学に着目する。それらは、心理や社会という観点を通して人間にとって言語がどのような位置にあるのかを明らかにしてくれるだろう。

来期（4年目後期）の予定

以下を受講予定。

これまでの記録

受講の感想

  1. 若手が育たないとか言っている暇はもう無い - 勘と経験と読経
  2. コンフォートゾーン外の学びの為にエンジニアが放送大学に入学してみた - 勘と経験と読経
  3. アラフィフ理系が放送大学の教養学部に入った記録（1年目前期完了） - 勘と経験と読経
  4. おっさんエンジニアの放送大学教養学部に入学記録2（1年目後期終了） - 勘と経験と読経
  5. 教育心理学はソフトウェア開発に活用できるか（教育心理学特論を読み終えて） - 勘と経験と読経
  6. おっさんエンジニアの放送大学教養学部に入学記録3（2年目前期終了） - 勘と経験と読経
  7. おっさんエンジニアの放送大学教養学部に入学記録4（2年目後期終了） - 勘と経験と読経
  8. おっさんエンジニアの放送大学教養学部に入学記録5（3年目前期終了） - 勘と経験と読経
  9. おっさんエンジニアの放送大学教養学部に入学記録6（3年目後期終了） - 勘と経験と読経

これまで受講した科目

  1. 哲学・思想を今考える（’１８）：1年目前期
  2. 西洋芸術の歴史と理論（’１６）：1年目前期
  3. 総合人類学としてのヒト学（’１８）：1年目前期
  4. 博物館概論（’１９）：1年目後期
  5. 文学・芸術・武道にみる日本文化（’１９）：1年目後期
  6. 西洋哲学の起源（’１６）：1年目後期
  7. 教育心理学特論（’１８）：1年目後期 ※大学院科目の聴講
  8. 「人新世」時代の文化人類学（’２０）：2年目前期
  9. 日本美術史の近代とその外部（’１８）：2年目前期
  10. 現代フランス哲学に学ぶ（’１７）：2年目前期
  11. 記号論理学（'１４）：2年目後期
  12. 舞台芸術の魅力（'１７）：2年目後期
  13. 西洋音楽史（’２１）：3年目前期
  14. レジリエンスの諸相（’１８）：3年目前期
  15. 心理学概論（’１８）：3年目前期
  16. 現代の危機と哲学（’１８）：4年目前期
  17. アメリカの芸術と文化（’１９）：4年目前期
  18. 中高年の心理臨床（’２０）：4年目前期

「スタッフエンジニア マネジメントを超えるリーダーシップ」をマネジメントの観点で読んだ

book Professional Engineer

読むのがホネな技術書やビジネス書を取り上げて２週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第57回。同僚と読書期限を約束することによって積読が確実に減るという仕組み。過去記事はこちら。

さて、今回取り上げるのは界隈では有名な「スタッフエンジニア　マネジメントを超えるリーダーシップ」である。スタッフとは参謀の意で、超上級・幹部エンジニアに関する本である。

スタッフエンジニア　マネジメントを超えるリーダーシップ

スタッフエンジニア　マネジメントを超えるリーダーシップ

Amazon

なお本書は英語で良ければ以下のサイトで読むことができる

著者のWill Larsonさんは現在はStripeやUberでエンジニアリーダー等をされてきた人。本書以外では「An Elegant Puzzle: Systems of Engineering Management (English Edition)」というエンジニアリングマネージャーに関する本が有名だがこちらは未翻訳（そして未読）。iwashiさんの紹介スライドが詳しい。
来年「The Engineering Executive's Primer」 という本が出版予定で、さらに上位のエンジニアリング職について論じるようだ。

なぜこの本を読もうと思ったのか

自分は現在はマネージャー側の立場であり、本書のテーマである「スタッフエンジニア」を目指しているわけでもない。それでも本書に興味を持った理由は次のようなものだ。

  • 周囲のスタッフエンジニア的、または志向があるメンバーへのアドバイスをするため
  • 所属組織における今後の検討材料として。残念ながらベンチャー企業および外資系を除いて、日本の企業にはそもそも「スタッフエンジニア」的概念が現在はない。所属組織でも同様である。しかしいずれは、こういった議論が本格的に必要だと考えているのだ
  • あとは単純な興味本位

……という、割と不純な動機で手に取った本書であるが、想像以上のいろいろな刺激を受けることができた良い読書であった。

全体的な感想

類書としては「エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド」を以前に読んでいるのだけれども、同書は海外事例でありテックベンチャーで若くしてCTOやVPoEを目指すという内容であり、なかなか日本企業で参考にするのは厳しいと思っている。いっぽうで本書は想定としているビジネス規模も大きく、中大規模の組織におけるスタッフ（幹部）エンジニアのありかた、役割、周囲との関係性が深く掘り下げられているので参考になる点が多いと思った。

これは私のようなマネージャにとっても有益で、例えば以下のような悩みを解決するヒントが得られたような気がする。

  • スタッフ（幹部）エンジニアのモデルがイメージできるようになったので、何をまかせるべきかが明確になりやすい。
  • また評価の際の参考にもなる。（自分はあまり経験がないが）組織の中でもトップレベルのエンジニアの評価はけっこうな難しさがあるはずなので、本書のような基準があるのは会話の土台として良いはずだ。

なお本書の付録にズバリな項目もあるのがお得だった。

スタッフプラスエンジニアの管理
StaffEngへ送られてくるフィードバックのなかに、「もっとスタッフプラスエンジニアの管理に関するコンテンツを」という要望があった。この話題は本書──会社やマネジャーではなく、スタッフプラスエンジニアをテーマとした本──で扱うには適していないが、興味深いトピックなので、ここで付録として論じたいと思う。
スタッフエンジニア　マネジメントを超えるリーダーシップ、補章 より

この項目はマジで参考になる。

その他の気になったこと

「部屋」の話がおもしろくて参考になる

本書では、経営会議などトップマネジメントが会社の方針を決定する場所を「部屋」と呼んでいて、

  • 部屋への入りかた
  • 部屋にとどまる方法
    • 話し方
    • 追い出されない方法

などの説明は、スタッフエンジニアに限らず参考になる。

A・グローブの「HIGH OUTPUT MANAGEMENT」推しの人が複数いた

本書の後半は様々な企業のスタッフエンジニアへのインタビューで構成されているのだが、「HIGH OUTPUT MANAGEMENT」を推している人が複数おり、ちょっと驚いた。同書はかなり骨太のマネジメント論である。毎年読み返しているという人もいる。自分が本書を始めて読んだのは8年前。時々思い出したように少しだけ読み返すことはあるが、本格的な再読は行っていない。読み直すか～。

本書のオススメの読み方が巻末の「解説」に書かれている

最近このパターンが多いので、かならず監修・監訳者の解説がある場合にはそこを最初に読むようにしているのだが、本書も末尾の「解説」から読むのがお勧めである。

私のおすすめの読み方は、まず第５章のインタビューを２～３人分読んでから、第１部を読み進めることです。とくにある程度経験を積まれたエンジニアの方は、第５章に登場するスタッフエンジニアの具体的なエピソードに大いに共感されることと思います。その共感を胸に第１部を読むことで、スタッフエンジニアに求められる役割が自然と腑に落ちるのではないでしょうか。
スタッフエンジニア　マネジメントを超えるリーダーシップ、解説 より

参考

というわけで本書は読了。次は何を読もうか。最近気になっている本はこんな感じ。