PR

 筆者は開発ベンダーのSEである。約10年間にわたって,現場で様々なシステムの開発に携わってきた。近年,「ITで実現できること」の範囲が広がり,開発テーマや取り組むべき課題が多様化している。加えて,ビジネスからの要請でシステム構築にスピードが要求されることも多い。われわれ中堅SEに求められているのは,もはや「ものづくり」の能力だけではない。プロジェクト・マネジメントや課題を「見える化」し適切に要件を定義する能力など,幅広いスキルが必要とされているのである。

 こうした外部環境の変化と,本当に「役に立つ」システムを構築したいとの意識から,筆者は約1年前から要求開発アライアンスに参加するようになった。要求開発アライアンスでは,従来のシステム開発の領域から一歩上流に踏み出し,ビジネス要求に基づいてシステムの「あるべき姿」をロジカルに導き出すための方法論「Openthology」を策定している。もっとも,筆者自身はOpenthologyの策定というより,方法論を学び,実業務で活用する立場にある。以下では,「現場で使う」という観点で,Openthologyを紹介していきたい。

「使われない」システムができるのは要求定義に問題がある

 これまで開発に携わったプロジェクトの中には,いくつか結果が不満足なものがあった。プロジェクト自体は完了したものの,出来上がったシステムが使いにくかったり,期待したほどの効果が得られなかったりしたのである。結果,完成後も様々な機能追加をする必要に迫られることもあれば,すぐに別のシステムに取り込まれてしまうこともあった。システム開発プロジェクトとしては何の問題もなかったのに,だ。

 ものづくりに携わるエンジニアとしては,やはり自分の作ったシステムが長く使われ,ユーザーのビジネスに貢献してほしいと思うものである。しかし,いくらシステム開発の技術やプロジェクト・マネジメントを学んでも,「何かが足りない」という気がしていた。ちょうど30代に差し掛かったころだったこともあり,「これがエンジニア35歳定年説の壁なのか?」と悩むこともしきりであった。

 いったい何が原因なのか。これまで携わったプロジェクトでは,程度の差はあるにせよ,いずれもユーザーと打ち合わせを重ねながらシステムを作っていた。「システムで実現しなければならないこと」をユーザーと煮詰めたうえで,要件定義書や要求仕様書といった名前の文書を作成し,ユーザーの承認を得たうえでシステム開発を開始していた。

 しかし,このように要求仕様書に記載されている事項をきちんと実現しても,「使えない」システムが出来上がることもある。これはつまり,要求定義の段階で何らかの問題が生じているということだ。定義の方法がいけないのか,技法に問題があるのか。それとも,単なる参加者のスキルの問題なのだろうか・・・?

要求は開発・テスト・評価するもの

 こうした問題に直面しているときに,要求開発アライアンスに参加し議論を拝聴するようになり,そこで一つの解答を得ることができた。そもそも,要求開発アライアンスは「情報システムに対する要求は,最初から存在するものではなく,ビジネス価値に基づいて『開発』するべきものである」というコンセプトのもとで活動している。さらに,システムと同様に「開発した要求」はテスト・評価するべきとも考えている。このテスト・評価については,最新のOpenthology Ver 1.0では,PDCA(Plan,Do,Check,Act)プロセス・キャビネットという形でまとめられている。

 これまで筆者が携わったプロジェクトでは,主に実現すべきユーザー要求のうち,システムにかかわる個所を明確にするだけで,本来システムが達成すべきビジネスのゴールに関してはあまり詳細化しないことが多かった。また,ユーザーの意をくむべくヒアリングを重ねた結果,要求仕様が膨れ上がってまとめきれず,時間切れで開発に着手したケースもあった。Openthology Ver1.0の特徴であるPDCAや段階的詳細化をプロジェクトに適用すれば,こうした点が解決されるはずである。

 とはいえ,実際のプロジェクトにOpenthologyを適用する場合には,既存の方法論とのすり合わせをはじめ,様々な問題が発生する可能性がある。次回は,現場でOpenthologyを利用する際のコツについて,筆者の経験を基に述べてみたい。

(石沢 健人=要求開発アライアンス執行委員)