このエントリーをはてなブックマークに追加LINEで送る

7.6. 要件定義の未来像

ハッピィ・エンジニアリング表紙

 一般的な開発方法論は、開発側の視点で概要から詳細にブレイクダウンしていく方法論である。また、開発方法論は技術者が提唱したものがほとんどである。つまり、SIベンダ自身が理解できる表現方法をユーザに教え込もうとしてきたのである。

 

 SIベンダが主導となり、ユーザに教え込もうとしてきたという点に気がつくと、要件定義に関する手法は、暗黙のうちにシステム屋がユーザに無理を強いることが前提となっていることを認識できる。

 

 上述の要件定義プロセスも、ユーザ企業とSIベンダが合意した要件定義の方法論となれば、過去における「要件定義ごっこ」よりも効果を期待できる。しかし、エンドユーザの主導による要件定義を行うには専門的な要素が多いため、エンドユーザの抵抗感を払拭するのは難しいだろう。抵抗感がある以上、エンドユーザが積極的に要件定義に参加することは難しく、新しい発想を生み出す障壁となる可能性は十分に高い。

 

 歴史的に見て、「正しい要件定義プロセス」が要件定義の本質的な問題解決につながっていないのは明らかである。では、その逆に、ユーザが自分自身の業務をSIベンダに教え込むためのアプローチは取れないものだろうか?

 

 過去の開発方法論を振り返ってみると、エンドユーザが主導で開発を行うアプローチが存在した。俗にいう、EUC(End User Computing)である。ただし、EUCには、

 

  • 基幹業務を補完する機能のみを作り込んだ
  • ユーザが独自に行うため、保守性が低く、担当者の異動や転勤などで改修が不可能になる
  • ごく単純に作られるため、データの共有、高速処理、大量のデータ処理などができない

 

などの弱点が存在した。

 

 しかし、EUCにより、日常的な業務に必要な機能のほとんどを開発した事例も存在し、かつては脚光を浴びた手法であることは間違いない。ただし、要件定義から基本設計に至る開発プロセスを、ユーザ企業とシステム設計事務所の両社が共同で行うのであれば、EUCの優れた部分のみを要件定義プロセスとして利用することが可能になる。

 

 上述したように、EUCで開発するシステムはごく単純化されており、データの共有、高速処理、大量のデータ処理などには不向きである。しかし、業務システムのモデルを作るには、これらの機能は必要にはならない。すなわち、業務システムのモデルを作るには、MicrosoftのExcelのような表計算ソフトやAccessのような簡易データベースソフトが持つ機能で十分だという結論に至る。実際にEUCで開発されたシステムの多くも、これらのソフトウェアを利用して作られている。

 

 簡易な業務処理であれば、表計算ソフトのシートをカスタマイズする程度で作成が可能であろう。ユーザは、Excelの計算ルールや関数を習得すれば、システム屋を媒介せずに、自分がやろうとしていることを、直接コンピュータに伝えられるようになっている。さらに、よくよく考えてみると、表計算ソフトは、オブジェクト指向的な性格を持っている。各セルはデータと関数を持つ。これは、オブジェクトとメソッドに類似している。さらに、計算式のコピーはメソッドの継承をも思わせる機能である。

 

 システム屋は、「表計算で実現できることは限られている」と言いたがるが、実はそれは誤りである。通常のシステムにおいて、表計算では実現できないものは、多数のユーザによる同時アクセスやデータの共有、大量かつ高速なデータ処理、データの二重化、障害時におけるサーバの切り替えなどの、ミドルウェアの機能を取り込んだプログラムだけである。そう考えると、極論してしまえば、システムエンジニアが開発しているものは、システム基盤とアプリケーションをつなぐ部分だけだといえなくもない。

 

 この方法論を実際のプロジェクトに適用するには、いくつかのポイントがある。例えば、

 

  • プロトタイプ開発と同様に、全体最適の考え方が失われやすい
  • ユーザが個々に作成したモジュールを、手作業で取り込んで開発する

 

ことが困難などである。

 

 前者は、業務モデル図を作り、既存の業務における問題点の抽出と新たな業務モデルの作成を行い、新たな業務モデルに合致しているのを確認しながら進めていくことで解決が可能である。

 

 問題は後者である。表計算による要件定義モデルと実際に開発する環境をシームレスに管理するような開発環境の構築が前提となる。要件定義モデルでは表計算や簡易データベースを利用するとしても、データベース部分は実際に利用するデータベースと同等のものを利用するような環境を用意しておく。実際のシステム開発では、同一のデータベース構造を利用して、非機能要件に注意を払いながらフロントエンドのプログラムを作り込んでいくような方法である。

 

 もし、どこかのツールベンダが、このような開発環境をツールとして提供したとしたら、システムエンジニアの仕事から業務の要素が減り、よりシステム基盤に近い部分にシフトしていくのかもしれない。

シェアしてくれると嬉しいです!
このエントリーをはてなブックマークに追加LINEで送る

7.6. 要件定義の未来像 ハッピィ・エンジニアリング関連ページ

7.1. 要件定義の重要性
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
7.2. 要件定義プロセスにおける課題
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
7.3. 歴史的背景
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
7.4. 相互誤解
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
7.5. 要件定義プロセス
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。

ハッピィ・エンジニアリングとは? 書籍を読む プロフィール コンサルティング