最近のエンジニアはエンジニアリングを楽しむことをしていないように思う。なんとなくの感覚であるが、狭い鳥かごに入れられて周りを見ずに開発をやっているようにも思えるのである。

これでは、ビジネス価値を高めるソフトウェア開発などできない。もちろん、優秀なエンジニアは、そのような表現には値しないだろう。しかし、多くのエンジニア達がそのような鳥かごに入っているように思えてしまうのだ。

これを解消するためには、ソフトウェアエンジニアのクリエイティブ力を高められるようなエンジニアスタイルを確立すべきだ。

そのようなクリエイティブなエンジニアスタイルとはどうあるべきなのか、ここでそのイメージについてみなさんと共有するために、ここにクリエイティブなエンジニアスタイル5カ条を定義する。しかし、開発プロセス同様に、定義した日からこの定義は改善されるので、1か月後には進化しているかもしれない(笑)。

さて、ここからそれぞれの説明を進めていくことにしよう。

第1条:納得感のある開発手法を身につけるべし

そもそもITエンジニアは、現代の匠になるべき。しかし、残念ながら現在のソフトウェア開発は多くの人が過去の職人気質を捨て去り、サラリーマン化しすぎてしまい、ビジネスの価値を高める最適なソフトウェア開発の姿を自ら描くことをしていない。

ソフトウェアエンジニアは過去の職人気質を取り戻す必要がある。

ただそれだけではなく、西洋のマイスターのように尊敬されるためにも、ビジネスとITを繋ぎ、ビジネス価値を高めることができる人材になるべきなのである。

その為には、まず納得感のある開発手法を身につけるべきだ。しかし、サラリーマン化したエンジニア達は、ソフトウェア理論を習うことだけ行い、自らそれを咀嚼し改善を加えようとしていない。その結果、開発手法はまったく洗練されていないのが現状である。

1.納得感のある開発プロセス

たとえば、いまだにウォータフォール開発を行っているプロジェクトが存在する。オープン系の開発においては、ウォータフォール開発はリスクマネジメントができない楽観的なプロセスなのである。このリスクマネジメントの代表的なものとしては「検証された要求」と「検証された設計」をできるだけ早く獲得することである。

メインフレーム時代とオープン系のマネジメントが大きく異なるのは、この2つのリスクマネジメントを利かせる必要性にある。残念ながら、このことを理解せず開発プロセスを管理しているマネージャーや開発者が多い。

この2つのリスクマネジメントの意図を持って反復を計画すべきであるが、それを行うことをしないウォータフォール開発では、最大のコストを使ってプロジェクトを成功させているか、失敗プロジェクトとなるだろう。しかし、最大のコストを使ってプロジェクトを成功させている場合、問題が表に見えてこないケースも起こりうる。なぜならば、人月見積もり段階から最大のコストを見積もり、それに合わせて管理するからである。

そして、かなり遅れつつも予定通りプロジェクトは完了し、開発マネージャーは見積もり制度が高まったと勘違いしている。

もちろんこのやり方は、ビジネス価値とは遠いところにあるプロセスなのである。このようなケースは大企業や政府においてベンダーに開発を丸投げているような場合など顕著に現れる。

これを解決するには、何らかの反復によって「要求の曖昧さ」と「設計の不確実さ」を検証する方法を導入すべきてあり、それは反復開発に移行せよというような表面的なことではないのである。

あるいは、RUP(ラショナルユニファイドプロセス)などの反復プロセスを実践している企業の中には、目的に合わせてテーラリング(カスタマイズ)せず、そのままの形状で実践してしまい、マネジメント工数が増大し要求が整理できず、設計もうまくいかないプロジェクトが多くある。反復すれはするほど、マネジメントコストは多くなり、テスト回数も増え、要求の獲得も増えるためマネジメントが難しくなるのである。この問題をどう解決するか、それはやはり反復の型を破った新たな開発プロセスを獲得すべきなのだ。

また、アジャイル開発プロセスも果たしてビジネス価値を高める開発につながっているだろうか。管理志向の強い従来のプロセスのアンチテーゼとして誕生したような感のあるアジャイル開発は、ウォーターフォール開発や反復開発よりもエンジニア達からの評判はよい。僕もそういう意味では非常に素晴らしい考え方であると思っている。しかし、ユーザのビジネス変化に耐えられるシステムの見える化ができるのであろうか?また、ビジネス戦略に基づいたシステム戦略の見える化をせず、一人の顧客から要求を聞きだすオンサイトカスタマーのやり方は、俗人かされた要求を実現したり、レアケースのシステム化に繋がることはないだろうか?

つまり要求開発の領域に踏み出すことが、アジャイル開発の次なる発展が望まれるのである。

2.ユースケースモデルに納得感があるのか?

また、UMLベースの開発手法であるユースケースモデルは、本当に有効に活用できているのだろうか?僕は現状のユースケースモデルは開発で使うべきではないと考える。本来は、ソフトウェア開発の前段階、たとえば要求開発で使うべきものなのだ。

ユースケースモデルは、ビジネスの視点でシステムの利用事例を整理するべきものである。しかし、現状では、要求(ユースケース)からユースケース記述、そしてロバストネス分析、そこから分析(概念あるいはドメイン*注)モデルといった経路で設計につなげていくために、いつの間にか開発者の視点でユースケース記述を書いてしまっている。

ここに第一の問題が存在する。つまり意識的にはユーザとのコミュニケーションのために書いているドキュメントが、実際には開発者のために書かれており、挙句の果てには、開発者もユースケース記述で書いている要求の本質を見失ってしまうことも多い。

さらに第二の問題として、ユースケース記述のようなイベントフロー(文章シナリオ)的な記述から設計に導き出す方法は、方法論提唱者のエゴだと言える(実は僕も経験がある)。つまり理論的で綺麗に流れるし教育的にも有効であるが実践的ではなく、多大なコストも必要とされる。さらに、その結果としての分析モデルの品質は悪い。なぜならバラバラに作成されたロバストネス図を統合して分析モデルを作成することなど、非常に難しい作業となるからだ。つまりは投資コストに見合わない品質の分析モデルを作ってしまう。

*注 分析モデル:ここでは、ソフトウェア分析として作成されるクラス図の事を言う。すなわちビジネスやソフトウェアの概念を表すモデルとして概念モデルと呼ばれたり、ソフトウェアの対象(ビジネス)を表すモデルとしてドメインモデルと呼ばれたりしている。

3.分析モデル(概念またはドメインモデル)の有効性

更に第三の問題として、ロバストネス分析の結果、完成される分析モデルの有効性である。このことをエンジニアは、納得がゆくまで考えたことがあるだろうか?

少なくとも現状のWebを利用したビジネス系開発は、分析モデルは「理解のモデル」でしかない。なぜなら、設計モデルはフレームワークや実装コンポーネントとして既に料理を載せるお皿のように存在しており、そこに分析モデル(料理)を適合するために変化させる必要がある。設計モデルはフレームワークや実装コンポーネントが完成されればされる程、その変化は激しくなる。よってスクラッチから開発していた時代と比べると、分析モデルは設計モデルに繋がりにくいのだ。だからこそ、分析モデルは「理解のモデル」として輝かせ保管しておくのが有効なのだ。

それなのにロバストネス分析の結果作成される概念モデルはシーケンス図などを使って精密に設計されるのである。そんな箱庭の世界を動かして何の役に立つのだろうか。

設計モデルは、「理解のモデル」に加えて「実装責任を負うモデル」でもある。これは抽象化と具現化という、相反するアプローチの両立させるバランス感覚が必要とされる。このような性質の設計モデルを理解させるためにも、ユーザと開発者の理解のモデルとしてシンプルな分析モデルを維持しておく必要性がある。さて、そのような分析モデルはどうやって作るべきか、それは、ユーザとビジネスを理解する局面(たとえば要求開発)で、時間をかけずにサラリとクラス図を書くという方法がある。このことはもっと詳細を書きたい部分であるが、それは読者が納得するまで問題を追及して自ら発見することを期待しよう

このように、もっと実施する作業について、結果として役立つ領域を明確に持つべきだ。そのようなことをしっかりと考え、チームの中で手法として確立させる、それが納得感のある開発手法を身につけることにつながるだろう。

エンジニアリングを楽しむためにも、みなさんと一緒に、これらの課題に対して楽しみながら取り組んでいければと思う。