ITアーキテクトの要求開発力向上作戦

　私が要求開発やコンサルティングなどを行っているとき，UMLのクラス図によるモデリングについてよく聞かれることがあります。それは，「どうやったらモデリングが上手くなりますか？」という質問です。

　そうした場合，私は「プログラムを書いたらいいですよ」とか「モデルを理解するためにも，プログラムを書いてみましょう」といったたぐいのことを，よく言います。

　しかし，こう回答すると，とても嫌な顔をされることがあります。「実装はプログラマのやることだろ」とか「プログラムを書かずにうまくなれないですかね～」などと言われたりします。確かにTFP分割によるモデル図などは，ユーザー系の方でも「読めたり」または「書けたり」するので，プログラミングまでする必要はないかもしれません。

　誤解のないよう，ここで要求開発に携わる人の役割を定義しておきましょう。ビジネスユースケースや要求ツリー，業務フロー，TFP分割図（読み書きレベル）ならば，図1の業務アーキテクトで十分作成することができます。

図1●要求開発に必要となるロールとスキル

　業務スペシャリストはユーザー部門であり，情報システム部門は，部門のポリシーによっても異なりますが，業務アーキテクトとITアーキテクトの両方の能力を持っていることが望ましいと思われます。ベンダーで要求定義を行う人は，業務アーキテクトとITアーキテクトを兼務している人材と定義できます。

　もし，情報システム部門で「うちの部門は業務アーキテクトのみに特化する」と決めた場合は，要求開発フェーズでITアーキテクトの助けが必要になるでしょう。

　今回の記事は，ここで定義するITアーキテクトの能力を持っている人に関する意見です。具体的には，一般的な情報システム部門の方，ベンダーで要求定義を担当している方，要求開発コンサルタントになろうという方です。

　そうした方々が，「手っ取り早く上手くなる」または「上級のモデラーになる」ための近道は，「コードを書く」ことだと私は思います。

　私の周りの上級モデラーはみな，SmalltalkやJava，Rubyなど，何らかのオブジェクト指向言語を使って，コードを“上手く”書くことができます。“早く”書けるわけではありませんが，“きれいな”コードを書けます。

　ときどき，モデラーが書いたモデル図を見て「ちょっとそれは違うんとちゃうかな？」と私が思う人は，たいていオブジェクト指向言語でオブジェクト指向らしいコードを書いた経験のない人が多いようです。逆に，現場のバリバリのプログラマの中には，モデリングがとてもうまい方をよく見かけます。

　もちろんプログラミングさえやれば，モデリングが上達するというわけではありません。しかし，コードを書くことの重要性があまり理解されていないようなので，ここではその点を強調したいと思います。

要件定義の実情

　要求開発をした後，最終的にはアプリケーションのコードを作ります。そして結局のところ，成果物としてはアプリケーションのコードが一番大切です。

　例えば，あなたが誰かに作曲を依頼するとしましょう。「私は楽器はいっさい弾けないし，わからないけれど，作曲できますし，楽譜なら書けますよ」と言う人に，作曲を依頼したいと思いますか？

　しかし，要件定義などの現場では前述のような場面に出くわすことがあります。「業務さえ知っていればええんや」というマネジャや担当者が，最新のアーキテクチャやデータ・モデリングについて何も勉強せずに要件定義をし，画面仕様やデータモデルを決めることもよくあります。

　そうするとどうなるか？ オープン系のWebシステムでRDBMSを使っているのに，ホストでフラット・ファイルを使ったプログラムのような仕様になってしまい，要求定義以降のフェーズで開発現場が大変になったり，成果物の保守性が極端に悪かったりといった状態になります。

　「要求開発や要件定義に，業務知識は不要だ！」と言いたいわけではありません。それはもちろん重要なことです。要求定義は，システム化する要求を定義する行為なので，ビジネスとITをつなぐ能力が必要です。当然ながら，このフェーズに携わる人は，ビジネスとITの両方の知識が必要になります。

　しかし，現実に要求定義をする方の中には，ビジネスの重要性ばかりが強調されるあまりに，ITの知識の重要性を軽んじている人がいるように感じます。

プログラミング力が必要な理由

　では，なぜモデリングが上達するために，コードを書かなくてはいけないのでしょうか？ 概念モデルなどは，あくまで「業務」をモデル化したものなので，理屈上は，コードなど全く関係ありません。普通にモデルを読んだり書いたり，あるいは議論するだけのレベルなら，コードを書けなくても問題ないでしょう。

　当然ながらITにかかわらない人に「コードを書け」と言うのは理不尽でしょう。TFP分割などは，そういった方でも業務の静的構造をモデル化できるようにできています。また，業務フローやビジネス・ユースケースは，コードは関係ない領域です。

　しかし，モデラーになりたいというのであれば，本質的にオブジェクトやクラスとは何か？といったことを深く理解しなくてはなりません。例えば，データベース・モデリングがうまくなるためには，関数従属性や識別子，エンティティ，関連の考え方などを学んだり，実際のデータがどんな構造になるかをイメージできることが大切です。

　それと同じように，オブジェクト・モデルでは，モデルの対象が「オブジェクト」なので，「オブジェクト」がどんなものかをイメージできなければなりません。とはいえ，「オブジェクト」と全く同じものは世の中には存在しません。世の中にある事象を「オブジェクト」としてモデル化したものは抽象化されており，情報が抜け落ちています。「モデル」を理解するときには，「モデル」の対象の具体的なものを想像できることが重要なのです。

　では，「オブジェクト」の具体的なものとは何でしょうか？ 「オブジェクト」は，オブジェクト指向言語のプログラムの中に出てきます。したがって，「具体的なもの」を体験するには，プログラムを書くのが一番手っ取り早いのです。

　コードを書くといっても，現場のプログラマみたいにバリバリ書くわけではありません。「概念を理解するために」書くだけなので，そんなにたくさん書くことも，細かいAPIを理解する必要もないのですから，気軽に取り組めばいいと思います。

　最近のメジャーなオブジェクト指向言語の中では，「Ruby」が一番純粋にオブジェクト指向であり，しかもかなりとっつきやすいので，大変お薦めです。

パラダイムの理解

　要求開発や要件定義に携わる人がコードを書くことのメリットは，ほかにもあります。例えば，パラダイムの違いを理解できることです。

　かつてCOBOLプログラムを書いていた方々は「昔コード書いたことがあるからもうええ」と思われるかもしれません。しかし，現在のオブジェクト指向言語は，構造化言語とはかなり違うところがあります。根本的なデータ構造や「良いプログラム」の考え方，プログラムを分けるときの考え方，関数に相当するものの考え方，設計の仕方などがずいぶん違います。

　今後も，これまでとパラダイムが異なる言語が登場してくるでしょう。メジャーになりそうな新しい言語は，積極的に触れてみましょう。簡単に体験するだけでも，かなりイメージしやすくなります。

　加えて，良い要件定義（ここでは要求開発フェーズが終わり，その後の画面仕様を作っているなどを想定しています）のためには，現在主流のアーキテクチャを理解するためにも，言語を体験しておくのがよいと思います。

　例えば，Webアプリケーション開発でStrutsのフレームワークを使っている場合，画面仕様例1（図2）と画面仕様例2（図3）では，どちらのほうが工数がかからないでしょうか？

図2●画面仕様例1。画面遷移する仕様

図3●画面仕様例2。1画面に収める仕様

　これらは，どちらも同じ内容の業務で，ヘッダー/明細タイプの画面です。画面仕様例1では，年月を選択してボタンを押すと，その内容が表示される仕組みになっています。明細の入力は，1明細ずつ別画面になっています。

　一方，画面仕様例2でも，年月を入力すると自動でデータが呼ばれて表示されます。ただし，項目間はTabキーで移動できます。また，ヘッダーと明細が1画面にあり，明細部分はスクロールすることができます。

　ご存じの方には当たり前のことですが，これは画面仕様例1のほうが，工数的にも保守性の点でも圧倒的に楽です。実際のアプリケーションでは，ユーザービリティの要件もあるので，一概に画面仕様例1にすべきという話ではありません。しかし，要求定義者としては，要求の取捨選択や優先順位付けをするにあたり，「この仕様だったら楽だ」とか「これは実装が難しい」といったことを知っておく必要があります。

　こうしたことは，採用しているフレームワークやアーキテクチャで変わるのです。もう一つ，例を見てみましょう。

　日報のような業務で，カレンダーの画面を選択すると，日報の入力画面に遷移する画面仕様例3（図4）と，日報の入力画面のところでカレンダーのポップアップを出す画面仕様例4（図5）の二つでは，どちらが開発が楽でしょうか。

図4●画面仕様例3。カレンダ画面選択

図5●画面仕様例4。ポップアップ・カレンダー選択

　これも採用するツールやフレームワークで異なるかもしれませんが，たいていは画面仕様例4のほうが工数的にかなり楽です。図5のような小さなポップアップは，すでに部品が世の中に出回っているからです。しかし，カレンダーに会社独自の休日なども考慮したいといったとたんに，そのポップアップ（部品）が使えなくなったりします。

　このように上流工程といえど，上達するためには，実装やアーキテクチャや言語と無縁ではいられません。すべてのアーキテクチャやツールを試す必要はありませんが，例えば，Webアプリケーションの要件定義をするのならば，Webアプリケーション開発のアーキテクチャをとりあえず一つ体験しておくのがいいでしょう。

Ruby on Railsはオススメ

　昨今，Webアプリケーション開発では，とてもいいものが出てきました。それは，Rubyという言語で書かれたRuby on Railsというフレームワークを使った開発方法です。とりあえず作ってみるという程度なら，Javaのフレームワークより何倍も簡単にWebアプリケーション開発を体験できます。本当に何も知らないレベルでも，1時間もあれば一通りWebアプリケーションを作れます。

　Ruby on Railsに関する記事は，ITProをはじめとしてたくさんあるので，ここでインストール方法などは説明はしませんが，ぜひ体験されることをお勧めします。Rubyという言語は使っていて大変「楽しい」言語です。オープンソースですから入手するのにお金はかかりません。最近プログラムに触れていないという方も，久々に体験してみてはいかがでしょうか？ きっと要求定義のスキルアップに役立ちますよ！

　しかし，「それはわかるが，ほかのことを勉強しなければならないので，アーキテクチャや言語まで手がまわらない」という方でも，道はあります。アーキテクチャに強い人をブレインにして，要求開発や要求定義の体制を作るときに相談できる程度の工数を確保しておくことです。

　要求開発や要求定義などの上流段階で，技術系の人をアサインすることは少ないかもしれませんが，要求定義と並行で開発標準を作っているケースはよくあると思います。だから，要求開発や要求定義をするときに「こんな仕様を考えたけど，技術的にどうなん？」などと相談して教えてもらえばうまくいくと思います。

概念と実装とを行き来できるか

　音楽プロデューサは，曲をプロデュースするときに，最終形がこうなるというイメージを作れることが重要だそうです。同じように上級のモデラーは，最終的にどう実装に落ちるかをイメージでき，抽象と具象の世界を行き来できる能力が必要です。

　私は常々，プログラミング能力というのは低く見られがちだと思っています。プログラムは誰でも書けるという話がありますが，それは甘いと思います＊1。

＊1 記事の上部でコーディングを勧めていますが，ここでは甘くないと記述しています。この意図は，オブジェクトやアーキテクチャを理解するためのコーディングは気軽に取り組めますが，現在の言語で製品版のコードを保守性や拡張性も考慮しながら作成できるためには相当のスキルが必要という意味合いです。

　その話は，実際は「保守性や拡張性などをまったく考慮しなければ，誰でも書ける」に近いと思います。つまり，少なくとも保守性や拡張性を求めるアプリケーションを書くには，それなりに優秀なプログラマが必要なのです。それは，分析や設計などでどうにでもなるという問題ではありません。

　仮に「誰でも書けるレベル」まで設計をしてしまうと，結局プログラムを書いているのと作業量的には変わらなくなります。その場合，プログラムは簡単に修正できるけど，一緒に大量のドキュメントを修正しなければいけないという本末転倒な結果を招きます。

上流と下流という言葉

　私は，大手ベンダーのSEやPMを経て，現在は要求開発のコンサルタントをしています。上流やマネージメントに携わっていると，ときどき「上流は難しいが，下流は誰でもできる」と考えているような雰囲気を感じます。

　私の意見では，プロとしての仕事を求める場合，プログラミングも要求開発やプロジェクト・マネジメントと同レベルの難しいスキルだと思っています。実際に海外では，歳をとった人が一流のプログラマ兼コンサルタントとして活躍されています。なかには，業界の動向を左右するような影響力を持った人もたくさんいます。

　また，上級レベルになると，プログラマも要求開発をする人も必要な知識体系は変わらないと思います。ただ，その人の軸足がどこにあるか？ どの知識エリアにより詳しいか？という程度の違いだと思っています。

　だから，「上流」「下流」という言い方では，どうも「上流」のほうが言葉として高級な感じがするので，もっと違う言い方がいいんじゃないかと考えています。

　プロジェクトでは，それぞれ異なる得意エリアを持ったメンバーがお互いを尊敬しあい，補いあいながら協調して，「プロジェクトの成功」というゴールに向かって行く姿が望ましいでしょう。これもまた，コタツモデルの一つのあり方じゃないかなと思います。

　なお，今回の記事は要求開発アライアンスの意見ではなく，筆者個人の考えであることをお断りしておきます。

（牛尾 剛＝要求開発アライアンス）