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?

【新人社内SEの葛藤】アジャイルで作り、あえて「ウォーターフォール」で書き直す理由

Posted at

はじめに

私は製造業の社内SEとして働いています。
入社1年目、エンジニアとしての学習期間を含めても2〜3年目。現在は理解のある上司のもと、比較的自由な裁量を与えていただき、1〜2名体制での小規模開発を行っています。

少人数かつスピード感が求められる環境なので、開発手法としての**「アジャイル」**は必須です。実際に私も、アジャイル的な動きでシステムをリリースまで持っていくことができています。

しかし最近、ある「強烈な原体験」と「AI活用の気づき」から、**「アジャイルで作ったシステムを、あえてウォーターフォール型の設計書として書き直す」**という、一見すると非効率な工程を自分に課すことにしました。

これは、**「属人化の解消」「AI時代の設計力」**の間で揺れ動く、一人の新人社内SEの思考ログです。

直面した「属人化」という壁

なぜ、スピード重視のアジャイル環境で、わざわざ重厚なドキュメントを書こうと思ったのか。
最大の理由は、現在進行形で直面している引き継ぎ業務の苦しさにあります。

社内には、定年を迎えられるベテランの方が数十年かけて守ってきたシステムがあります。
ドキュメントは残っています。しかし、長年の継ぎ足しと属人化によって、「どれが最新で、どれが正しいのか分からない」という、いわゆるスパゲティ状態になっていました。

「動いているシステムはあるが、正解を知っているのはその人の頭の中だけ」

この状況を引き継ぐ中で、私は痛感しました。
「自分が今アジャイルで作っているこのシステムも、ドキュメントを整備しなければ、数十年後に同じ地獄を後輩に見せることになるのではないか?」

アジャイルは開発には最適ですが、気を抜くと属人化が加速するという側面も持っています。
将来、私のポジションに入ってくれる人が(すぐには来ないとしても)いつか現れたとき、スムーズに渡せる状態にしておくことが、社内SEとしての責務だと感じるようになりました。

AIにとっての「ノイズ」と、人間にとっての「道標」

一方で、開発の相棒として欠かせない「AI(ChatGPTなど)」の視点で見ると、また違った景色が見えてきます。

開発中、AIにコードを書かせたり設計の壁打ちをしたりする中で、一つの仮説を持ちました。
「人間にとって親切な、全部入りのウォーターフォール設計書は、AIにとってはコンテキスト過多(ノイズ)ではないか?」

業務要件、機能要件、細かい画面遷移……これらを冗長に書き連ねたドキュメントをAIに渡すと、かえって混乱を招くことがありました。
AIに渡すのであれば、

  1. データベース設計(ER図・正規化):ここは絶対に手を抜かず、地獄を見ないように固める
  2. 要件定義(コアロジック):仕様の矛盾がないよう論理的に整理する

この2点が研ぎ澄まされていれば、AIは非常に高精度なコードを吐き出してくれます。
つまり、**AI時代に必要なのは「AIに正しくコンテキストを渡せる、洗練された設計情報」**であり、昔ながらの重厚なドキュメントではないのかもしれません。

それでも私が「あとからウォーターフォール」をやる理由

  • AIのためなら、ドキュメントは簡潔でいい。
  • しかし、属人化を防ぐなら、人間が理解できる詳細なドキュメントが必要。

この矛盾の中で、上司と相談し、昨日たどり着いた結論がこれです。

「開発自体はアジャイルで進める。しかし、完成後にあえてウォーターフォール形式で設計書を書き直す」

一見すると二度手間です。しかし、今の私のフェーズではこれが最適解だと信じています。理由は2つあります。

1. 「未来の誰か」のための属人化解消

前述した通り、社内SEはSIerと違い、「納品して終わり」ではありません。作ったシステムと一生付き合っていく可能性があります。
開発中は試行錯誤(アジャイル)で進んでも、最終的な成果物として「誰でも読めば分かる状態」に整地しておくこと。これが、スパゲティコードと属人化への唯一の対抗策だと考えました。

2. 将来に向けた「設計筋」のトレーニング

私は今、少人数で開発していますが、将来的には大規模なプロジェクトやチーム開発に参加したい、あるいはPMやPLとして活躍したいという目標があります。

アジャイルで「なんとなく動くもの」を作って終わりにするのではなく、「なぜその設計にしたのか」「どういう論理構造なのか」を、後からでも論理的に再構築してドキュメントに落とし込む作業。
これは、将来AIに的確な指示を出すための言語化能力を磨くことにも繋がりますし、大規模開発で手戻りを防ぐための「設計基礎力」を鍛える、またとない練習になります。

おわりに:先輩エンジニアの方々へ

今の私の結論は、
「開発スピードはアジャイルで担保しつつ、品質と継続性はウォーターフォールの型を借りて担保する」
というハイブリッドな(泥臭い)運用です。

「AI時代に逆行している」「効率が悪い」と思われるかもしれません。
ですが、ベテランの方の引き継ぎで感じた「ドキュメントの重要性」と、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?