このウインドウを閉じる

Take the rough with the smooth.

 
● SE は、業務戦略 (operational な仕事に対する手順・統制) に関与する。

 拙著「IT コンサルタントのスキル」のなかで、僕は、IT コンサルタントを、以下の2つに切り離しました。

 (1) IT に関するコンサルタント
 (2) IT を使うコンサルタント

 「IT に関するコンサルタント」は、、IT そのものを直接の対象とします。すなわち、新しい IT が出てきたら、その IT が、どのような設計思想を前提にして、どのような構造 (mechanism) になっていて、どのように使えば良いか、という点を探るのが、「IT に関するコンサルタント」の仕事です。

 いっぽう、「IT を使うコンサルタント」は、IT そのものを直接の対象としてはいない。「IT を使うコンサルタント」は、事業戦略のなかで、IT を役立てることを考えるのが仕事です。したがって、「IT を使うコンサルタント」は、IT そのものに関する知識よりも、事業に関する知識のほうが豊富でなければならない。

 同じような類型が SE とプログラマの関係にも適用できるでしょう。
  SE が、事業戦略に関与することは、まず、ないと思うのですが、 SE は、業務戦略 (operational な仕事に対する手順や統制など) に関与するので、業務知識がなければならない。いっぽう、プログラマは、コンピュータ言語を使うので、言語のシンタックスやデータベース・プロダクトの特徴や通信のプロトコル構造について、知識がなければならない。

 
● SE は、構成的な思考と解析的な思考を体得していなければならない。

 会計学・生産管理・経営学・マーケティングなどの書物を読んで得られる知識は、「通論」の入門的な知識であって、それぞれの企業に対して、そのまま、当てはまる訳ではない。「通論」の入門的な書物を読んでも、実地に使われている詳細な手続きに関する知識を得られる訳ではないので、「通論」の入門的な書物を読んで得られる利点は、「体系」を知ることができる、ということでしょうね。逆に言えば、「通論」の「目次」を、まず、鳥瞰して、「目次」のなかに記述されている領域を、網羅的に知っているかどうか、という点を検証すればよいでしょう。入門書のなかに記述されている程度の知識を体系立って習得していなければ、およそ、システム的に考えること (全体と個々の関連を構造的に観ること) ができないでしょう。「通論」の知識というのは、実地の仕事に適用するとき、構成的な思考として作用します。

 現状を調査して、改善案を提言して、改善案をシステム設計として具体化するためには、「通論」の知識を、網羅的・体系的に習得しているいっぽうで、現状を、正確に、知らなければならない。現実の仕事 (手続き) には、劇的な労役などない--すべては、退屈なくらいにルーチン化されている。良い組織というのは、ルーチン化されている勤労が営まれている静かで穏やかな組織である。したがって、ルーチン化された手続き体系を、改めて、最初から やり直して記述しなければならない、というようなことは、まず、ない。
 逆に言えば、そういうルーチン化された手続きのなかで使われているデータ (情報) を、ひとつの取りこぼしもしないように拾って、手続きが、どのように、計画・実行・統制 (事前報告・進捗報告・事後報告) されているのか、という点を正確に記述しなければならない。現状を記述することは、構成的に考えるよりも、解析的に考えることです。

 ルーチン化された仕事の安定さが、往々にして、単調さになってしまい、制度 (システム) が形骸化しそうになったとき、制度 (システム) を再構築して、活性化することもあります。

 正確に記述された現状を、「通論」の体系と対比して、体系的な類似点・相違点を確認して [ 相違点が、「勝ち点」なのか、非効率な点なのか、という点を確認して ]、現時点の事業を計画・統制している情報体系が、環境の変化に対して、対応できるのかどうか、という点を判断して、ユーザの提案を、コンピュータ・システムを使って、具体化することが SE の仕事でしょうね。したがって、 SE は、通論の「構成的な思考」と、現状記述の「解析的な思考」を体得していなければならない。

 「構成的な思考」と「解析的な思考」という対比から導かれる結論は、「連続」と「変化」を理解しなければ、システムを効果的に作ることができない、ということでしょうね。しかも、「制約された合理性」のなかで、情報の ありかた (改善案) を判断しなければならない。

 
● モデル志向も現場主義も、それぞれ、一理あるが、いずれかのみでは、
  無力である。

 つまらない退屈な仕事も大切な仕事も、同じように、制度のなかで営まれているのであって、モデル技法に対して関心を示す SE は、往々にして、抽象化された構造のほうが、ささいな事実の蓄積に比べて、「工学的」であるという勘違いをしているようですが、ネジの1本も疎かにしないというのが、設計図の正しい考えかたであるべきです。
 いっぽう、「現場主義」とか「経験主義」というのは、かなり特殊な いくつかの事実を性急に一般化した やりかた であって、なじみぶかい環境のなかでは、そういう やりかた は、ときどき、成功することがあるけれど、環境が変わって、いままでの習慣・技術が適用できないときには、ほとんど、無力でしょう。

 (業務戦略は事業戦略から導き出されるので、) 業務戦略に関与する SE の仕事というのは、新しい事業を提示するのではなくて、事業のなかで、いまも、継続して使われているが、環境適応力を喪った古い情報を、環境に対応するように改善して、改善された情報を1つのシステムとして統制することです。
 そのためには、網羅的・体系的な「通論」の知識と、現状を正確に記述する技術を習得していなければならない、ということです。「モデル志向」も「現場主義」も、それぞれ、一理あるけれど、いずれかのみでは--あるいは、いずれかが偏って つよい、というのでは--、SE として落第だ、ということです。「通論」の知識を、体系的に、多くの量を習得して、現状を記述する技術を、高い質にて体得して、そのいずれも、「拮抗」して調和していなければならない、ということです。

 
 (2004年5月1日)

  このウインドウを閉じる