ユーザー主導の要件定義
ユーザー主導の要件定義 · 15日 3月 2022
システム開発のための要件定義を行うことが想定される場合、仕事を進める上での何らかの課題や問題が発生していると想定されます。そのような場合、問題の原因や、課題の解決策などを社内で論議しなければなりません。今回はそうした議論をするために有効なブレインストーミングと親和図法（KJ法）について考えてみたいと思います。...
ユーザー主導の要件定義 · 13日 3月 2022
システム開発とは、「仕事」の一部をコンピュータのロジックとしてソフトウェア化するということです。ソフトウェア化とはコンピュータが動くようにプログラムを書くと言うことでプログラマの仕事になります。勿論、プログラマは「仕事」がどう言うものかは知りません。仕様書に書かれた指図に従ってプログラム・コードを書くだけです。システム開発とは、つまり、仕事を段階的に構造化し、そのシステム化する部分につき、最終的に言語・図表等によりプログラマに指図をしてプログラム・コードに変換する行為です。 仕事を構造化する行為は、仕事を「知っている人間」にしかできません。当然ですが、一番仕事を知っているのは、その仕事をしている社員です。しかし、「社員」と言っても誰でもという訳には行きません。例えば、販売管理システムについて考えると・・・まず、顧客からの発注書を受け取り、販売管理システムに受注データを入力することが最初の仕事ですが、多分、この仕事をしている社員は発注書の読み方と、どこのデータをシステム端末のどこに入力したら良いのか・・・と言う、「操作」しか知らないかもしれません。このケースで、真の意味で「仕事」を知っている社員とは「受注」から「販売」に至る全工程（プロセス）を知っている社員になります。（しかし、「全工程を知っている」社員が一人である必要はなく、販売業務工程を何人かが分担して「知っていても」いいのですが・・・）知っていると言っても、端末機器の操作や、データの転記などの「手の動かし方」を知っているだけでは足りず、販売業工程を構成する各「仕事」（工程、またはプロセス）がなぜ必要なのか・・・まで理解していることが必要です。 別の言い方をすると・・・、上記の「仕事を知っている人」ならば、仕事を構造化する手法さえ身につければプログラマへの指図をすることが出来ると言うことになります。 筆者も30数年前、ある大型システム開発の要件定義を担当した時に、10人ほどのプログラマを預けられて（SEではありません）、要件定義書（実際はプログラム仕様書）を書いたことがありますが、筆者は対象だった「業務」を手作業でこなしていた経験を持っていたので、当該業務の「全工程」と「なぜ」を知っていたので何とか出来たのだと思います。 横山芳成氏（ウルシステムズ取締役）によると・・・ 「筆者は事業会社の情報システム部門を対象としたシステム開発のトレーニングを開催している。受講者は部長クラスから現場の担当者まで職位も年代もさまざまだ。ただ、一つだけ共通していることがある。それは「皆、要件定義に悩んでいる」ということだ。筆者はトレーニング後に自部門の課題を問うアンケートを必ず実施する。その回答で、「要件定義スキルの不足」が常に突出しているのだ。アンケートを取り始めて7年以上たつが、この結果には変化がない。要件定義がいかに難しい問題であるかが分かる。」 と、指摘しておられますが、「要件定義スキルの不足」という言葉の解釈は2通り出来ます。 1. 一つは、社員の業務知識の低下です。 30年前、それ以前は多くの仕事が「手作業」で行われていたため、各個人は意味を理解しながら「仕事」をしていたが、情報システムが導入され社員は「操作」を覚えれば「仕事」をこなせるようになり、仕事の意味を深く考えなくなり、業務全体を俯瞰して構造化できる人材が減った。 2. もう一つは、システム開発を要件定義も含めてＩＴベンダーに丸投げする日本での風潮により、社員は自ら要件定義をせずＩＴベンダーのシステム・エンジニア（以下ＳＥ）に任せてしまい、要件定義が社員本来の業務である・・・と言う意識が薄れてしまった結果、社員が自ら業務設計を行う技量が失われてしまった。 これには経営者の責任も重大です。 ZDNet Japanサイトの記事『ITベンダーに依存するユーザー企業の理由--「丸投げ」「責任転嫁」が上位に』（國谷武史 （編集部） 2021-11-25）をご覧ください。 https://japan.zdnet.com/article/35179937/ その中に・・・【あなたはベンダーとお付き合いする上で得したことはあるか】という設問の回答1位が「基本的にすべてお任せで仕事を進められるので、仕事が楽だ」とあります。これでは経営者失格と言わざるを得ないと思います。 昨今、デジタル・トランスフォーメーション（以下ＤＸ）という言葉がいろいろな場所で語られるようになりました。 経済産業省では、「デジタル・トランスフォーメーションを推進するためのガイドライン（DX推進ガイドライン）」において、以下のようにDXを解釈しています。 「企業がビジネス環境の激しい変化に対応し、データとデジタル技術を活用して、顧客や社会のニーズを基に、製品やサービス、ビジネスモデルを変革するとともに、業務そのものや、組織、プロセス、企業文化・風土を変革し、競争上の優位性を確立すること」 社会が大きくＤＸに向かって舵を切ろうとしている中で、ＩＴベンダーに要件定義も含めて「すべてお任せ」では、早晩、峻烈な競争から脱落してしまうでしょう。 システム開発を行うにあたって、システム開発が単独で行われることは稀です。ほとんどの場合、業務設計が行われ、業務設計の結果として要求されるシステム機能についてシステム開発が行われます。要件定義とは業務設計の一部として策定されシステム機能を定義します。重要なのはこの部分です。ＩＴベンダーに依存している多くの企業は業務設計まで丸投げしてしまっています。それ故に、楽はできますが、社員の業務能力は低下してしまい、上で述べた「要件定義スキルの不足」に陥ってしまいます。以前のブログで『「システム開発内製化の動き」と「ユーザ主導の要件定義」』を採り上げましたが、業務設計と要件定義が自社で出来る（要件定義の内製化の）力量を有していれば、「システム開発内製化」までしなくても問題はなくＩＴベンダーに頼るべき部分（要件定義から仕様書への変換、システム基盤の設計、コンティンジェンシー・プランの策定など）に絞って外注出来るようになれば良いのです。 経営者は、自社の社員が「顧客サービスの最大化」のために「自社の業務プロセスの最適化」を設計できるように教育・訓練する必要があるのですが、その成果の一つが「要件定義の内製化」です。要件定義の内製化が出来るようになれば、開発コスト１／２、開発期間１／２、開発リスク１／２も夢ではありませんし、この教育・訓練を通じて、社員の自社業務への理解が深まるとともに、社内コミュニケーションも高まり、結果として自社の業績アップにつながって行くのです。
ユーザー主導の要件定義 · 23日 2月 2022
米国国防総省がソフトウェア開発における品質、生産性の向上、工期短縮などのニーズを満たし、ソフトウェア開発の活動をより高度なレベルに高めるためために、カーネギーメロン大学にソフトウェアの下請業者を客観的に評価する基準として使えるモデルを作る研究を依頼し、能力成熟度モデル（CMM: Capability Maturity Model）が開発されました。（1989年）...
ユーザー主導の要件定義 · 18日 2月 2022
住宅を建てる時に最初に考えるのは「間取り」であるのが一般的だと思います。間取りを決める時には、住む人の「動線」が基本になりますね。どこを居間にして、居間から食堂へ、食堂とキッチンに住む人がどうのように移動するか？お風呂屋、トイレはどの位置にするか・・・など、この人の動線が仕事においては「業務工程」「業務手順」とか、また一般的に「業務プロセス」と呼ばれます。業務プロセスを広くは「ビジネスプロセス」と呼ぶことが多いです。 皆さんが仕事をするときには、「決められた業務工程」に従って業務を運用しているはずです。「決められた」と言うことは、どこかに「決めごとを定めたもの」があるはずです。一般的には「業務手順書」「業務手続」と呼ばれているでしょう。そこには、「どういう順番で」「どういう作業を」（つまり、業務プロセス）をするかが定められています。 ちょっと横道にそれますが・・・この決めごとは書かれたものがある場合（ちょっと難しいですが）「形式知化されている」といいます。書かれたものがなく誰か担当者の記憶に頼っている場合、これを「暗黙知」と呼びます。「形式知」と「暗黙知」を覚えておいてください。 さて、話しを戻します。業務プロセスは、企業や団体の活動目的に沿ったものになっています。製造業であれば「製品を作って販売し利益を得る」という大きな経営目標を達成するために業務プロセスが従業員等により実行されます。大きな目標のことを「ビジネスモデル」と呼んでいます。 整理すると、ビジネスモデルを達成するために業務プロセスが実行される訳です。 もう一つ覚えて戴きたいのが「業務判断基準」です。一般的にビジネスルールと呼びますが、業務プロセスを実行するとき、その過程で「判断」が求められる場合に採用すべき判断基準が定められています。ビジネスルールも覚えておいてください。 業務プロセスとシステムの関係を考えてみましょう。先に述べたように、ビジネスモデルを達成するために業務プロセスが存在しました。システムは業務プロセスを実行するための道具となります。従って、システムの振る舞いと言うものは業務プロセスによって決められ、「判断」が必要なときにはビジネスルールに従うことになります。 従って、システムは業務プロセス実行過程で使用される「道具」ですから、システム開発を行う場合とはその元となる業務プロセスになんらかの変更・追加・削除等が行われることが前提になっています。 つまり、システム開発の検討を行う前段階において業務プロセスをどのように変化させるのかが検討され定義されなければなりません。ここが重要なポイントです。 そして、業務プロセスの変更後の姿が決まった後に、その業務プロセスとビジネスルールからシステム開発の「要件」が導き出され定義したものが「要件定義」です。 さて、上で述べた「業務プロセス」や「ビジネスルール」について、最も詳しい立場の人は誰でしょうか？言うまでもなく「業務担当者」（階層はありますが広い意味で）が最も詳しいはずです。 従って、私が申し上げたいことは・・・「要件定義」は原則「業務担当者」（システム開発においては「ユーザ」と呼ぶのが一般的）これを策定すべきだと考えます。 また、であるからこそＩＰＡ（情報処理推進機構）から「ユーザのための要件定義ガイド」も発刊されたのだと思います。 前々回のブログで述べましたが、システム開発の失敗の半分以上が、要件定義の不備・不足に起因しています。その理由は、業務について知識のないＩＴベンダーに「要件定義」を含めて丸投げしてる現下の日本におけるシステム開発の体質にあると言わざるを得ません。 日本のＩＴベンダーは、システムの黎明期から50年間にわたりユーザの要件定義を支援してきており、要件定義の技術も蓄積されています。しかし、ユーザが１００人いれば１００種類のビジネスモデルがあり、業務プロセスがあります。従って、ＩＴベンダーは新しいユーザに接する都度新しいユーザの業務プロセスの分析をしなければなりません。しかし、ユーザの知見は自社に特化しているので、言うまでもなく、ユーザが要件定義を行えばシステム開発の失敗も大幅に減少するはずです。 ですので、ユーザである皆さんに是非「要件定義」の手法を身につけて戴きたいと思います。
ユーザー主導の要件定義 · 08日 2月 2022
では、なぜシステムを開発するのでしょう？ いろいろな理由が考えられます。 1． 古いシステムを最新のシステムにリプレイスする必要が生じた。 2． 新規ビジネスを立ち上げることになり、新しいシステムが必要になった。 3． 子会社を吸収することになり、システムの統合が必要になった。 4．...