【レビュー】実務に活かす IT 化の原理原則 17 ヵ条
ひと昔前の資料になりますが、 2010 年に情報処理推進機構（ IPA ）が発行された『 実務に活かす IT 化の原理原則 17 ヵ条 』という PDF を読んでみました。
（本資料は無償で公開されているので誰でも自由に読むことができます）
システム化プロジェクトにおけるポイントをまとめた小冊子で、ユーザー側・ベンダー側のどちらの人が読んでも役立つ内容となっています。
今回はこの資料について一ウェブ技術者の立場からコメントをしてみたいと思います。
先にお断りですが、関係者の方には申し訳ありません、辛辣に好き勝手書かせていただきます。
「 17 ヶ条」とは
『原理原則 17 ヶ条』とは、システム化プロジェクトにおいて知っておくべきこと・押さえるべきことをまとめたもので、各項目のラベルは次のとおりです。
- 原理原則［１］ ユーザとベンダの想いは相反する
- 原理原則［２］ 取り決めは合意と承認によって成り立つ
- 原理原則［３］ プロジェクトの成否を左右する要件確定の先送りは厳禁である
- 原理原則［４］ ステークホルダ間の合意を得ないまま、次工程に入らない
- 原理原則［５］ 多段階の見積りは双方のリスクを低減する
- 原理原則［６］ システム化実現の費用はソフトウェア開発だけではない
- 原理原則［７］ ライフサイクルコストを重視する
- 原理原則［８］ システム化の方針・狙いの周知徹底が成功の鍵となる
- 原理原則［９］ 要件定義は発注者の責任である
- 原理原則［１０］ 要件定義書はバイブルであり、事あらばここへ立ち返るもの
- 原理原則［１１］ 優れた要件定義書とはシステム開発を精緻にあらわしたもの
- 原理原則［１２］ 表現されない要件はシステムとして実現されない
- 原理原則［１３］ 数値化されない要件は人によって基準が異なる
- 原理原則［１４］ 「今と同じ」という要件定義はありえない
- 原理原則［１５］ 要件定義は「使える」業務システムを定義すること
- 原理原則［１６］ 機能要求は膨張する。コスト、納期が抑制する
- 原理原則［１７］ 要件定義は説明責任を伴う
出典：IPA－SEC「超上流から攻めるIT化の原理原則17ヶ条」
各項目はタイトルと本文の趣旨が一致していないものもあるため内容を正確に理解するには本文を読む必要がありますが、このタイトルをざっと眺めるだけでもおおよその内容は把握していただけるでしょう。
コメント
超上流から攻めるIT化の原理原則17ヶ条
早速ですが、まずこのタイトルから突っ込ませてください。 「超上流」なんて言葉遣いはセンスが悪いのでやめましょう 。
要はプロジェクトの「初期の初期」の工程を指す言葉で、「上流の上流だから『超上流』だ」とのことで言わんとすることはわかるのですが・・・「上流」に「超」を付ければいいじゃんというのはあまりにも安易です。
加えてまずいのは、この言葉遣いからは
- 「私たちは超が付くほどすごいことをしている」
- 「私たちは超上流だ」
という関係者らの姿勢が透けて見えることです。 もしかしたら
- 「下流は単純作業なので下々の者たちにやらせておけばいい」
- 「上流は高度かつ重要なので一流の私たちが進めるのだ」
とでも思っているんじゃないかとも思えます。
もともと「上流」「下流」という単語には、「上流階級」や最近で言えば「下流老人」という言葉があるように、川の上下の他に立場や身分の高低を表す意味合いもあります。 その「上流」にさらに上位を表す「超」を付けることは悪趣味だと思います。
もしかすると特に深い考えなしで単に重要性を強調する意味で「超」と付けたのかもしれません。 それならそれで、「重要なのは一部の工程だけではなく一連のプロセスです、一部の工程をことさら重要視するのはやめましょう」という反論があります。 プロジェクトでも日常のビジネスプロセスでも何でも、重要なのはバリューチェーン全体を通して一定の品質を保つことです。 その一部の工程に「超」を付けてことさら持ち上げることは、発信者らにその意図が無かったとしても、他の工程を軽んじることに繋がります。
もうひとつ私が気になるのは「その言葉、英語でどう表現するの？」という点です。 もしかしたら「 Japanese Cho-Joru ― Super Upstream 」等と言うのでしょうか。 誰か日本人が得意顔で海外の人にそのように言っている光景を想像すると、私は何とも言えない気持ちになります。 この 21 世紀の、中でも英語が共通語となっているソフトウェアの世界において、英語で表現したら明らかに変な単語には何か重大な欠陥があると誰かが気づいて止めるべきです。
ソフトウェア開発プロジェクトの実情として、深刻な問題の原因の多くは「上流」工程にあること、「上流」工程での失敗を「下流」工程でリカバーするのが難しいことについては全面的に同意します。 そこに注目を集めるべきだというベースの考えにも共感します。
しかし、彼らが「超上流」と呼ぶ概念は 2010 年当時の時点で何ら新しいものではないですし、変な名前を付けて表層的なインパクトに走るべきではありません。 言葉遣い・表現についてはソフトウェアエンジニアリングの世界ですでに一般なものを使って、肝心の内容の濃さや洞察の深さで勝負すべきだと思います。
IPA さんの資料ではこの資料にかぎらず「超上流」という言葉が度々使われているようなのですが・・・ぜひ見直していただきたいところです。
・・・とタイトルで早速つまづいてしまいましたが、気を取り直して中身を見ていきます。
本文を読むと、 主張の中身についてはおおむね共感できます 。 全体的に日本語がこなれていない印象がありますが、ソフトウェアプロジェクトの実務経験がある方であれば多くの方が「そうそう」とうなずく内容ばかりではないでしょうか。 断片だけですが事例等の紹介もあり、多くの立場の読者が自分の状況に引きつけて興味深く読めるようになっていると思います。
書かれているレベルについては、実際に体験してみないと実感が湧かないところも多いでしょうが、 ソフトウェアプロジェクトを本気で成功させたいユーザー企業の担当者の方はぜひ一読すべき水準だと思います 。
細かいポイントも見ていきます。
- 原理原則［１］ ユーザとベンダの想いは相反する
主張に異論はありませんが、「想い」なんてフワフワした表現はここでは避けるのがよいでしょう。 おそらくここで使うべき単語は「ニーズ」や「関心事」です。 エンジニアリングの方法論を語る文脈なので、解釈の幅が広い言葉を不用意に使うのは極力避ける方がよいと思います。
- 原理原則［２］ 取り決めは合意と承認によって成り立つ
これは何でしょう？定義？定理？それとも「べき論」でしょうか？
本文の説明を読むと、おそらく「べき論」を言いたいのでしょうが、もしそうなら明確にそうとわかる表現にした方がよいでしょう。 私なら次のように書きます。
- 原理原則［２］ 取り決めは明確な合意と承認をもって行うこと
続いて他のポイントを見ていきます。
- 原理原則［３］ プロジェクトの成否を左右する要件確定の先送りは厳禁である
- 原理原則［４］ ステークホルダ間の合意を得ないまま、次工程に入らない
- 原理原則［１０］ 要件定義書はバイブルであり、事あらばここへ立ち返るもの
言わんとすることはわかりますが、バラバラな文章表現がノイズとなり、メッセージが効果的に伝わってきません。 英語にしてみるとそのちぐはぐさがよくわかります。
- 原理原則［３］ プロジェクトの成否を左右する要件確定の先送りは厳禁である
It's strictly forbidden to delay decisions of requirements which determine the project's success or failure.
- 原理原則［４］ ステークホルダ間の合意を得ないまま、次工程に入らない
You must not enter the next phase without achieving stakeholders' clear agreements.
- 原理原則［１０］ 要件定義書はバイブルであり、事あらばここへ立ち返るもの
Statements of requirements are so-called the Bibles for software projects. They should be referred frequently. （「事あらば」を意訳しました）
「厳禁である」と「次工程に入らない」は実はどちらも「 must not 」と言っているのですが、わざわざ言い回しを変えてあります。 何らかの深い狙いがあってあえてそうしているのでなければ、技術に関わる資料でそんなことをしてはいけません。
「原理原則」として列記するなら少なくともタイトルの表現は揃えるべきです。 私なら例えば次のように書きます。
- 原理原則［３］ 要件を確定させてから次工程に進むこと
- 原理原則［４］合意を得てから次工程に進むこと
- 原理原則［１０］ 要件定義書を必ず作成しその後の工程で参照し続けること
「表現を揃える」というのは技術文書だけでなくビジネス文書全般における基本であり、ここでその基本を破ることにはメリットよりもデメリットが大きいでしょう。
・・・ということが気になってくると、そもそもの「原理原則」という表現も気になってきます。 「原理原則とは何ぞや」の理解が著者らには不足している感じがします。
例えば、次の 2 つは「原理」として適切な感じがしますが・・・
- 原理原則［１］ ユーザとベンダの想いは相反する
- 原理原則［６］ システム化実現の費用はソフトウェア開発だけではない
次の 2 つは少なくとも「原理」ではありません。
- 原理原則［１１］ 優れた要件定義書とはシステム開発を精緻にあらわしたもの
- 原理原則［１４］ 「今と同じ」という要件定義はありえない
「守るべき行動規範」という意味でこれらを「原則」と言うこともできないわけではありませんが、この資料が紹介しているものはむしろ「成功させるためのコツ」等と呼んだ方がよいものでしょう。
そもそも「原理」というのは自然現象や摂理を表すもので、例えば「水は加熱すれば気体になる」といったものです。 たいていは文末に「〜ものである」と付けても違和感がありません。
- 原理原則［１］ ユーザとベンダの想いは相反する 〜ものである
- 原理原則［６］ システム化実現の費用はソフトウェア開発だけではない 〜ものである
他方、次にあげられているようなものは明らかに「原理」ではなく「コツ」です。
- 原理原則［１１］ 優れた要件定義書とはシステム開発を精緻にあらわしたもの
- 原理原則［１４］ 「今と同じ」という要件定義はありえない
「コツ」は、適切に表現を整えてあげると文末を「〜べきである」「〜べきではない」で統一することができます。 ですので、私なら例えば次のように書きます。
原理原則［１１］ 要件定義書では、さまざまな視点から具体的・詳細に要件を記述する〜べきである
原理原則［１４］ 「現行システムと同じ」でも具体的に要件を記述する〜べきである
このように原理原則について書くのであれば、ベースにある「原理」（≒観測された事実）のレイヤーと、その上に乗っかる「コツ」（≒「こうすべきだ」という推奨）のレイヤーの 2 つに分けて書くのがよいでしょう。
例えば、健康管理マニュアルを書く場合で考えてみると
- 夏に野外で激しい運動をすると、大量の発汗と塩分の排出が起こる
- 水分や塩分が少なくなると、熱中症や健康障害につながる
という「原理」があって、だから
- 夏に野外で激しいスポーツをする場合は、塩分・水分をこまめにとりましょう
という「コツ」がある、という具合です。 この「原理」と「コツ」をないまぜにすると、ロジックが弱いとみなされ、説得力のある文書になりません。
なので、少なくとも「原理原則」の表現を改めるか、できれば整理・再構成し直すべきです。
これはいわゆる「国語レベル」の問題ですが、資料の本質と無関係かというとそんなことはありません。 なぜなら、 彼らの言う「超上流」――いわゆる最初期の工程では「国語力」こそが成否を左右する重要な要因だから です。
私の認識が間違っていなければ、ですが
- 人の話を正しく理解する
- 人が言葉にしないニーズを汲み取る
- 事実間の関係を整理し可視化する
- 誤解の少ない正しい伝え方をする
といった国語的な作業が一定以上のレベルでできないことには、要件定義をまともに行うことはできません。 そして、この資料ではそれができていません。 ダイエットを実践できていない人がダイエット理論を語っても説得力がないように、拙い文章で要件定義を語っても説得力がありません。 そのため、この資料における「国語力」問題は深刻です。
じゃあどうすればよいか、なのですが、批判だけではアレなので、具体的にこの 17 ヶ条を整理した「バージョン 2.0 」を以下提案してみます。
ビフォー・アフターを示すだけだとわかりづらいので、途中経過を書きながら段階的にバージョンアップしていきます。
「 17 ヶ条」バージョン 2.0 の提案
- バージョン 2.0-alpha
- バージョン 2.0-beta
- バージョン 2.0
まずは、各タイトルはそのままに、上の説明のとおり「原理」と「コツ」に分けてみます。
バージョン 2.0-alpha
原理（〜ものである）:
- 原理原則［１］ ユーザとベンダの想いは相反する
- 原理原則［６］ システム化実現の費用はソフトウェア開発だけではない
- 原理原則［１２］ 表現されない要件はシステムとして実現されない
- 原理原則［１３］ 数値化されない要件は人によって基準が異なる
- 原理原則［１６］ 機能要求は膨張する。コスト、納期が抑制する
コツ（〜べきである）:
- 原理原則［２］ 取り決めは合意と承認によって成り立つ
- 原理原則［３］ プロジェクトの成否を左右する要件確定の先送りは厳禁である
- 原理原則［４］ ステークホルダ間の合意を得ないまま、次工程に入らない
- 原理原則［５］ 多段階の見積りは双方のリスクを低減する
- 原理原則［７］ ライフサイクルコストを重視する
- 原理原則［８］ システム化の方針・狙いの周知徹底が成功の鍵となる
- 原理原則［９］ 要件定義は発注者の責任である
- 原理原則［１０］ 要件定義書はバイブルであり、事あらばここへ立ち返るもの
- 原理原則［１１］ 優れた要件定義書とはシステム開発を精緻にあらわしたもの
- 原理原則［１４］「今と同じ」という要件定義はありえない
- 原理原則［１５］ 要件定義は「使える」業務システムを定義すること
- 原理原則［１７］ 要件定義は説明責任を伴う
一見分類が不適切に見えるものもありますが、それはタイトルと本文の趣旨が異なる項目があるためです。 本文の趣旨も考慮してふりわけるとこのようになります。
続いて、「コツ」については数が多いので、似たもの同士をグルーピングしてみます。
バージョン 2.0-beta
コツ（〜べきである）:
「意思決定と合意」のコツ
- 原理原則［２］ 取り決めは合意と承認によって成り立つ
- 原理原則［４］ ステークホルダ間の合意を得ないまま、次工程に入らない
「認識共有」のコツ
- 原理原則［８］ システム化の方針・狙いの周知徹底が成功の鍵となる
- 原理原則［１５］ 要件定義は「使える」業務システムを定義すること
- 原理原則［１７］ 要件定義は説明責任を伴う
「フェーズ分け」のコツ
- 原理原則［３］ プロジェクトの成否を左右する要件確定の先送りは厳禁である
- 原理原則［５］ 多段階の見積りは双方のリスクを低減する
「多面的認識」のコツ
- 原理原則［７］ ライフサイクルコストを重視する
- 原理原則［１１］ 優れた要件定義書とはシステム開発を精緻にあらわしたもの
「発注者責任」のコツ
- 原理原則［９］ 要件定義は発注者の責任である
「明文化」のコツ
- 原理原則［１０］ 要件定義書はバイブルであり、事あらばここへ立ち返るもの
- 原理原則［１４］「今と同じ」という要件定義はありえない
「意思決定と合意」「認識共有」「フェーズ分け」「多面的認識」「発注者責任」「明文化」というグループでくくれました。 これはもっと大がかりに組み直すこともできますが、原型を残すためにこれぐらいでとどめておきましょう。
さらに、同一グループのものをまとめ、ラベルを変えてみます。 「原理」のものもあわせてラベルを変えてみます。
バージョン 2.0
原理（〜ものである）:
- 各ステークホルダーのニーズは異なる ［１］
- ソフトウェアにはそのライフサイクル全体にわたってコストがかかる ［６］
- 設計・実装担当者は要件に記載の無い内容は設計・実装しない ［１２］
- 要件を数値化しないと解釈のギャップが大きくなる ［１３］
- 要件はプロジェクトが進むにつれて膨らむ傾向が高い ［１６］
コツ（〜べきである）:
- 「意思決定と合意」のコツ
- 重要な意思決定ポイントについては、必ずステークホルダーの明確な合意・承認を得るべきである ［２］［４］
- 「認識共有」のコツ
- プロジェクトの目的と方針を明らかにし、ステークホルダーに対して能動的に説明を行い、理解と合意を得るべきである ［８］［１５］［１７］
- 「フェーズ分け」のコツ
- 各作業フェーズを明確に分け、各フェーズではその成果物をすべて出し切った後で初めて次フェーズに着手するべきである ［３］
- 見積もりと契約は多段階に分けて行うべきである ［５］
- 「多面的認識」のコツ
- プロジェクトの各側面に目を向け、重要なポイントの考慮漏れが無いようにすべきである ［７］［１１］
- 「発注者側」のコツ
- 要件定義作業の最終責任者は発注者と認識して主体的に要件定義をチェックするべきである ［９］
- 「明文化」のコツ
- 要件定義書は、その後のすべてのフェーズの土台になるので、重要なポイントは漏れ無く記述し常時参照すべきである ［１０］［１４］
表現を大幅に変えたので、元のナンバリングを各行末に加えました。
ここからさらに項目を追加し再構成すればよりきれいにわかりやすく整理することもできそうですが、ひとまずここまでで止めておきたいと思います。
これで「原理」 5 つと「コツ」 7 つの合計 12 個に減りました。 ビフォーの状態に比べると、技術の方法論を語るのにより適した、ブレと過不足の少ない形になったのではないかと思うのですが、いかがでしょう。 比較のためにビフォーの一覧を再掲します。
- 原理原則［１］ ユーザとベンダの想いは相反する
- 原理原則［２］ 取り決めは合意と承認によって成り立つ
- 原理原則［３］ プロジェクトの成否を左右する要件確定の先送りは厳禁である
- 原理原則［４］ ステークホルダ間の合意を得ないまま、次工程に入らない
- 原理原則［５］ 多段階の見積りは双方のリスクを低減する
- 原理原則［６］ システム化実現の費用はソフトウェア開発だけではない
- 原理原則［７］ ライフサイクルコストを重視する
- 原理原則［８］ システム化の方針・狙いの周知徹底が成功の鍵となる
- 原理原則［９］ 要件定義は発注者の責任である
- 原理原則［１０］ 要件定義書はバイブルであり、事あらばここへ立ち返るもの
- 原理原則［１１］ 優れた要件定義書とはシステム開発を精緻にあらわしたもの
- 原理原則［１２］ 表現されない要件はシステムとして実現されない
- 原理原則［１３］ 数値化されない要件は人によって基準が異なる
- 原理原則［１４］ 「今と同じ」という要件定義はありえない
- 原理原則［１５］ 要件定義は「使える」業務システムを定義すること
- 原理原則［１６］ 機能要求は膨張する。コスト、納期が抑制する
- 原理原則［１７］ 要件定義は説明責任を伴う
ということで、バージョン 2.0 の提案でした。
・・・
とここまで作業をして改めて思ったのですが、このような「 ロジックの整理 」や「 ユビキタス言語の精錬 」「 過不足の少ない明快な記述の追求 」こそが、ソフトウェアエンジニアリングの前工程で重要なことではないでしょうか。 内容が実情と大きく乖離しているということはありませんが、文章がふんわりしているとせっかくの内容も読者に十分に伝わりません。 関係者の方には、改訂の機会があればぜひもうひと工夫していただきたいと思います。
再びコメント
辛口になりすぎてしまったので、よいところをもう少しあげてみます。
そもそも論ですが、この小冊子ぐらいの長さの資料でソフトウェア開発プロジェクトについて語るのは難しいと思います。 ポイントだけを書くには長いですし、丁寧に語り尽くすには短いので、どうしても中途半端な説明にならざるを得ません。 この制約の中でこれを書いたのは大変だったことと思います。
また「日常業務と並行で 1 ヶ月以内に書きあげないといけない」「レビューを通しているリソースは無い」といった厳しい制約もあったのかもしれません。 そのあたりこそザ・プロジェクトマネジメントの領域ですが、環境や道具立てが十分でなかった可能性もあるでしょう。
そして、繰り返しになりますが、肝心の内容については、おおむね「そうですよねー」と思うものが多かったです。 特に最近の私の関心でいうと、次の項目等は「そうそう、そうですよね！」と思いました。
- 原理原則［４］ ステークホルダ間の合意を得ないまま、次工程に入らない
- 原理原則［５］ 多段階の見積りは双方のリスクを低減する
- 原理原則［６］ システム化実現の費用はソフトウェア開発だけではない
- 原理原則［８］ システム化の方針・狙いの周知徹底が成功の鍵となる
そして、このような資料が無償で公開されていることは、業界で働く者にとっては大変ありがたいことです。 日本のソフトウェアエンジニアリングに対して何かしらよい影響を与えたい、という著者らの意思を感じました。
ただ、上述のとおり、日本語がこなれていないところがあるので、そのあたりを整理・編集してみられるとよいのではないかと思います。
最後にもうひとつ、気になる点をあげます。 それは「先人が遺した資産に言及していないこと」です。 この種の話題はこの PDF が公開された 2010 年よりもずっと前から長年議論されてきたことですし、援用できる文献はたくさんあります。 ですので、次の改訂版を出されることがあれば、参考文献もぜひ載せていただきたいと思います。
というわけで、 IPA さんの『実務に活かす IT 化の原理原則 17 ヵ条』に対する一技術者の立場からのコメントでした。
厳しいコメントをたくさんしてしまいましたが、ユーザー側企業の方でソフトウェアプロジェクトの書籍を読んだことが無い方には、ぜひ一度ご覧になってみてください :)