masayuki5160's diary

滋賀県大津市に住むソフトウェアエンジニアの日常

この要件、ほんとに実現可能? ━ ソフトウェア工学チャンネル

要件を確認しつつ、"ほんとにそれは実現できるのだろうか?"、と感じた経験は多くの方があると思います。実装難易度や技術的な制約を考慮した要件を定義することが重要になると考えますが、そういったお話についてまとめてみました。

なお、本記事はYoutubeチャンネル投稿内容(参考:この要件、ほんとに実現可能?)をもとに、Geminiに動画の内容をまとめてもらったことを記載しています。

【開発現場あるある】この要件、本当に実現可能?不安を解消しプロジェクトを成功に導くには

ソフトウェア開発の現場で、こんな不安を感じたことはありませんか? 「この機能、本当に実装できるの?」 「この要件で、スケジュール通りに進むのかな?」

今回は、多くのエンジニアやプロダクトマネージャーが直面する「要件の実現可能性」に関する課題と、その解決策について解説します。

現場でよくある「要件への不安」

開発現場では、以下のようなシーンで要件への不安が生じがちです。

  • エンジニア側の不安 [00:44]
    • 要件を確認したものの、技術的な背景から「本当にできるのか?」「時間がかかりそう」と感じる [00:51]。
    • 記載されている通りに機能を作成できるか分からない、といった漠然とした不安がある [01:24]。
  • プロダクトマネージャー側の不安 [01:42]
    • エンジニアのフィードバックがないまま要件を決めてしまい、「この要件で大丈夫か?」と後から不安になる [02:03]。

これらの不安は、「この要件、本当に大丈夫なのか?実現できるのか?」という疑問に集約されます [02:28]。

要件の実現可能性における本質的な問題点 

要件の実現可能性における問題点は、大きく分けて以下の2点に集約されます [02:54]。

  1. 実装難易度が考慮されていない要件 [02:58]
    • 実際にシステムを構築する際の難易度が考慮されていない要件は、後々大きな課題となります [03:02]。
    • 「時間がかかる」「技術的な検証が必要」など、難易度は様々です [03:21]。
  2. 技術的な制約 [04:43]
    • どのようなプロダクトにも技術的な制約は存在します [04:52]。
    • 現状のアーキテクチャでは実現が難しい場合や、アーキテクチャ変更で可能になるとしても大幅なスケジュール延長が必要になる場合などがあります [05:01]。これはプロジェクト全体の要求に合わないケースも多いでしょう [05:23]。

実現不可能な要件が引き起こす「アンチパターン」

不確実な要件をそのまま進めてしまうと、プロジェクトの後半で深刻な問題を引き起こす可能性があります。

  • 後工程での手戻り [06:14]
    • 開発やテスト、品質保証(QA)の段階になってから、要件や要求との乖離が発覚し、受け入れができないといった事態に陥ることがあります [06:20]。
  • スケジュールの遅延 [06:46]
    • 実装の難易度や技術的な制約により、想定以上の時間が必要になることがあります [06:50]。この時間的な要求がうまくネゴシエーションできていないと、スケジュール遅延に繋がりかねません [07:07]。

このような状況は、プロジェクト全体にとって非常に困難なものとなります [07:12]。

改善策:要件の実現可能性を高めるアプローチ

では、このような課題に対し、どのように改善していけば良いのでしょうか。

  1. 実装難易度・技術的制約を考慮した要件定義 [07:40]

    • 要件定義の段階で、技術的なバックグラウンドを持つ人材(アーキテクトなど)がステークホルダーと密に議論し、実装の難易度や技術的制約を考慮に入れることが不可欠です [07:53]。
    • これにより、要件定義書に実現可能な内容を落とし込むことができます [08:01]。
    • アーキテクトのような役割がうまく機能することで、問題の軽減・解消が期待できますが、その役割は容易ではありません [08:12]。
  2. 要件定義と設計・実装工程の往復による解像度向上

    • 要件定義と設計工程は密接に関わっており、時には設計を始めたり、ごく一部を実装してみたりすることで、初めて見えてくる課題もあります [09:07]。
    • 技術検証を行うことで、当初の想定よりも実装難易度が低かったり、新しい知見が得られたりするケースも少なくありません [09:11]。
    • チャレンジングな要件やプロジェクトにおいては、プロトタイピングや技術検証の時間をスケジュールに組み込み、要件定義と設計・実装の工程を繰り返し行き来することが重要です [09:55]。
    • これにより、不確実な部分の解像度を段階的に上げていくことができ、プロジェクト全体の見積もり精度も向上します [10:20]。

明日から試せるヒント

まとめると、明日から試せるヒントは以下の2点です。

  • 実装難易度や技術的な制約を考慮して、要件をしっかりまとめましょう [10:55]。
    • 理想的には、アーキテクトのような技術的な視点を持つ人材が、関係者と対話しながら要件をまとめていくと良いでしょう [11:04]。
  • チャレンジングな要件やプロジェクトでは、プロトタイピングや技術検証の時間を確保しましょう [11:34]。
    • 要件定義、設計、実装の各工程を柔軟に行き来し、少しずつ不確実性を解消することで、プロジェクト全体の解像度を上げていき、成功に導くことができます [11:39]。

まとめ

要件の実現可能性に関する不安は、多くの開発現場で共通の課題です。しかし、実装難易度や技術的制約を考慮した要件定義と、プロトタイピングや技術検証を交えた反復的な開発プロセスによって、これらの課題を克服し、プロジェクトを成功に導くことが可能です。

おまけ)おすすめ記事のご紹介

ソフトウェア工学を学ぶ際に参考になる書籍をまとめていますのでご興味ある方ぜひご覧ください。

masaytan.com

ソフトウェアエンジニアも体が資本。若い時と同じくらい、とまではなかなか難しいかもしれませんが、体力があれば考え続けることもできます。

というわけで個人的におすすめしている体調管理術についてご紹介している記事を置いておきます。向き不向きはあると思うのでご注意いただきたいですが、これからも楽しくソフトウェアを作ることをしていきたい方にはお勧めです。ご覧いただければ幸いです。

masaytan.com