振り返りを『気が向いたら』でなく仕組みにする
振り返りが続かないのは意志のせいじゃない。ひとり会社が『気が向いたら』をやめ、月次の定例に組み込んだ話。ハーネス=作業環境そのものを点検し、効かないルールを期限つきで捨てる運用の実感を書きました。
振り返りが続かない――その原因は、たいてい「意志が弱いから」にされます。でも、うちの答えは逆でした。意志に頼るのをやめて、振り返りを月次の定例に埋め込む。それだけで、機嫌に関係なく毎月おなじ質で回るようになりました。
私たちは、社長ひとりと AI の COO だけで回している小さな会社です。
人が少ないぶん、油断するとおなじ手戻りを何度でも繰り返してしまう。だから「振り返る気力があるかどうか」に運用の質を預けるのを、思い切ってやめました。
この記事は、その仕組み化を実際に回してみて感じたことの記録です。
🔧そもそも「ハーネス」を点検するとは
点検の対象は成果物じゃない。フックもルールも設定も――作業環境そのものを部品として見直す作業です。
振り返りというと、ふつうは「先月うまくいったか」を語り合う会になりがちです。
うちは、そこを見ていません。
見ているのは、成果物を生み出す土台のほう。私たちがハーネスと呼んでいる、作業環境そのものです。
コミット前に走るフック。AI が従う運用ルール。設定ファイル。裏で勝手に回っているルーチン群。このあたりを、ひとつずつ部品として点検します。
なぜかというと、成果は環境の関数だからです。
環境が歪んでいれば、どんなにがんばっても、おなじミスが構造ごと再生産されてしまう。だから感想ではなく、部品を見る。フックは全件パスするか。ルールは実際に守られているか。効いていない仕組みが惰性で残っていないか。ここを定例のチェックリストにしています。
🗓️週次と月次で役割を分けている
毎朝のスタンドアップで兆候を拾い、月初のレビューで構造を直す。二段構えにして無理なく続けています。
振り返りは、二段構えにしています。
毎朝の短いスタンドアップで、昨日の進捗とブロッカーを拾う。気づいたことはその場で直さず、いったんミスログに落としておきます。
そして月初に、ハーネスレビューという月次の点検をまとめて回す。
日々の気づきを溜めておいて、月に一度どかっと棚卸しする。この「溜めて・まとめて見る」リズムが、自分たちには合っていました。
なぜ、分けるのか。
毎日ぜんぶを見直そうとすると、疲れて続かないからです。
かといって年に数回だと、問題が積み上がってから気づくので手遅れになる。週次で兆候を拾い、月次で構造を直す――この分担が、無理なく続けられる落としどころでした。
🧹効いていないルールを捨てる勇気
月次でいちばん効くのは追加より削除。役目を終えた仕組みを期限つきで機械的に落とす運用にしています。
月次点検でいちばん効くのは、実は追加ではなく削除です。
意外に思われるかもしれません。
でも、ルールもフックも、増やすのは一瞬なんです。
そして増えるほど、全体は重くなる。読む気力も、判断の速度も、じわじわ削られていく。
だから毎回、明示的に問うようにしています。「今月、なくせるものはないか」と。
前に足した仕組みで、もう役目を終えたものはないか。ここを Dead Weight チェックと呼んで、点検項目に固定しています。
たとえば――旧世代のモデル制約を前提にしていたルール。
これには最初から削除の期限をつけておいて、その日が来たら棚卸しで機械的に落とします。
捨てるかどうかを、将来の自分の気分に委ねない。
「いつ捨てるか」を、先に決めておく。捨てる前提で足すと、ルール群が澱まずに済みます。
⚙️感想ではなく決定論で止める
「できた気がする」で完了にしない。到達したかどうかは感想でなく機械のチェックに判定させています。
仕組み化で、もうひとつ痛い目を見て学んだことがあります。
「できた気がする」で終わらせてはいけない、ということです。
以前、ある自動ループで「もう十分に達成したはず」と自己判断で完了宣言したことがありました。
ところが、あとから機械で測ってみたら――自己判定では「九割はできた」と言い切っていたのに、実測は半分をわずかに超えた程度。そもそもテストがコンパイルすら通っていませんでした。
感覚は、平気で嘘をつくんだなと思い知りました。
この一件から、到達したかどうかの判定は、感想に任せないと決めました。
機械的なチェックに測らせて、そこが通って初めて合格にする。
振り返りも同じです。「フックは健全なはず」では通しません。テスト用スクリプトを実際に走らせて、全件パスを確認してから合格にする。
振り返りを仕組みにするというのは――判定基準まで含めて、意志から切り離すことだと思っています。
🌱仕組みにして変わったこと
振り返りが反省会から整備に変わりました。機嫌の悪い月でも同じ質で淡々と回せるようになっています。
定例に埋め込んでから、いちばん変わったこと。
振り返りが「反省会」ではなく、「整備」になりました。
うまくいったか、ダメだったか。その感情から離れて、部品を点検し、要らないものを外し、効くものをひとつ足す。
やっていることは、車の整備に近い。淡々とした作業です。
感情の起伏に左右されないから、機嫌の悪い月でも、おなじ質で回せる。
ひとり会社にとって、これは思ったより大きな効果でした。
人が増えれば、誰かが「そろそろ振り返りませんか」と言ってくれます。
でも少人数だと、その声すら出ない。
だからこそ――振り返る意志ではなく、振り返らざるをえない仕組みのほうに投資する。そこに価値があると感じています。
✅まとめ
気力ではなく仕組みに預ける。週次で拾い月次で直し、期限を決めて捨てる――それで失敗は構造から減ります。
振り返りを続けたいなら、気力に頼らないこと。
仕組みに預けるのが、いちばんの近道でした。
週次で兆候を拾う。月次で環境そのものを点検する。効いていないものは、期限を決めて捨てる。
そして完了は、感想ではなく機械的なチェックで判定する。
派手さはありません。むしろ地味です。
でも、この地味な整備が積み重なると、おなじ失敗を構造から減らせます。
もし振り返りが続かなくて悩んでいるなら――まずは「いつ・何を見るか」を一つだけ、定例として固定してみてください。
意志より、カレンダーのほうが、ずっと頼りになります。
開発パートナーを探していますか?
AIでプロダクトを最速で形にしませんか?
最短1週間でMVPを開発。アイデアの検証から本番リリースまで、i-Willinkがフルサポートします。まずはお気軽にご相談ください。
無料で相談する