要求開発の心得

要求開発の心得 -プリンシプルとプラクティス-

ここでは、要求開発の心得となるプリンシプルとプラクティスを説明します。
プリンシプルとプラクティスは、要求開発方法論ver0.6で説明されているものであり、僕がお客様と一緒に要求開発を行ってきた際に、重要視していたことをまとめたものです。

要求開発方法論(Openthology)5つのプリンシプル

1.ビジネス主導によるIT化 業務の姿にITを合わせる
2.効果検証型プロセスの導入 最低1ヶ月に1回はモデリング効果を検証する
3.検証可能なビジネスモデル 概念モデルをビジネスフローで検証する
ビジネスフローをプロトタイプで検証する
4.ビジネス担当主導のビジネスモデリング重視 現場のビジネスナレッジを重視したボトムアップアプローチ
5.フレキシブル・ビジネスモデリング スピーディかつ状況に応じてビジネスモデリングを行う

5つのプリンシプルはしっかり守ろう

それでは説明していきましょうね。

1.ビジネス主導によるIT化

最初の「1.ビジネス主導によるIT化」とは、まずは、IT化ありきで進んでいるプロジェクトのビジネスの姿を描いてから、その姿に適したIT化を図ることです。
要求開発を行う上では、IT化プロジェクトではなく、ビジネス開発が先にくることが多いのです。もちろん、ビジネス企画や業務はまったく変えずにIT化という道もあるでしょうが、少なくとも、ITを導入した際のビジネス価値を事前に検証し確証を持つ必要がありますよね。
私たちITエンジニアは、IT開発ありきですべての要件を決めてしまいがちです。しかし何もIT化だけがビジネス価値を高めたり、コスト削減に繋がったりするわけではないのです。
従って、要求開発実践者としては、ビジネス主導でIT化を考え、もしIT化が必要なければ別の案も出せるようにすることが重要になるのです。

 

2.効果検証型プロセスの導入

要求開発では、「見える化」の作業に時間を多く取られることが多いものです。見える化を行うとは、UML等を使ったモデリングを行うということですが、その際に、見える化を行った結果、何が、どのように効果が出たのかという検証を、できるだけ短い期間で回すことが重要となります。後でどのように使用するのか決めずに、見える化ドキュメントを大量に作成してしまうことがないように、結果イメージを予測しましょうね(笑)。

 

3.検証可能なビジネスモデル

作成するモデルは、検証可能であるべきです。僕はよく「ToBeのビジネスモデルは覚悟するために書く」という話をします。
つまり、将来業務の覚悟を行うために見える化されたフローなどを、ToBeのビジネスを検証するという観点でフル活用するわけです。そうなると、作成するモデルは、検証可能なレベルのものが必要となります。

 

4.ビジネス担当主導のビジネスモデリング重視

よく聞く話として、開発会社やコンサル会社がビジネスフローをモデルとして書いて、それをユーザ企業で保存管理しているケースがあります。しかし、このようなケースの多くは、ビジネス担当者のビジネス知識が入っていなかったり、ビジネスチームに覚悟ができていなかったりするものです。
書き方はさておき、少なくともビジネスモデリングの主役はビジネス担当者です。まあ、担当者と言いましても、ビジネスの意志決定まで関与しているマネージャ・リーダレベルの方々がしっかり内容に対して把握しておく必要があります。

 

5.フレキシブル・ビジネスモデリング

ビジネスモデリングとは、毎回清書するようなものでもありません。ディスカッションの最中にホワイトボードに気楽に書いていくものでもあります。そのようなフレキシブルさを持つ事により、モデリングに慣れることも重要ですよね。

ページトップへ

 

7つのプラクティス

7つのプラクティスとは、要求開発を日々実践する際に、習慣づけて欲しいことをまとめたものです。

1.勇気 問題を発言する勇気を持とう
2.オープン 問題点をオープンにする環境と人を形成
3.成功は失敗から 失敗を隠さず、業務問題を抱えていた部署が新たな改善策を提案する文化を築こう
4.スピーディなビジネス改善と公開 改善できるものは即改善、改善したら即公開
5.目的を理解したモデリング ビジネスモデリングはモデリングの目的を理解して初めて実践できる
6.モデリングの価値 モデリングによる視覚化・共有化こそが、ビジネス改善の第一歩
7.ペアモデリング 常にモデルの共有化を図り、最低でもペアでモデリングすること

7つのプラクティスは、習慣づけしよう

まあ、見たまんまですが、7つのプラクティスは、習慣づけするとよいようなエッセンスを書いています。僕の経験から出たものですので、経験を交えてご紹介しましょう。

1.勇気

要求開発には勇気が必要です。言ってみれば、チームの皆さんの業務変革の活動ともなるわけで、将来の業務に立ち向かう勇気を持たせたり、取りつけたりするのが、要求開発リーダーの大きなミッションとなります。勇気を持って取りかかると不思議なもので、関係する人達も勇気をもって本気で取り組んでくれるようになります。人間は、やはり心で動くのですね(笑)。

 

2.オープン

通常、業務の問題点をオープンにすることは恥として、なかなか表に出てきません。ところが、要求開発を進めていく中で、自社のビジネス価値を高めるためになんとかしようと考えるようになってきます。オープンにすることで、皆で問題・課題を共有して楽しい気持ちで課題に取りかかることができるようになるものです。

 

3.成功は失敗から

業務の問題、および失敗などを認めて率先して解決していく姿勢が見え始めると、その組織は輝きを取り戻します。要求開発の実践の場でも、失敗している組織から改革意欲が湧いてきました。その改革ムードが、他の組織に伝染していったのです。

 

4.スピーディなビジネス改善と公開

システム開発が伴う業務改革は、システムが完成しないと結果を出せません。長い時間結果を出せないと、要求開発チームのメンバーはとても不安になります。また、他の部署から「この忙しい中、いったい彼らは何をやっているんだ」という苦情も出てきます。そこで、「システム開発を伴うビジネス改善」と、「すぐやるビジネス改善」の2つを柱に添えて、日々の業務改善を行い、Web等でその活動を公開することで、要求開発チームの存在価値を示していく戦略をとりました。これはとても効果的でした。やはり、短期的には、スピーディさを伴うビジネス改善と公開を繰り返し、中期的にシステム導入後のビジネス改善といきたいものですね。

 

5.目的を理解したモデリング

モデリングでは、常に、何のためやっているかという目的を理解してやるべきものです。単に綺麗に清書して保存することが重要ではないのです。

 

6.モデリングの価値

モデリング(見える化)によって情報を共有することが、ビジネス改善の第一歩となります。みんなで指さしできる程度の、戦略の見える化、問題の見える化、業務の見える化、など、その効果はかなり大きいです。一人の知識に眠っているものを呼び起こし、絵にするだけで、ビジネス改善の手がかりになります。

 

7.ペアモデリング

モデリングは一人でやらない方がよいものです。2人以上でモデリングすることで、議論したり、アイデアを組み入れたりすることができます。ペアモデリングといっても二人で行わなければならないというわけではありません(笑)。

ページトップへ

 

  • ※掲載されている製品・サービスは、掲載当時のものです。
  • ※掲載されている社名および製品名は、各社の商標または登録商標です。

ページトップへ