『The BDD Books - Discovery Japanese Edition』を読んだ
『The BDD Books - Discovery Japanese Edition』を読み終わったので、感想を書きます。
はじめに
新しく参加したチームでBDDの考えに則って開発しようということになった。ただ、自分はBDDについて何一つ知らない状態だったので、まずは基礎知識を得る必要があった。
チームでは実例マッピングなどのワークショップが定期的に開催されていて、それに参加はしていたのだが、正直イベントの目的を完全には理解できていなかった。ただ参加するだけではなく、自分でもファシリテーションができる状態になりたいと思っていた。
この本は要件の発見に至る方法を体系的に説明しており、まさに今の自分に必要な内容だと感じて手に取った。
印象に残ったところ
BDD とは
Behavior-Driven Development（振る舞い駆動開発, BDD） とは、製品の振る舞いを定義し、具体例を用いて開発を進めることで、開発とテストを効率的に進める方法だ。BDDは3つのプラクティスから構成されている：
- Discovery（発見）: 明確な具体例の使用による協調作業
- Formulation（定式化）: Discoveryで作成した明確な具体例をビジネスメンバーが理解できるシナリオに変える作業
- Automation（自動化）: シナリオをテストに変えるコードを記述する
この本では、この中でも特に Discovery の部分に焦点を当てて説明されている。
ここで重要なのは、BDDはツールではなく、主に関係者の協調やドメインの発見を行うものだということだ。「BDDツール」と呼ばれるものは様々存在するが、それらは協調した議論やドメインの共通理解があって初めて機能する。
BDDでは、ビジネス担当者が開発プロセス全体を通して参加し続けることを促進するため、その開発手法名から「テスト」という言葉を含めていない。テストはシステムの振る舞いの具体例を表現したもので、多くの場合 Given, When, Then というシナリオ形式を使って記述される。
また、具体例に注目するとユーザーストーリーが満たすべきルールが明確になるという点も印象的だった。それぞれのルールは1つ以上の具体例で説明するべきで、こうしたルールをもとにシナリオを定式化していく。
シナリオはユビキタス言語を用いて全員が理解できる言葉で記述し、「生きているドキュメント」として参照できるようにする。これは古くなることのないドキュメントのことで、あるシナリオがサポートされているかを常に確認できる。
実例マッピングという手法
チームは要件ワークショップを行う。このミーティングの目的は、ストーリーを探索し、その範囲を理解し、明確な具体例を用いてはっきりと説明することだ。多様な視点を持ち込んでより具体的な話をするために、様々な役割のメンバーの参加が求められる。ソフトウェア開発を始める前に、多様な視点を持つ複数のメンバーが一緒に要件を分析することで、早い段階で「わからないこと」の発見が可能になる。
要件ワークショップを効果的に進める方法として、実例マッピングという手法がある。これはユーザーストーリーに対してルールや具体例を発見・収集していくワークだ。
実例マッピングの進め方は、ストーリーの状態によって異なる：
- ストーリーが明確な場合: ルールを考え、それを説明する具体例を作成して詳細を理解する
- ストーリーが曖昧な場合: 具体例を収集していき、その具体例からルールを導き出す
具体例からルールを導き出した後は、そのルールから他の具体例について一度考えることでルールに対する理解が深まる。
実例マッピングの構成要素
実例マッピングでは四種類の付箋を使う：
- ストーリー: 実例マッピングに対して通常一つ。このストーリーに対して多様な具体例を収集していき、ルールとして抽象化する
- ルール: ストーリーの一段下に配置される。受け入れ基準・ビジネスルール・要件などと呼ばれる
- 具体例: 関連するルールの一段下に配置する。具体例のタイトル部分となる1行目に下線を入れる
- 疑問点: 実例マッピングの一番下に置いておく
こうした実例マッピングを進める上でファシリテーターは必須だが、これは特別なロールではないので誰でも担うことができる。チームメンバーでローテーションすることが推奨される。
具体例の構造
具体例とは、コンテキスト・アクション・結果の3つの部分に分割されたものと考えると良い。そしてそれを逆順に考えると想起しやすいというのが印象的だった：
- 結果: 関心を持っている振る舞いが発生した後のシステムの状態
- アクション: 関心を持っている振る舞いを引き起こすイベント
- コンテキスト: アクションが実行される前のシステムの状態
具体例の粒度について
こうして収集された具体例は、ルールの全ての条件を説明するには不十分な時がある。その場合には、全ての場合を出し切ることに注力するべきではない。
全ての組み合わせを徹底的に探索するようになると、要件の理解というワークの目的から離れてしまい、ソフトウェアのテストについて考えることになってしまう。要件の理解とは、ビジネス側が求めていることを理解することだ。具体例はその挙動を表していれば良い。
もしプロダクトオーナーが興味を持っていないような細かい議論にまで踏み込んでいた場合、ファシリテーターは議論を元に戻すようにする。
また、具体例はルールを説明するが、ルールを置き換えるものではない。ルールは簡潔で抽象的な説明を提供し、具体例は正確で具体的な説明を提供するという関係性だ。
複数のルールを表す一つの具体例を書いていることに気づいたら、具体例を複数のものに分割し、それぞれが1つのルールを説明しているかを検討すると良い。
スクラムにおけるBDD
本書ではスクラム開発におけるBDDの実践方法についても触れられている。
まず、要件ワークショップを定期的に開催し、全ての役割の代表が参加することが望ましい。ストーリーは実例マッピングなどを経てより具体的かつ整理された形になり、いくつかのルールと具体例に分解される。チームがプロダクトオーナーと話しやすい関係の場合は、リファインメントの代わりに短時間の実例マッピングを定期的に開催することが推奨される。
次に定式化のフェーズだ。要件ワークショップで上がってきた具体例をシナリオへと定式化する。ストーリーの実装前にシナリオとして残し、開発メンバーのみならずビジネスメンバーにとっても読みやすい記述方法と記述場所である必要がある。
シナリオを定式化するために最も良いのは、ストーリーを実装する際の一連の流れの中に定式化をタスクとして含めてしまうことだ。理想の流れとしては、開発者とテスターがペアで作成し、プロダクトオーナーにレビューしてもらうというものが挙げられている。
スコープが固定されたプロジェクトにおけるBDD
スコープが固定されたウォーターフォール型のプロジェクトでも、BDDはドメインにおける発見や気づきを与えたり、要件を文章化して残す助けになる。
仕様書から発見できるすべてのルールと具体例を含む実例マッピングを作成することで、開発する機能の全体像を把握し、スコープを調整することができる（例えばどの機能やルールを削減して間に合わせるか、など）。
感想
この本を読んで、自分が実例マッピングに参加する際にどのようなことを実践できるだろうか、と考えてみた。
参加者として
まず参加者側の立場では、具体例を想起するときに結果→アクション→コンテキストの順で考えてみようと思う。本書で紹介されていたこの順序で考えることで、明確に説明された具体例を作り上げることができるはずだ。
ファシリテーターとして
ファシリテーターを担当する時は、参加者が出してきた具体例について「このコンテキストは？」「どんなアクションが伴う具体例か？」と掘り下げることで、より具体性があり、テストで利用できる具体例を作成できるのではないかと感じた。
残された課題
実例マッピングワークショップを通して作成したルールや具体例一覧を定式化する際、どこにどうやって残すのが良いかというのは常に悩ましい問題だ。ワークショップ時に作成した付箋一覧と二重管理にならない粒度で、かつ整理された状態で残すちょうど良い塩梅が難しい。
定式化部分について説明された『The BDD Books - Formulation』という書籍があるので、それを読むことで学びたいと思う。
また、実例マッピングの手前として、ユーザーストーリーが適切に分割されていて整理されていることが重要だと感じた。ユーザーストーリーの定義や優先順位の付け方の手法の一つであるユーザーストーリーマッピングやインパクトマッピングについても勉強していきたい。
『Web API The Good Parts』を読んだ
『Web API: The Good Parts』を読み終わったので、感想を簡単に書きます。
動機
Web API開発に関わる人なら読んでおいた方が良い本としてよく挙げられる本で気になっていた。最近API自体の設計から離れていたこともあり、基礎固めをしたくなり読むことにした。
印象に残ったところ
エンドポイントの設計とリクエストの形式
- エンドポイントの基本的な設計では、覚えやすく、どんな機能を持つURIなのかが一目でわかることが重要。また、サーバー側のアーキテクチャが反映されていないURIが重要。クライアントはサーバーの実装について興味を持ってはいないし、攻撃者の喜ぶ余計な情報を与えてしまうことにも繋がりかねない。
- 適切なHTTPメソッドを使用する
GET: リソースの取得POST: リソースの新規登録PUT: 既存リソースの更新POSTとは異なり、更新したいリソースのURIそのものを指定する。
DELETE: リソースの削除PATCH: リソースの一部変更PUTが送信したデータで元々のデータを丸々置き換えるのに対し、PATCHではその更新したい一部のデータのみ適用する。
HEAD: リソースのメタ情報の取得
- 認証にはOAuth2.0を使うと良い
レスポンスデータの設計
- 基本的にはJsonをサポートしていれば良い。それ以外のフォーマットもサポートする場合は、フォーマットを指定するためのクエリパラメータ用意して、そこで
jsonやxmlといったデータ形式を指定する方法や、Acceptというリクエストヘッダを利用することで、クライアントがサーバー側に受け取りたいデータ形式を伝えること、などが考えられる。 - Chatty APIにならないように注意する。一つの作業を完結するために複数回のAPIコールが必要な設計にしない。そのAPIがどのように利用されるかを想像し、利用者が使いやすいAPIを検討する。
- ステータスコードでエラーを表現する
- 100番台：情報
- 200番台：成功
- 300番台：リダイレクト
- 400番台：クライアントサイドに起因するエラー
- 500番台：サーバーサイドに起因するエラー
- エラーの詳細情報をレスポンスヘッダもしくはボディに含める。一般的には、ボディに含めた方がクライアント側が処理しやすい。
- その一方で、セキュリティの観点から意図的に不正確なエラー情報を返したい場合もある。APIの性質を考えた上でどの程度詳細なエラーをクライアントに返すか考える。
HTTPの仕様を最大限利用する
- HTTPのリクエストとレスポンスでは、送信するデータの形式を表すためにメディアタイプを指定する必要がある。メディアタイプとはデータ形式のこと。
- リクエストで用いられるヘッダ
- レスポンスで用いられるヘッダ
- Same Origin Policy と CORS
XMLHTTPRequestでは Same Origin Policy の元、異なるドメインに対してアクセスを行った際、レスポンスデータを読み込むことができない- CORS (Cross-Origin Resource Sharing) を利用すると、特定のoriginからのアクセスのみに対してアクセスを許可できるようになる
- CORS の基本的な仕組み
- クライアントが
Originというリクエストヘッダに自身のoriginを含めて送る（例：http://www.example.com/→http://api.example.com/の場合、Origin: http://www.example.com） - サーバー側ではあらかじめ許可するoriginリストを保持しておき、
Originヘッダで送られてきた内容がそれと一致するかを確認する - 含まれている場合、
Access-Control-Allow-Originヘッダにそのoriginを含めて返し、アクセスが許可されたことを表す（例：Access-Control-Allow-Origin: http://www.example.com）。どこからでも読み込み可能な場合は*を指定する
- クライアントが
- CORSではプリフライトリクエストという、サーバーへの問い合わせ方法が定義されている。これはCross-Originリクエストをサーバーがサポートしているか事前に問い合わせるためのもので、
OPTIONメソッドを使って送信される。次の場合はプリフライトリクエストが必要- 利用するHTTPメソッドが Simple Methods (
HEAD,GET,POST) 以外 Accept,Accept-Language,Content-Language,Content-Type以外のリクエストヘッダを送信しようとしているapplication/x-www-form-urlencoded,multipart/form-data,text/plain以外のメディアタイプをContent-Typeに指定している
- 利用するHTTPメソッドが Simple Methods (
- 自分メモ：今では主にfetch APIが代わりに利用されている
感想
HTTPメソッドの定義、それから各リクエスト・レスポンスヘッダの種類についておさらいすることができた。セキュリティの項目などは少し難しい部分もあったので、また自分が開発する時に戻ってきたい。
教育格差と社会階層の構造について考える
なぜこのテーマに関心を持ったのか
そもそもこのテーマに興味を持つようになったきっかけは、自分の高校時代の体験にあります。同じ学校（しかもそこそこの進学校）に通っていても、家庭の事情によって受けられる教育が大きく異なる現実を目の当たりにしたことでした。
塾に通える生徒とそうでない生徒、家庭学習をサポートしてもらえる環境にいる生徒とそうでない生徒、そもそも大学進学を前提として考えられる家庭環境にいる生徒とそうでない生徒。同じ学校に通っていても、選択肢や機会には明らかな差がありました。
この経験から、「家庭の経済事情や家庭環境の影響を受けずに、子どもが本来受けたい教育をどのように受けることができるのだろう」という疑問を持つようになりました。個人の努力や能力だけでは乗り越えられない壁があることを実感し、その状態をどうにかしたいと思うようになりました。
同時に、自分は非常に恵まれた環境にいるのだということを強く実感しました。しかし振り返ってみると、正直なところこの事実を自覚している高学歴な人をあまり見たことがありません。むしろ「努力したから今がある」「機会は平等だった」と考える人が多いように感じます。
概要
なぜ同じ公教育を受けているのに、子どもたちの学力や進路に大きな差が生まれるのでしょうか。近年の教育社会学の研究が明らかにしているのは、教育格差は単なる個人の能力差ではなく、「努力のしやすさの不平等」という構造的な問題だということです。これは自分にとって非常に考えさせられる視点でした。
この記事では、松岡亮二さん、本田由紀さん、苅谷剛彦さんらの著書をもとに、日本の教育格差がどのような仕組みで再生産されているのか、そして「メリトクラシー」が「能力主義」と誤訳されたことで隠された問題についてまとめてみたいと思います。
「努力」は平等ではない：家庭環境による学習格差
学習時間の階層差
苅谷剛彦さんの研究によると、小学生の学校外での学習時間には明確な階層差があります（『学力と階層』）：
- 階層上位グループ：76.7分/日
- 中位グループ：60.7分/日
- 下位グループ：55.4分/日
さらに、「グループ学習の時にまとめ役になることが多い」という項目で、階層上位グループが45.2％であるのに対し、下位グループは30.4％にとどまっています（同書より）。
新学力観型授業への参加格差
1990年代から導入された「新学力観」に基づく授業（自ら学び、考える力を重視）においても、家庭の文化的階層による差が顕著に現れています。階層下位グループの子どもにとって、このような学習活動に積極的に関わることは少数にとどまります。
つまり、「努力する」「積極的に学ぶ」という行為自体が、生まれ育った家庭の文化的背景に大きく影響されているのです。
「能力主義」という言葉のトリック
メリトクラシーと能力主義の違い
本田由紀さんが指摘する重要な問題があります（『教育は何を評価してきたのか』）。英語の「meritocracy」が日本では「能力主義」と訳されていますが、これは本来の意味とは異なります：
この誤訳により、日本では教育が「学んだ内容」よりも「素質や態度」を評価する方向に向かい、結果として垂直的序列化（能力による格付け）と水平的画一化（特定の行動様式の強要）が同時進行しています。
評価の二重構造
現在の日本の教育では、以下の二重構造が子どもたちに過度の圧力を生み出しています：
- 従来の学力による評価（テスト点数、偏差値など）
- 「人間力」による評価（関心・意欲・態度、資質・能力など）
この結果、子どもたちは学力だけでなく、人格や態度までも評価の対象となり、「望ましい人間像」への同調圧力が強まっています。
地域格差の固定化
学歴による居住地域の分断
松岡亮二さんの研究が明らかにしたのは、「学歴によって住む地域が分かれる現象」です（『教育格差 ──階層・地域・学歴』）。高学歴者が都市部に集中することで：
- その地域に「教育熱心」な文化が生まれる
- 近隣の大卒者割合が高い地域では、子どもの教育に対する期待値が高くなる
- 地域の政治的発言力に差が生まれ、教育予算の配分にも影響する
これは「いつの時代にも地域格差がある」（同書より）という状況を構造的に固定化する仕組みとして機能しています。
AI時代の新たな格差：読解力の重要性
新井紀子さんの研究は、従来の教育格差論に新たな視点を提供しています（『AI vs. 教科書が読めない子どもたち』）。読解力について従来効果があるとされてきた要因（読書量、学習時間など）が実際には関係なく、家庭の貧困のみが読解力に明確な悪影響を与えることが明らかになりました。
さらに重要なのは、12歳時点での読解力がその後の大学受験結果を左右するという事実です。これは「いつでも取り戻せる」という従来の教育機会論が成り立たなくなっていることを示しています。
認知科学からの示唆
実は、脳科学の研究も教育格差の理解に重要な視点を提供しています。自分が以前読んだ記憶の脳科学研究によると、学習は神経回路の可塑性に基づいており、ヘブの法則（「一緒に発火するニューロンは結びつく」）に従って記憶が形成されます。
特に重要なのは「連合性」という概念です。一つの刺激だけでは記憶の閾値を超えないが、複数の刺激が組み合わさることで学習が促進されるというものです。これは、家庭環境が豊かな子どもが多様な刺激を受けることで学習しやすい状態になることの科学的説明ともいえそうです。
学習資本主義の時代
新しい格差の構造
現代は、苅谷剛彦さんが提唱する「学習資本主義」の時代といえます。知識のストックよりも、学習能力そのものが価値を持つ時代において、教育格差は以下の構造で再生産されています：
- 初期条件の重要性：家庭の社会経済的地位が学習能力の蓄積力を決定
- 格差の拡大メカニズム：学習能力の差が自己増殖的に拡大
- 制度的な格差拡大：教育制度が格差縮小ではなく拡大装置として機能
- 時間の不可逆性：一度生じた格差の修正が困難
個人的な感想
これらの研究を読んで感じたのは、まず自分自身が持っている「努力は平等」「機会は開かれている」という思い込みを見直す必要があるということでした。
教育に関わる立場として考えてみると：
- 子どもの背景にある家庭環境をもっと理解しようとすること
- 「態度」や「意欲」で判断することの危険性を意識すること
- 一つの正解ではなく、多様な表現や学び方があることを受け入れること
などが、小さな一歩として大切なのかもしれません。
制度的な面では、読解力支援の早期化や地域格差への対応、貧困対策との連携などが重要だと感じますが、これらは政策レベルの話で、個人ができることには限界があります。
効果的な学習に関する知見
実際の教育現場で参考になりそうなのは、Visible Learningの研究で明らかにされた効果的な学習の原理です：
- 分散学習の効果：一度に詰め込むより、時間をあけて複数回学習する方が効果的
- 先行知識の重要性：新しい情報は既存の知識と関連付けることで学習しやすくなる
- 認知負荷の管理：複雑すぎる課題は学習を阻害するため、適切な難易度設定が重要
これらの知見は、家庭環境による差を部分的に補う可能性がありますが、結局は「これらを実践できる環境があるかどうか」という根本的な問題に戻ってしまいます。
最後に
これらの本を読んで、教育格差の問題は単に「教育」だけの問題ではないということを改めて感じました。それは社会全体の価値観や構造と深く関わっているのだと思います。
「努力すれば報われる」「機会は平等に与えられている」という考え方は確かに素敵な理念に感じますが、実際には「努力のしやすさ」そのものが不平等だという指摘は、なんとなく実感はしていたもののこうして明示的に表現されると、正直なところ衝撃的でした。
完全な解決策があるわけではありませんが、まずはこうした構造的な問題があることを知ること、そして自分の身近なところから少しずつ意識を変えていくことが大切なのかもしれません。
OECD Education 2030で提唱されている「変革をもたらすコンピテンシー」（新たな価値を創造する力、対立やジレンマに対処する力、責任ある行動を取る力）のような新しい教育目標も、結局は「それを育める環境にいるかどうか」で差がついてしまう可能性があります。技術的な解決策だけでなく、社会全体で格差の構造的な原因に向き合うことが必要だと感じました。
ソフトウェアエンジニアとして、この問題にどう関わっていけるかも考えています。まずは自分たちが想像できない教育の機会に気付ける機会を増やすことに関われると嬉しいな、と感じたりしてます。
アプローチはいろいろあると思っていて、例えばSaaSとして学習データを集めることができれば、そのデータからその子におすすめとなる教育機会を提案できるかもしれません。他にも、教育を受ける人と教育を受けさせる人それぞれが訪れるプラットフォームになれば、自分たちが普段生活しているだけでは気付けないような教育の機会に気付けるかもしれません。
もちろん、機会に気づいたからといって行動をとれるとは限りません。経済的な制約や時間的な制約は技術だけでは解決できないからです。でも、少しずつの小さなステップを踏んでいくことが大事だと思います。想像の範囲外のものを提供できるというところに、ソフトウェアエンジニアとして貢献できる可能性を感じています。
答えはないですが、「教育の機会均等」という理想に向けて自分はどのように働きかけることができるのだろうか、と考えていきたいです
参考文献
生成AI時代に感じること
これはただのポエムです
動機
最近、生成AI / LLMの話題がどこでも聞こえてくる。ChatGPT、Claude、GitHub Copilotなど、毎日のように新しいツールが登場し、「AIがエンジニアの仕事を奪う」という議論も盛んになっている。
ソフトウェアエンジニアとして働いている自分は、この変化をどう感じているのか。恐怖なのか、ワクワクなのか。正直な気持ちを整理してみたいと思った。
ソフトウェアエンジニアとしての私の感情
よかった点（というか、ワクワクしている点）
抽象化レイヤーが一つ上がっただけだと思っている
そもそも私たちエンジニアは、コンパイラが行っている最適化を隅々まで把握しているわけではない。コンパイラがプログラムをバイナリに変換してくれるおかげで、私たちはその詳細を知らなくても開発できている。
でも、コンパイラの仕組みを理解している人の方が、うまくコンパイラのアウトプットを使える。これが抽象化レイヤーの下を学んでいる強みだと思う。抽象化されているモジュールでは、限界が来た時に中身を見に行く必要がある。（HTTPクライアントライブラリとかでも同じことが言えそう）
適切にデザインされた抽象化は生産性を上げる。実際、サイバーエージェントでは「6～7割以上のエンジニアがGitHub Copilotを活用しており、Copilotで推薦されたコードの3-4割が採択されている」状況で、「感覚的に2割前後は生産性が改善した」という報告もある1。
今回の抽象化は確かにすごい
ただ、今回の抽象化はかなり分厚く、広範囲に影響を及ぼしている。コンパイラやクラウドのようなソフトウェアエンジニアリング特定の領域に留まらず、あらゆる分野に影響を与えているのがこれまでとの違いだ。
でも、私たちソフトウェアエンジニアにとってはこれはチャンスだと思う。適応できるだけの能力と慣習を持っているはずだから。
レイヤーが分かれていくのが楽しみ
AIを活用する人間、AIがどう動作するかを理解している人間、AIが提供する機能の裏側を理解している人間。それぞれでレイヤーが分かれていき、異なる強みを発揮していくんじゃないか。
エンジニアの役割は「複雑なコンポーネントの専門開発エンジニア」「ソフトウェア要素を組み合わせるコンポーネント組立エンジニア」「AIを活用するコンポーネントコンサルタント」に分化していくと予想している記事もある2。
自分の仕事がなくなるのであれば、それはそれで良い。抽象化されるレイヤーが増えたのであれば、その上を考えれば良いだけ。プログラミング自体が好きな人には少し酷な時代かもしれないが、プログラミングの先の目的により集中できるようになると思う。
イマイチな点（というか、不安な点）
本当に楽観的すぎるのかもしれない
上記のように楽観的でワクワクしているような人間は、いつの間にか職を失っている、ということもあり得るかも。この辺は正直全然想像がつかない。
「人間らしさ」が求められない分野はどうなるのか
正確さだけが求められる分野では、価値を出し続けるのは難しくなっていくのだろうか。ソフトウェアエンジニア領域の一部分（もしくは大部分？）もそういう分野の一つかもしれない。
一傍観者の立場として考えたこと
将棋の電王戦から学んだこと
AIがある領域に踏み込んできて人の能力を超えた時、どのように人間は反応するのか。自分の記憶に新しいのは将棋の電王戦だ3。
AI対人間の真剣勝負が何回か開催された後、AIの勝利という結末に終わった。これで「将棋に関してはAIの方が強い」という認識が固定化された。
でも、その後どうなったか。むしろ将棋観戦の需要は高まっている。
人々は「AIのような最善手を指せるか」という観点に加えて、指している人間の人間らしさ、プロ棋士らしさを求めているのだ。羽生善治九段も、人間同士の将棋では「多分に心理的な要素が働いている」「互いにこう指したいという大局的な意図が先にあるから、そこに駆け引きの妙味も生まれてくる」と語っている4。
「あんなに強いプロ棋士がこんなところで間違えるなんて、プレッシャーがすごいのだろう」とか、「AIなら指せる最善手だが、人間にとっては今指した手が展開が読みやすく最善になるのだろう」とか、「この渋い受けの一手は〇〇さんらしさがある」といった具合に。
そして、羽生さんの本でも触れられているが、「直感力」とその直感に基づく「決断力」の価値が上がっていることも注目に値する5。この直感は当て感ではなく、これまでの経験に裏打ちされた勘所とそれに基づく決断力は人間ならではの営みである。
娯楽と経済活動の違い
ただ、上記は娯楽の分野だからこのような楽しみ方ができているのだと感じる。経済活動の分野ではどうなるのだろうか。
社会階層の分断への懸念
また、AIによって社会的階層の分断がより広がってしまうのではないか、という懸念も自分の中では大きい6。
AIは基本的に課金が必要で、サブスクリプション料金を支払える層だけが利益を享受していく構造になっている。
さらには、AIの使い方自体も社会経済的地位によって異なるという研究もある7。高い社会経済的地位の人は抽象的で短い指示で専門的なタスクを依頼する傾向があり、低い地位の人はより具体的な指示でAIと会話的にやり取りする傾向があるとされている。
これにより、現在存在している経済的・能力的な格差がより広がっていくことは懸念している。大衆が同じような利益を享受するためにはどうすれば良いのだろうかと考えたりする。
感想
個人的には、職が失われた場合にはカフェ店員でもしてゆっくりと過ごせれば良いと思っている。AIの方が社会に良いインパクトを与えられるのであれば、それは道を譲るのが良いのではないか。
そんな風に考えている自分は、やっぱりこの変化にワクワクしているのだと思う。恐怖よりも好奇心の方が強い。
- エンジニアを目指す学生と共に考える、生成AIでエンジニアの未来はどう変わるのか | CyberAgent Way↩
- 生成AIが変えるシステム開発とソフトウェアエンジニアの未来 - LaKeel DX↩
- 将棋電王戦 - Wikipedia↩
- 現役名人がコンピューターに負けた。将棋電王戦が、人間同士と違う部分。- Number Web↩
- プロ棋士・羽生善治が語る"直感の正体"。将棋で「長考に好手なし」と言われる理由とは｜新R25↩
- 【AI格差】AIは誰のもの？社会経済的地位がAIとの付き合い方を変える「AI格差」の実態｜高梨洋平｜リサーチャー↩
- MIT Tech Review: 主張：人手不足を補うAIがなぜ、経済格差を拡大するのか↩
2024年買ってよかったもの
2024年に買ってよかったものをまとめておくよ。去年は家電が多かったけど、今年は自分へのご褒美系が多いかな
去年のはこちら
キーボード
一体何台目のHHKBなんだよ...というツッコミを入れながら、ずっと気になっていたので買ってしまった。Amazonのブラックフライデーセールで安くなっていた。
買ってしまいました、後悔はしていません pic.twitter.com/dr7DEKe1gV
— ひらめくん🐟 (@hiramekun_eng) December 3, 2024
ジェスチャーパッドで色々できるらしいんだけど、まだ全然使いこなせていないところに課題感あり
よかった点
- 大体の作業はキーボードから手を離さずに完結する
- タイピング音がかなり静か。静音のHHKBよりも静かで個人的には好きな打感。これだけで買ってよかったって思えるくらい気に入っている
- マルチペアリングができ、ボタンひとつで接続先を変更できる。接続状況をライトで教えてくれるので、起動中なのか、どの機器と繋がっているかなど一目でわかる
イマイチな点
- draw.ioやMiroで作業する時は、細かいところの作業がうまくいかないことが多かった。カーソルが気持ちより早く移動している気がするので、感度を変えたりして調整可能なのだろうか
- 少し他のHHKBと比べて重いかも？手軽に持っていける感は減ったかも（けどそんなに困ってない）
気になっているなら買う価値あると思う。真ん中のボタン（ポインティングスティックと呼ぶらしい）なしだとしても、HHKBの上位モデルとしてとても良い。
ジェスチャーボタンとか使いこなすコツあったらぜひ教えてください！
広角レンズ
ズームレンズと単焦点レンズをずっと使っていたので、そろそろ新しいレンズが欲しいなと思って購入。単焦点レンズはポートレートには最高だけど、風景を撮るにはもう少し広角が欲しいなと思っていた。まだ買ったばかりだけど、夕日を撮るだけでもその良さがわかってとても嬉しい
広角レンズを手に入れたよ pic.twitter.com/tprYVk4eZo
— ひらめくん🐟 (@hiramekun_eng) December 7, 2024
よかった点
- とっても広角。風景を撮るときには迫力のある写真が撮れそう
- F2.8で明るめなので暗いところの撮影でも綺麗に撮れそう。天体撮影とかに使いたい
イマイチな点
- これまでのレンズと比べて、とても大きくて重い！なので気軽に普段使いできるようなものではない。風景を撮るぞ！と気合を入れて出かけるときに持っていくと良いかな
- 広角レンズなのでどうしても端っこは歪んでしまう。レビューでは歪みが少ないと言われているので、きっと抑えている方なのだと思う
初めての広角レンズなので、ずっとワクワクしている。 最近買ったばかりでまだ夕日を撮る以外で使えていないので、旅行先の風景を撮るときにぜひ持って行きたいな。
香水
甘い系の匂いは自分につけるには好みではないので、夏頃にすっきりしているのを探していた。 アウトレットのセレクトショップで匂いがすごい好みだったので、元々知らない香水だったんだけど買ってしまった。
めちゃくちゃ好みの香水を偶然見つけたのでテンションが高い
— ひらめくん🐟 (@hiramekun_eng) July 4, 2024
柑橘系の爽やかさの中にほんの少しだけ甘い香りがする感じで、男女問わず使えると思う。柑橘系の匂いが好きだったらぜひ試してみてほしい！小さいサイズもあるのでそっちを試してみるのがおすすめ
財布
年齢を重ねてきてそろそろ良い財布を持ちたいとずっと思っていたので、自分への誕生日プレゼントに買ってしまった。色々と迷ったんだけど、普段小銭は使わないのと極力荷物を少なくしたいので、スリムなタイプにした。
自分への誕生日プレゼントにいい財布を買っちゃった
— ひらめくん🐟 (@hiramekun_eng) December 15, 2024
カッコよくてその割に程よくシンプルなので非常に気に入っている。手入れしながら大切に長く使っていきたい。
イマイチな点を強いてあげるなら、小銭類は入らないので、別でコインケースを持つ必要があるということかな。これまでは財布の小銭入れ部分に家の鍵を一緒に入れていたので、それと同等の機能を担うものが必要になった。まだいいものを見つけてないので、おすすめあったらぜひ教えてください。
『プロダクトマネージャーのしごと』を読んだ
積んでいた『プロダクトマネージャーのしごと』を読み終わったので、内容を簡単にまとめます
動機
エンジニアとしてプロジェクトをリードする中で、プロジェクトマネジメントのノウハウをもっと取り入れ、エンジニアの枠を超えた働き方を目指したいと考えている。
また、プロダクトマネージャーという役割について、「具体的にどのような業務を担当するのか」「どのような姿勢で取り組むべきか」といった点を理解することで、プロダクトマネージャーとの円滑なコミュニケーションに活かしたり、エンジニアとしてより効果的にサポートできるようになりたいと思い、この本を手に取った。
印象に残ったところ
第1章 プロダクトマネジメントの実践
プロダクトマネージャーという役割には常に曖昧さが伴い、あらゆることをこなす必要がある
- 責任は大きいが権限は小さい。チームが締切を守れなければプロダクトマネージャーの責任である
- チームとプロダクトの成功のために、終わらせる必要なることはなんでもするのがプロダクトマネージャーの責任である
- プロダクトマネージャーはあらゆることの中心となる
- 優れたプロダクトマネージャーとは、人やものを繋げる中心にいる人である
第2章 プロダクトマネジメントのCOREモデル
プロダクトマネージャーに必要なCOREモデルとは、次のものである
- Communicate: ステークホルダーとコミュニケーションする
- 心地よさより明確さが行動指針。心地悪さは明確さの欠如の兆候であることが多いので、自ら心地悪いコミュニケーションをとっていく必要がある
- やっていることとその理由をチームが明確に理解しているか会話の中で確かめる
- Organize: 持続的に成功するチームを組織化する
- 自らを不要とせよが行動指針。組織化に優れたプロダクトマネージャーは自己継続的な仕組みを作る
- 今何しているのか、そしてそれはなぜかという問いにチーム全員が答えられるような状態にする
- Research: プロダクトのユーザーのニーズとゴールをリサーチする
- ユーザーの現実に生きよが行動指針
- 全てのプロダクトに対する意思決定は、ビジネスゴールとユーザーニーズに紐づいている必要がある
- Execute: プロダクトチームがゴールに到達するための日々のタスクを実行する
第3章 好奇心をあらわにする
- 好奇心を示すというシンプルな行動は、プロダクトマネージャーとしての仕事に大きなプラスの影響を及ぼす。他人に何かを求める前に関係性築いておく必要がある
- 職場の同僚を訪ねて、仕事をもっと詳しく教えてもらえないか声をかけてみる
- 同僚同士が学び合うように促し、お互いのスキルを学びたい人をペアにする
第4章 過剰コミュニケーションの技術
- 失敗するなら、コミュニケーション過剰の方に倒しておくほうが良い。
- 自分が当たり前だと思っていることも、他の人には当たり前でないことがある。当たり前のことを問うことを恐れないこと
- 心地よい言い回しをしてまわりくどい言い方をしがちだが、曖昧にするのは良くない。これは責任回避であり、悪いやつだと思われずに結果を得ようとする受動的攻撃生の表れ
- Disagree & Commit
- 集団での合意形成の際には、参加者全員の「進めてよい」という積極的なコミットメントが必要だ、ということ
- 沈黙は不合意として扱う
第5章 シニアステークホルダーと働く
上司がバカだった、という発言をすると、それは実質的にチームを壊す。シニアステークホルダーからのどんな要求であっても合理的でないとチームがみなすようになってしまうから。 プロダクトマネージャーの仕事はシニアステークホルダーからチームを守ることではなく、強力的なパートナーである。
第7章 「ベストプラクティス」のワーストなところ
ベストプラクティスを盲信すると、それに従わない人は全て敵に見えるようになってしまう。しかし、ベストプラクティスは様々なプロセス、人、運、タイミングといった様々な要素が絡んでいることを忘れてはならない - 業界トップ企業のケーススタディは、採用のためのプロパガンダであることが多いので、誇張を鵜呑みにしない - ケースバイケースの制約と限界が存在している - ベストプラクティスを実施する前に、組織特有の状況について学ぶための時間を常に取る
第8章 アジャイルについての素晴らしくも残念な真実
プロセスを内省して洗練する時間を作らなければ、形式上のセレモニーのせいで結果的にチームの士気を低下させることになりかねない。アジャイルプラクティスやセレモニーの背景にある本質や本来の目的をドキュメントに残すと良い。
第9章 ドキュメントは無限に時間を浪費する
最高なドキュメントは不完全である。不完全であることは、行動のきっかけとなる
- 意図的に不完全なドキュメントを共有した時は、チームからの質問や貢献は前に進めるために不可欠
- 他のメンバーの参加度合いやその質は完璧なドキュメントを共有した時より圧倒的に高い
- 次のミーティングでは不完全なドキュメントを持っていくことを推奨する
- 最初のドラフトは1ページで、作るのに1時間以上かけない
第12章 優先順位づけ：すべてのよりどころ
志は大きく、スタートは小さく！
- どの意思決定もトレードオフ
- その意思決定が良い結果になるかどうかはやってみないとわからない。小さく始めてフィードバックをもとに軌道修正するのが良い
- 仮説をもとに物事を進める場合はその仮説を文章化してチームと議論する
- 単独の機能ではなく、ユーザージャーニーやユーザータスクの全体を考える
- 他のプロダクトマネージャーやチームとの調整が少なくて済みそうな機能を優先しがち
- 複数チームの責任領域を跨ぐ昨日や改善こそ、一番インパクトが大きい
- 小さくはじめる & 作業の依存関係の話ではなく、どのようなゴールを目指すか、というワクワクする話から始める
第13章 おうちでやってみよう：リモートワークの試練と困難
リモートワークにおいてすぐに実践できるtipsが多く書かれていたため、多めに内容をまとめる
- 日々のコミュニケーションに対する期待があっていないことが、しばしチームの信頼関係の１番の障害になっている。コミュニケーションマニュアルを作成し、コミュニケーションの緊急度合いに対する期待値を揃えると良い
- それぞれのチャネルの非同期メッセージにどれくらい素早く反応することを期待するか？
- お互いに仕事をお願いするときに、明示すべき基準は？（例：どれくらいの期間お願いするのか、納期は、遅れることのリスクは）
- 個人とチームの仕事時間は？仕事時間以外に送受信したメッセージの扱い方は？
- まずはチームのメンバーからメッセージを受け取ったらどれくらい早く返信が来ることを期待するか、という質問から始めると良い
- 非同期コミュニケーションでは、送信する前に時間をかける
- 送信するのが一番簡単な非同期メッセージは、返信する際に多くの時間を要する
- メッセージを受け取った人は、10秒以内にとって欲しいアクションがわかるか？
- 期待する結果と納期が明記してあるか？
- メンションされている場合、なぜメンションされているかが明確か？（ccに入れられている理由など）
- フィードバックを求める場合は、どんな種類のフィードバックを求めているのか、そしてそのフィードバックを求める理由が明確になっているか？
- フォローアップや確認の場合には、どんなタイプの反応やリアクションが欲しいかを明確にしているか？
- 同期サンドイッチのススメ
- ミーティングの1日前までには事前に読む資料を非同期で送る
- タイムボックスを設定した同期ミーティングをファシリテーションし、判断を下してドキュメントを一緒に作成し、事前資料で説明された問題を解決する
- 同期ミーティングから1日以内に、次のアクションを含むフォローアップを非同期で送る
第14章 プロダクトマネージャーのなかのマネージャー（プロダクトリーダーシップ編）
プロダクトを所有しようと意地になったり、機能の押し付け合いになったりすることが多い。次の文章を本からそのまま引用する
あなたの仕事はビジネスとユーザーのためのアウトカムを届けることで、プロダクトのなるべく多くを「所有」することではないことを忘れないでください。いちばん合理的な道に集中し、「あなたが持つか、私が持つか」という二元的な考え方の枠をなるべく早く越えようと努力してください。ビジネスゴールに対して最善を尽くすために、両チームがどのように協力できるのかを話し合うために、フォローアップの会話の機会を提案することを検討してください。
感想
プロダクトマネージャーは責任が大きいが権限は小さく、プロダクトを成功させるためにあらゆることをやる人物だというのは、ある意味では酷だな、と感じた。しかし、あらゆる人をつなげてプロダクトを成功させることに熱意を感じる人であればそこに強いやりがいを感じるのだろう。
自分としては、エンジニアの立場としてプロダクトマネージャーを支えるように関わっていきたいと感じた。エンジニアとしてもプロダクトマネージャーの行動の背景・意図を知ることでよりスムーズにコミュニケーションができ、より大きなインパクトを最終的に残せるようになると思う。場合によってはプロダクトマネージャーが足りていないところに手を貸すような動きもできるかもしれない。
明日から実践できることとして、次のようなことを意識していこう
- コミュニケーションでは心地よさより明確さが重要。心地悪いコミュニケーションを率先して取っていき、明確さに欠ける部分を埋めていくようにしたい
- 失敗するならコミュニケーション過剰になる方が良い。当たり前を問うことを恐れない
- ベストプラクティスは様々な要因が重なって作られているので、盲信せずに自分の組織特有の状況を見定めたい
- 最高なドキュメントは不完全。チームに対して不完全なドキュメントを作成し、それを皆で埋めていく作業を行う
- チーム内で、非同期メッセージにどれくらい素早く反応することを期待するか聞いてみる
- メッセージには取って欲しいアクション、期待する結果と納期を明確にする
次に読みたいもの
本の中で紹介されていた『Agile Retrospectives』を読んでみたい。振り返りを行い、チームとして学び続けることで改善し続けたい。今もレトロスペクティブは行っているが、KPTを回しているだけの状況になりがちなので、体系的に学ぶことでより効果的なレトロスペクティブを開催していきたい。
『小さな習慣』を読んだ
『小さな習慣』を読み終わったので、感想を簡単に書きます。
動機
習慣化したいことがいくつかあるのだが、それがどれも三日坊主に終わってしまったり、いつの間にかやらなくなっていることに気づいた。どうやったら努力を継続していけるかについてのヒントを得られると良いと思い、この本を読むことにした
印象に残ったところ
- 小さな習慣の基本は、こんなに簡単でも良いのかと自分でも疑うほど簡単な課題を設定し、それを本当に小さな意志の力によって実行するというもの
- そして何度もその行動を繰り返して、その行動専用の神経回路を強化していけば良い
- モチベーションを上げてモチベーションに基づいて行動を習慣化することは信頼できない
- なぜなら、モチベーションは感情に基づくものだから。人間の感情は変わりやすく、モチベーションがコンディションによって大きく変わってしまう
- つまり、モチベーションを使う方法が上手くいくのは、エネルギーが有り余っている時、健康的な考え方をしている時、他に大きな誘惑がない時に限る
- 小さな習慣はその逆で、先に行動をとり、モチベーションがその後を追いかけてくる仕組みになっている
- 課題がほんの小さなものなので自分の気分に関係なく実行できる
- どんな課題でも、始めること自体が最初の抵抗を引き起こし、最初の壁となる
- 小さな習慣の8つのステップ
- 小さな習慣とプランを選ぶ。ここで重要なのは、小さすぎて失敗するはずがない行動にまで細かくしていくこと
- 「なぜドリル」を使って習慣を身に付けたい理由を掘り下げる
- 行動開始の合図を決める。時間ベースもしくは行動ベースで行動開始のトリガーを考える
- 報酬プランを考える
- すべてを書き留めておく。大きなカレンダーに書き留めたり、スマホアプリに記録をつけたりする
- 小さく考える
- スケジュールを着実にこなし、期待しすぎない
- 習慣になる兆しを見逃さない
感想
小さな課題は意志力を使わずに取り組める、という点が何度も述べられており、それには納得した。意志力には限りがあるため、決断を繰り返すと、強い意志で物事を進める力が徐々に失われてしまう。
そのため、小さな課題に取り組みながら、気が向いたら追加の課題を少しだけやってみるという考え方は、ぜひ実践してみたい。振り返ると、昔AtCoderの問題を毎日1問解く習慣を続けていたときも、A問題だけでも解き続け、気が向いたときには追加で数問解いていた。その際、一番のハードルは「解き始めること」だったので、この「最初のハードル」をどれだけ低くするかが大事だと改めて感じた。
意志力については『スタンフォードの自分を変える教室』で詳しく言及されていたので読み返してみたい。
自分だったらこんな習慣になるだろうか
| 目標 | 小さな習慣 |
|---|---|
| 健康的で活力のある毎日を過ごしたい | 1日1回ダンベルを持つ or ジムに行く（行くだけ） |
| エンジニアとしてコーディング力を磨きたい | 毎日LeetCodeのEasyを1問解く |
| 知識をインプットして社会にインパクトを残せる人になりたい | 寝る前に本を2ページ読む 歯磨き中にKindleで本を読む |
| 感情に動かされるのではなく、感情をコントロールしてマインドフルに生きたい | 朝起きたら2分瞑想する |
また、習慣をきちんと記録することも始めてみたい。プログラミングではGitHubで履歴が可視化されるので進捗がわかりやすいが、他の習慣については記録していない。まずはカレンダーを用意し、そこに毎日印をつけていくことから始めてみようと思う。
次に読みたいもの
意志力について、自分のまとめを読み返す hiramekun.hatenablog.com
Soft Skills にも毎日のinputやコードを書くことについて何かしら書かれていたような...忘れてしまった
