ITライフサイクルの課題

IT部門は経営や業務部門に貢献するため、IT技術を活用したサービスを提供することがミッションです。その代表的なサービスが業務アプリケーションシステムの提供です。業務アプリを提供するプロセスは、企画、要件定義、設計、開発、試験、運用、そしてまた次の企画という具合に循環するサイクルになります。これを“ITライフサイクル” と呼ぶことにします。

 

ITライフサイクルの過程には様々な役割の組織が絡んできます。要求側として経営層、業務部門、実現する側としてはIT部門の企画者、設計者、開発者、運用者等です。今回は開発と運用をそれぞれ専門の業者に委託している企業を想定して話を進めます。そうすると大別して「要求者（経営層や業務部門）」・「発注者（IT企画）」・「開発者（ベンダーや情報システム子会社の開発部門）」・「運用者（運用アウトソーサーや情報システム子会社の運用部門）」という４つの役割分担が想定されます。ITライフサイクルにおける様々な課題は、この４者間におけるミスコミュニケーションによって引き起こされます。

 

それでは、４者間におけるミスコミュニケーションを３つに類型化します。

 

1：「要求者」から「発注者」へのミスコミュニケーション

 

経営層や業務部門の要求をIT部門が正確に把握できていないケースです。要件に抜け漏れがあり、要件が曖昧なまま開発者と契約してしまい、開発工程に入ってから手戻りが発生します。このケースでは開発者に非はありませんので、訴訟を起こしてもこの企業は負けてしまいます。開発者に追加費用を支払ってでも開発を続行するか、途中で開発を断念し、それまで支払った費用を無駄にするか、何れにせよ想定外のコストが発生することになります。失敗のインパクトが最も大きいミスコミュニケーションと言えます。

 

2：「発注者」から「開発者」へのミスコミュニケーション

 

この両者間では通常、請負契約により期間、金額、成果物が明確化されますので、定義された要件に対し、開発者側に誤解があったとしても、それは開発者側の責任となります。とは言え、特に日本では即座に訴訟に至るようなことは少なく、金額は据え置きで開発期間が延ばされたり、開発範囲が縮小されたりすることにより、要求元の組織が不利益を被ることがあり得ます。特定のベンダーが長年その企業の開発や運用を受け持っているケースなどは、馴れ合い（癒着とも言いますね）の体質が常態化してしまい、表には見えにくい不利益が蓄積されてゆきます。

 

3：「開発者」から「運用者」へのミスコミュニケーション

 

日本が得意とするモノづくりの世界では、品質は設計段階で作りこまれるのが普通ですが、ITの世界ではなぜか開発完了の後、運用に入って初めて気づく品質不良を良く耳にします。運用設計というものが一応行われますが、実際に運用する人が設計段階で意見しているケースは稀かもしれません。この両者間ではミスコミュニケーションという以前に、「押し付け」が横行します。「運用でなんとかしてくれ」と。結果として不利益を被るのはやはり要求元、この業務アプリを使うユーザさん達という事になります。

 

前置きが長くなりましたが、次章からはこれらのミスコミュニケーション（もしくは押し付け）を防止し、要求元の不利益を回避するにはどうしたらよいか、３つのフェーズに分けてご説明します。IT開発の工程をよくV字に例えることがありますが、１つ目は「V字の下り」の工程（要件定義～開発）、２つ目は「V字の上り」の工程（開発～試験）、そして３つ目に運用工程へと続けます。

(図1: V字と運用の絵)

 

V字の下り：縦のトレーサビリティー

「要求者」から「発注者」、そして「開発者」へと伝えなければならない情報の事を「要求」もしくは「要件」といいます。言葉の厳密な定義は割愛します。（これだけで一つの論文になってしまう世界ですので）ここでは簡単に、曖昧な期待を含んだ“やりたい事” を指して「要求」、それを実行可能な具体的な事項として定義したものを「要件」と呼ぶことにしましょう。この二つの言葉が示唆するとおり、V字の下りでは、要求情報を幅広い範囲から特定の範囲に絞り込み且つ、曖昧な状態から具体的な条件へと明確化してゆく作業を行います。上流から下流へ向けて情報が流れてゆく訳ですが、この伝言ゲームの中で本当の“やりたい事” を最後まで正確に伝えることは、実は結構難しい仕事です。上流から下流への情報の整合性を維持することから、これを縦のトレーサビリティーと呼んでいます。

 

上流から下流への要求の伝達はなぜ難しいのでしょう。
ひとつには登場人物間に専門性と責任範囲の違いがあることが挙げられます。「要求者」はITのプロではありません。ITに何ができて、何ができないか詳しくは知りません。要求を伝えることの難しさやリスクなどにも無頓着です。

 

一方、「開発者」は業務のプロではありません。ITの一機能を便利にすることや、パフォーマンスを良くすることはできても、それが業務的にどれだけの意味を持つのか、自分で判断・評価できる立場ではありません。特に開発者が外部業者の場合は、請負契約により予算と納期に制約を受けていますので、原則は“言われたとおり”（上流で定義された要件どおり）にしか動くことができません。必然的に、この両者間を（双方の気持ちがわかる立場として）「発注者」が取り持たなくてはならないという事になります。

 

世界の違う両者がわかり合うためには、どちらにとっても分かり易く、誤解のない明快なコミュニケーション手段が必要になります。言葉や文字だけでは不十分です。大昔からそのためには様々な図表（表やツリー図やフロー図等）を描き、要求元によるレビューを繰り返すことが有効とされています。企画、要件定義、設計という工程において作成されるこれらのドキュメント類によって、要求から要件に至る情報の劣化を如何に防止できるかが鍵となります。

 

しかし、多くのケースでは、IT部門や開発ベンダーが作るドキュメント類はIT視点寄りの言葉で細かく書かれており、しかも既に自分達の責任範囲に絞られたものが多い事が実態です。要求元の経営層や業務部門にこれらを見せて、抜け漏れや間違いがないかレビューしてくれと言っても、書いてあることが部分的で、全体との関係性がわからない、細かすぎて理解できない、といったことがほとんどです。要求元と開発者の双方が同じドキュメント上で分かり合える、そのギリギリの境界はどこか？ 自社のITライフサイクルにおいて作られてきたドキュメント類を一度棚卸してみて、その境界を明確にすることが一つの解決策になります。

 

BPM (Business Process Management：ビジネスプロセス・マネジメント)ではプロセスを使って、その境界を明確にしようとします。プロセスといっても経営層が語るような視点の高い、概念的なフロー（ビジネスモデルと言ったり、サプライチェーンやディマンドチェーンと言ったりされるもの）から、システムの操作手順やプログラムの処理ロジックのフローに至るまで、プロセスの世界にも様々な階層（細かさ）があります。それらの階層のどこかに、要求者と開発者の境界としてちょうど良い境目があるはずです。

 

先行するBPM 事例では、業務部門の現場担当者レベルの業務フローを、その境界とする事が多いようです。現場担当者が誰かから作業を依頼され、そのアウトプットを生み出すまでの仕事を一単位（一つの仕事の箱）とするような業務フローのレベルになります。現場担当者がどの局面で、どんな文脈で、どの画面や帳票を使って仕事をするかが書かれています。このレベルよりも細かいフロー、IT寄りの情報が盛りだくさんなフローでは、業務サイドには理解ができなくなります。一方、このレベルよりも粗いフローでは、ITとの関連が曖昧になってしまい、ITの設計に対して情報が不十分となります。現場担当者が目の前で使っている画面や帳票が、業務とITのちょうど良い接点であると言えます。

 

このようなレベルの業務フローは開発に対して重要な要求情報を与えてくれますが、もちろんそれだけで十分ではありません。その業務アプリに対する経営層や業務部門からの期待事項、業務上で守るべきルール、そこに行き交うデータ（画面や帳票の項目）、必要となる機能のパフォーマンス等、業務フローだけでは十分に表現しきれない要素があります。このため、プロセスの階層化と並行して、他の様々な要素についてもそれぞれの視点別に階層化し、業務とITとの接点を特定する必要があります。図2 はプロセスを中心としてIT開発に必要な様々な要素を階層化し、業務とITとの接点を網羅的に定義した例です。

(図2: 業務とITとの接点を網羅的に定義)

 

図2 に示した接点の上部は、要求元がしっかりとレビューし、誤解が生じないことを保障しなくてはなりません。「うちとの付き合いも長いのだから、言わなくてもわかっているだろう？」という考え方は誤解の元です。業務部門に言わせてみれば“当たり前” の事をしっかりと書くことが大切です。接点の下部については、IT視点で仕様を詳細化してゆけばよい、開発者の得意分野となります。開発すべき機能（画面や帳票）に対して、戦略（期待）、組織、ルール、プロセス（文脈）、インプットやアウトプットとなるデータ、要求されるパフォーマンス等が明確になっていれば、“要件定義” としては十分な情報となります。それをどう実現するかは、発注者と開発者の間で概要仕様、詳細仕様という順序で詰めてゆけば良いことになります。

 

V字の上り：横のトレーサビリティー

誤解を避けるために明記しておくと、BPM はIT開発の“単位あたり” の生産性や品質を向上してくれるものではありません。それは開発者の腕次第です。改善されるのはミスコミュニケーションによる手戻りです。上流から下流へ向けた要求の伝言ゲームは、プロセスを中心として階層化して表現し、要求元と開発者との接点を明確にして、そこで握ることがコツです、というのが前章の主旨でした。

 

さて、首尾よく要求が開発者に伝わり、業務アプリの開発が完了したとしましょう。今度はそれが本当に要求どおり作られているかを、要求元の立場で確認しなくてはなりません。V字の上り、開発（コーディング）から試験を経て検収に至る工程です。試験はV字の下りとは逆に、細かい範囲から広い範囲へと登ってゆきます。まずは、個々の機能が仕様どおりに動くか、個々に試験します（単体試験）。次に各機能を組み合わせて業務アプリとして機能するかを試験します（内部結合試験）。さらに、業務アプリは企業内に一つではありませんので、その周辺に既にある業務アプリとの連携を試験します（外部結合試験）。ここまでが開発者の責任となります。できていなければ開発者の責任でやり直しです。

 

開発者が「これでできた！」と思った後、それを要求元として認めることを「検収」といい、そのための試験を一般的に総合試験や受け入れ検査と呼びます。さて、この試験では何を基準に良し悪しを判断したらよいでしょう。V字の始点と終点の比較になることから、これを“横のトレーサビリティー” と呼んでいます。前章の図2で示した業務とITとの接点となるレベルの図表（業務フローや各種のモデル）が役に立ちます。

 

もし、そのような図表類が存在しなかったら、発注者は何をもって開発物を検収するのでしょうか。多くのIT開発プロジェクトにおける検収の実態は、たいへん属人的な世界です。企業としての業務フローを持っていないと、検収時に比較する対象が人の頭にしかないという事になってしまうのです。当該のプロジェクトで多くの“改革” を語ってきたにもかかわらず、検収基準は間もなく捨てる現行システムのメニュー体系に沿って考えてみた等という笑い話が普通に横行しています。ぶつけるものがないための苦肉の策ですね。

 

「BPMは試験に役立つ」という意味は、受け入れ検査時の比較対象になるという事を指しています（開発ベンダーによる試験が楽になる訳ではありません）。開発ベンダーが作ったドキュメントのとおりにシステムが動くのは当たり前。要求元が言った通りにシステムが機能するか？という事について、比較対象となるドキュメントがBPMの業務フローです。繰り返しますが、ベンダーが作った業務フローと比較しては駄目です。

 

運用の視点：運用設計と属人化の防止

多くのITプロジェクトは納期に追われます。余裕を持って完了できたプロジェクトを私は見たことがありません。ギリギリまで機能の抜け漏れに対する追加開発や仕様変更に対応し、その試験に追われることが通常です。このため、運用者にとっては、運用すべきシステムがギリギリまで手元に揃わない、ドキュメントはさらに遅れてやってくる、という事態に陥ります。

 

BPMの業務フローはこのような悩みも解決してくれます。要件定義の段階で、今回開発される業務アプリが業務の中でどのように利用されるかを示している訳ですから、実物がなくてもある程度の運用設計が可能となります。設計段階では、運用視点からの要件を網羅的に提示することができます。運用要件が満たされているか、受け入れ検査の試験項目にも目を光らせることができます。開発者に“押し付けられる” 立場から、開発者に運用開始条件を“突き付ける” 立場へまわることができます。

 

企業にとって業務アプリの保守運用に関する悩みのもう一つは、運用ノウハウの属人化です。昔はメインフレームで一枚岩だった業務アプリも、昨今ではオープン化が進み、業務アプリが狭い範囲で乱立し、そのアプリの数だけ運用者が必要になります。障害が起きた時や、仕様変更の要望に対処する際、その作業による業務への影響がどうなるかが判断できなければ保守運用は務まりませんが、多くの場合は、その運用者による膨大な時間をかけたドキュメントやソースコードの読み込みと、経験と度胸によって成り立っています。

 

BPMはこのスーパーマンの価値の全てを代替することはできません。しかし、このスーパーマンは、誰にでもできる仕事を密かにいっぱいやっている、やらざるを得ない事もまた事実です。私にも苦い経験がありますが、彼らもやはり人間ですので、仕事を人に教えたり、こまめにドキュメント化したりするよりも、自分でやった方が早いと考えると、つい億劫になってしまいます（億劫だけのせいではありません。納期に追われて本当に暇がないのです）。こうして属人化はどんどん進んでゆくことになります。彼らを経営や業務部門への新たな貢献のため（新規投資のため）に、もっと価値ある企画の役割として使えたら、とお悩みのIT 部門長は多い事と思います。誰にでもできるはずの仕事は可視化してアウトソースしましょう、少なくともスーパーマンを使うのは止めにしましょう。

 

適用前の注意点

BPMをITプロジェクトに適用することにより、要求の縦のトレーサビリティーを維持して開発手戻りを防止し、横のトレーサビリティーにより合理的な受け入れ検査を行って開発・運用品質を高め、運用の属人化も防ぐことができることを説明してきました。ここでその適用の仕方について注意点があります。

 

ITプロジェクトの予算が確定し、開発ベンダーとの請負契約が決まった後では、このBPMの手法を取り入れることは難しくなります。開発ベンダーさんは既にWBS（作業タスク一覧）を定義済であり、BPMに関するタスクは追加作業と捉えられてしまうためです。BPMのことは自社で行うから、と言っても嫌がられるケースがあります。要件定義が従来よりもしっかりと行われるという事は、これまで開発ベンダーが見積もりの中に含めていた現状調査や仕様変更のためのバッファが少なくて済む、という事になり見積金額の圧縮を求められてしまうからです。企業にとっては良い事なのですが、急に言い出すと抵抗されてしまいます。BPMを適用するか否かは少なくとも企画段階で判断し、開発ベンダーを選定する際の前提条件とすることがお勧めです。

 

昨今では本論で述べてきたようなウォーターフォール式のV字開発ではなく、パッケージソフトやクラウドサービスを簡単に適用したり、Webベースのアジャイル型の開発を短期間に繰り返すケースも増えてきていると思いますが、要求者、発注者、開発者（導入またはサービス提供会社）、運用者の間に潜むミスコミュニケーションのリスクは同じであると言えます。開発、導入のアプローチが異なるだけで、要件の縦横のトレーサビリティーや運用設計、運用の可視化が必要であることに変わりありません。

 

まとめ

BPMの本質をお分かりの方は、やはり継続してゆく体制や制度がなければ意味がないのではないかと思われるでしょう。その通りですが、敢えてお伝えしたいのは、BPMは一度のIT開発プロジェクトにおいても、ある一定以上の開発規模があれば、前述の効果を発揮する（費用対効果は出せる）ということです。維持するための体制や制度というものは、それによる効果が実証された後でないと、なかなか確立できません。

 

多くのBPM先進事例では、まずBPMをIT開発プロジェクトに適用させ、そのプロジェクトの中に暫定的な維持体制とルールを作ります。会社としての恒常組織やフォーマルな制度とするのは、その成功事例を横展開しながら、徐々に経営層を啓発した後でやっと認められるケースがほとんどです。維持運用の事を全く意識せずに始めるのはお勧めしませんが、成果が先か、体制・制度が先か、と悩んで数年間何も始められない企業もよく耳にします。企業にとって比較的大きなシステム再構築を控えているなら、それはおそらくBPMを適用する数年に一度の大きなチャンスです。