ITシステムを作るには

「ITシステム=ソフトウェア」というのは、間違いです。
ソフトウェアは、ITシステムの一構成要素でしかありません。

ITシステムを構成するのは、以下3つの要素です。

00_01.jpg

この構造は、ITシステムを取り巻く社会的問題、技術的問題を解決するようにうまく機能しています。

システムユーザ

ITシステムが存在する理由は、人々が、ITシステムを利用して、ある目的を達成したいと考えているからです。
その目的が達成されないのであれば、ITシステムがそこに存在する理由はありません。

それが企業であれば、ある目的を達成するため、ITシステムを利用して「業務」を行います。

業務は、人・社会の影響を受け、刻一刻と変化します。
このような状況の中、同じ目的を持った作業を複数の部署、担当者が受け持つ「部分最適化」や、
人的、あるいはITシステムの制約から、目的が達成されない「乖離」という現象が発生します。

また、企業の業務には重要度や頻度というものがあります。
24時間常時止める事のできない業務もあれば、
止まる事が大して害にならない業務、年に一度だけ行えば十分な業務もあります。

このようなビジネス上の要件を踏まえた上で、
業務は、部分的にコンピュータによる自動化を行います。

システムユーザとは、
ITシステムを構成する要素のうち、
コンピュータで行わない「人間側で行う作業を行う者」と定義できます。

ITシステムを作る際には、目的とそれにマッチした業務を明確にし、
品質・コスト・期間の観点から、業務内の最適なシステムユーザ・コンピュータの境目を決定します。

単にコンピュータ上に仕組みを作るのではなく、
人間側にもITシステムが機能するよう仕組みを作る必要があります。

コンピュータと人間は特性が全く異なるので、これを踏まえた上で、
例えばシステムユーザの育成・啓蒙等の活動等も、
ITシステムを動かすための仕組みの一部として組み込むべきでしょう。

コンピュータによる自動化で十分なメリットが得られないようであれば、
人間のみで業務を遂行するという選択もあります。

業務の分析を行ったり、業界の常識を理解し要求を聞き出す作業が主であるため、
業界の知識、コミュニケーション能力が、ここで最も要求されます。

プラットフォーム

コンピュータ技術の進歩と共に、要求のハードルは高まっていきます。

初期のコンピュータはハードウェアのみでしたが、
要求のレベルがあがりそのメカニズムに複雑さが増し、
コンピュータを「ハードウェア」と「ソフトウェア」に層化し、
ソフトウェアを「オペレーティングシステム」と「ユーザプログラム」に層化し、
ユーザプログラムを「ミドルウェア」と・・・、といった具合で、
層化を進めて対処を繰り返してきました。

コンピュータは複雑さが増すほど、類似する処理・機能を多く持ち、
既に作られたことがある部品を再び作ってしまうといった現象が発生します。
この問題を「車輪の再発明」と呼び、部品化して層として扱うことで解決を図ってきました。

今後もしばらく、コンピュータの構成要素を層化するといった傾向を変える事は無いでしょう。

プラットフォームとは、ビジネス上の要件・制約の影響を受けない「汎用的なコンピュータの構成要素」と定義できます。
先述した、車輪の再発明を防止するために層化された部品のことです。

「汎用的」とは表現していますが、それは万能なものでなく、実際に分野ごとに特化されています。
これは、コンピュータの応用分野は広く、その領域ごとに多くの車輪の再発明が起こるためです。

ITシステムを作る際には、業務の分野、利用方法の観点から、
最適なプラットフォームを決定します。

プラットフォームはあくまで部品です。
ツギハギで良いのか、精巧なのが良いのか、頑丈なのが良いのか、シンプルなのが良いのか、
要件に合わせて最適な部品の選別し組み立てる能力が、ここでは最も要求されます。

アプリケーション

アプリケーションは、コンピュータの構成要素のうち、
「ビジネスの要件の影響を大きく受ける部分を表現する要素」と定義できます。
汎用的な部品の集まりであるプラットフォームの上に構築されれます。

コンピュータの技術が進歩し処理能力等の品質が高まるにつれ、
アプリケーションは人間側で行ってきた作業をどんどん吸収していきました。
それが一定の規模になると、汎用化が行われ、プラットフォーム側の機能として吸収されていきます。

近年では、パッケージソフトウェアと呼ばれる、
企業の業務・作業までも汎用化して部品化したソフトウェアが販売されるようになりました。
このようなケースでは、アプリケーションは設定情報の変更のみで完成できます。

しかし、これでは独自性の強い業務を実現できないという問題が残ります。
そこで、モデル駆動開発と呼ばれるアプリケーション開発手法も考案されました。
これは、ビジネスのルール、フローを記述するモデルと呼ばれる専用の記法を用いることで、
パッケージソフトウェアよりも柔軟に、業務要件を吸収できるようにしたものです。

それでもやはり限界があり、未だ業務をプログラミング言語によるロジックで記述する風習は残っています。
OS・ミドルウェアの仕組みを表現するのに向いたCと呼ばれる言語は、
現在の先進したプラットフォーム上で動作させるアプリケーションを開発するのには向かなくなりました。
そこで2000年に入ってからは、Javaと呼ばれる言語が持て囃されるようになり、
アプリケーション開発におけるデファクト・スタンダード(事実上の標準)と呼ばれる地位にまで昇格しました。

今後、プラットフォームの最上位の層である「フレームワーク」がさらに先進し、
より高度に層化がすすめば、その表現方法がJava言語とは合わなくなってくるでしょう。
その際には、さらに別の表現方法が生まれ、新たな考え方も開発されることになるはずです。

ITシステムを作る際には、業務の特性の観点から、最適なアプリケーションの調達方法を決定します。
プログラミング言語等を用いてアプリケーションを開発できるという特性から、
柔軟性が非常に高く、色々なやり方が考えられます。
このため、一概にどのような能力が必要とは言い切れないようです。


  • 最終更新:2010-05-21 23:55:56

このWIKIを編集するにはパスワード入力が必要です

認証パスワード