投稿日: 投稿者: sho

[IPA] デスマらないために「超上流から攻める IT 化の原理原則17ヶ条」が思った以上に使える件 [要件定義]

このエントリーをはてなブックマークに追加
Pocket

「超上流」という言葉自体はとても気に入らないけれども、IPA 独立行政法人 情報処理推進機構 が作って公開している「超上流から攻める IT 化の原理原則17ヶ条」が、当たり前のことを当たり前に並べてあってとても役に立つ。

超上流から攻めるIT化の原理原則 17ヶ条

4274500764

経営者が参画する要求品質の確保―超上流から攻めるIT化の勘どころ (SEC BOOKS)
オーム社
2006-06
情報処理推進機構ソフトウェアエンジニアリングセンター
￥ 1,851 （2015/01/19 06:42時の価格）

目次

原理原則 17箇条

  1. ユーザとベンダの想いは相反する
  2. 取り決めは合意と承認によって成り立つ
  3. プロジェクトの成否を左右する要件確定の先送りは厳禁である
  4. ステークホルダ間の合意を得ないまま、次工程に入らない
  5. 多段階の見積りは双方のリスクを低減する
  6. システム化実現の費用はソフトウェア開発だけではない
  7. ライフサイクルコストを重視する
  8. システム化方針・狙いの周知徹底が成功の鍵となる
  9. 要件定義は発注者の責任である
  10. 要件定義書はバイブルであり、事あらばここへ立ち返るもの
  11. 優れた要件定義書とはシステム開発を精緻にあらわしたもの
  12. 表現されない要件はシステムとして実現されない
  13. 数値化されない要件は人によって基準が異なる
  14. 「今と同じ」という要件定義はありえない
  15. 要件定義は「使える」業務システムを定義すること
  16. 機能要求は膨張する。コスト、納期が抑制する
  17. 要件定義は説明責任を伴う

個人的に読み解いてみる

具体的な使い方、考え方、行動規範が全て記載されているので、個人的な想いを書き連ねておきます。裏原理原則17箇条の行動規範とでも呼んであげてください

1. ユーザとベンダの想いは相反する

相手の立場になって考えれば済むと言うことになるわけだけれども、もうコレばっかりは相いれることはないと思う。
どちらか一方の言いなりになるか、両者が納得のいくプロセスを完成しないかぎりどうこうならない。

とは言え、相手の気持ちをくんで考えることは重要で、交渉の役には立つ。交渉の役にしか立たないけど。

2. 取り決めは合意と承認によって成り立つ

合意形成は結構楽にできるもんだけど、そのエビデンスを取ることを忘れたらいけないってヤツ。だけど、喫煙所で合意した内容について、後でステークホルダ全員を CCに入れたメールで、証拠になるようなものを送りつけると「そんなことを言った覚えはない」って言われる。なので、一人だけの合意じゃなくて、権力のあるステークホルダに根回ししてうまいことやらないと破綻する。

また、証拠の理由も残しておかないと、なんでその合意に至ったのか、でまたやり直しになる。

3. プロジェクトの成否を左右する要件確定の先送りは厳禁である

全ての要件が確定しないと、先に進めない方がプロジェクトとして安全です。ただ、今時そのようなやり方はナンセンスかも知れません。先送りにしてもいいようなプロジェクトスタイル、または要求の優先度を決めて進めることができるような、そんなプロセスを作るのが、今後はいいのかも知れません。アジャイル開発は、その回答に近いかも知れません。

4. ステークホルダ間の合意を得ないまま、次工程に入らない

そもそも「ステークホルダ」自体が分かっていないケースが多く、各工程で実権を握る担当者は誰なの、を明確にして進めていかねばなりません。声だけがうるさいだけの人も、全く関係ないのにジャマになるコトは多いです。そういった、本来不要だけど、ネゴっておかないと先に進めなくなる人、それから、普段は黙っていて素通りだけどサービスインの直前になって爆弾を投下してくる担当者、など、「ステークホルダ」として認識していなかった、一ユーザが後になって実権を握ることはよくあります。人間関係のドラマを軽く見ると、後で痛い目に遭います。

5. 多段階の見積りは双方のリスクを低減する

分かっているのに、エンドユーザはこのリスクテイクをしようとしません。

なぜか。

それが縦割り構造のデメリットです。そういうものなので、経験でねじ伏せるしかありません。こればっかりは経験がものをいってきます。がんばれ。

6. システム化実現の費用はソフトウェア開発だけではない

自分の分野にしか興味がない人が多いので、ホントにインフラにお金がかからないと思っていたり、電気代でびっくりしたり、通信代金で白目剥いたり、そもそも、新たに入れた業務を使うための人を雇ったら、目も当てられないようなマイナスになることもあるわけで、「ホントにその IT化は、効果があるの?」とお客さまに問うといいと思います。余計な仕事が減るかも知れません。

7. ライフサイクルコストを重視する

なぜか初期費用しか見ない人が多いです。えげつないことに、高いモノに限って数年経ってから保守料金が発生するような仕組みで泡を吹いたり、ぼーっとクラウドのサーバ上げっぱなしにして、データも青天井にストアしていったら、気持ちの悪いことになったりします。それで、気がついたときにはどうしようもなくなることがほとんどです。
ちゃんと、運用を開始してからの費用や、いつハードやソフトを入れ替えるのか、一生、かれるまで付き合うのか、お金はいつまで払うのか、よくよく計算させてあげてください。

後で、文句を言われてでもお金をほしいのなら、6point よりも小さい字でパワポの提案書に書いておきましょう。相手は老眼で読めないはずです。それでいて、あとで突きつけてあげましょう、このお金を払わないと一切サポートしないよ、と。

まぁ、二度と開発させてくれないと思いますけど。

8. システム化方針・狙いの周知徹底が成功の鍵となる

全員が同じ理念を持つことは重要です。でも行き渡りません。なぜなら、個々人には利害があって、その理念に従うことで、自分の損失を生み出す人がいるからです。これまで、自分が気持ちよくやってきた業務を、他の全員が効率よく、気持ちよく働くために、その人一人を悪くするような、そんなシステム開発も時にはあります。そんな時に限って、その理念に反発する人は権力を持っていたりして難航することはよくあります。

方針･理念を説く人は、必ずトップ、またはそれに準じる人から発行させ、対するテロリストには強い意志を持って立ち向かえる人でなければなりません。結局、そういったコミュニティの強さが重要になってくるわけで、スキルなんて関係ないなとやっと気がつくことになります。

9. 要件定義は発注者の責任である

これを忘れている人が多く、要件定義を実施したベンダにさじを投げてくるエンドユーザが多いです。お前が定義したんだろと。

ぜひ言い返してください。「お前が言い出したんだろ」と。

出禁になります。

10. 要件定義書はバイブルであり、事あらばここへ立ち返るもの

要件書を見ないエンジニアが多いです。いい加減くたばって欲しいものです。要件をバカにしすぎ。はやく居なくなってね。

11. 優れた要件定義書とはシステム開発を精緻にあらわしたもの

こんなもん作れる人はいません。なぜなら、要件をまとめたものを要件定義書だと考えているベンダーとユーザーがほとんどだからです。要件定義書では、システムの概要が自ずと分かる、そんな状態に本来は持っていけていて当然なのですが、RFP を要件定義書だと言い張る人も居る程度には世の中が腐っています。どうぞ、あなたがこれからの IT社会を変革していってください。私はもう疲れました。

12. 表現されない要件はシステムとして実現されない

表現されないというか、作ることが不可能な要件定義書を作る人が多いです。要件定義書は実際には既に設計がはいってきていて、各々の要件は、他の要件を実施できないような、そんな哀しい要件になってはいけないのです。

例えば、予算は 5万円という制約の中で、3LDK 5部屋あるマンションを建てたい、という要件は何も産まないのです。各々の要件は全て、実際に満たすことができるよう、実は設計が成されなければならないのです。お客さまが言ってきた要求全てを、ただまとめただけの要件定義書は、ただの要望一覧であって要件定義ではないです。頭を一切使っていない要件定義は、ただの要望書であることを理解して、正しく定義してください。できること、できないこと、どれかを実現するために、落とさないといけない要求があれば、いずれかを選択して、もう一つを落とすべきなのです。

分かってんの?

13. 数値化されない要件は人によって基準が異なる

日本人は副詞と形容詞が大好きなので [I]既に「大好き」とかいってる 、数字に直す努力をしましょう。「良い感じで障害時には切り替わって欲しい」というときの「良い感じ」を具体的な数値目標として表現して、実現可能なものを定義しましょう。障害時の切替なら、RPO/RTO や、障害が発生した瞬間のトランザクションはどうなるべきなのか、とか。

日本人は修飾語が好きですが、要件定義書には修飾語を一切いれない、強い気持ちで臨みましょう。

尚、この文章は修飾語メインで記載しています。

14. 「今と同じ」という要件定義はありえない

みんなが言うけど、「今と同じじゃねぇか、そりゃダメだろ」とか意味不明なことを言う人が多いので、正しくすべての要件を明確にしましょう。現行機能踏襲であれば、その機能を全て明確にしてもらいましょう。してくれないなら、断りましょう。

15. 要件定義は「使える」業務システムを定義すること

機能を搭載しただけでは使えないものができあがりますので、どれだけ業務に特化した、ホントに役に立つものができるのかを目指しましょう。

日々の事務処理や、特化した業務処理などは、なんで WEB化したんだろうね、と思わずにはいられません。私なら、本当に業務を効率化して実現するならば、CUI のホスト系の画面で、必要最低限の文字を入力させて、レスポンスだけは異常に早いシステムを提供しますけどね。

しってますか? GUI/WEB になって、特化業務の効率は落ちてますよ。分かっていない人たち大杉です。熟練度のことを忘れてます。

16. 機能要求は膨張する。コスト、納期が抑制する

要件定義では「制約」と「要件」とで要件定義を実施します。「制約」は変更できないもので「要件」は要求のうち取捨選択をして、優先度に応じて実現の可否を問うものです。

にも関わらず、その制約の中できないことを要求して困らせるような人はデスマーチの根源なので、ぜひ、ご退場いただくように暗躍してください。貴方のためです

17. 要件定義は説明責任を伴う

要件定義に限りません。アウトプットを作った人は、なぜそのアウトプットになったのか、説明責任があります。理由を全て明確にして残しておくことが保身のための第一歩です。

理由が不明確になったとき、あなたはつるし上げられるのです。死にたくなかったら、理由は全て必ず残して、明確にして、ブツにして残しておきましょう。それがあなたの残る道です。

References

References
↑I 既に「大好き」とかいってる

“[IPA] デスマらないために「超上流から攻める IT 化の原理原則17ヶ条」が思った以上に使える件 [要件定義]” への75件の返信

  3. 超上流から攻める IT 化の原理原則17ヶ条が思った以上に使える件 [要件定義] | oshiire*BLOG

  4. 簡素だがリッチ。詳しく知りたいです！→"CUI のホスト系の画面で、必要最低限の文字を入力させて、レスポンスだけは異常に早いシステムを提供しますけどね"

  8. “日々の事務処理や、特化した業務処理などは、なんで WEB化したんだろうね、と思わずにはいられません”同感。熟練オペレータの凄まじいキーボードさばきを見てみるべき。

  9. [IPA] デスマらないために「超上流から攻める IT 化の原理原則17ヶ条」が思った以上に使える件 [要件定義]

  15. [IPA] デスマらないために「超上流から攻める IT 化の原理原則17ヶ条」が思った以上に使える件 [要件定義]

  22. まずは3,9,17辺りが厳守されるようになると状況がかなりマシになる気がする;他方11辺りは少し「触るな危険」臭を感じる

  26. “ぜひ言い返してください。「お前が言い出したんだろ」と。出禁になります。” 笑った。／内容には特に異論なし。コメントが9個目あたりから徐々に荒んでるのが笑えた。

  28. 「要件定義ベースのシステム開発成否は発注者のリテラシーが9割」って本出したら売れそう。買うのはベンダーばっかだろうけどw

  29. 『ぜひ言い返してください。「お前が言い出したんだろ」と。出禁になります。』 →ちょｗｗｗ出禁にならないようにこれを言い返すテクを知りたい。

  35. "要件定義は発注者の責任"vsプロジェクトマネジメント義務 ﾌｧｲｯ! →スルガ銀裁判、みたいな事態を防止するためにこれらの原則が重要という無限ループだなー

  36. システム開発に限らず、すべてのプロジェクト推進に当てはまる原則。わかっちゃいるんですがね・・・(;´･ω･)

  39. Web化しても大丈夫だよ。キーボードショートカットがすべて使えて、入力確定してもページ遷移しなくて、Excelから行列をそのまま貼り付けるとこういうレコードに展開される、ってちゃんとUI/UXの要件決めれば。

  41. この手の話が共有できるのはユーザのシステム部門までで、現場にいる100人のステークスホルダにひっくり返されるのが悲しい所

  43. これ、ベンダーもだけど4番とか上の人間が役立たずなユーザー側担当者にとっても「ぐはっ（吐血）」みたいなスイッチがあってあれなんだろう目から汁が出てくる

  44. 超上流から攻める IT 化の原理原則17ヶ条が思った以上に使える件 [要件定義] | oshiire*BLOG

  45. 受託側からすれば常識なんだけど、明文化するのは発注者側にも理解して貰う上では大事よね。個人的には「初めて仕事をする相手の、力量・品質は常に疑う」とか「ステークホルダーの力関係を重視する」がTOP10に入るか

  49. とても真っ当な項目。そしてコメント見たら…この人応援したくなった。がんばれー。

  51. “しってますか? GUI/WEB になって、特化業務の効率は落ちてますよ。分かっていない人たち大杉です。熟練度のことを忘れてます。”ある。まじである。

  52. しょっさんの言うことは正論過ぎて、悶絶する人が出ているのではと想像している。いずれにしても本は買って読んでみます。

  53. 書きながらこみ上げてきた感情が文中に入ってきてて面白い。苦労してるのが滲み出てる。

  54. 精緻に作った要件に価値があるかが、判りようもないしuser testみたいな現実からのフィードバックも力関係上むずそうなので計画通りにゴミを作ったということが起こりそう（もちろんそんな物ばっかだとは言わんけど

  56. 「死にたくなかったら、理由は全て必ず残して、明確にして、ブツにして残しておきましょう」→これな。 #開発

  58. ぜひ言い返してください。「お前が言い出したんだろ」と。出禁になります。 このくだりが好き、勝てない戦いだよな

  61. 要件定義書では、システムの概要が自ずと分かる、そんな状態に本来は持っていけていて当然なのですが、RFP を要件定義書だと言い張る人も居る程度には世の中が腐っています。

  62. デスマらないために「超上流から攻める IT 化の原理原則17ヶ条」が思った以上に使える件 [要件定義] @sho7650さんから

  63. (IPA) 超上流から攻める IT 化の原理原則17ヶ条が思った以上に使える件 (要件定義) | oshiire*BLOG

  65. 第ゼロ条、プロジェクトは時間の余裕を持って開始しましょう。／『「今と同じ」という要件定義はありえない』『「今と同じ」という要件定義はありえない』大事なことなので二回連呼。／超上流って、社長とかやな。

  70. 「超上流」という言葉自体はとても気に入らないけれども、IPA 独立行政法人 情報処理推進機構 が作って公開している「超上流から攻める IT 化の原理原則17ヶ条」が、当たり前のことを当たり前に並べてあってとても役に Ta

  71. 5. 多段階の見積りは双方のリスクを低減する→牛丼頼んどいて、天ぷら乗ってないけどどうなってるんだコラという感じのモンスターが一人二人はいるｗ

  72. デスマらないために「超上流から攻める IT 化の原理原則17ヶ条」が思った以上に使える件 [要件定義]

  73. ステークホルダ間の合意を得ないまま、次工程に入らないってのは色々な場面で重要だと思う。

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください。