0
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時代、会社開発と個人開発の境界が溶けてきた話

0
Posted at

AI時代、会社開発と個人開発の境界が溶けてきた話

image.png

はじめに

AIで実装が速くなってきた。

コードを書く、テストを書く、調査する、設計のたたき台を作る。
このあたりは、以前よりかなり短時間でできるようになっている。

そうなると、ふと疑問が出てくる。

もう大人数で開発する必要あるのか?
会社で作るより、個人で作った方が速くないか?
アジャイルやPBI管理って、まだ必要なのか?

このあたりについて考えたことをまとめる。


PBIとは何か

PBIは Product Backlog Item の略。

スクラムやアジャイル開発で使う、プロダクトバックログの1項目のこと。

ざっくり言えば「やることリストの1件」だ。

例えば、

  • ログイン機能を作る
  • 検索機能を改善する
  • 管理画面を追加する
  • 不具合を修正する

こういうものがPBIになる。

ただし、本来のPBIは単なるタスクではない。

重要なのは、

  • なぜ作るのか
  • 誰の課題を解決するのか
  • どんな価値があるのか
  • MVPはどこなのか
  • 今回やらないことは何か

といった情報だ。

つまりPBIは、単なる作業管理ではなく、

意思決定の記録

でもある。


ウォーターフォールとは何か

ウォーターフォールは、開発を上から下へ順番に進めるやり方だ。

要件定義
  ↓
設計
  ↓
実装
  ↓
テスト
  ↓
リリース

名前の通り、滝のように一方向へ流れる。

このやり方は、要件が安定しているなら合理的だ。

先に決める。
設計する。
実装する。
テストする。

ただし、途中で変更が入ると重い。

「やっぱりこの機能はいらない」
「別の仕様にしたい」
「ユーザーの反応が想定と違った」

となると、手戻りが大きくなる。

だから変化が多いプロダクト開発では、アジャイルのように小さく作って確認するやり方が使われてきた。


AIによって何が変わったのか

AIによって、実装コストはかなり下がった。

例えば、

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

このあたりはかなり速くなった。

昔なら数時間かかっていた作業が、数十分で終わることもある。

そうなると、開発者としてはこう思う。

PBIをきれいに書くより、AIに作らせた方が速くないか?

これは自然な感覚だと思う。


もはやカスケード状ではなく、噴水状ではないか

image.png

ウォーターフォールは一方向だ。

要件
  ↓
 設計
   ↓
  実装

でもAI時代の開発は、もっと往復が速い。

要件 ←→ 設計 ←→ 実装
 ↑              ↓
 └──────────────┘

要件を少し変える。
設計をすぐ直す。
実装をすぐ作る。
動かしてまた考える。

この往復がかなり高速になる。

そう考えると、もはや「滝」ではない。

どちらかというと、

噴水状

に近い。

下から上に吹き上がり、また落ちて、循環する。

つまり、

アジャイルかウォーターフォールか

という分類自体が、少し古くなってきているのかもしれない。


ただし、消えたのは実装コストであって意思決定コストではない

ここが重要だ。

AIによってコードを書くスピードは上がった。

でも、

  • 何を作るべきか
  • どこまで作るべきか
  • 誰の課題を解決するのか
  • 本当に価値があるのか
  • 今回のMVPはどこか
  • 何をやらないか

は、依然として難しい。

むしろ実装が速くなった分、意思決定の重要性は上がっている。

なぜなら、作れるものが増えるほど、

何を作らないか

を決める必要があるからだ。


AI時代のPBIの価値

PBI管理が面倒なのは分かる。

ただ、PBIの価値は「タスク管理」ではなく、

意思決定の履歴を残すこと

にあると思う。

コードはGitを見れば分かる。

でも、

なぜこの機能を作ったのか
なぜこの仕様にしたのか
なぜ今回はここまでにしたのか
なぜこれは見送ったのか

は、残しておかないと消える。

特に大型案件では、意思決定の履歴が消えると後で困る。

だからPBIは今後、

作業チケット

ではなく、

意思決定ログ

として再定義されていくのかもしれない。


個人で作った方がよくないか問題

AIで開発速度が上がると、こう思う。

これ、会社で大人数で作るより、1人で作った方が速くないか?

これは半分当たっている。

小規模なプロダクトなら、個人や少人数の方が速い。

特に、

  • 業務ツール
  • 小規模SaaS
  • 社内システム
  • 自動化ツール
  • ニッチなWebサービス

このあたりは、個人開発の強さが出やすい。

昔は1人では作れなかったものが、AIによって1人でも作れるようになってきた。

これは大きな変化だ。


それでも会社が残る理由

ただし、会社が不要になるわけではない。

会社の価値は、コードを書くことだけではない。

会社には、

  • 契約主体
  • 責任の所在
  • 継続性
  • 保守体制
  • 法務
  • 営業
  • 請求
  • サポート
  • セキュリティ
  • 担当者が抜けても続く仕組み

がある。

つまり会社は、

開発力の集合体

というより、

信用と責任の受け皿

でもある。

ここが個人との最大の違いだ。


個人と会社の最大の違い

最大の違いは、

継続性と責任の受け皿

だと思う。

個人は、その人が止まると全部止まりやすい。

会社は、誰か1人が抜けても組織として続けられる。

技術力の差ではない。

今は個人でも会社より速く作れることがある。

でもクライアントから見ると、こう見える。

個人 = 能力は高いかもしれないが、依存先が1人
会社 = 能力は普通でも、継続する仕組みがある

だから個人開発者が大きな仕事を取るには、

自分は作れます

だけでは足りない。

自分に何かあってもシステムは止まりません

を示す必要がある。


個人開発者が用意すべきもの

個人で仕事をするなら、これからはコード以外の整備が重要になる。

例えば、

  • Git管理
  • README
  • 設計書
  • 環境構築手順
  • デプロイ手順
  • 障害対応手順
  • バックアップ方針
  • 保守契約
  • 引き継ぎ資料
  • 代替で対応できる協力者
  • ソースコードエスクロー

このあたりだ。

特にクライアントが心配するのは、

あなたに何かあった時、このシステムはどうなるのか?

である。

これは技術の話ではない。

事業継続の話だ。


ソースコードエスクロー

そこで出てくるのが、ソースコードエスクローだ。

ソースコードエスクローとは、

ソースコードや設計資料を第三者に預けておき、一定の条件が発生したらクライアントに開示する仕組み

である。

例えば、

  • 開発者が死亡した
  • 連絡不能になった
  • 廃業した
  • 保守不能になった
  • 契約上の開示条件を満たした

といった場合に、預けていた情報が開示される。

これは個人開発者にとって、かなり重要な信用補強になる。

覚え方は雑に言えば、

エスクロー = 第三者に預ける仕組み

でいい。


会社開発は今後どう変わるか

会社開発は今後、

大人数でコードを書く場所

から、

少人数がAIを使って意思決定し、責任を持つ場所

に変わっていくと思う。

昔の会社開発は、開発工場に近かった。

要件定義する人
設計する人
実装する人
テストする人
管理する人

のように分業していた。

でもAIによって、作業そのものは圧縮される。

すると重要になるのは、

  • 何を作るか
  • なぜ作るか
  • どこまで作るか
  • 誰に価値を届けるか
  • どのリスクを取るか
  • 誰が責任を持つか

になる。

つまり会社開発は、

実装組織

から、

意思決定と責任の組織

へ変わっていくのではないか。


これから価値が上がるエンジニア

AI時代に価値が上がるのは、単にコードを書ける人ではない。

もちろん技術力は必要だ。

ただ、それだけでは足りない。

これから強いのは、

  • 課題を整理できる
  • ユーザーの困りごとを理解できる
  • MVPを決められる
  • 優先順位を決められる
  • 技術とビジネスをつなげられる
  • AIを使って高速に検証できる
  • 作った後の運用まで考えられる
  • クライアントを安心させられる

こういう人だと思う。

つまり、

作れる人

より、

何を作るべきかを考えて、責任ある形で届けられる人

の価値が上がる。


備考:AIが奪うものと残すもの

AIは実装作業の多くを奪うかもしれない。

でも、全部を奪うわけではない。

残るのは、

  • 判断
  • 責任
  • 信用
  • 文脈理解
  • 合意形成
  • 優先順位
  • 継続性
  • 価値の定義

だと思う。

AIはコードを書ける。

でも、

この会社にとって今これを作るべきか?

は、まだ人間側の問題だ。

AIは選択肢を出せる。
でも、選ぶ責任は人間に残る。


考察:個人開発者のチャンス

個人開発者にとって、今はかなりチャンスだと思う。

なぜなら、AIによって「作れる範囲」が一気に広がったからだ。

昔なら会社でないと作れなかったものを、今は個人でも作れる。

ただし、個人が会社に勝つには条件がある。

それは、

会社っぽい安心感を持つこと

だ。

単に、

自分は実装できます

では弱い。

これからは、

自分は作れます
さらに、保守できます
さらに、自分に何かあっても引き継げます
さらに、情報は整理されています
さらに、責任範囲も明確です

まで言える個人が強い。

つまり目指すべきは、

個人開発者

というより、

1人会社のような個人

なのかもしれない。


これからの未来

これからの開発は、たぶんこうなる。

少人数
  ×
AI
  ×
高速な検証
  ×
明確な意思決定
  ×
継続できる仕組み

大人数であること自体の価値は下がる。

一方で、

責任を持って届けられること

の価値は上がる。

会社はなくならない。

でも会社の役割は変わる。

個人も弱くない。

でも個人のままだと信用面で負ける。

だから今後は、

会社 = 信用と責任の仕組み
個人 = 高速な実行力
AI = 実装と検証の加速装置

という構図になっていくのではないか。


おわりに

AI時代の開発では、

作れるかどうか

の価値は相対的に下がっていく。

代わりに、

何を作るか
なぜ作るか
どう届けるか
どう続けるか

の価値が上がる。

これは会社開発にも個人開発にも言える。

個人で作れる時代になった。
でも、個人で続けられるとは限らない。

会社に属す意味は薄くなる部分もある。
でも、会社が持っていた信用や継続性はまだ必要だ。

だからこれから強いのは、

1人で作れるうえに、会社並みに安心させられる人

だと思う。

AI時代の開発者に求められるのは、単なる実装力ではない。

実装力に加えて、

意思決定力
信用設計
継続性の設計

まで含めた力なのだと思う。

0
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
0
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?