こんにちは、CARTA fluct ソフトウェアエンジニアをしている25卒のくま（@K_K_2306）です。この記事は CARTA アドベントカレンダー2025の19日目の記事になります。
私はfluctで内定者インターンをしており、学びをまとめた記事を執筆しました。今回の記事はその記事からの差分(Version up)をまとめてみる試みです！
この記事では、そのギャップを埋めるためにこの半年間実践してきた工夫を紹介します！
🚀 新卒エンジニア v2.0 リリースノート
本記事では、以下の3つの機能アップデートについて解説します！
- Update 1. 非同期コミュニケーションの実装
- (Before) 困ったら口頭ですぐ質問する
- (After) GitHub Issueに思考プロセスを書き殴り、自己解決と非同期相談を可能にした
- Update 2. 情報収集戦略（判断ロジック）の強化
- (Before) とにかく手を動かして「決断」をする
- (After) 20分ルールで「情報不足」を検知し、リスクの低い「判断」を積み重ねる
- Update 3. 自己成長サイクルの自動化
- (Before) 根性で日報を書き、書きっぱなしにする
- (After) 日報を「朝の起動スイッチ」にし、AIによる客観的デバッグを取り入れた
Update 1. 「口頭での質問」から「思考のログ化」へ
インターン時代の「すぐ質問」は、入社後、逆にレビュワーのコンテキストスイッチコストを高めてしまっているという課題に直面しました 。このギャップを埋めるため、私は「思考をローカルに残す」のをやめ、タスクに関する試行錯誤をすべてGitHub Issueに書き殴るスタイルに切り替えました 。このログ化により、質問の前に自己解決が劇的に増え、チームのコンテキストスイッチを最小限に抑えることができています 。
思考を書き殴ってからリファクタリングする
Phase 1. 書き殴る（発散）
どんな些細な悩みもIssueコメントとして残し、「ローカルに残す」という選択肢を自分から消す
思考が発散したり間違っていても、GitHubの機能で隠せるため、ノイズを気にしなくていい
Phase 2. 中間で整理する（収束）
ログを残すだけでは思考が煩雑になるので、作業の区切りで「Issueの整理時間」を設ける
「今何をしていて、ゴールは何か」「試行錯誤の結果、何が正解だったのか」を要約した「まとめコメント」を追記
この動きで、ローカルではなくIssue上で思考を展開することで、書き出している最中に論理の飛躍に気づきやすくなり、質問する前に自己解決（自己完結）できるケースが劇的に増えたように感じます。
また、整理されたIssueのリンクを貼るだけで相談が完了するので、チームのコンテキストスイッチを最小限に抑えることができてる気がしています。思考プロセス自体が、チームメンバーが後から確認できるようになり一石二鳥🐓
Update 2. 「決断」ではなく「判断」を積み重ねる
新卒の私は「行動あるのみ！」という言葉を真に受け、闇雲に手を動かしては時間を溶かしてました。そんな私の考えを改めるきっかけをくれたのは、CARTA技術コーチである@soudai1025さんとの1on1から教わった「判断と決断」の考え方です。
• 判断：情報を集めれば論理的に答えが出るもの。やり直しがきく（可逆性が高い）
• 決断：情報不足の中で選ぶ賭け。やり直しにコストがかかる（可逆性が低い）
成功と失敗は「分かれ道」ではない
新卒の私がすべきは、リスクの高い「決断」ではなく、徹底的に情報を集めて「判断」できる材料を揃えること。「成功と失敗は分かれ道ではなく、一本道である」という思考は、小さな失敗を恐れずに繰り返すことの重要性を今一度考えさせてくれました。
ref: https://x.com/Sudo_Sho/status/1422178731032940548
20分ルール
最近の自分の行動から、日々のタスクで手が止まる原因を分析してみました。するとコードが書けない以前に、「仕様やドメイン知識（ビジネスルール）がわかっていないから手が止まっている」ケースが大半でした。そこで導入したのが「20分ルール」。
「20分考えて手が動かないなら、それは悩んでいるのではなく『情報不足』の状態」
ない知識を頭から捻り出すのは「決断」に近い危険な行為だと思ってます。20分で手を止めて、現状を整理してすぐに助けを呼ぶ。これは「諦め」ではなく、ドメイン知識不足を補うためのある種の戦略だと自分は考えてます。
Update 3. 「三日坊主」をハックする — ログから始まる成長サイクル
私は、自他ともに認める「やる気だけはある三日坊主」
しかし、この半年間、日報だけは継続できています。 これは根性で続けたのではなく下記を意識してみたからです。
Hack 1. 日報は「夜の反省文」ではなく「朝の起動スクリプト」
多くの人は日報を一日の終わりに書きますが、私はこれをやめて「翌日の朝、仕事の開始スイッチとして書く」ように変えました。 前日の自分からバトンを受け取り、脳の「作業興奮」を利用してスムーズに業務に入ることができるようになった気がします。こちらも、技術コーチである@soudai1025さんから教わった「フィードバックループのメリット」です。
Hack 2. NotebookLMによる「客観的デバッグ」
書き溜めた約半年分の日報ログをすべてNotebookLMに読み込ませ、「くまデータベース」を構築しました。 ここに定期的に「今の働き方に慢心はないか？」「同じ失敗を繰り返していないか？」と問いかけてます。
一番大きなメリットは、AIは私情を挟まず、冷徹かつ的確なフィードバックを返してくれること。
🤖AI：「タスク処理速度は上がってますが、深い技術理解（コードリーディング）の時間をもう少し確保すると、さらに盤石になります。 目の前の火消しだけでなく、基礎固めが必要です。」
このように、AIを「忖度のない第三者レビュワー」として雇うことで、自分自身のバイアスを排除できた気がします。
結論：成長を楽しめる「仕組み」を作ろう
インターン時代に私が書いた「チーム開発のコツ」は、今も私の大切な指針です。 この半年間で変わったのは、その指針を実現するための「解像度」と「手段」だと思ってます。
口頭だけでなく、テキストで資産を残す
悩むのではなく、戦略的に判断する
AIやログを活用して、自分自身を客観視する
これらはすべて、私のような「三日坊主」でさえ、エンジニアとしての成長を「根性」ではなく「仕組み」で楽しめるようにするための工夫です。
ログさえあれば、未来の皆さんやAIが、それを貴重なデータセットとして分析し、成長へのルートを示してくれるはずと信じてます！
ちなみに...
実はこの記事の構成案などは私の日報データを読み込ませたNotebookLMと壁打ちをしながら作成しました。 日々の積み重ねが、こうして記事という形のアウトプットに繋がっています！
参考資料
https://techblog.cartaholdings.co.jp/entry/fluct-console-team-internship-tips-kuma
https://soudai.hatenablog.com/entry/2022/01/04/151923
https://speakerdeck.com/soudai/grow-one-day-each-day?slide=48
