5
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

はじめに

私は現在、大型開発案件でエンジニア兼スクラムマスター(SM)として働いています。
先日、チームの開発者と話していたときにこんな声が上がりました。

PBI管理が面倒すぎるw辞めたいw
AI駆動開発ならアジャイルよりウォーターフォールの方が相性良くない?
SlackでPOと会話しながら、そのまま設計・実装まで進めたい

最初に聞いたときの感想は、
「たしかに、めっちゃ分かるw」
でした。

私自身も生成AIを活用しながら開発しており、実装速度は明らかに上がっています。
だからこそPBIを書くより実装したい。
その気持ちは自然だと思います。

一方でSMとしては、
「いや分かるけど、それPO置いていかれない?厳しいかも」
とも思いました。

でも数日考えていたら、ふとこんなことを思いました。
POも含めて高速に意思決定できる仕組みが作れたら、それって実現できるんじゃないか?

むしろこれは、
「アジャイル不要論」
ではなく、
「AI時代の新しい開発の形」
を考えるきっかけになる話なのではないか?と。

実は私は、この話を聞いて少しワクワクしました。

なぜなら、
「AI時代の新しい開発の形」
を考えることは、

「これからのエンジニアに求められる価値」

を考えることでもある気がしたからです。

私はウォーターフォールも経験している

前職ではオンプレミス環境でインフラエンジニアをしており、プロジェクト全体としては典型的なウォーターフォール型でした。

なので私は、ウォーターフォールを否定したいわけではありません。
要件が安定していて変化が少ないのであれば、とても合理的な進め方だと思っています。

ただ、実際のプロジェクトではそうならないことも多いです。
ビジネス環境は変わるし、ユーザーの要望も変わる。
半年前に正しかった要件が、今も正しいとは限りません。

だから私は、アジャイルは開発手法というより、
「変化を前提にするための考え方」
だと思っています。

AIによって実装コストは確実に下がった

これは多くの開発者が実感しているのではないでしょうか。

私自身も、

  • 調査
  • 設計のたたき台作成
  • コーディング
  • テストコード作成
  • リファクタリング

などで生成AIを活用しています。
以前なら数時間かかっていた作業が、数十分で終わることもあります。
実装速度は確実に上がっています。

だからこそ、

PBI管理より実装したい

という声が出てくるのも自然だと思います。
でもそこで一つ疑問があります。

実装が速くなったのに、なぜ私たちは相変わらず忙しいのでしょうか?

開発のボトルネックはどこへ行ったのか

最近担当しているプロジェクトにて、新機能について社長レビューを行う機会をいただきました。

そこで印象的だったのは、議論になったのが実装方法ではなかったことです。

議論になったのは、
「どこまで作るのか」
でした。

将来的には必要そうな機能もある。
でも今回はそこまで作らない。
なぜなら、まず検証したい価値があるから。

  • その機能は本当に必要なのか?
  • ユーザーに価値を届けられるのか?
  • MVPはどこなのか?

POや関係者と議論していたのは、実現する方法ではなく、その判断でした。

AIがどれだけ進化しても、
「何を作るか」
までは決めてくれません。

むしろ実装が速くなったからこそ、
その前段の意思決定の重要性が増しているように感じています。

PBIはタスク管理ではなく意思決定管理なのかもしれない

そこで改めて考えました。
PBIは何のために存在するのでしょうか。

私は正直、PBIを綺麗に管理すること自体にはあまり価値を感じていません。
管理のための管理になってしまったら本末転倒です。

ただ、PBIには重要な情報が含まれています。

  • なぜ作るのか
  • 誰の課題を解決するのか
  • MVPはどこなのか
  • 今回見送ったものは何か

つまり、
意思決定の履歴です。

コードはGitを見れば分かります。
でも、

「なぜその判断をしたのか」

は残しておかなければ消えてしまいます。
大型案件になればなるほど、この価値は大きくなります。

だから私は、
PBIの本質はタスク管理ではなく、意思決定管理なのではないかと思っています。

AI時代に価値が上がるもの

AIによってコードを書くコストは下がりました。
でも、コードを書くだけでは価値は生まれません。

  • 誰のどんな課題を解決するのか?
  • 本当にその機能は必要なのか?
  • MVPはどこなのか?
  • どうやってビジネス価値につなげるのか?

そうした問いに答える重要性は、むしろ高まっているように感じます。

AIによって「作れるかどうか」は差別化になりにくくなる。
一方で、

「何を作るべきか」
「なぜそれを作るのか」
「どうやってビジネス価値につなげるのか」

を考えられるかどうかは、ますます差が出るようになる。
私は最近、そんな風に感じています。

AI時代に求められるエンジニアとは?

少し極端な言い方をすると、
AIによって「実装できること」そのものの価値は相対的に下がっていくのかもしれません。

もちろん技術力は今後も重要です。
ただ、実装コストが下がるほど、その前後の工程の重要性は上がっていくように感じています。

例えば、

  • 課題を整理する
  • MVPを考える
  • 優先順位を決める
  • 関係者の認識を揃える
  • ビジネス課題を技術課題に翻訳する

といった仕事です。

実は最近、私は自分自身のキャリアについて考える機会が増えています。
ChatGPTを使ってこれまでの経験を棚卸ししたり、
「自分は何が得意なんだろう?」
「これからどんなエンジニアになりたいんだろう?」
と考えたりしています。

その中で面白かったのは、
自分がやりがいを感じた仕事を振り返ると、必ずしも実装だけではなかったことです。

  • 開発チームのスクラム移行を推進したとき
  • ユーザーの課題を整理したとき
  • MVPを考えたとき
  • 設計思想を説明したとき

振り返ると私は、
「どう作るか」
だけでなく、
「何を作るか」「なぜ作るか」
を考えることに面白さを感じているのかもしれません。

そして最近、お客様との1on1で

「育休明けに戻ってきてほしい」

と言っていただく機会がありました。
もちろん嬉しかったですw

でも後から考えると、それは私の実装力を評価していただいたわけではないと思っています。

  • 積極的に発言すること
  • 課題を整理すること
  • 考えを言語化すること
  • チームやプロダクトを良くしようとすること

そういった部分も含めて見ていただいていたのではないかと思います。

実は私は、
会議に参加しているなら発言するのは当たり前だと思っていました。
でも、それは人によっては当たり前ではなかった。

自分では当たり前だと思っていたことが、実は価値だった。

キャリアの棚卸しをしていて、そんな発見もありました。
AI時代のエンジニア像について考えていたはずなのに、
気付けば自分自身がどんな仕事にワクワクするのかを考えていました。

最近の私は、新しいフレームワークを学ぶことよりも、

  • 誰かの課題を整理したり
  • チームが前に進める状態を作ったり
  • 技術とビジネスをつないだりすること

に面白さを感じています。

もしAIによって実装のハードルが下がるのであれば、
私はその先にある価値づくりにもっと向き合ってみたい。
そんなことを考えています。

おわりに

この記事は、

「PBI管理が面倒」

という何気ない一言から始まりました。
でも考えていくうちに、

  • AI時代のアジャイル
  • 意思決定
  • MVP
  • ビジネス価値
  • エンジニアの役割

そして自分自身のキャリアの話にまで繋がっていきました。

正直なところ、私はまだ答えを持っていません。
これから自分がどんなエンジニアになっていくのかも模索中です。

ただ一つ言えるのは、
AI時代に価値が上がるものと、自分が面白いと思う仕事が、
少し重なって見えた気がしていることです。

そして今回の「PBI不要論」は、
そんなことを考える、とても面白いきっかけになりました。

5
1
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
5
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?