定期購読しているランナーズの2月号が届きました

ランナーズ2026年2月号

開けた途端にトランプマンさんが出てきて吹き出しそうになりました。
すごい懐かしい！

そして、月間走行距離は150km前後ということですが、チャレンジ富士五湖やサロマ湖などのウルトラマラソンにも出場されているとのこと。
すごいですね。

この格好で走っているわけではないので、流石にわかりませんが実は隣を走っているのがトランプマンさんだった！なんてこともあるのかもしれません。

筋トレ

今月号の”プレイバックランナーズSince1976”は筋トレ大全ということで、これまで誌面で紹介されてきた筋トレが色々と紹介されています。

筋トレ。なかなか続かないんですよね。。。
サブスリーを目指す身としては、ベースアップを図る必要があるので筋トレは必須と考えているのですが、うまいことタイミングが合いません。

Garminのプランでも、予定よりランを多くしたりするとすぐに筋トレプランがどっかへ行ってしまったりしてしまう。
立ててくれるプランとは別に、自分自身でしっかりと計画を立てる必要がありますね。

良いルーチンを作っていかないと行けないと改めて感じる次第です。
曜日を決めてやらないとですね。。。

AI活用

走力向上にAIを活用ということでいくつか事例が載っていました。

私も過去に、RunmetrixやGarminのデータを食わせてサブ3.5行けそう？って聞いてみたのですがあまり参考になる答えが帰ってきませんでした。
というのも、日々のデータってジョグも多く入っていたりするので、そのデータを見てサブ3.5行けるか？って聞かれたらそりゃ難しいですって答えになるんですよね。

そうなると、各ランの意図などを含めた情報を作って連携しないといけなくなり、うーんって感じでやめてしまいました。

活用談3として書かれていた下記の情報を食わせるやり方は面白いかな、と思いました。

早速試してみる

これから先のマラソン大会へ出場するに当たってのトレーニングプランを考えたいです。 ・自己ベスト：3時間21分08秒（フルマラソン） ・これからの出場レース：2026年 1月18日第45回フロストバイトロードレース (大会詳細)、2026年 2月8日さいたまマラソン2026 (大会詳細) 、 2026年4月19日チャレンジ富士五湖（120km） ・ロング走をする曜日：土曜日か日曜日 目標：さいたまマラソンでサブスリー。チャレンジ富士五湖は120km完走

この目標を達成する上で必要となるトレーニングのチャレンジ富士五湖までの大まかな概要と1月末までの日別のトレーニングメニューを作成してください

上記のプロンプトをClaude Opus4.5に考えさせてみた結果がこちら（一部抜粋）

特に指示は出していなかったけど、何故かDOCX形式で作り始めた。マークダウンでも良い気はしたんだけど。

見てみると、ランニングメニューしか無いので、このあと筋トレの必要性を聞いて、メニューに入れ込んでもらったりしました。
実際のところ、Garminでやろうとするとこの情報をカレンダーに登録しておかないと手動で計測することになるのでうーんというところ。

カレンダーへの登録はAPIが無料ではないのでGarminConnectから手動で。。面倒だなぁ
となると、楽なのはChrome拡張を作って、自動登録させる、、なんてことができれば良さそうですね

ちょっとどこかで試してみたいところです。

少しずつですがクルーシャルカンバセーションを読み進めています

クルーシャル・カンバセーション −−重要な対話のための説得術

きっかけとしては、以前読んだ「GitLabに学ぶ 世界最先端のリモート組織のつくり」で紹介されていたGitLab Handbookで本が紹介されていました

Crucial Conversations | The GitLab Handbook

色々と考えさせられる本で、相変わらずの遅読ですが学びになっています。

ここで言うクルーシャルカンバセーションは下記のようなものです

（一）重要な結果、（二）反対意見、（三）強い感情を伴う、二人以上で行われる話し合い

必ずしも評価面談のような最初から予想のできる重要な会話・対話の機会に限らず、日常的な会話から急に重要な分岐点となる会話に変化することがあります。

ただ、その時にその変化に対応せず流れで進めたり、感情のまま進めることで”本来自分が望みたい結果”ではなく”眼の前の会話に勝利する”ための会話になってしまったりする。

思い返すと恥ずかしくなります。

謝罪してやり過ごすのでもなく、へりくだるわけでもないので非常に難しい。
というか、自分の感情との付き合い方なのかもしれません。

まだ半分くらいしか読めていませんが、それでも「あれ、この会話はクルーシャルカンバセーションになっていないか？」を意識するようにしています。

それだけでも随分と自分の行動は変わるもの。
残りも読み進めていってより良い会話ができるようにしていきたいです

サーバント・リーダーシップ入門

入門となっている本書は、サーバントリーダーシップに関しての背景や著者二人の対談などを通してどんなものであるかの解説を行っている。

サーバントリーダーシップという言葉を聞いたのは随分と昔の話だなぁと思って発売日を見ると、2007年。
もう18年も前の本なんだな、と気づく。
当時はサーヴァントと聞くとFateのことしか思いつかなかったものだ。

世の中的に、今のリーダーシップ像がどうなっているのだろうか？はあるのだけど、現代においてサーバントリーダーシップで語られている話はだいぶ受け入れられているようにも思える。
考え方自体は受け入れられているとは思うのだけど、それはリーダーなのかマネージャなのか？となるとちょっと考え込んでしまう。
人を支える。という意味においてはマネージャのほうがしっくり来るんですよね。

グリーンリーフがサーバントリーダーの持ち味として以下を出している

1. リードするという個人の側の意識的なイニシアチブ
2. 大きな夢、ビジョナリーなコンセプト、究極のコミュニケーション
3. 傾聴と理解
4. 言語と想像力
5. 控えることを知っている
6. 受容と共感
7. 感知力、予見力
8. 直感、信頼、決断
9. 見通し
10. 気づきと知覚
11. 説得上手
12. 癒やしと役立ち

半分くらいはサーバントリーダーとしてわからなくもないけれど、別にサーバントリーダーじゃなくても、というのが正直な感想だ。

本書でも語られているけれど、トップダウンで物事を決めていく従来型のリーダーシップと、フォロワーにつくすというか、フォロワーが動きやすいようにフォローしていくようなサーバントリーダーシップ。
それぞれ必要な場面は存在すると思うので、どちらかという話ではないんだと理解はしている。

そしてどちらを選ぶかは、チームが何に対面しているかにもよるし、チームメンバーの成熟度というかなんというか、そういうものにも左右されてしまう。
自走が難しいからこそフォローをする必要があるんだろうけれど、フォローで方向性に関してうまいこと向かわせることができるのだろうか？
そもそも、この”向かわせることが”って考えている時点で違うのかもしれない
うーん

まぁ、とりあえず引っ張るだけがリーダーじゃないよ！ってところと、当時と今では前提がちょっと変わってきているものもあり、その変わることへの一役を買っていたんだろうと思うことにした。

Audibleで「プロジェクトマネジメントの本物の実力がつく本」を読んだ

書名: プロジェクトマネジメントの本物の実力がつく本 組織力・コミュニケーション能力・リーダーシップ・キャリア構築力を全部鍛える
著者: 橋本将功
出版社: 翔泳社
発売日: 2023年10月19日

本書は、いわゆるプロジェクトマネジメントの手法が書かれているわけではない。どちらかというと、マインドセットや組織のあり方といったものが中心となっている。

プロジェクトマネージャー一筋23年の著者が、これまでに経験した失敗から学び得た知見を注ぎ込んだ一冊で、組織力・コミュニケーション能力・リーダーシップの3つの能力を高めるための考え方と行動が丁寧に解説されている。

印象に残ったキーワード

本書を読んで気になったワードをいくつか挙げる。

• 組織のマネージャとプロジェクトのマネージャを兼任しない
• ブリリアントジャーク(有能だが組織に対して悪影響を与える人材)
• 防衛戦・撤退戦となるプロジェクト
• いつまでプロジェクトマネジメントをし続けるのか
• フェーズにおけるプロジェクトマネジメントの労力
• プロジェクトマネージャへの評価と待遇

思い返して特に記憶に残っているのは、「防衛戦/撤退戦」という考え方と、プロジェクトマネージャへの評価・待遇、そして組織マネージャとの兼任に関してである。

防衛戦と撤退戦という考え方

私はこれまで「負け戦に挑む」と表現していた。どう考えても最初から負け戦になるのが目に見えているプロジェクトは存在する。すでに炎上しているケースが一番わかりやすいが、そもそも内容的に無理なのではないかというものを、政治的な理由や業績的な理由で受けざるを得ない状態がそれに当たるだろう。

本書では、それらに対して「最終防衛ラインをどこに置くのか」を定めるべきだと述べている。なるほどと思った。

これは「勝利の定義をどこに置くのか」という話と似ているが、たとえば「プロジェクト完了時に誰も辞めていなければ勝利」といった定義や、場合によっては「プロジェクトを終わらせること」自体を勝利条件として設定せざるを得ないこともあるだろう。

何かしらのライン、目標を持たないと、精神的に全員が潰れてしまうか、ゾンビのような状態になってしまう。このあたりは心の持ちようとして意識していきたい。

プロジェクトマネージャの評価という課題

プロジェクトマネージャの評価に関しては、正直答えが思いつかない。

会社組織における人事制度として、プロジェクトマネージャという職種がどこまで定義されているだろうか。職階としてのリーダーやサブリーダー、マネージャという位置づけはあったとしても、プロジェクトマネージャというのはプロジェクトにおける役割であって、組織上の職階として定義されていないのが私の所属組織である。

そうなると、もちろん評価のタイミングでその業績に基づいて評価は行うが、「プロジェクトマネージャという功績に対しての評価なのか」と問われると悩ましいところだ。技術職上のスペシャリスト的な位置づけとして、プロジェクトマネージャの職階を作ってしまった方がすっきりする気もする。

組織マネージャとの兼任問題

私自身は、プロジェクトマネージャとして動くこともあるが、最近は組織のマネージャに軸足が移ってきている。そもそも、しっかりとプロジェクトを導いていくような難易度の高いことは私には厳しい(組織のマネージャが難易度が低いというわけではないが)。

しかし、兼任している方が世の中的にも圧倒的に多いのではないだろうか。もちろん、何をプロジェクトとして捉えるのかは現場や組織によっても違いはあるだろうが、結局プロジェクトマネージャができる有能なメンバーは、評価された結果、組織のマネージャに任命されそうである。

人事制度として組織のマネージャの方が給料が高い傾向にあり、ある程度昇進してきたら組織を任せる立場に上げないと給料が上がらないという、なんとも本末転倒な理由がありそうだ。このあたりは大きな課題になっていると感じる。

最後に

本書は、プロジェクトマネジメントの実践的な「実力」を身につけたい人、特に新規事業やDXに携わるマネージャー、受託プロジェクトのマネージャー、キャリアアップを図りたいプロジェクトメンバーにおすすめの一冊である。単なるテクニックではなく、プロジェクトマネージャとしてのキャリアや組織との関わり方まで含めて考えさせられる内容だった。

だいぶ前に届いていたのですが、なかなか読み進められず。。時間がかかりました

Software Design (ソフトウェアデザイン) 2025年12月号

今月の特集はID管理。
このあたりはちょっと苦手ですね。。。

BtoBというか、社内システム的なものを作る上ではLDAP連携はあれど外部の認証基盤を使うシーンは無いわけではないですが、結構限られる・・・うーん、相手によりますかね。

それこそOktaとか入れていれば使うことになるでしょうし。
それでも連携の手法というかやり方はそこまで大きくは変わらない印象です。
どうもあまり読み進められませんでした

連載で最近のお気にいりは「技術選定の舞台裏」今回はSUZURIのスマホアプリが取り上げられており、面白く読むことが出来ました。

いつもこの連載では自分の不勉強を感じられて辛いところですが、今回はKMPに関して。
少し前にKotlinのMultiplatformという存在を知ってはいたものの、しっかりと調べておらず今回の内容をきっかけにして調べてみようと思います。

また、Flutterでの難しさに関してもちょっと気になるところですね。
ちょうど今、Flutterに案件で挑戦しようとしているところなので、SUZURIの方々がうまく行かなかったというところが該当するのかどうか。
このあたりも勉強不足です。

というかですね、勉強なんて追いつかんのですよ。もう。
ふんがーってところです。眼の前の仕事にどれだけ積み重ねていけば良いのやら。

眼の前のことばかりだと外に目を向けることが億劫になってしまうので、やはりSoftware Designさんには頑張ってほしいところです。
ありがとうございます（何目線）

なんとなく手に取った本だったが、自分自身が組織運営に関しては悩んでいるというか、なんとかしないとなと思っている背景もあり色々と考えさせられる本だった。

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

Audibleで10時間近かったけれど、2周してしまった

オフィスワーク、リモートワーク、ハイブリッドワーク

GitLabはタイトルの通り、全従業員がリモートワークを実施しているオールリモートの組織とのこと。
本書としては、リモートワークの推進。それもハイブリッドの形態ではなくGitLabと同様に全従業員をリモートワークにすることを推奨としている

ただ、個人的には少し極端な気もする。
ハイブリッドの問題として挙げられているのは、オフィスワーカーとリモートワーカーそれぞれのメリット・デメリットによるお互いへの不満から来ているもの。
オフィスワーカーにとっては、通勤時間があることへの不満はありつつもオフィス設備の利用や情報取得の即時性。特に会社組織の上位レイヤーが出社している場合は、それらの人たちからの覚えの良さや情報伝達のスピードが利点として挙げられる。
リモートワーカーはなんといっても通勤が無いことによる時間の有効活用が一番の利点となる。一方で、オフィスワーカーだけが享受できる設備や情報取得に対する格差を感じてしまうところかもしれない。
先輩社員が出社している場合は、直接的な指導を受けやすいのは間違いなくオフィスであるだろう。

実際問題、新入社員やロースキルの若手メンバー育成を考えた場合、オフィスワークのほうが質問のしやすさや、問題を抱えていることへの察知のしやすさという点で良いように感じる。
どうしても、こういう有名企業の場合は、そもそもそこに入ってくる人のベースが高いという前提があるのではないかと勘ぐってしまう。
このあたりは、単純に管理の仕方の問題はあるかもしれないが、正直できる気がしないのが実情。
結果として、これを実現するためには先輩社員も出社をする必要があるなど、全体的にリモートから逆行してしまうという問題が生じる。

GitLabをオールリモートで効率的な組織足らしめている一つの要素として、情報を徹底的にドキュメント化していることを本書では紹介している。
このドキュメント化ができるのであれば、ハイブリッド状態でもある程度まで情報格差は解消できるのではないかとも思う。
オフィスワークするかリモートワークをするかの選択肢がエンジニア側に委ねられているのであれば、そこまで問題にならないのではないだろうか。もちろん、このドキュメント化の徹底ということの難しさは大いに感じることではあるのだけれど。

ドキュメント化

本書を読み、そしてGitLab Handbook の存在を知ってから、自社のドキュメント化をなんとか進めないといけないという認識を強く持つようになった。
あまりにも暗黙のルールが多すぎてしまい、ルールが定まっていない。
もしくは、明確になってなくその時その時で判断されてしまっている。これは臨機応変とは違うだろう、と。

リモートワークをするためではなく、しっかりとしたルールを明確化する。記録を取るということはこの先のAI活用が当たり前となる会社組織の中で非常に重要な要素に感じる。
ツールの進化によってドキュメント化も随分と以前と比べればやりやすくなっている。
特に私はミーティング中に話に夢中になってしまってあまりメモを取ることが出来ない。自動文字起こしをしっかりと活用しつつ、そのテキストをどう活用していくのかを含めて検討し、明文化していくことで組織の中での浸透を図っていかなければいけない

うーん、現状があまりにも出来ていないのでやることが多すぎてめまいがしてくる

これまでは正直、そのあたりをバックオフィス部隊の仕事であろうと文句をいうだけの立場だったが、少なからずメンバーからの質問は定期的に発生する。
それを考えると、二度手間なところはあるが、整備したほうが全体としては良くなりそうな気もする。
一方で、それはあくまで暗黙のルールで、公式的に明文化されていないのであればそれを明文化する方に組織内へ働きかけるのが正攻法ではある。

正攻法ではあるのはわかるんだけれど、結果としてすごく面倒くさい方向になりそうな気もするので気が進まないというのも正直なところ。

まとめ

読んでいて、学びになることは非常に多かったのだけど、モヤモヤしていたりだめだなーって思うところが多く、「ではどうするか」に関しては足がすくむところはある

言ってしまうと、本書で書かれていることの殆どは、会社組織における人事制度を中心とした枠組み。
開発組織に属している中で、どこまで独自制度を整備できるかということには結構な制約がかかる。
そして全社的な立場に立ってしまえば良いのかもしれないけれど、それは別にやりたいことじゃないんだよなーって。

まずは自組織でできるところ。
特にドキュメント化に関しては進めていくとしてそれ以上の範囲をどうするかは戦略を考えないと行けない。

今回、本の主題であったリモートワークに関して記事を書いたが、それ以外にも初めて聞く単語や考えさせられること満載の書籍だった。
GitLab Handbookは公開されていることなので、膨大ではあるが少しずつ読み込んでいってエッセンスを有効活用していきたい。

いい本だった。

Audibelで「本質をつかむ」を読んだ

本質をつかむ

先日、会社の研修でマネージャーに求められるスキルとしていくつか挙げられた中に、この「本質を見極める」というようなものがあった。

本質

自分自身、色々な場面でものすごく表面的な反応をしてしまうことがよくあると思う。
色々な場面でそれを感じるわけだが、特に上司と話をしている中で、物事の捉え方が違うな、という場面に出会うこともある。
何かしら検索でヒットしたものを、そのまま鵜呑みにしてしまうというと考えてない感じがするが、でも実質的に考えが足りていないのだと思う。
反射になっているのだと思われる。

そんなこんなで色々とモヤモヤしている中で本書を見つけたので手にとって見たというわけだ。

前半は本質を見抜くことのメリットなどが書かれているが、基本的に本書を手に取る人であればそのメリットを列挙することにそれほど意味が無いのではないかと思う。

読み進めていくとわかるが、結局のところ、考える訓練を続ける必要がある。
ただ、そもそも考えた結果導き出した自分なりの答えが、本質なのかどうかの判断が難しい。
考えた結果の確からしさがわからないと、なぜなぜを続けて行っても終わりが見えなくなることもあるはず。
この、答えがあるようでないような問いはどうしたものかと攻めあぐねる

面白いと思ったのが、本質をつかむトレーニングとして、1週間のメニューを提案してきている点。

• 月曜日: 本質的な「意味」を見抜くトレーニング
• 火曜日: 本質的な「原因」を見抜くトレーニング
• 水曜日: 本質的な「目的」を見抜くトレーニング
• 木曜日: 本質的な「特性」を見抜くトレーニング
• 金曜日: 本質的な「価値」を見抜くトレーニング
• 土曜日: 本質的な「関係」を見抜くトレーニング
• 日曜日: 本質的な「大局」を見抜くトレーニング
  題材はニュース記事や仕事の中から選ぶことになる

やってみないとわからないところだが、変に深読みしているだけで本質にたどり着くことができるのだろうか。
まぁ、でもやってみないとわからないところはありそう。

技術書」の読書術 達人が教える選び方・読み方・情報発信&共有のコツとテクニック

読書術と銘打たれているが、読書の方法にとどまらず、本の選び方から始まり、読み方。そして情報発信や共有の方法までを含めた構成になっている。

選び方に関しては、書店や図書館での選び方は正直私にとってはあまり活用することはないかな？と思ったが、洋書を買う際のHumble Bundle, Better World Booksなどは初耳でした。
ちなみに、紹介されていたBookDepositoryはすでに閉鎖されているそうです。。。

特にHumble Bundleは、1.0USDでのまとめ買いもできるみたいで、その時々でラインナップの差はあるのですが試してみるのには面白そう。
洋書の場合は読むのが大変そうという問題はあるのですが、このあたりはLLMを駆使するなりしてなんとかしていきたいところですね。
Humble BundleはPDFでの提供をしてくれそうなのでまだなんとかなるのですが、問題はKindleでの洋書です。
Kindleで購入して読み進められていない本も実は手元にあったりするので。。。
そういう意味で考えると、Amazonで洋書を買うのはやめておいたほうが良いかな、という気がしてきてしまいます。
Kindleで読みたければPDFを取り込めば良かったと思うので。

読み方に関しても、わかっていながら実践できていないことが多いです。
特に、物理本であればパラパラとめくるということはよくあるのですが、電子書籍になるとパラパラと進めるのが正直難しいんですよね。
ただ、技術書などで例題をコーディングするような系統だとどうしても時間がかかり、結果として最後まで走り切ることが出来ないケースがよくあります。
そういうときに、定期的に先を見ることで、進めるためのモチベーションを復活させるということはいいな、と改めて感じました。
このあたりは実践していきたいところ。

本を読んだあと。
基本的に私はBlogに書くことにしているけれど、書いているだけだな、と改めて思った。
あまり活かしきれていない。

仕事におけるコミュニケーションは、すべからく行動に結びつく必要があるということをどこかで読んだ気がする。
本に関してもそうであって、この本を読んだ後で、では自分の行動として何に活かしていくのか。どう変えていくのか（場合によっては何も変わらないこともあるとは思うけれど）
つまりは何かしらの学びがあってほしいところ。
その整理ができていないのだと思った。

まずは、Blogに書く前にObsidianに記載してその内容を整理可能にする。
そしてこの本を受けてどうしていくのかを考えて見るということをやってみようと思った。
洋書に関しての挑戦もしていくとともに、技術書を継続して続けるためにも定期的に先を見てモチベーションを上げる。先を見てモチベーションが上がらないようであれば、それは逆にあまり現時点の自分にとってはタイミングとしてあっていない本なのかもしれない。
その時はおいておこう。

また、新しいプログラミング言語などを学ぶ際には図書館で複数冊借りて違いを見るというのも面白い方法だと思った。これは直近でDartを勉強しようとしているので試してみたいところ。
ただ、千葉市の図書館でFlutterを検索したら3年前のSoftware Designしか出てこなかった。。。

技術書はなかなか厳しいな。現実は。。
これは、都内の図書館のほうが良いのかもしれない

創刊50周年記念号であるランナーズ1月号が届きました

ランナーズ 2026年1月号 

私自身はランナーズを定期購読し始めて数カ月というひよっ子ですし、そもそも走り始めて3～4年というレベルなので、50周年と言われても何にも懐かしさの欠片もないわけですが、これまでの歴史を感じる一冊です

面白いのが、それぞれの時代に色々なトレーニング方法が紹介されているのですよね。
LSDが初めて紹介された号や、ファルトレクなどなど。
知っているトレーニング方法からちょっとしたTips的なものまで紹介されていて面白かったです。

個人的に取り入れてみたいな、と思ったのは2012年11月号「信号待ちはジャンプの時間！」
これは面白い。

走っていると少なからず赤信号や車を待つようなシーンに遭遇します。
トラックを走っているわけではない以上しょうがないですね。

これまでは迂回したり信号無視したりウロウロしたりとしていましたが、ジャンプによってバネを鍛えるという発想はなかったです。
これであれば、無理に信号無視する必要もないし、かえってリラックスしてトレーニングすることができそうですね

また、同じようにバネを鍛える方法として縄跳びも紹介されており（2019年10月号）、そういえば縄跳びは地味に長くやるの大変なんだよなぁと思い返します。

多くの著名人が50周年に寄せてコメントを入れているのでまだ見切れてはいませんが、のんびり眺めていきたいと思います

「一分で話せ」でおなじみの伊藤羊一さん著「壁打ちは最強の思考術である」をAudibleで読んだ

壁打ちは最強の思考術である

伊藤羊一さんといえば、Voicyで話をよく聞いており、壁打ちに関してのよく話が出ていたことを思い出しました。
（最近はVoicy自体を諸々の理由で聞かなくなってしまったのですが）

何年もVoicyで伊藤さんの話を聞いてきているので、なんというか書かれている内容がどれもいつも話されている内容であることに、本当に日常的に壁打ちが溶け込んでいるのだと気が付きます。

実際のところ、壁打ちに限らず発話することで思考が整理されるというのは何度も経験していることで、それは部下との1on1でもよく生じる現象です。
ただ、これを壁打ちとして日常の中に取り入れるというのは、職場環境にもよるとは思いますが、どうすれば良いのかがパッと出てこない。

多分、余裕がなさすぎるのだろう

本書の中でも、コーヒー片手にウロウロしていると壁打ちの依頼が来る。。。なんてエピソードが紹介されているけれど、それは壁打ちが組織レベルで根付いている職場であるし、そもそも日常的に壁打ちをするようなネタがある・・・？

と、ここまで考えてふと思うのは、我々IT技術者に取ってみれば、壁打ち＝ソースコードレビューなのではないかと。
いやいや違うだろうと。

レビュー ＝> 対象に対してのレビューアーからの評価や改善点の指摘
壁打ち ＝> 壁打ちをしたい人の思考の整理・深堀り・気づきの創出

と考えるとやはりレビューを壁打ちとするのにはちょっと無理がありそう。
レビューを出すもっと前の段階なんだろう。

であるならば、タスクを与えた後でその実装方針やなんかの検討結果を話してもらうような”壁打ち場”を意図的に作ってしまうのが良いのかもしれない。
ペアプロやモブプログラミングに近いのかもしれない

そんな気がしてきた。
いずれにしても、時間を取って行う行為ではあるので全てに適用するというのは難しいところだけれど、やってみる価値はありそうだ。

そしてここまで書いていてちょっと思うのは、私にとってこうやってブログを書くという行為も一人でやっているけれど壁打ちみたいなものだよな、と。
誰かに読んでもらって反応が返ってくるわけではないので、打ちっぱなしな感じはあるけれど。
まぁ、それはそれだろう。