要求開発とは、ビジネスを"見える化"し、IT化すべき箇所をできるだけ早く定め、そこに必要とされる要求を決めていく活動ことである。要求開発はビジネス開発と言っても過言ではない。クリエイティブなエンジニアスタイルとして、なぜ要求開発まで踏み込むべきなのか説明しよう。

第4条:要求開発まで踏み込むべし

エンジニアリングを楽しむという事

クリエイティブなエンジニアは、エンジニアリングを楽しむべきである。そしてエンジニアリングの価値を証明すべきなのである。

エンジニアリングを楽しむためには、納得感のあるエンジニアリングを行うことが必要となる。なぜなら納得感があるからやりがいがあり、楽しめるからだ。

さて、エンジニアは、どのような事で納得感を得られるのだろうか?

それを考えるためには、逆に納得感のない状態を考えるとよいだろう。

●納得感のないエンジニアリング
ユーザから出る要求の根拠が分からない。
システム要求の意図がつかめず、プロジェクト管理者に質問してみると「これはユーザと決定した仕様だから」と言われるだけ。しかし、どう考えてみてもユーザに役立つ要求とは思えない。ユーザから出る要求の根拠を聞こうと思っても、ユーザと話す機会などこれっぽっちもない。

更に、エンジニアリングの価値を証明しないかぎりクリエイティブなエンジニアとは言えない。エンジニアリングの価値を証明するためには、システム開発プロジェクトよりも、もっと大きいスコープでエンジアリング価値を評価する方法を知っておかなければならない。なぜなら、エンジニアリングの価値には、将来の価値も数多く含まれており、その将来の価値は、システム開発プロジェクトの開発サイクルの中では評価できないからである。

拡張性・再利用性・わかりやすさとはどのような価値か?

たとえばエンジニアリングによってもたらされる拡張性・再利用性は、システム開発が完了した段階では評価できないものなのだ。なぜなら、拡張性とは、ビジネスの何らかの変化があった際に、システムを拡張するタイミングで、拡張しやすさという観点により評価可能となるものである。また、再利用性とは、システム開発で作成した部品などを他のプロジェクトに再利用できてその価値が評価できるものである。

よって、システム開発プロジェクトの1サイクルの中では評価ができない。その評価は、もっと大きなビジネスの視点で評価されるものなのだ。

また、わかりやすいソフトウエアも、しっかりとしたエンジニアリング知識によってもたらされるものである。

しかし、わかりやすいソフトウエアも、開発中の他の開発メンバーにとってわかりやすいということ以外の価値は、システム開発プロジェクトの範囲外のものとなってしまう。つまり保守フェーズに価値として評価されるのである。

エンジニアリングの価値は要求開発プロジェクトで評価すべし

エンジニアリングの価値は要求開発プロジェクトで評価すべきなのだ。

要求開発でよく使う図を持ってこのことを説明しよう。

図:要求開発

この図は、システム要求の根拠(what)は、ビジネスオペレーションにあり、ビジネスオペレーションの根拠(what)は、ビジネス戦略にあるということを表している。しかし、一般の技術者は、システム要求が(What)で、システム設計や開発が(How)というレベルでしか、システム開発を捕らえていない。

そもそもシステム開発が必要とされる根拠には、ビジネスがあり、ビジネス開発の枝葉としてシステム開発が必要とされるのだ。

このことを考えるとシステム要求はビジネスオペレーションの(How)となる。

つまりは、システム要求も、システム設計も、すべてビジネスオペレーションをどうするのかということが根拠となり、ビジネスオペレーションの変化に耐えられるシステム構築を、エンジニアリングによってもたらさなければならない。

つまり、システムの拡張性・再利用性・わかりやすさというものは、ビジネス開発プロジェクトの視点で初めて評価することができるおものなのだ。 そして、ここで言うビジネス開発とは、要求開発のことなのである。

要求開発方法論とは、この目的(What)と手段(How)の連載を表すZ軸の上位部分を受け持つ方法論であり、この上位の部分にエンジニア踏み込むことで、ビジネス価値を生み出すチャンスが大きくなる。この事を要求開発では、エンジニアが要求開発プロジェクトに入ることで「Howの手探り」が可能となる。また、エンジニアによる「Howの突き上げ」によってビジネス戦略の価値をも高めることができる。

エンジニアは、システム開発の牢屋に閉じこもって要求くれ~と叫んでいても駄目なのである。

イラスト

クリエイティブなエンジニアは、ビジネスを戦場として戦うエンジニアであり、要求開発段階に背伸びしてでも、踏む込む意欲がなければならないのである。

そして要求開発段階に参画し、ToBeの業務の延長にあるITの姿をできるだけ早い段階で見せるように動く必要がある。これが「Howの手探り」という。また、ITの手段によってビジネス戦略の価値を向上させられることをできるだけ早い段階で要求開発プロジェクトチームのメンバーに気付かせる(見える化する)ことが重要となる。これを「Howからの突き上げ」と言う。

このような事ができて初めて、クリエイティブなエンジニアになれるのだ。

終わり