システムエンジニアに業務知識が必要かとか、必要だとすればどの程度必要かといったことが時々話題になるが、これは、問題設定自体が、間違っているとは言わないが、面白くない。
業務知識があまりなくてもそこそこメシを食っているSEだってたくさんいるわけだから、上記のような問題設定をすれば、結局、下限を見極めるという方向にしか話が流れない。いやいや、業務知識がなくたって業務分析力とか問題発見と解決能力があれば良いのだ、といったところに行きつくのがオチだ。この結論はたしかに真実を含んでいる。実際、ある分野で深い分析や問題解決をした経験は、他の分野でも応用が利く。しかし、そこに話を落ちつけたところでその先が無い。地頭がいい人は何やらせても頭いいよねということを再確認できるだけ。だから面白くないというのだ。
必要かどうかじゃなくて、情報技術や色々な分析メソッドを身につけた人がさらに業務知識を取り込むことによって何が生まれるかを考えた方が楽しくないか？
IT分野で培われた様々な図法やその基礎にある思考法は（色々な点で今後も改善の余地はあるにしても）よく出来ている。これに対して多くの業務知識分野の専門家は、自分たちの仕事を組織だったやり方で体系化したり抽象化する訓練を受けていない。僕の主な仕事の領域は会計だが、その分野の研究者が書いたものを読んで、ああ、この人がデータモデリングの素養を持っていたらもう少し違った分析をしていただろうに、鋭い点をついているのにもったいないなあと感じることが何度かあった。
多くの業務分野の基礎となっている概念や慣習はITが成立する前の時代に形成されてしまっている。IT導入の初期にはあまり難しいこと考えず、手作業を機械処理に置き換えれば劇的な効果が得られた。しかし、現在では、（特に業務システムでは）ほとんどのシステム構築は再構築である。この場合、業務モデルを変更せずに技術インフラを置き換えただけでは十分な効果を得にくい。従来の業務の基礎にある概念や慣習を見直し、ITという新しい道具だてのもとで組み立て直すという作業が、程度の差はあれ、必要である。
僕が言っているのは別に新奇なことじゃない。MRPやSCPはたぶんこういった変化の顕著な例だと思うし、会計のような比較的保守的な分野でもダイレクトインプット（伝票レス化）のような変化があった。
プロジェクトの初期段階でこのような検討を行うことはもちろん重要だが、こうした見直しの契機となる「気づき」が、そのタイミングで都合よく降臨してくれるとは限らない。こうした気づきには、たぶん、業務分野に精通した人とIT分野に精通した人の間での、非常に密で（お互いが相手の分野に深い理解を得るほどに）、かなり長い期間にわたる断続的なコミュニケーションが必要だ。あるいは、両方の知識を備えた一人の人間が、ありうべき業務の姿について持続的に考え続けることが必要だ（この場合でも複数のこういう人々が含まれている方が良い）。
システムエンジニアが業務知識を興味を覚えたならば、二つ目の道の入口に、少なくとも立ったことになる。
この半世紀の間、情報技術は長大な進歩を遂げた。僕らの仕事のやり方や慣習はそれに追いついてない。とりあえず目につくところに使ってみただけだ。キャッチアップの道は長いだろう。今後数世紀にわたって続くかもしれない。こうした考えは楽しくはないだろうか？ 僕らはまだその道の入口をほんの少し入ったところにいると考えるのは。
