情報システムの開発プロセスは、「上流工程」「下流工程」に分けてとらえることが多い。通常は、計画から要求（要件）分析、基本設計までの工程を「上流」、詳細設計から実装（プログラミング）、テストまでを「下流」と位置づける。IT業界に長くいる方なら「上流CASE」「下流CASE」といった言葉をご存じだろう。

　開発プロセスを「上流」「下流」と分けることに異議を唱える声は以前からあった。そもそもこの区別はウォータフォール型の開発プロセスに基づくもので、繰り返し型の開発にはなじみにくい部分が多い。特に分析・設計から実装・テストまでを2週間あるいは1カ月といった短い期間で繰り返しつつ、ソフトウエアを成長させていくアジャイル開発では、上流・下流と呼ぶことにほとんど意味はない。

　何よりこの分け方や呼び方は、特に「下流」に属する人たちや組織・会社にとって、好ましいものではない。上流というと、実態はともかくとして「上流階級」「上流社会」のように、きらびやかな印象を受ける。下流はその逆であり、IT業界では下請け構造のイメージとも重なる。開発プロセスを上流・下流と分けることを容認する人でも、口に出して「下流工程」とはあまり言わないのではないだろうか。

　筆者は2年前まで、下流のど真ん中であるプログラミングを扱う雑誌にいた。このときは「プログラミングこそシステム開発の中心であり、プログラマは主人公である」という思いで雑誌を作っていた。今もその思いに変わりはない。実際、筆者がかかわったブログラマは、下流というイメージとは程遠い人たちだった。

　現在は、IFRS（国際会計基準）やJ-SOX（日本版SOX法）、ITガバナンスのフレームワークであるCOBIT、ビジネスアナリシスの知識体系であるBABOKといったものにかかわっている。これらはシステム開発というより、ガバナンスやライフサイクル管理にかかわるものだが、あえて上流・下流に分けるのであれば、上流の中でも最上流に位置するといえるだろう。

　こうした経験を通じて、「下流」への違和感以上に、「上流」を上流と呼ぶことに、より違和感を感じるようになった。システム開発における「上流」は必ずしも上流ではないからである。これを上流と呼んだり意識したりすることが、ビジネス（経営）とITのギャップを生む要因となっているではないか。こう感じられてならない。

IFRS対応プロジェクトでのシステム構築は「上流」か？

　「上流」が必ずしも上流ではないとはどういうことか。日本の上場企業が社内にIFRS対応プロジェクトを立ち上げるケースを例に採ろう。このプロジェクトは2015年にも始まるIFRSのアドプション（強制適用）に対応するのが狙いである。

　最初にアクションを起こすのは経理・財務担当者だろう。まずは「IFRSとはいかなるものか」を調べなければならない。IFRSは会計の基準であり、会計の専門知識を持つ担当者でないと、その正体を正しく把握することは不可能だ。この段階でIFRSとは何か、日本の会計基準とどう違うかなどを押さえる。

　続いて、経営企画担当者を巻き込みつつ、タスクフォースあるいは小プロジェクトを立ち上げる。ここではまず、現状分析や影響分析を実施する。連結対象子会社を含めた連結経営・ビジネスの現状と、IFRSの導入によりどのような影響が及ぶかを確認する。その後、連結グループ全体としてのIFRS対応の基本方針を固め、全社プロジェクトの実施に向けた計画を立案していくことになる。

　タスクフォースでは経理・財務や経営企画の担当者に加えて、様々な担当者の参加が必要になる。特に経営層の参画が重要だ。できればリーダーとして連結経営の視点でIFRS対応の意義や方針の検討に加わるのが望ましい。

　現状や影響を分析するためには、現業部門の担当者も欠かせない。連結経営の実態を知るには、国内外の主要子会社のメンバーを参集する必要もある。IFRSに詳しい外部コンサルタントの手を借りるケースも多いだろう。

　当然、CIO（最高情報責任者）ないし情報システム部門の担当者もタスクフォースに参加する必要が出てくる。会計周りの処理にシステムを使っていない企業はまずあり得ないからだ。ただし、タスクフォースの段階では具体的な話までは至らず、システムに関する現状や影響に関する概要の説明や資料の提出を求められる程度にとどまるのではないか。

　システム部門が本格的に作業を始めるのは、タスクフォースの活動が一通り完了し、全社プロジェクトが始動してからだろう。会計や販売管理、固定資産管理などIFRSにより影響を受けるシステムを中心に現状分析や影響分析を実施して、どのシステムをどの程度改変・再構築すべきかを判断し、実際の構築・刷新作業に取りかかる。システムに関する影響分析はある程度タスクフォースでできていたとしても、この段階で改めて詳細に実施する必要がある。

　システム開発における一般的な意味での「上流」はここでようやく始まる。システム構築・刷新の計画を立案し、要件を洗い出したりRFP（提案依頼書）を作成したりする。

　だが、タスクフォースを含むIFRS対応プロジェクト全体の工程の中では、この段階はもはや上流ではない。「下流」ととらえる方が実態に即している。IFRS対応プロジェクト全体の方針や計画は既に決まっており、あとは計画にのっとり、実行に移すフェーズにあるからだ。

　もっと言えば、全体プロジェクトが始まってすぐシステムの構築・刷新が始まるとは限らない。J-SOX対応でも、「ITへの対応」を内部統制の基本的要素として挙げていたにもかかわらず、システム関連は後回しにされるケースが多かった。IFRSでも同じ事態が発生することは十分考えられる。その場合、システム絡みの作業は「下流の中ほど」くらいの位置づけになる。少なくとも上流ではあり得ない。

　IFRSやJ-SOX対応に限らず、新規事業の開発や業務改革でも同じことが言える。ビジネス上の一連の活動が先にあり、情報システムにかかわる活動はその後に本格化する。情報システムがビジネス（経営）の実現手段である以上、当然の話であるといえる。

　企業のシステム開発に携わっているのであれば、システム開発における「上流」は上流とは限らないという認識をまず持つべきだろう。「上流」は非常に大事な工程だが、あくまでシステム開発の中に閉じた世界観である。この言い方あるいは見方がシステム開発に携わる人たちの視野を狭めているように思えてならない。