システム開発の上流工程に向く人と向かない人…（単なるグチ）
システム開発の上流工程に向く人と向かない人…（単なるグチ）
今回の記事は要するに単なるグチにすぎないので、そのおつもりで軽く受け流していただきたい。
ちょっとばかり、最近、思うことがあったので、特に整理せずに書いてみたい。
１．（仮定）とある航空業界の航空路管理システムというものがあったとする
いわゆる特定業界/業種のユーザー企業の、基幹系業務システムを考える。
ここでは仮に、とある航空業界のとある空港の業務システムがあると仮定する。（実際にはそのようなシステムはないだろうし、私はそもそも航空業界には属していない）
【システムの概要】
とある空港における、特定の複数本のランウェイ（滑走路）と、その前後の工程を意識した、特定の航空機材（航空機）のたどる航空路の管理・表示を行う。
主要機能のひとつに、航空機材の状況予測を計算表示するというものがある。
【今回のユーザーの要望】
上記の状況予測のための専用の計算仕様を全面的に変更したい。
計算の大まかな考え方はできているが、それを現行システムにどのように当てはめたら良いかは、ユーザー側もわかっていない。
２．ユーザー企業の業界の常識
例えば、順不同に挙げても、下記のような常識が存在する。
航空機は自力ではバックできない
ランウェイの両端に書かれている数字には特定の意味があり、ランウェイの呼び方もその数字が用いられる（つまり同一のランウェイでも呼び方が2つ存在する）
離陸、着陸を、どの方向に向かって行うか、またはどのランウェイを使用するかは、その時の風向きによって常に変化する
航空路の工程には、例えば空港から半径9km以内からは、タワー管制域になるなど、複数の工程が存在する
空港のスポットとランウェイ、またはその他の格納庫などへの移動（タキシング）のルートは、パターンがいくつもあり、状況によって常に変化する
管制官の許可なくランウェイをタキシングで横切る事はできない
ディパーチャー用の航空路、アライバル用の航空路が、それぞれ存在する
……などなど。
実際には、他にも大量の、専門知識が無いとわからないような常識も存在する。（上記にも少しだけ専門用語を混ぜてみたが、これらの用語も業界にとっては専門用語でも何でもなく、当たり前の用語である、と仮定する）
業界にとって、これらは「常識」の範疇であるため、わざわざそれらを丁寧に知らない人向けに解説したドキュメントがあるわけではない。
３．その業務システムに熟知している者は自分以外にはほとんどいない
そもそもユーザー企業側や、私の所属組織の、人材育成面の欠陥かもしれないが、そのシステムの中身をいろいろ知っている者は、今となっては自分のみという状況にある。
以前の記事でも書いたが、ユーザー企業側は、いわゆる中央官庁などと同じで、どんどん官僚化が進んでいる。
また、どうやら私の所属組織の中から新たな人材も投入できないらしい。
最上流工程の要件定義のうちだけなら、まだ自分ひとりだけでも何とかなるかもしれないが、実際にシステムを再設計/プログラム修正/テストの作業を行う場合、とても一人では回せなくなる。
そのため、上流工程から、いわゆる協力会社に入ってもらう事にした。
協力会社は、IT業界では有名な大手IT企業となった。（はっきり言って私の所属組織などよりはるかに立派な会社である）
なお、今回の業界や、特定の業務システムに対する経験値は、あまり高くはない。
４．意識の差による平行線
名のしれた大手IT企業だと言う事もあり、一緒に仕事をして行くパートナーとしての協力会社メンバーには、けっこう期待は大きかった。
投入してくれるSE（システムエンジニア）も、いわゆる上流工程の経験を持つSEだろうと思った。
自分で言うのも何であるが、この仕事は、人によって、もしくは会社によっては、「お金を払ってでも経験したい仕事」であると思っている。
下記の記事でも書いたが、特定業界の特定システムの知識とは、実はそれくらい貴重なのである。
しかし、一緒に検討を進めて行くうちに、意識の差がある事に気がついた。
【私の意識】
いまやっている作業は上流工程（要件定義）であるが、ユーザー側からの強い牽引力は全く期待できない。しかし、これは見方を変えれば、我々システム開発者側が主導して、アーキテクチャー設計を含めて提案できる状況である
まだ基本設計でも無い要件定義の段階なので、作成する資料は100点の完成版である必要はなく、60点のたたき台である。それを検討の場でブラッシュアップして行くのが良い
ユーザー側の担当者は、システム的な「ファイルの図形」「フロー図」などを見てもピンと来ない種類の人達である。従って、システムの全体像をざっくりと把握できるような（俯瞰的な）概要資料が必要となる
上記の概要資料は、システム改訂を行う我々にとっても今後有用になる。何故なら、それが書けないとシステムテスト計画が作成できないからである
システムの調査作業にはいろいろな方法があるが、今回の場合は、どの部分を改定しなければいけないかが、大まかにはわかっている。従って、その部分を起点として、業務目線で影響調査を行って欲しい
システムの設計書などのドキュメントには業界の常識を前提とした記述が多い。自分もその常識の中に居る人間なので、素朴にわからない用語や概念などがあればどんどん質問して欲しい（もちろん、現行システムのドキュメント一式は全てお渡しする）
【大手IT企業メンバーの意識】
ユーザー側の要望事項が全ての出発点である。（システム開発者側からどんどん提案して良いという事を言うと驚かれる）
次回の検討会までに作成すべき資料の内容は、いまの打ち合わせの中で詳細まで確定しないといけない。そうしないと作業にムダが生じる
概要資料を作りたいという言葉の意味はわかるが、それを作成するにはシステムを隅々まで調査しなければならず、時間が非常にかかってしまう
システム概念図のような資料は自分たちなりに作成して来ているが、それでも「ユーザー側にはピンと来ない」と言われると、もはや何を作成して良いかわからない
今回変更となる画面項目などのキーワードを起点として、grep検索などを行い、ボトムアップ的な影響調査がどうしてもメインになってしまう
例えば「宿題」でも良いので、「次回までにこれを調べて来てくれ」といったような具体的な指示が欲しい。それがあると作業が楽である
断っておくと、私は協力会社の方を否定するつもりはない。
おそらく、言っている内容は間違いではない。
ただ単に、意識の差がある。
それだけだろう。
５．ユーザー側はシステムには全く興味がないし、システム開発者（ITエンジニア）の多くはユーザー業務には全く興味がない
官僚気質が強い大企業や、中央官庁などのシステム担当者と話をするとよくわかるのだが、彼らは、システムの事など全くといって良いほど興味がない。
中には、自作PCが好きなどという人も居るが、PCの世界と、システム開発の世界は、また別である。
興味がないという事も、無理からぬ事である。
システムの話は業務のいっかんでついでに覚えられるほど、生易しいものではない。従って、覚えるとなると、相当に頑張らないといけない訳であるが、そこまでして、本業ではない分野を覚えたとしても、2～3年で定期異動になってしまう事を考えると、意義が見いだせないのである。
あまつさえ、システム開発/保守は、アウトソーシングしてしまっている。現場からの問い合わせ業務さえもヘルプデスクとして外注している現状がある。
一方で、本業の業務面はどうかと言うと、これもまた、先に別の記事で書いた通り、支社/支店などの「現場側」に知識が集約される形になり、定期異動でコロコロと部署異動をするため、深い知識はなかなか身に付かないという事になる。
システム開発者の方は、良く言われているように、一般的には、
ユーザー企業 ＞ 大手IT企業 ＞ 中小IT企業 ＞ 中小IT企業 （１例）
…などといった、多重請負構造の中で、どうしても末端近くに位置するエンジニアのユーザー企業に対する帰属意識は希薄となり、それに伴ってユーザー企業の業務への興味も薄れていく傾向がある。
先の別記事にも書いた通り、ユーザー企業の特定分野/特定業務システムの知識を買われて、ユーザー企業や、そこに近いIT企業に誘われて転職する事例もあるのだが…。
しかし、こういった情報は、内容の性質的にも、秘密裏に行われているので、なかなか一般には知られていないのが現状である。
上記のような、「システムには知識も興味もないユーザー側」と、「ユーザー側の業務には興味がないシステム開発者」との、仲立ちをうまく行える人材が、実は最も不足している。
一般的には知られていないが、こういう人材が本当はとても貴重。
花形と思われる「インフラエンジニア」は、実は世の中には数多く居る。そのため、過当競争になっているのである。
６．大手IT企業の人といえども上流工程はなかなか難しいのかな？
上述したような、「システムの事など知らないし興味もない」という人と打ち合わせを数多くすれば、「システム概念図」などのシステム屋がよく作成する資料が、いかに相手に『響かない』かが、わかるだろう。
システム屋から見て、ユーザー業務側の専門資料が非常に難解であるのと同じように、例えば入出力設計書などの、システム屋からすればユーザーにレビューしてもらう対象ドキュメントであっても、それがユーザー側から見れば非常に難解なのである。
例えば元請けIT企業でユーザー側と直接折衝をしている人が居るとして、そういった人は、プログラミングなどは体制的にやらない訳であり、そういった人を小馬鹿にするエンジニアも多くいるが…。
前項で書いたような、ユーザー側とシステム開発者との間を仲立ちする役目を担っているのであれば、それは価値のある仕事であると思える。（一方で、それすらも放棄し、下請けに丸投げしているようなら、たしかに小馬鹿にされても致し方ない）
この役割は、おそらく経験しないと、わからない。
どんなに大手のIT企業のエンジニアだとて、そういった経験がないと、わからないのだろう。
さて…。
上記のような思いを強く思った5月の私なのである。
本当にどうしようかな。
（注１）上記に挙げた業界や業務システムは本当にこの場だけの架空の例です。
（注２）私は航空業界とはいっさい関係ありませんし、専門家でもありません。細かいツッコミもあるかもしれませんが、暖かな目で見てください。
