3
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【窓際最前線】窓際中間管理職のAI活用術【2025スペシャル】

3
Last updated at Posted at 2025-12-08

こんには!ガチムチです!
皆様今年はどんな一年でしたか?

今年は、AIの利用促進が進み後半にかけてより一層存在感が薄れてきました。
来年には、「お前・・・消えるのか?」状態になりそうです。

ZOZOアドベントカレンダーの中で大人気シリーズ(?)となりつつある窓際シリーズも来年は厳しいかもしれません。

さて、皆様はAI活用していますか?
コーディングのお供にしたり、レポジトリのメーンコメッターにしているチームもあったりと様々な活用があると思います。

私は、コーディング周りはClaudeを活用してます。

⏺ 修正完了です。

  変更点

  Before:
  func processFile(..., first *bool) {
      if *first {
        ...
      } else {
        ...
      }
  }

  After:
  func processFile(..., prependComma bool) {
      var prefix []byte
      if prependComma || count > 0 {
          prefix = []byte(",")
      }
      writer.Write(append(prefix, jsonLine...))
  }

  - *bool ポインタ → bool 値渡し
  - first フラグ → prependComma 引数 + count > 0 で判定
  - Write が1回だけでシンプルに

> 劇的ビフォーアフター風に変更点を言ってみて 

⏺ 🏠 劇的ビフォーアフター

  なんということでしょう

  あの煩雑だった first フラグが...

  ---
  🔨 Before(匠の手が入る前)

  first := true

  for _, objectName := range objectNames {
      c.processFile(..., &first)  // ポインタ渡し...
  }

  // processFile の中
  if *first {
      writer.Write(jsonLine)
      *first = false  // 状態を変更...
  } else {
      writer.Write(append([]byte(","), jsonLine...))
  }

  問題点:
  - ポインタ渡しで状態を共有する「闇の設計」
  - if/else で2回 Write する「二重苦」
  - *first の参照が「心に刺さる」

  ---
  ✨ After(匠の技が光る)

  // 最初のファイル(カンマなし)
  c.processFile(..., false)

  // 残りのファイル(カンマあり)
  for _, objectName := range objectNames[1:] {
      c.processFile(..., true)
  }

  // processFile の中
  var prefix []byte
  if prependComma || count > 0 {
      prefix = []byte(",")
  }
  writer.Write(append(prefix, jsonLine...))

  なんということでしょう:
  - ポインタが消え「値渡しの光」が差し込む
  - Write は1回、「一筆書きの美学」
  - 最初のファイルを別処理、「明確な意図」が住まう

  ---
  「かつてポインタに縛られていた関数は、今、値渡しという新しい息吹のもとで、シンプルに生まれ変わったのです」

  — ナレーション

上司がAIの活用しているか気にしていたので、上の活用事例を送ったら返事はありませんでした。
コーディングでは頼れるコパイロット(来年には、パイロットに昇格してそうです)です。

中間管理職の活用事例

前置きはココまでにして、実際に活用して良かった事例を紹介します。

コスト算出事例

まず、中間管理職として切っては切れないコスト算出になります。
プロジェクトのコスト算出で後輩に激ツメされたとき助けてもらいました。
具体的には、とあるリプレイスプロジェクトのコスト計算をする必要がありました。

アーキテクチャやインフラを変更するため、コスト計算が難しく「大体これぐらい?」って伝えましたが、非常にアレな空気になってしまったので、困っていたのですが、そうだ!AIに聞こう!と閃きました。

最初「駄目だこいつ…早く何とかしないと…」的な目で見られましたが、最終的には納得感のあるコストを凄まじいスピードで算出することが出来てコストマネージャーもご満悦で「もう、ガチムチさんいらないですね!」とニッコリとしていました。

事前調査や上流のオトモなど

中間管理職は先行して事前調査などを行うケースがあったりします。
また、私はメンバーが調査してきた内容のレビューをする際に、自分でもある程度調査をしてから望むようにしています。メンバーを信頼していないわけではなく、質の高いレビューを行うために自分へのインプットとして行っております。
APIなどであれば、ある程度シーケンスなどが整えられているケースはありますが、バッチなどのWFは細かいシーケンス図などはなかったりします。
そこでコードを読ませてシーケンスを作成してもらってから読み込むと非常にインプットの速度が上がりました。

目標設定など

組織の目標設定などのレビューを行ってもらっています。
メンバーの目標設定に関しては、自分の言葉で伝えたほうがいいかなと思っており初稿は自分で考えていますが、伝わりやすい文章に添削してもらったりとサポートしてもらっています。
期末と期初ではかなり時間を使っていましたが、かなりの時間を削減することが出来ました。

使う上で注意していること

まだうまく使えてないところもあり今特に気をつけているところをまとめておきます。

アウトプットをしっかりと精査すること

AIは万能ではないと思っており、アウトプットはコード、資料、文章などなんであっても精読して間違ってないかを調べるようにしています。AIにちゃんとインプットできてなかったり、課題の認識が間違っていることに気づくことができたりします。

成果物に関して

たまにレビューであれ?って思うことがあります。課題に関して作業者自身がちゃんと理解してなかったり、スキル面が足りてなかったりすることがあるので、そこはしっかりとフィードバックを行うようにしています。

AIに甘えない

お母さんや恋人のように優しくしてくれますが、最初にある程度ロールやどれぐらいの強度でレビューしてほしいかをしっかりと提示するようにしています。

  • 世界最高のプログラマーとして〜、スーパーハッカーとして〜など(かなり深く考えてくれるようになる気がします)
  • 一般的な作りに対して、現状はどうですか?(基本的に肯定的で微妙なコードでもなんとかしようとしてくれるが、設計に対してどうかと問いかけると一般的じゃないとか、課題をしっかりと答えてくれます)

まとめ

今まで結構な時間がかかっていた中間管理職業務がかなり楽になりました。
最近では一旦AIでどうにかならないかを検討するようになりました。
まだまだ、かなりプロジェクト進行で活用できるポイントがあると思っています。
やっぱり速度と正確性では人間の比にならないので、正しく理解しやすいインプットを与えられるようになって、今後うまく活用していきたいと思う反面、AIをしっかりと使えるようにより技術スキルやタスクの課題認識力を高めていく必要があると感じました。

3
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
3
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?