なぜ非機能要求をシステム開発の上流工程で検討しなければいけないのか?/そもそも非機能要求とは何か?【ITプロジェクトのための プロマネの右腕】
Summary
TLDRこんにちは、吉田です。本番組では、特にITシステムの開発をマネジメントする新任の方々に向けて、実践的なプロジェクトマネジメントを学んでいただける内容を提供します。今回は久しぶりに要求定義、特に非機能要求に焦点を当て、その重要性や、後から発覚する問題を避けるための対策について説明しました。非機能要求はパフォーマンスやセキュリティといったシステムの品質面を扱います。次回は、非機能要求グレードについて詳しく解説しますので、ぜひチャンネル登録をお願いします。
Takeaways
- 💻 ITシステムの開発をマネジメントする立場の人向けの番組。
- 🔍 要求定義と要件定義の重要性に関する話に戻ることを説明。
- 🛠 非機能要求とは、機能をどのように、どのレベルで実現するかを定めるもの。
- 📊 非機能要求にはパフォーマンスやサービスレベルなどの品質が含まれる。
- 📖 社長が望んだ機能を持つシステムが作られたが、パフォーマンスが悪く使えなかった例を紹介。
- ⌛ 別のプロジェクトでも、処理に時間がかかりすぎてシステムがタイムアウトした問題を共有。
- 🔄 非機能要求が後で出されるとプロジェクトの進行が困難になる。
- 📉 システム方式を変更しないといけないような要求が終盤に出ることが問題となる。
- 📋 情報処理推進機構(IPA)が非機能要求グレードというツールを提供している。
- ⏭ 非機能要求グレードの説明は次回に続く。
Q & A
1. この番組は誰を対象にしていますか?
-この番組は新しく企画担当や現場のリーダーになった方、特にITシステムの開発をマネジメントする立場になった方を対象にしています。
2. 非機能要求とは何ですか?
-非機能要求とは、システムがどのように動作するか、またはどのレベルで動作するかを定義する要求のことです。具体的には、パフォーマンスやサービスレベルなど、機能以外の部分を指します。
3. 機能要求と非機能要求の違いは何ですか?
-機能要求は「これができるようにしてほしい」という要求であり、非機能要求は「どのようにやるか」や「どのレベルでやるか」という要求です。
4. 非機能要求が重要な理由は何ですか?
-非機能要求はシステムの性能やユーザー体験に直結するため重要です。例えば、どんなに機能が優れていても、パフォーマンスが悪ければシステムは使い物になりません。
5. 非機能要求の例としてどのようなものがありますか?
-非機能要求の例としては、パフォーマンス、サービス稼働時間、セキュリティ、スケーラビリティなどが挙げられます。
6. 非機能要求が欠如していた場合、どのような問題が発生する可能性がありますか?
-非機能要求が欠如していると、システムのパフォーマンスが低下したり、セキュリティリスクが高まったり、ユーザーに不便を感じさせるシステムが出来上がる可能性があります。
7. 非機能要求を後から追加することのリスクは何ですか?
-プロジェクトの後半で非機能要求を追加すると、システム方式を変更しなければならない場合があり、納期が遅れるか、他の要件を諦めざるを得ないリスクが生じます。
8. IT業界で非機能要求に対する意識はどのように変わりましたか?
-昔はパフォーマンスが主な非機能要求でしたが、年々セキュリティやサービス稼働時間など、システムの機能以外の部分にも意識が向けられるようになりました。
9. 非機能要求の重要性を認識するために、どのようなツールや方法がありますか?
-情報処理推進機構(IPA)は、非機能要求の項目リストや非機能要求グレードというツールを提供しており、迅速に非機能要求を決定するためのアプローチを推奨しています。
10. 非機能要求を出すのが難しいケースはどのような場合ですか?
-新規事業でまだ動くシステムが存在しない場合、非機能要求を具体的にイメージするのが難しく、要求を出すことが困難です。
Outlines
💻 ITシステムの非機能要求について
この段落では、ITシステム開発において重要な非機能要求について説明しています。非機能要求は、システムがどのように機能するべきか、またその品質をどのように保証するかという観点から、機能要求と対比されています。著者は、昔のIT業界では「非機能」という言葉は使われず、パフォーマンスやサービスレベルなどで表現されていたことを述べています。エピソードを交えながら、システムが機能してもパフォーマンスが悪ければ意味がないことを強調し、非機能要求の重要性を解説しています。
🐢 パフォーマンス問題と設計の失敗
この段落では、著者が関わったプロジェクトにおけるパフォーマンス問題の例が紹介されています。開発チームがオンライン処理にこだわった結果、システムのパフォーマンスが非常に悪化し、処理が50分経っても終わらない状況が発生しました。バッチ処理が適切だったと後から気づいたが、リーダーがオンライン処理を変更しなかったことが原因で、問題が解決されなかったことが述べられています。このエピソードを通じて、非機能要求やパフォーマンスを適切に考慮しなければ、システム全体が失敗する可能性があることが示されています。
📈 非機能要求グレードの重要性
この段落では、非機能要求を適切に管理するためのツールである「非機能要求グレード」について触れられています。著者は、プロジェクトの終盤で非機能要求が後から出されると、納期を延ばすか、何かを諦めるしかない状況になることを説明しています。これを防ぐために、IPA(情報処理推進機構)が提供する非機能要求グレードのツールが有効であることが紹介されていますが、詳細は次回に持ち越されました。
Mindmap
Keywords
💡非機能要求
💡機能要求
💡パフォーマンス
💡要求定義
💡ステークホルダー要求
💡ソリューション要求
💡バッチ処理
💡サービスレベル
💡非機能要求グレード
💡オンライン処理
Highlights
ITシステムの開発をマネジメントする立場の方のために、実践的なプロジェクトマネジメントを学べる番組。
要求定義・要件定義の話から開発プロセスの話へシフトしていたが、今回は再び要求定義に戻る。
非機能要求の重要性について、新しいITシステムの開発マネージャー向けに解説。
非機能要求は、機能が「どう」動作するか、「どのレベル」で行うべきかに関する要求。
かつては非機能要求を「パフォーマンス」や「サービスレベル」と呼んでいたが、現在ではより広範な概念に。
システム開発初期のエピソード: 社長のスケジュール管理システムが性能不足で使い物にならなかった。
オンライン処理で実装されたシステムが、処理が50分もかかりタイムアウトしてしまう問題が発生。
画面設計書に基づいた開発では、重たい処理をオンラインで処理するのが難しかったという教訓。
システムのパフォーマンス問題が非機能要求における大きな課題だった時代背景。
セキュリティやシステムの利用時間拡大など、非機能要求の重要性が年々増している。
既存システムがない新規事業では、非機能要求を明確にすることが難しい。
非機能要求がプロジェクト終盤に出てくることが開発者にとって大きな課題。
非機能要求の遅れた発見が、納期の延長や仕様の妥協を強いる結果に繋がる。
情報処理推進機構(IPA)が提供する「非機能要求グレード」というツールが、非機能要求の決定をサポート。
非機能要求グレードの詳細は次回解説予定。
Transcripts
こんにちはプロジェクトオーガナイザーの
吉田です
この番組は新しく企画担当になった方や
新しく現場のリーダーになった方
その中でも特に it システムの開発を
マネジメント数立場になった方をために
実践的なプロジェクトマネジメントをご
一緒常に学んでいただける内容を置く
いたしますよろしければチャンネル登録を
お願いします
ずっと要求定義要件定義の話をしていまし
たが最近は開発プロセスの話すが続きまし
たので久しぶりに要求定義要件定義の話に
戻りたいと思います
今日扱いたいのは匹の要求です
システム開発に携わったことがないと非
機能といってもピンと来ないと思いますな
ので新しく it システムの開発を
マネジメントする立場になった方のために
非機能要求とは何かということについてご
一緒に学んでいきたいと思います是非最後
までご覧ください
まずはおさらいです
これは以前行った
はボックガイド第3パンに基づく要求の
階層構造の頭です
思い出していただきたいんですが
要求というのは経営レベル
組織レベルのビジネス要求から初めて業務
レベル役割レベルのステークホルダー要求
作業レベルシステムレベルの
ソリューション要求という具合に順番に
落とし込むでいきます
そしてソリューション要求は
はボックガイドではステークホルダー要求
を満たすソリューションの能力と品質と
定義されていまして
能力というのは機能要求に該当し品質と
いうのは匹の要求に該当します
つまり機能要求っていうのはあれができる
ようにしてほしいとかこれができるように
してほしいということで
非機能要求というのはそれをどのように
あるいはどのレベルでやれるようにして
ほしい
まあざっくりいうとそういうことです
私が it 業界に入った頃は
少なくとも私がいた会社では非機能という
言い方はしていなくてパフォーマンスとか
サービスレベルとかそういった言い方をし
ていた気がするんですが
非機能というのはそういう機能描いの一切
合切を含めた言葉として理解して
いただければよろしいかと思います
私が it 業界に入ったばかりのころに
いい
実は私を it 業界に引っ張ってきて
くれた方がおられるんですがその方から
こんなエピソードを聞かされたことがあり
ますその方と直接の関わりあるかどうかは
わからないんですがある会社の社長が社員
に社長自身のスケジュールとか
アドレス帳を管理するシステムを作って
くれと頼んだそうです
今ではスマートフォンがその機能を担って
いますが当時はまだ手帳で管理するのが
主流でした
そこで社員はわかりました
そう言ってシステムを構築したそうなん
ですが
出来上がったものは
確かに社長が望む機能が実装されていた
ものの動作がものすごくを測定
全く使い物にならなかったそうです
それに対して社長が最初にこれこれの機能
ができるかと質問したときに
社員の人ができますというからお願いした
んだと
こういう風になるんだったら最初からお
願いしなかったよというようなことを言っ
たとか言わなかったとか
私も当時人に披露する前提で聞いてい
なかったのでうろ覚えで申し訳ないんです
がまあ趣旨としてはそういうことです
昔は今ほどコンピューターも早くありませ
んでしたのでそういう話は昔はあるある
だったと思います
例えば似たような話なんですがこれは
さっきの話の数年後の話で
ある開発プロジェクトにいました
その開発プロジェクトではベテランの
エンジニアが作成した画面設計書に基づい
て
内部設計とコーディングをやっていく仕事
だったんですね
10名以上はいたと思うんですけれども
そこそこの規模のチームでやっていまして
ただ私は完成を待たずにそこの現場を離れ
たんですねで私はそこの現場で知り合った
エンジンやと仲が良かったので
私がそこを離れてしばらくしてからその
うちの1人と飲み会か何かで話す機会が
ありました
そうしたら
その時開発していたシステムに問題があっ
たらしくて
一連の業務の一番最後に実施する一番応対
処理が
し50分経っても終わらなくて画面が
タイムアウトしてしまうんだということ
でした
もちろんそのパフォーマンスを改善する
ためにいろんなチューニングはしたと思う
んですけれども
でもし50分停なかなかですよね
確かにすごく重たい処理を詰め込んでいた
ので
うすうす大丈夫かなぁとは思っていました
ただ私が受け取った input 資料が
画面設計ショーでしたから私もその画面の
処理として内部設計を進めたんですね
でもやはり実際には画面つまりオンライン
の処理でやるのは厳しかったようです
そのエンジンやも言っていたんですけども
確かにこれはバッチ処理6日かな予選一連
のオンライン処理が終わって最後にバッチ
処理程度感と重たい処理をやるっていう
やり方が適切だったんじゃないかなと今で
は思います
でここからがすごいんですがそれを話して
くれたエンジニアが
ここはバッチ処理にした方がいいんじゃ
ないんですかってリーダーに提案したそう
なんです
ところがそのリーダーはもうオンライン
処理で実装を進めてしまっているから
今更変更できない東突っぱねられたそうな
んですね
そうは言ってもなかなかオンライン処理
だけでどうにかするっていうのは厳しかっ
たと思うんですよ
最終的にどう着地したのか続報は聞いてい
ないんですがさすがにそのままの日したと
は思えませんよね
というように昔は匹のを取りいえばその
多くがパフォーマンス問題でした
それが年々セキュリティの事故が発生し
たりサービス向上の一環でシステムの利用
時間が拡大されたり本来システムが備える
機能以外の部分もちゃんと考えて手当て
することが大切だよねという意識が高まっ
てきました
それは良いことなんですが
では機能要求と同じように匹の要求を
あまねく出すことができますかという問題
が出てきます
別の言い方をすると非機能要求を出して
くださいって言われて何項目出せますかと
いうことですね
既存の事業ですでにシステムが稼働してい
てそのシステムを刷新するんだというよう
な場合は既存のシステムがありますから
だいたいどのような要求を出せばよいよか
というのはあたりが付きますけれども
新規事業の場合は動くシステムがまだ存在
しいないのでなかなかイメージするのが
難しいという側面があります
出せと言われてもイメージできなければ
出しようがないわけです
そうすると匹の要求が出ないまま
まぁ出たとしてもパフォーマンスとか
システム利用時間とかそれ以外の部分は
全然出てこないまま時間だけが過ぎて行き
ますそういうプロジェクトに限ってシュ
ステムがある程度出来上がって
総合テストとか受け入れテストで実際に
触ってからいろいろと匹の要求に気づくん
ですよ
これ
開発者の立場にたストですね
何が一番困るかというとそういった非機能
要求を後かな言われることなんですよね
しかもシステム方式を変更しなければいけ
ないような
クリティカルな要求がプロジェクトの終盤
に出てきたところでそれを取り込む時間が
ありませんのでどうしてもということで
あれば何かを諦めるか
納期を伸ばすしかありません
でこういうことが起こらないようにする
ために
ita
情報処理推進機構がですね
非機能要求の項目のリストと非機能要求を
迅速に決定するためのアプローチとして非
機能要求グレードというツール法を公開し
ていますで非機能要求グレードについて
説明しようと思ったんですが時間が
なくなってしまうあったのでこの続きは
また次回にやりたいと思います本日は以上
です
最後まで聴いてくださってありがとう
ございますチャンネル登録がまだの方は
ぜひ登録していただいて次回の配信をお
待ちください
5.0 / 5 (0 votes)