一段上のレイヤーを考えるために、今の仕事を効率化する
NotionやAIを使って、タスク管理・エラー監視・レビュー・情報整理に使う認知資源を減らし、その余白をシステム全体や事業側の問いへ振り向け始めた過程を振り返る。
今感じていること
最近、仕事の中で一段上のレイヤーを考えられる場面が少し増えた。
これまでは、機能実装やレビュー、エラー監視、細かなタスク管理に頭を使うことが多く、そこまでが自分の責任範囲だと捉えていた。
今は少しずつ、
- システム全体をどう構成するか
- どの順番で作るか
- どこを最初のスコープから外すか
- 技術上の整理から、事業側が何を決めるべきか
まで考える機会が増えている。
この変化を振り返ると、単に「全体を見る意識を持った」からではなかった。
一段上のレイヤーを考えるための時間と認知資源を、少しずつ作り始めたこと。
これまで頭を使っていたもの
最近取り組んでいる改善は、見た目には別々のものだった。
- Notionでのタスク管理
- 本番環境のエラー通知の要約
- レビュー観点のナレッジ化
- ディスカバーで扱う情報の集約
- AIを使った実装や成果物作成
それぞれに個別の課題がある。
レビューには時間がかかる。
エラー通知は流量が多く、重要なものが埋もれる。
ディスカバーでは議事録やメモが増え、文脈を頭の中だけで持ち続けるのが難しい。
タスク管理では、未完了の仕事を忘れないために頭の片隅を使い続ける。
どれも改善する意味がある。
ただ、共通する上段の目的があった。
今のレイヤーの仕事に使っている時間と認知資源を減らし、一段上のレイヤーへ配分する。
タスクを終わらせるより、頭の外へ置く
Notionには、今抱えているタスクをすべて書き出している。
各タスクの進捗状態を持たせ、「今日やるもの」だけにチェックを付け、その一覧だけを見る。
一日の終わりに今日のリストが空になることは、まだあまりない。
載せる量が多く、少し残ったものを翌日に持ち越す日もある。
それでも、以前とは違う。
- 未完了タスクは残っている
- どこまで進んだかはNotionに残っている
- 明日やるものも一覧に残っている
- 自分は「今日はここまで」と区切れる
今日の仕事を全部終わらせたから安心できるわけではない。
終わっていないものを、頭の中で管理しなくてよくなった。
紙でやっていたことをNotionへ移しただけにも見えるが、「今日やるものだけが見える」「ステータスを動かすと一覧から消える」という体験は思ったより大きかった。
一日の終わりのすっきり感が変わった。
エラーを全部見る運用から、見るべきものを確認する運用へ
本番環境のエラー通知チャンネルは、チーム全員で監視している。
ただ、通知を見てくれる人は多くない。
ある金曜日、昼頃に通知されていた気になるエラーを夜に確認したところ、インシデントに近い事象が見つかり、深夜にメンバーが対応することになった。
ここで問題だと感じたのは、個人の注意力ではなかった。
- 通知量が多い
- 日常的に同じようなエラーも流れる
- たまに重要なものが混ざる
- 全員が継続して監視する運用には限界がある
「もっと見てください」と頼むだけでは続かない。
まず試し始めたのは、毎朝、前日一日分の通知をAIに確認させ、未知のエラーや気になるものをまとめてもらうこと。
まだ理想形ではない。
本当は一件ずつ取り上げ、対応の要否まで判断できる状態にしたい。
今はまず、
人間が全部読むのではなく、AIが絞り込んだものを人間が判断できるか。
その確認から始めている。
エラー数そのものを減らしたわけではない。
通知を読む時間を、見るべきものを判断する時間へ変える。
レビューコメントを、その場限りの指摘にしない
ここ一、二週間はレビューの負荷が高かった。
平日のうち、六、七時間ほどレビューに使う日もあった。
レビューしていると、同じ種類の指摘を繰り返している。
- 設計上の前提がコードに表れていない
- テストで確認すべき観点が抜けている
- 既存の実装ルールとずれている
- エラーハンドリングやログが不足している
個々のコメントには意味がある。
ただ、毎回自分がゼロから見つけ、同じ説明を書く必要はない。
そこで、自分がレビューで指摘した内容を個人のナレッジとして蓄積し、次回以降はAIが機械的に確認できる観点へ変え始めた。
目指しているのは、レビューをなくすことではない。
- 繰り返す指摘はAIへ移す
- 人間は今回固有の設計判断を見る
- 新しい問題に認知資源を使う
レビュー時間をゼロにするのではなく、レビュー時間の中身を変える。
ディスカバーの文脈を、頭の中だけで持たない
最近は、あるプロジェクトの初期検討を、プロダクト側や事業側のメンバーと一緒に進めている。
日々の議論では、まとまっていない一次情報が多く出てくる。
- 顧客との会話
- 会議の文字起こし
- 各所で作ったメモ
- 途中で出た仮説
- まだ確定していない要件
以前なら、それらを自分の頭の中でつなぎ続ける必要があった。
今は、関連する情報を一度まとめてAIへ渡し、そのコンテキストをもとに、
- 論点を整理する
- ユースケースをまとめる
- 成果物の叩き台を作る
- 抜けている観点を確認する
という使い方をしている。
自分は細かな情報を漏れなく保持することが得意ではない。
何かを忘れたあとで、「あれもあった」と気付くことも多い。
忘れない人になろうとするより、
忘れても文脈を復元でき、成果物を作れる状態。
これも、頭の中に置いておく情報を減らす取り組みの一つになっている。
空いた時間で、Howの全体像を描いてみた
今回のプロジェクトでは、少しだけ一段上のレイヤーで動けた実感があった。
これまで自分が責任範囲だと捉えていたのは、
ある機能をどう実装するか
という、Howの一部だった。
今回は、まずシステム全体の大枠を考えた。
そのうえで、
- 必要なタスクを分解する
- 依存関係を整理する
- ざっくり見積もる
- 着手順と開発スケジュールの叩き台を作る
ところまで進めてみた。
全体を分解すると、大きく二つのタスクツリーが見えた。
片方は、依存するタスクが多く、初期段階から入れるとプロジェクト全体の不確実性を上げる構造になっていた。
その整理を持って議論したことで、
このタスク群は、初手では入れなくてもよいのではないか
という話ができた。
結果として、片方のツリーを軽量化できた。
起きたことは、実装速度の向上ではない。
- 作り始める前にスコープを見直せた
- 依存関係の多い部分を軽くできた
- プロジェクト全体の不確実性を下げられた
実装前の意思決定を変えられた。
技術の整理が、事業側の問いにつながった
タスクツリーを整理したことで、技術だけでは決められない論点も見えた。
どの利用者を最初の対象にするのか。
どこまでの行動をプロダクト側で支援するのか。
何を初期スコープに含めるのか。
事業側のメンバーは、その論点を別の定例へ持ち帰り、営業側とも話すことになった。
ここで価値があったのは、技術的な全体図をきれいに描けたことだけではない。
Howを整理したことで、Whatとして決めるべき問いが表に出た。
これまでなら、決められた機能をどう作るかというところから参加していた。
今回は、その前にある意思決定を少し前へ進められた。
一段上のレイヤーで価値を出すというのは、こういうことかもしれない。
材料は以前から見えていた
今回のことを振り返ると、少し悔しさも残った。
数か月前から、次のフェーズを示すような話は出ていた。
当時は、それぞれを別の発言として聞いていた。
今見ると、同じ方向へ向かう情報だったと分かる。
アーキテクトに壁打ちしたときには、かなり前に作られた全体構成のメモも出てきた。
アーキテクトだけが特別な情報を持っていたわけではない。
自分も、同じ情報にアクセスできていた。
違ったのは、
- 自分は機能実装までを責任範囲だと思っていた
- アーキテクトは曖昧な段階でも全体像を描いていた
という点だった。
考える材料がなかったのではない。
一段上の問いへ頭を使う余裕と、そのレイヤーまで自分が考えてよいという認識がなかった。
個別株を通じて、事業を見る視点も増えた
最近は、資産形成だけを目的にするのではなく、事業を深く知るために個別株も少し勉強している。
興味があるのは、短期的な株価よりも、
- 企業が何で利益を作っているか
- 持っている資本をどう使うか
- どこへ投資し、何を伸ばそうとしているか
- 収益性をどう上げるか
という部分。
仕事でも、プロダクトを作ること自体ではなく、その先の事業をどう成立させるかという議論に触れる機会が増えた。
知識として見ていた企業分析と、仕事の中で起きている意思決定が少しずつ重なっている。
個別株を見ることも、事業責任者と話すことも、別々の学習ではない。
事業がどう動くのかを見る解像度を上げること。
今回の整理
最近取り組んでいることを並べると、次の流れになる。
機能実装・レビュー・監視・タスク管理に
時間と認知資源を使う
↓
NotionやAIへ、記憶・監視・反復作業を移す
↓
今のレイヤーに必要な時間を減らす
↓
Howの全体像を考える時間ができる
↓
実装前にスコープや不確実性を見直せる
↓
Whatとして決めるべき問いも見える
最近やっている効率化は、単に仕事を早く終わらせるためのものではない。
空いた時間を、別の細かな仕事で埋めるためでもない。
自分が考えるレイヤーを、少しずつ上へ移すための効率化。
次に試すこと
これからも、機能実装やレビュー、運用対応は必要になる。
今の仕事を手放したいわけではない。
同じ品質で担うために必要な時間を減らしたい。
そのために、次の改善を続ける。
- 繰り返すレビュー観点をAIへ移す
- エラー通知を、全件監視から確認対象の絞り込みへ変える
- タスクやプロジェクトの文脈を頭の外へ置く
- 機能実装でも、AIに任せられる範囲を増やす
- 情報が揃い切る前に、Howの全体像を一度描く
そこで生まれた時間を、次の機能実装で埋めない。
Howの一部に使っていた時間を、Howの全体像へ移す。
Howの全体像に使える時間が増えたら、Whatの言語化にも少しずつ関わる。
今のレイヤーの仕事を効率化しながら、時間配分そのものを一段ずつ上へ動かしていく。