ビジネスとITの摩訶不思議な世界を“創発号”に乗って旅する匠Style研究所。第1回と第2回では、「要求とは何か」について旅をしてきました。第3回は、要求の開発という世界を探求していきます。ここまでみなさん、楽しい旅ができていますか？この旅が、もっと楽しくなるように、さらに常識を崩していきましょう。創発号の出発です。 次に挙げるのは、業務改善・業務改革ソリューションで失敗しないために、一般的に言われている常識です。ですが、大切なことは、これらをまずは疑ってみることです。 要求に伴う、疑うべき四つの常識 ●常識１：要求はユーザーから聞き出すもの 今回までの“創発号”の旅の中ですでに、このことが「おかしいのかも」ということには気が付いたと思います。ユーザーの業務を知り、ユーザーがやりたいことを聞きだすことは、基本としては正しいでしょう。 しかし、それだけではダメなのです。ITの使い方は、ITの

正確で明確な「要求仕様」を作成するのは非常に難しい。それがオフショア開発となればなおさらである。 開発技術の発展により，従来よりも変更に強く，速くシステムを作ることは可能になった。しかし，実物を作らずに「紙上」だけで仕様を正確に定義するのは，いまだにとても難しい。 システム化の対象業務も様々で，近年では経理システムのように定型なものは少なくなった。要求を出す側のユーザーでも，アプリケーションを作成して初めて仕様が見えてくるといったことはよくあることだ。 システムに対する業務的な要求が，時間の流れによって変わってしまうこともよくある。チェンジビジョン代表の平鍋健児氏は，このことをで「ムービングターゲット」，つまり動く標的という言葉で説明している。 オフショア開発の場合，それが顕著になる。日本人同士のように，電車で移動すれば顔を合わせられる位置にいても，仕様に対する意識の違いや，仕様そのものの

1.プロジェクト内の情報や知識を構造化する 問題解決思考は，頭で理解するぶんには容易に感じられるが，いざ体を動かして現場で実践しようとすると途端に難しく感じられる厄介な代物だ。 問題解決の教科書にはたいてい「理想と現実のギャップが問題である」「目に見える現象を問題と勘違いせずに，その背後に潜む本質的問題を発見する」と書かれている。しかし，頭ではこれを理解できても，現実にプロジェクトで実践しようとすると，何をどうやれば本質的問題が見えてくるのかがさっぱりわからずに，途方に暮れてしまうことが多い。筆者も幾度となくそんな挫折を味わってきた。 さらに，せっかく本質的問題を発見したと思っても，それを他人が納得できるように説明するのが，これまた一苦労だ。問題の本質を他人に納得してもらうには，事実やデータで裏付けて論理的に説明することが必要だが，これは実際にやってみるとかなり難しいことがわかる。 特に関

いかがだろうか？　実は、例のヒアリング結果ではあらかじめ、「何を・どうする」（＝「どのような媒体に対して、どのような加工をするのか？」）がそろえてあったので、粒度自体は上と下で変わりはないが、イメージがつかめただろう。 きちょうめんな人と大ざっぱな人の違いの克服 他人の業務内容をヒアリングした経験のある人は、「そもそも話を聞き出すまでが大変だ」と気付いたかもしれない。同じ例で今度は、金井さんはきちょうめんな人、松岡さんは大ざっぱな人で、以下のように自分の業務を認識していたとする（岡田さんは、同じ内容なので省略する）。 2. 金井： 注文書に関して私のやる仕事は、まず注文書を見て、日付が合っているか、顧客の社名とご担当の部署名・お名前が書いてあるか、製品名と型式番号が書いてあるか、注文数が書いてあるか、単価と合計金額が書いてあるか、納期が書いてあるか……（中略）、確認します。問題がなければ、

実際の現場では、多数の例外処理が行われている。新発想の業務フローチャート作成手法を紹介する連載の第2回として、例外処理という業務バリエーションを、どのように業務フローチャートとして可視化していくのか。これを原点に立ち返って解説する。 日本版SOX法（注1）の3点セットでは、業務フローチャート（注2）が中心的な役割を担うにもかかわらず、その作成方法には公式が少なく、いざ作成を開始するとさまざまな課題に突き当たってしまう。 連載2回目の今回は、代表的課題である、業務バリエーション、すなわち現場で実際に行われている多数の例外処理を、どのように業務フローチャートとして可視化していくのかについて考える。 例外処理を描き切れない原因 業務フローチャートのそもそもの目的は「業務プロセスの可視化」であるから、業務プロセスを現実に行われているとおりに記述することに意義がある。実際の業務プロセスは、何も問題が

アジャイル開発やプロジェクトファシリテーションを実践している現場は、幼稚園や小学校とよく似た光景ややり方を目にすることがある。たとえば、「ニコニコカレンダー」だったり、「バグレゴ」だったり、「朝会」だったり、「プロジェクトホームルーム」だったり、「あんどん」だったり。 このエントリは、そのような場面を見て、「いい大人が、何をやっているのか！プロフェッショナルは黙って自分の仕事をせよ！」というような仮想議論（この意見を実は直接聞いたことがない）に対する仮想回答である。 ソフトウェア開発は、「ナレッジ創造(Knowledge Creation)」活動なのだ。よく分かっていないものを、アイディアとコミュニケーションでつないで、ドキュメントにしたり、テストやコードにしたり、マニュアルにしたり、している。この「よく分からないこと」というのは、要求にしても基盤技術にしてもそうだ。顧客は要求を完全に分か

前回は，なぜ私たちシステム開発者が「要求の発明」にもっと関心を払うべきかについて，筆者の想いを語った。その背景には「顧客を喜ばせようと思えば，彼らが望まないものを作ることだ」という意識を開発者が強く持たなければ，顧客に心から満足してもらえる高付加価値を提供することが，今後ますます難しくなるのではないかという強い危機感がある。 しかし，いきなり「要求を発明する」と言われても，具体的に何をどうすれば良いのかをすぐにイメージできる人はそう多くはないだろう。そこで今回は，企業情報システムの開発プロジェクトにおいて，私たち開発者が「何をどうやって発明するのか」について考察することにする。 発明という言葉の意味 ほとんどの人は「発明」という言葉から，エジソンのような天才が白熱電球や蓄音機・映写機といった人々のライフスタイルを劇的に変えてしまうような画期的な発明品を創造する，中村修二氏のような企業の研究

顧客の望み通りのシステムを開発したはずなのに，なぜか満足してもらえない。彼らが語った要求はすべて正確に実現しているのに，いったい何が不満だというのだ？ そんな割り切れない気持ちを抱いた経験を持つ読者も多いだろう。 その答えは「顧客を喜ばせようと思えば，彼らが望まないものを作ることだ」というパラドックスの中に隠されている。つまり，顧客が想像すらしなかった要求を発明して提供する必要がある。今回はそんな「要求の発明」について考えてみよう。 要求の価値判断基準の把握が難しい 筆者は20年以上にわたりシステム開発に携わってきたが，顧客に心から満足してもらえる価値の高い要求を，どうやれば識別できるのかが未だによくわからない。価値が高い要求だと考えて精魂込めて作り込んだ機能が，こちらが期待するほどには喜んでもらえない。逆に，あまり価値が高くないと値踏みしていた機能が，意外なほど喜んでもらえたりする。そん

業務において時間は非常に重要な要素だ。にもかかわらず、業務フローチャートに時間の概念を盛り込む方法で、標準化され、定着しているものはない。今回は新発想に基づき、時間の概念を業務フローチャートの基本要素として組み込む方法を考える。 本連載では、業務フローチャート作成における課題への対処方法を考えてきた。前回までに、従来の方式の問題点である、業務バリエーションの盛り込みと、作業の大きさについての課題を解決する方法を提唱してきた。 連載第4回の今回は、まず時間の概念をどのように業務フローチャートに盛り込むかということについて考える。時間の概念は作業の要素の中で最も可視化が難しく、描く人に委ねられてきた部分であった。そのため、吹き出しを使って、思い思いのことを描くというのが一般的であった。 後半では、本連載で紹介してきた新しいフローチャートの作成に必要な時間が、従来のものと比較してどのように変わる

業務フローチャート作成で悩ましい問題の1つは、業務の最小単位である作業を描く際に、同じ業務プロセスであっても人によって大きさがまちまちになってしまうことだ。今回は、これをどのように解消できるかを考える。 日本版SOX法の3点セットでは、業務フローチャートが中心的な役割を担うにもかかわらず、その作成方法には公式が少なく、いざ作成を開始するとさまざまな課題に突き当たってしまう。 今回は、代表的な課題の１つである、作業の大きさの問題を取り上げる。同じ業務プロセスにもかかわらず、描く人によって業務の最小単位である作業の大きさ、つまり「粒度」がまちまちになってしまう。これをどのように解消するのかについて考える。 まず、本連載でこれまで述べてきたことをおさらいしてみよう。 業務フローチャートのそもそもの目的は、「業務プロセスの可視化」にある。しかしながら、実際に業務プロセスを可視化していく際には、「多

新しい視点による業務フローチャートへの展開 今度は、「担当者や担当部署によって仕切られたスイムレーンに作業をプロットする」という従来の発想を捨て去って、業務フローチャートの記載ルールを考えてみよう。 「要素」と「流れ」の組み合わせによって、従来の様式以外の業務フローチャートを作ることができる。 例えば、先ほどの例を取りながら、以下の定義に従うと、どのような業務フローチャートが出来上がるだろうか？

「1タスクあたり8万円の明瞭な価格体系でシステムを構築する。そして要件はユーザーが決める」（スターロジック 代表取締役兼CEO羽生章洋氏）---システムインテグレータのスターロジックは7月19日に開催した同社初の単独イベント「Starlogic Conference 2007」で新しいSIメニューを発表した。同社が考案した要件定義ツール「マジカ！」やアプリケーション自動生成ツールを組み合わせることで，定額かつ低額のシステム構築を実現するという。「人月はSI業界の問題の根源。もう二度と人月商売はしない」（羽生氏）。 エンドユーザーが自分で要件を書けるようにするツール 「マジカ！」は同社が考案し公開している，エンドユーザーが業務プロセスを自分で書き出せるカード型のツールである（関連記事「仕事の流れをマンガ風にまとめよう」，スターロジックが業務分析ツールの新版「マジカ！」をお披露目）。人物が仕事

「ユーザー企業が必要としているのはどのようなシステムか」を定義した要求仕様書を，いかに適切に作成するか――IT業界における長年の懸案事項である。日本情報システム・ユーザー協会（JUAS）は7月5日，この課題の解決を狙った「要求仕様定義ガイドライン」を発表した。システム開発に必要な情報を盛り込んだ要求定義書をどのように書けばよいかを具体的に示すことを意図したもので，「要求仕様書をいかに作るかという“how”に踏み込んだガイドラインは初めてではないか」と，JUASの細川泰秀専務理事は話す。まだ未完成の部分もあるが，ユーザー企業やベンダーの参考資料として役立ちそうだ。 要求仕様定義ガイドラインでは，要求仕様書の構成要素を，(1)（狭義の）要求仕様書，(2)概念データモデル，(3)入出力の定義，の三つとする。中核となるのは(1)。まず，システムに対する要求を「上位の要求」「下位の要求」という二つの

ITが経営に対する貢献を求められている昨今、「要求」を決めるプロセスの重要性が増している。「システムは出来上がったが役に立たない」という結果を招かないためには、どうすればよいか？ 企業におけるITシステムの重要性はもはや言うまでもない。ITシステムは単なるツールから、ビジネスを支えるものへと変化している。事業戦略に即したITシステムの良否が、ビジネスの成否を決定するといっても過言ではない。しかし、逆にITシステムがビジネスに貢献できない結果となることも多くなってきている。 よく「経営戦略と一体化したシステム開発」と言われる。情報システム部門もその認識は強く持っているものの、具現化するとなると非常に難しい。それは、そもそもITシステムが経営のどこにどのように貢献しているかという因果関係、目的と手段の関係が目に見えないからである。 常に変化する経営環境と事業戦略を支えるシステム構築を実現するた

いろいろな人がビジネスモデルという言葉を使っています。ビジネスモデル特許の問題が議論になって以来，概念として注目されるようになってきたわけですが，一般に世の中で使われているビジネスモデルという語と，要求開発アライアンスを含めてIT業界や情報システムの世界でビジネスモデルというときとでは，少し違った意味合いがそこに込められているようです。 まず，世の中一般に流通しているほうのビジネスモデルとは，うまくビジネスを行うためにはどうすればよいのか，より儲かるためにはどんな商売の仕組みを考えればよいのか，を具体的な仕掛けとして提案したものを指します。「儲かる仕掛け・儲ける仕組み」と言ってもよいでしょう。企業家，例えば新たに会社を起こして一旗揚げてやろうと考えているベンチャー経営者は，誰もがここに知恵を絞っているでしょう。これが狭義のビジネスモデルです。 そして，ビジネスモデル特許と言う場合には，この

顧客や開発メンバーなど膨大な人員が関係する大規模プロジェクトでは，コミュニケーション不足が致命傷となる。プロジェクトを破綻から守るには，「聞き返し」や「無駄話」などのスキルが欠かせない。 奥井 規晶　インターフュージョンコンサルティング 代表取締役 システム開発プロジェクトで最も効率が悪いのは，開発・テスト段階で要件が追加・変更されたり，現場の担当者が要件を勘違いしていたりして，設計段階まで手戻りする“逆流現象”である。この逆流現象が，コスト超過や納期遅れ，低品質といった失敗プロジェクトを引き起こす。 プロジェクトの逆流を防ぐには，要件定義の段階で顧客から要求仕様をきっちり聞き出して文書化し，関係者で合意を形成しておけばよい。これで，プロジェクト終盤での追加や変更は激減するはずだ。 ところが，日本において大規模プロジェクトの失敗は後を絶たない。「テストフェーズになって，顧客から『話が違う』

要求開発では「正しくないシステムを正しく作る」ことがないように，まず，システムを開発する前に要求を開発しています。今回はその要求を開発するための「場作り」の大切さを考えてみたいと思います。 「コタツモデル」と呼ばれる，よくあるシステム開発の現場の例えがあります。経営者，SIer，実務担当者，システム部門の開発担当者，各々の関係をまるでコタツの中にいるかのように一つのテーブルを囲み，車座になっているモデル図です（参考：要求開発アライアンスHP）。 コタツの中で私達は一つのチームとなり，信頼関係・人間観関係を構築します。問題点だけでなくビジョンやコンセプトを可視化することで，見えない壁を見えるようにすると同時に，心の壁を取り払います。 人間関係や要求は存在するものではなく，コタツモデルの中で育て，開発していくものだと思います。そのために，磐石な土台としてのコタツモデルの構築，コタツという安心で