Gitで、特定の文字列が取り込まれたコミットを探す
「この処理がプロダクションコードに入ったのはどのコミット（PR）なんだ？」が知りたい場面があり、調べた。最近はこういうのもChatGPTで一発なので便利な世の中になった。
結論
git log -S'{文字列}'
コミットが特定できたら、GitHubでコミットハッシュで検索かければPRの特定もすぐにできる。
例
実行するとこんな感じ
$ git log -S'aaa'
commit dfef04b4e9bc708a1b3866f4cabfd202bf58486f (HEAD -> hoge)
Author: Shimpei Wakida <[{user_email}】>
Date: Sat Jul 19 17:22:43 2025 +0900
commit-2
commit 2a3ee1983aecdb0fbd7358c7474377871a5bf6c0
Author: Shimpei Wakida <[{user_email}】>
Date: Sat Jul 19 17:21:02 2025 +0900
commit-1
オプション
-p オプションをつけると、diffが見れる
$ git log -p -S'aaa'
commit dfef04b4e9bc708a1b3866f4cabfd202bf58486f (HEAD -> hoge)
Author: Shimpei Wakida <[{user_email}】>
Date: Sat Jul 19 17:22:43 2025 +0900
commit-2
diff --git a/sample2.txt b/sample2.txt
index e69de29..d0bc53a 100644
--- a/sample2.txt
+++ b/sample2.txt
@@ -0,0 +1,3 @@
+aaaaa
+bbbbb
+ccccc
commit 2a3ee1983aecdb0fbd7358c7474377871a5bf6c0
Author: Shimpei Wakida <[{user_email}】>
Date: Sat Jul 19 17:21:02 2025 +0900
commit-1
diff --git a/sample.txt b/sample.txt
index e69de29..1802a74 100644
--- a/sample.txt
+++ b/sample.txt
@@ -0,0 +1,3 @@
+aaa
+bbb
+ccc
-- path/to/file でファイルを指定することも可能
$ git log -S'aaa' -- sample.txt
commit 2a3ee1983aecdb0fbd7358c7474377871a5bf6c0
Author: Shimpei Wakida <{user_email}】>
Date: Sat Jul 19 17:21:02 2025 +0900
commit-1
Vimでファイルを閉じてもUndoできるようにしたい
Claude Codeの登場により、ターミナルでの作業が圧倒的に増えた。これを機にCLIなエディタをキャッチアップしたいと思い、Neovim入門中。元々IDEのVim拡張を使っていて、サーバー内作業で vi しか使えない時でも恐怖心はないかな、くらいのレベル感。
直近、Git管理していないファイルに対して意図しない編集をしてしまってそのままファイル閉じてしまい、元の状態に戻したいけど元の状態が分からん！となる状況に出くわしたが、それを解消できる方法について。
.vimrcに以下設定入れると、セッションをまたいで u(undo), ctrl+r(redo)ができる。
set undofile # 履歴をファイルに保存 set undodir=~/.vim/undodir # 保存先ディレクトリ（任意）
これをChatGPTで調査する過程で、:earlier という数分前や数ステップ前にジャンプできるコマンドがあることも知った。明確に「1つ前に戻りたい」みたいなとき使うといいかも。
↓ o3の出力そのままコピペ
| やること | コマンド | メモ |
|---|---|---|
| 1 回だけ元に戻す／やり直す | u / Ctrl-r |
いわゆる Undo / Redo |
| 数分前や数ステップ前にジャンプ | :earlier 10m（10 分前）:earlier 15（15 ステップ前）:later 5 |
m=minutes、s=seconds、h=hours、d=days も使える |
Macアプリ「Clean」がApp Storeから消えたので、自作してみた
はじめに
Macのデスクトップ整理アプリの「Clean」を愛用していたが、いつからかApp Storeでの提供が終わっておりPCリセットしたタイミングで使えなくなってしまった。デスクトップにあるファイルを日に一度自動で日毎のフォルダを作ってそこに格納するシンプルなアプリだが結構助かっていたので、AIの力を借りて自作してみることにした。
環境
- macos: Sonoma 14.7.2
要件
- 毎日、特定の時間に一度実行する
- 前日の日付（yymmdd形式）のディレクトリを
~/clean/配下に作成 - デスクトップにあるファイルを全て作成したディレクトリに移動
実装方法
ChatGPTに相談すると、要件 2と3 に関しては シェルスクリプトで、1に関しては Macのlaunchdの機能を使えば実現できることが分かったのでその方法で進める。launchdは使うの初めてだったのでちょっと苦戦した。
1. シェルスクリプトの作成
要件23を満たすシェルスクリプトの作成
#!/bin/zsh # 前日の日付を取得（yymmdd形式） YESTERDAY=$(date -v-1d "+%y%m%d") # 移動先ディレクトリの作成 DEST_DIR="$HOME/clean/$YESTERDAY" mkdir -p "$DEST_DIR" # デスクトップのファイルを移動 mv "$HOME/Desktop/"* "$DEST_DIR/" 2>/dev/null || true
このスクリプトを~/scripts/clean_desktop_files.shとして保存し、実行権限を付与します。
2. launchctlによる自動実行の設定
launchd を制御するためのコマンドラインツールであるlaunchctlを使用する。
以下のようなplistファイルを作成し、~/Library/LaunchAgents/com.example.clean_desktop_files.plistとして保存。
<?xml version="1.0" encoding="UTF-8"?> <plist version="1.0"> <dict> <key>Label</key> <string>com.example.clean_desktop_files</string> <key>StartCalendarInterval</key> <dict> <key>Hour</key> <integer>0</integer> <key>Minute</key> <integer>5</integer> </dict> <key>ProgramArguments</key> <array> <string>/bin/zsh</string> <string>/Users/username/scripts/clean_desktop_files.sh</string> </array> <key>RunAtLoad</key> <true/> </dict> </plist>
この設定では、
- 毎日午前0時5分に実行
- システム起動時にも実行（
RunAtLoadがtrue） /bin/zshを使用して/Users/username/scripts/clean_desktop_files.shを実行
あたりが書かれている
3. 権限の設定
スクリプトを実行するために、/bin/zshにフルディスクアクセス権限を付与する必要があるのでする。
4. launchctlの設定
以下のコマンドでlaunchctlの設定を行う。
plistファイルの権限を設定
chmod 644 ~/Library/LaunchAgents/com.example.clean_desktop_files.plist
新しい設定を読み込む
launchctl bootstrap gui/$(id -u) ~/Library/LaunchAgents/com.example.clean_desktop_files.plist
即時実行テスト
plistファイルが正しく設定されているか、手動実行で確認できる。
launchctl kickstart -k gui/$(id -u)/com.example.clean_desktop_files
問題なく動けば、StartCalendarIntervalの時間設定以外は正常に行われていると言えそう。
5. plistファイルの更新手順
一度launchctl bootstrapで登録した後にplistファイルを更新する場合は、以下の手順で行う。
既存の設定をアンロード
launchctl bootout gui/$(id -u)/com.example.clean_desktop_files 2>/dev/null # 設定が正しくアンロードされたか確認 launchctl list | grep com.example
新しい設定を読み込む
launchctl bootstrap gui/$(id -u) ~/Library/LaunchAgents/com.example.clean_desktop_files.plist # 設定が正しく読み込まれたか確認 launchctl list | grep com.example
まとめ
launchdは今回初めて使ったので学びあった。AI使えばこのあたりはサクっといける。
『モノリスからマイクロサービスへ』読んだ
最近ソフトウェアの設計領域に興味が沸き始めている。最近の業務では統括EM的ポジションで採用やチームスケール体制づくり等組織開発メインでやっており、コードを書くことはほぼない。ただ、コンウェイの法則の通り、組織とアーキテクチャは同時に考える必要があり、組織を設計する人には少なからずアーキテクト的素養が求められる（逆も然り）。
現職の組織開発において、これまでは1チーム体制が続いていたのだが直近一気に3チーム体制になり、チームの境界をどう引くか？など複数チーム特有の問題に頭を悩ませる時間が増えた。そうなると自然にアーキテクチャにも関心が向くようになった、という背景。
現職に入社するまでまともなWeb開発経験もなく、これまでモノリス以外の構成は未経験なので、具体の事例は正直理解が難しかった。
ただ、
- マイクロサービスは銀の弾丸ではない
- マイクロサービス化するメリットがコストやリスクを上回るのか、移行まえに時間をかけて真剣に考えろ
- 移行するなら、安全に段階的にやるべし（そのための手法は本書を見ればよい）
といった本質的に著者が伝えたかったであろうメッセージは伝わり、自分の解像度も上がった。
チームで技術的な会話をしていると「この問題の解決策なら、マイクロサービス化するくらいしかないですかね〜」といった、おそらく発した本人も本気で言ってはいないであろう雑な提案を見聞きすることは多い。マイクロサービス化した時のうまみはまだまだ分からないが、やるとなったらどれだけ大変か、その上で進む覚悟はあるか、といった問いかけをし、議論できるくらいの知識は身についたかなと思う。
大規模スクラム手法と現状整理
社内向けに言語化したのもをせっかくなのでこちらでも言語化しておく
LeSS
- 「LeSSはスクラムである」と公式サイトでも言われるように、通常のスクラムを拡張したシンプルなフレームワーク
- 8チームまでを想定しており、それ以上のチームになると「LeSS Huge」
- 1つのプロダクトバックログ、1人のプロダクトオーナー、複数の開発チーム
- リファインメントやレトロは、各チームごとと全体でそれぞれ実施
Scrum@Scale
- チームごとにプロダクトバックログ＆プロダクトオーナーを持つ
- 「単一のスクラムに、チーム間連携の仕組みを追加したもの」
- プロダクトオーナーをスケールする仕組みを持つことがLeSSとの大きな違い
- WHAT領域のプロダクトオーナーをスケールさせる仕組み（= プロダクトオーナーサイクル）と、HOW領域の開発をスケールさせる仕組み（= スクラムマスターサイクル）という概念がある
- イベントをチームごとと全体で実施するのはLeSSと一緒
発散的メモ
- LeSSの「1つのプロダクトバックログ」とはどういう状況なのだろうか。うちでは一応Jiraプロジェクトとしては1つだが、チームごとにフィルター分けて管理している。これは1つのプロダクトバックログというのだろうか
- ツール起点で考えるのは本質的ではないが、「1つのプロダクトバックログ＆チームごとにスプリントバックログを持つ」はJiraだとどう表現されるのか気になる。もしかしたら今がそうなのか
- 今はチームごとに独立して何を作るか決めている（他チームのイシューとは分けて優先度付けしている）ので、今のうちの状況はおそらくScrum@Scaleに近そう
- そうなると、チーム間の連携（プロダクトオーナーサイクル/ スクラムマスターサイクル）をうまく回す仕組みがないと全体として正しい方向に向かって最大出力出せない状態になってしまいそう
- その全体整合性を保つのが自分の仕事になりそう
- 先日の事業内でのプロダクト意思決定ライン整備のワークショップ（RACIで責任範囲を明確化）で、「複数チームにまたがるプロダクトのWHAT（何をいつ作るか）」領域は事業責任者がRACIでいうA（責任者）、自分がR（実行者）を担うことになった。このRに求められる役割を一言でいうと「開発組織全体のスクラムマスター」だという結論になった。各チームはそれぞれスクラムマスター＆POがいてその中で意思決定してもらい、全体の方向性づけや交通整理を自分がやるイメージ。このワークショップで全ての役割が抜け落ちず明確化されたかは分からないが、落ちていたらそれを拾いにいくのも、その後どうにかするのも全体のスクラムマスターの仕事。アラインメント体制決めのMTGを設けたことも、まさにその仕事の1つだった。
ハイパー起業ラジオ：ず〜っと愛される番組を作る秘訣の会が面白かったのでメモ
ハイパー起業ラジオのプロデューサー・樋口さんゲストでここまでのハイパー起業ラジオそのものの戦略を語る会が、個人のブランディングや組織論にも応用できそうで面白かったのでメモ。
この動画をChatGPT要約した内容が以下
段階的な発展の重要性: 樋口さんは、ポッドキャストのコンテンツや戦略を急がず、段階的に発展させることの重要性を強調しています。外部からの影響や反響に左右されず、しっかりとした基盤を築くことで、長期的に愛される番組を作ることができると述べています。特に初期段階では、番組の方向性が定まっていない時に外部の反響が大きすぎると、思わぬ方向に進んでしまうリスクがあるため、慎重な進行が求められると指摘しています。 SNS影響力の制御: ポッドキャストの告知や宣伝は、番組の形がしっかりと固まるまで控えることが推奨されます。SNSでの影響力が大きい場合、過度な期待やプレッシャーがかかり、結果として番組が不自然な方向に進んでしまうことを避けるため、あえて外部に広めず、内輪での熟成期間を持つことが重要だとしています。 コミュニティの育成と管理: 樋口さんは、コミュニティを一気に大きくしないことの重要性を語っています。コミュニティが急激に拡大すると、文化やノリが固まる前に多くの人が集まり、結果として統一感や一体感が失われる可能性があるため、慎重に人数を増やしていくことが大切だと述べています。また、少人数からスタートすることで、自然にメンバー間に階層やメンターシップが生まれ、運営側が過度に関与しなくても、コミュニティ内での文化が育まれるとしています。 文化の醸成と維持: 初期段階でのコミュニティ運営においては、文化の醸成を重視し、ノリや雰囲気が自然に形成されるように工夫することが大切です。特に、初期のメンバーが自発的に後から入ってくるメンバーをサポートする仕組みを作ることで、持続可能なコミュニティを育てることができると樋口さんは考えています。 忠実なファンベースの構築: 最初からのファンやコミュニティメンバーに特別な価値や誇りを感じてもらうことが、番組の成功につながるとしています。初期のファンが、自分たちが早い段階で番組を見つけたことに喜びや優越感を感じ、その満足感が他の人に広めたいという動機につながることを期待しています。これにより、自然にファンベースが拡大し、結果的にブランドや番組が長く愛されるものになると考えています。
要約をベースに、メモ
段階的な発展の重要性: 樋口さんは、ポッドキャストのコンテンツや戦略を急がず、段階的に発展させることの重要性を強調しています。外部からの影響や反響に左右されず、しっかりとした基盤を築くことで、長期的に愛される番組を作ることができると述べています。特に初期段階では、番組の方向性が定まっていない時に外部の反響が大きすぎると、思わぬ方向に進んでしまうリスクがあるため、慎重な進行が求められると指摘しています。 SNS影響力の制御: ポッドキャストの告知や宣伝は、番組の形がしっかりと固まるまで控えることが推奨されます。SNSでの影響力が大きい場合、過度な期待やプレッシャーがかかり、結果として番組が不自然な方向に進んでしまうことを避けるため、あえて外部に広めず、内輪での熟成期間を持つことが重要だとしています。
→
個人のブランディングでも、発信によって影響力をつけるフェーズと、自力をつけるフェーズがあると思っている。発信によって影響力をつけるフェーズは、ある種スキルや時間の切り売りであって、そこでの純粋なインプットは少ないと思われる。
今の自分は、年齢は30代中盤に差し掛かろうとしているが、エンジニアに転職した時点でキャリアはほぼリセットされている。エンジニア転職して5年なので、社会人歴5年のつもりで生きている。
尊敬する山口周さんは「長期的にはインプットとアウトプットの量は同じになる。若い頃の無目的なインプットが超重要」と述べており、成田悠輔さんは20代の働き方として「若いうちは人目につくな」と述べている。
どちらも、若いうちには自分の興味が赴くままにインプットすることが長期的なキャリア形成においても大事という趣旨。
自分も、駆け出しエンジニア時代にはSNSの影響力をつけるぞ！と意気込みXのフォロワーを増やすために色々と頭を使っていた。当時は、「いいねやRTがいっぱいもらえそうかどうか」で投稿内容を決めていたし、自然とそういったインプットにもなっていた気がする。 それは本質的に自分が今すべきインプットではない場合もあったはず。
今ではXのフォロワー数やインプレッションを1ミリも考えなくなった。またストックとフローで考えた時、自分の思考や学びの軌跡はフローであるXではなくストックであるブログに中心に書くようになった。 ブログでは、Xよりも能動的に見にこなければ人の目に触れることはない特性があるので、心理的安全性が保たれている。
あとは、発信ありきでのインプットになると、いいねがもらえないとモチベーションにつながらないというリスクもある。誰も見てないやーくらいのノリでやっていれば、落ち込むこともない。
この状況で、20代のようにひたすらにインプットを続けていきたい。
コミュニティの育成と管理: 樋口さんは、コミュニティを一気に大きくしないことの重要性を語っています。コミュニティが急激に拡大すると、文化やノリが固まる前に多くの人が集まり、結果として統一感や一体感が失われる可能性があるため、慎重に人数を増やしていくことが大切だと述べています。また、少人数からスタートすることで、自然にメンバー間に階層やメンターシップが生まれ、運営側が過度に関与しなくても、コミュニティ内での文化が育まれるとしています。 文化の醸成と維持: 初期段階でのコミュニティ運営においては、文化の醸成を重視し、ノリや雰囲気が自然に形成されるように工夫することが大切です。特に、初期のメンバーが自発的に後から入ってくるメンバーをサポートする仕組みを作ることで、持続可能なコミュニティを育てることができると樋口さんは考えています。 忠実なファンベースの構築: 最初からのファンやコミュニティメンバーに特別な価値や誇りを感じてもらうことが、番組の成功につながるとしています。初期のファンが、自分たちが早い段階で番組を見つけたことに喜びや優越感を感じ、その満足感が他の人に広めたいという動機につながることを期待しています。これにより、自然にファンベースが拡大し、結果的にブランドや番組が長く愛されるものになると考えています。
→
採用と組織拡大においても同じことが言えそう。
一気に拡大すれば、大事にしたい文化が定着せず、結果としてすべてが機能しなくなるリスクがある。
また、古参メンバーの帰属意識をどうやって高めるか？という視点もとても大切。
新メンバーに文化を伝えるオンボーディング的な役割は、文化をよく理解し体現している古参メンバーにやってもらいたい。マネージャーのリソースは有限。
『アメリカはなぜ安倍晋三を賞賛したのか』読んだ
政治系の本は初めて読んだかもしれない。
現在の世界を正しく理解するには、政治・経済・社会とその歴史を知る必要があると最近強く感じる。大学生の頃から考えていたが、15年経ち、より深くそう思うようになった。
これまで政治に無関心だったので、興味を持つきっかけになればと手に取った1冊。結果的に、大きく目的達成できた。
安倍晋三元首相の活動や功績（慰安婦問題、靖国神社参拝、憲法改正など）に対する、日本と関係の強い外国の反応を、安倍氏を長年取材してきた記者目線で語る内容。
慰安婦問題、靖国神社参拝、憲法改正の議論の根底には歴史的背景があり、特に第二次世界大戦は現代社会理解に不可欠な知識だと実感した。
政治への興味が目的だったが、結果的に昭和史、特に第二次大戦前後への知的欲求が掻き立てられた。政治を知りたかったのは、歴史の文脈で当時の政権や社会情勢を理解するためだったと気づいた。
最も印象に残った（驚いた）のは、慰安婦問題での外国（特に中国）からの無根拠な批判を読んで、自分の中に怒りが芽生えたこと。 これまで全くと言っていいほど政治に無関心で、「日本人としての誇り」のようなもの特にないと思っていたのに、自分の中の日本人の心が怒っていた。
国内のリベラル派からの同様の批判には怒りを感じなかった。明らかに、「批判者が外国人であること」が怒りの原因だと思う。
歴史をもっと知りたくなり、その中での政治家の活躍についてもさらに学びたくなった。
『世界のエリートはなぜ「美意識」を鍛えるのか』
1年ぶりの再読。最近は仕事に直接すぐ関係しない本もたくさん読むようにしているが、その理由はこの本に詰まっている。今後も定期的に読み返したい。
ビジネスにおける3つの意思決定
1. アート
組織の創造性を後押しし、社会の展望を直感し、ステークホルダーをワクワクさせるようなビジョンを生み出す。 「美意識」はこのアート領域を指す。
2. サイエンス
体系的な分析や評価を通じて、「アート」が生み出した予想やビジョンに、現実的な裏付けを与える
3. クラフト
地に足のついた経験や知識を元に、「アート」が生み出したビジョンを現実化するための実行力を生み出す
上記3つが、どれか1つだけ突出していてもダメで、バランスが大事。
これまでのような論理思考に軸足を置いた経営、つまり「サイエンス重視の意思決定」では、VUCAと言われるこの不安定な時代を舵取りすることができない。「直感」や「感性」、いわゆる「アート」な決定も同様に重要。
なぜなら現実のビジネスでは、「数値化や論理で説明ができ、白黒はっきりできる問題」ばかりでなく、最終的にはリーダー個人の感覚で意思決定しなければならない場面が多くある。ここで必要になるのが美意識。
論理で説明ができるというのは、逆にいうと誰でも同じ答えに辿りつくことができる。つまり正解のコモディティ化が起こっている。差別化のためにも美意識が必要。
アート VS サイエンス
アートな意思決定は、ロジックで説明できない（説明できるならサイエンス/クラフト）ので、議論の場においてはサイエンスやクラフトにどうしても劣ってしまうとあった。直近の仕事で、まさにこうした場面に遭遇した。
上司であるCTOと同僚のEMがサイエンス的に導き出したGoの意思決定に対して、自分がいわばアート的な感覚でNoをぶつけた。「ワクワクしない」という非常に感覚的な理由でNoを伝えることになったが、最終的には自分の意見を尊重してもらえた。
まともに議論し「論理の正しさ」で勝負するとほぼ確実にアート側が負ける。アート的な意思決定を通すためには、日頃から信頼貯金を貯めておくことが大事だなあと、このブログを書きながら改めて感じた。
グレーゾーンで求められる美意識
変化が激しく法整備が追いつかない現代においては、「違法ではない（≒ グレーゾーン）」の領域が必然的に多くなる。その中では、道徳や倫理観に基づいての意思決定が求められる。つまり美意識。
近年の大企業の不祥事の数々は、まさしく美意識を欠いた意思決定の典型例。意思決定時には合法でも、後から遡って違法になるということもよくあるらしい。特に日本人は、違法性よりも倫理観を重視する傾向にあるらしく、より美意識が重要視される。
美意識の鍛え方
ではどうやって美意識を鍛えるのか？という話だが、本書の中では大きく4つ挙げられていた
- 絵画
- 哲学
- 文学
- 詩
このあたりは、山口周さんが多くの著書で一貫して述べている「リベラルアーツを学べ」に通ずるところ。 最近は仕事にすぐ役立つか分からない哲学・歴史・政治などの本を読むことが増えた。間違いなく山口周さんの影響が大きいが、純粋に知らない領域の知識が増えていくのが面白くて続けられている。
『独学の技法』読んだ
独学を単なるインプットとしてではなくシステムとして捉え、より知的戦闘力を高めていこうという本。
読書後ブログ等でアウトプットする場合としない場合、明らかに前者の方が記憶の定着がいい実感があった。しかし、これまでその理由はうまく言語化できていなかった。「アウトプットするといい」のは漠然と理解できているものの、そのメカニズムはよく分かっていなかった。
本書を読んで、アウトプットする過程で何をアウトプットするか（抽象化）、どうアウトプットするか（構造化）の思考プロセスを経ることで、改めて整理された状態で記憶されるのだと理解できた。つまり、アウトプットすること自体よりも、そのプロセスに意味がありそう。
また独学の技法とは直接的な関係の薄い内容だが、個人的に最も刺さったのは以下の点。
「リベラルアーツを学ぶ意味④ 領域横断の武器となる」において、「リーダーになるということは『非専門家』になることである」と述べられている。その究極は社長。
リーダーの仕事は、領域を横断して領域内に閉じている領域専門家を共通の目的のために駆動させること。「何かおかしいな」と感じたら、非専門家としての立場から領域専門家に口出しをしなければならない。自分はマネージャーとして、ある種の非専門家としてプロフェッショナルのエンジニアメンバーと一緒に働いている。彼らと仕事をする上で、プロフェッショナルとしてのリスペクトを最大限持って接しているつもりだが、その反動として本来言うべきこと言えていないという状況はないか。振り返ってみると、少なからずそういった場面はある気がする。
しかし、「非専門家として専門家に口出しするのはいかがなものか」と遠慮するのはリーダーの責務を果たせていないことになる。
今後、自身の課題としてしっかりと向き合っていきたい。
以下読書メモ
- 独学はシステム
- 戦略
- インプット
- 抽象化・構造化
- ストック
- 重要なのは覚えないこと
## 序章
- 学ぶだけでも、考えるだけでもだめ
- ケーススタディは、「自分ならどうしたか？」を考えなければ意味がない
- インプットが「学び」、抽象化が「考える」
- 戦略
- 何をインプットしないか
- 知的戦闘力を高めないものはインプットしなくてよい
- 政治ゴシップ
- 宿題）自分にとっての戦略は？
- 戦略は、荒い方向性だけでいい
- 偶有性からしか大きな学びはない
- インプット
- 本やネットの情報は、誰かの知的生産物なので、それを元に知的生産するのは劣化コピー
- 自分の五感で収集した情報は唯一無二
- 抽象化
- 情報に意味づけする
- 「問い」のないところに学びはない
-
## 第一章 戦う武器をどう集めるか
- テーマが主、ジャンルが従
- 盲目的な読書はバカになる
- いちチームにジャンルは複数またがる
- 自分が既に持っているものに着目する
- ポイントは2つ
- クロスオーバー
- 既にもっているものに着目
## 第二章 生産性の高いインプットの技法
- 長期的にアウトプットとインプットの量は同じになる
- 機会費用
- メタファーとメトニミー
- 読書量に比例して読書スピードはあがる
- 情報量ではなく情報処理能力がボトルネック
- 意図的に遮断すべき
## 第4章 ストック
- 記憶に頼らない
- いけすに情報という魚を生きたまま泳がす
- 分厚い知識ストックが常識を相対化する
- 終身雇用は日本の伝統でもなんでもなく最近の話
- 常識を疑う「why」思考がイノベーションをうむ
- 自分は全然ないなー
- 創造は、新しいものを生み出すのではなく、既存のものの組み合わせでしかない（by ジョブズ
- だからこそ、アイデアの種となるストックを取れだけ持っておけるかが重要
- アンダーラインは「事実」「洞察・示唆」「行動の指針」に引く
- 共感できない・反感を覚える情報にもアンダーラインを引く
- 転記する箇所は、「9箇所」に絞る
- 9という数字に意味はない
- 全て転記することはコスパ悪い
- 絞る過程で、再度読み込むので記憶の定着は高まる
- → ブログに書くのは、まさにこの行為
- 読書ノート、適度に読み返すことが重要
## おわりに
- 独学者こそが、世界を変えてきた
『LEADING QUALITY』読んだ
「品質文化をどのように組織に根付かせるか」がメインテーマの本。具体的なテストへの向き合い方が知れたのも大きかったが、自分も現場のマネージャーでやっている目標設定やビジョン作りについて言及があったのも面白かった。
品質はビジネスの成果と顧客価値に直結していることを再認識。
3つの品質ナラティブ
リーダーとして現場に変革を起こすために、まずは組織に根付く品質文化について理解する必要がある。
1. 責任ナラティブ：誰が品質に責任を持つかが考えられ、語られている
どう変化させていくのがよいか？でいうと、結論品質への責任は特定のチーム（QAやエンジニアチーム）が持つのではなく、組織全体に広げていくのがよいよね、という話。あらゆる部署がプロダクトの品質に直接関わっている。
2. テストナラティブ：品質向上につながる正しいテスト技法はどれか・どのツールを使うべきかが考えられ、語られている
いわゆる「どうやってQAするの？」の領域。QA界隈で最も語られるもの。
どんなプロダクトなのか？どんな開発手法なのか？ユーザーからの期待や要望はどのようなものか？こうしたコンテキストを踏まえ、テストナラティブは語られる。
プロダクトライフサイクルによっても適切なテスト手法は変わるので、テストナラティブは静的なものではない。
3. 価値ナラティブ：品質に投資した場合の見返り（ROI：投資収益率）が考えられ、語られている
QA界隈で最も語られづらいもの。採用・インフラ強化・ツール導入等の品質への投資は分かりやすいが、その結果としての顧客満足度の向上・社内業務の効率化・チームが費やす時間の短縮の測定は難しい。
収益性・コスト削減・リスク軽減の3つの観点で見るとよい。
テストの種類
テストには大きく2種類ある。1つは新たな情報を得るための「調査」と、もう1つは「検証」で想定通り動くかを確認するもの。
調査と検証、という区分は、『知識ゼロから学ぶソフトウェアテスト』では「探索的テスト」と「テストケースベーステスト」と表現されていた。直近うちのチームでも一人目QAエンジニアを迎え入れてQA体制の構築を行っているが、まさにの調査と検証を使い分けている。開発と並行して調査を行い、未知のバグを発見していく。ここでかなりの数のバグが見つかる。その後、テストケースで正しい仕様通り動くか確認していく。
本記事執筆時点ではテストケース作成前なので「検証」フェーズはこれから。QAとして意図的に調査を組み込むのは初めてだったので、どれほどクリティカルなバグが拾えているか、検証フェーズの結果が楽しみ。
自動化すべきか
なんでも自動化すればいいというものではない。自動化すべきかの判断基準が本の中で紹介されていたので、引用。
- 自動化されたテストケースが変更の手を入れることなく長期にわたって利用できると期待できること
- テストケースが比較的自動化しやすいものであること。すなわち、細部にわたる操作を必要としない手動テストから生成できるか。手順が複雑になるほど、自動化は著しく困難になる。
- 手動で実施するよりも自動化して実施および維持するコストの方が安い
基本的には費用対効果で考える必要がある。直近E2E自動テストツールのMagicPodを社内に導入したのでこれからシナリオを充実させていく予定だが、どこまでを自動化させるのか誰も判断基準を持っていなく路頭に迷っている感があったので、一つの基準として使ってみたい。
プロダクトライフサイクルと品質
フェーズによって求められる品質が変わるのは当然。また、数多の素晴らしいプロダクトで溢れている昨今ユーザーも目が肥えてきて当たり前品質の水準は日々上がり続けるので、MVPといえども品質の要求水準は高まる一方。品質が低すぎるとユーザーは2度と使ってくれないので、どこまで品質を求めるか？はユーザー感度の高さが求められる難易度の高い領域だなと思った。
適切な目標指標
プロダクトの種類によって適切な指標は3種類ある
1. アクションベースの成長指標
メディア、ゲーム業界等多くの toCエンタメサービスにおいて有効。DAU等。
2. トランザクションベースの成長指標
商品やサービスを購入させることが本質のEC、マーケットプレイスなど。Airbnbは予約成立数、Uberは乗車完了数など。
3. プロダクティビティーベースの成長指標
toBサービスの多くは、顧客の業務生産性を高めることが目的。顧客が与えられたタスクをどれだけ素早く成功させられるか。 Slackの「2000以上メッセージをやりとりしたチームの数」など。
アクションベースがアクションそのものに着目するのに対し、その結果に着目しているという解釈をした。
戦略の前にビジョン
明確に描かれたビジョンには、とてつもないパワーがある。自分たちはどこに向かいたいのかを示す最上位レイヤー。 ただ、ビジョンが役に立つかどうか、リーダー自身がそのビジョンにワクワクしている必要がある。
元々自分自身がビジョンを持たずに生きてきたタイプなので、未来や社会に目を向けるのはとても苦手という自覚がある。しかし、ビジョンを作り語るためには、未来や社会の視点が不可欠になる。自分がマネージャーとしてさらに飛躍するために、間違いなく重要な要素の一つ。しっかりと向き合っていきたい。
