「今こそ学び、新たな文明を築くべき時です」PMとITILを学ぼう!#pmil0424
![](https://tgfile.tg-static.com/static/web/img/placeholder.gif)
機能要求:営業情報をシステム上で整理して見たい、などの要求 非機能要求:システムダウン時にどう復旧、レスポンスは●秒がいい、といった、業務と直接紐づかないもの。 #pmil #pmil0424
2011-04-24 18:22:19![](https://tgfile.tg-static.com/static/web/img/placeholder.gif)
非機能要求についてユーザに問いかけるのは難しく、システム要件にはなりえない。やりたいことがこれだから、という発注をするが、レスポンスについては「速ければ速い方がいい」になる #pmil #pmil0424
2011-04-24 18:23:15![](https://tgfile.tg-static.com/static/web/img/placeholder.gif)
ユーザ・ベンダー間で握りにくい要素でもある。実際にリリース後に「これじゃ困るわ」と出てきやすい要件 #pmil #pmil0424
2011-04-24 18:23:54![](https://tgfile.tg-static.com/static/web/img/placeholder.gif)
ピークトラフィックを越えられる設計。実況系コンテンツだと、バルスの時とかあけおめのときとかに耐えられなくてはならない件 #pmil #pmil0424
2011-04-24 18:26:59![](https://tgfile.tg-static.com/static/web/img/placeholder.gif)
空調やら騒音、CO2についても、実は非機能要件。この辺は想像できないな。。。 #pmil #pmil0424
2011-04-24 18:29:13![](https://tgfile.tg-static.com/static/web/img/placeholder.gif)
非機能要件について精通してる人って、会社だとどういう部署の人になるんじゃろ。使い勝手、ほしい機能についてはユーザ部署でも分かるけど、復旧時間等は経営陣やその権限のある人が決めるほかなさそう。 #pmil #pmil0424
2011-04-24 18:32:55![](https://tgfile.tg-static.com/static/web/img/placeholder.gif)
他の顧客とやり取りするときの約款に関わる話題が非機能要件にはある感じ #pmil #pmil0424
2011-04-24 18:33:20![](https://tgfile.tg-static.com/static/web/img/placeholder.gif)
非機能要件を組むためには、ユーザの働き方の定義が必要。また、運用担当者が必ずレビューに参加する。これを参加しないと定義はできないし、成功しない。 #pmil #pmil0424
2011-04-24 18:36:33![](https://tgfile.tg-static.com/static/web/img/placeholder.gif)
インフラ資源と業務要件の合意形成時、状況証拠を逐次残しておく。 #pmil #pmil0424
2011-04-24 18:38:21![](https://tgfile.tg-static.com/static/web/img/placeholder.gif)
システムの運用面で秀でている人が、実務面から出てくる課題・運用要件´を反映するようにする。つくり逃げになってしまうコンサル、設計者だけでは危険。 #pmil #pmil0424
2011-04-24 18:39:06![](https://tgfile.tg-static.com/static/web/img/placeholder.gif)
新規のシステムを使って誰がどのくらい働くのかは読めないものの、それでも業務読みをベースにドキュメントに落とし込み、具体化する。どうせわかんない、で設計してしまって落ちた時の責任問題は設計開発者に来るため、事前に確からしい予測で顧客と握る。 #pmil #pmil0424
2011-04-24 18:44:08![](https://tgfile.tg-static.com/static/web/img/placeholder.gif)
変更管理委員会の一覧化をしておき、どこで何の意思決定をするかを決める。一つの事業や媒体立ち上げするときに会議体一覧作るのはよく見かけた。そのボードは何のためにあり、どの頻度で行い、誰が責任とって議論を上に持っていくのか #pmil #pmil0424
2011-04-24 18:47:38![](https://tgfile.tg-static.com/static/web/img/placeholder.gif)
開発プロセスにおいて、最初の最初でインフラ影響の議論をする。要件があまり固まっていないうちにでも、CPU数含め決める。ITサービスマネージャーに立ち会ってもらう。後で拡張しなければならないことが分かった場合、時間がかかりすぎてボトルネック化する #pmil #pmil0424
2011-04-24 18:52:28![](https://tgfile.tg-static.com/static/web/img/placeholder.gif)
予測できない、作らない、にしても、それはなんでそうなっていて、誰でもそれは一意にしか取れない表現になっているドキュメントにしておくかが重要。文書が独り歩きしても運用がぶれないように。 #pmil #pmil0424
2011-04-24 18:56:00![](https://tgfile.tg-static.com/static/web/img/placeholder.gif)
大規模で人が多くかかわっている案件ほど、妥協せず残しておくのが重要ということ。 #pmil #pmil0424
2011-04-24 18:56:46![](https://tgfile.tg-static.com/static/web/img/placeholder.gif)
一方、ドキュメント化を最小限で前に進んでいく事業、というのもある。運用者が多いものなのか、最低限の当事者だけで回せるものなのかにもよるかな? #pmil #pmil0424
2011-04-24 18:59:47