ボトムアップで「業務改革」はできない

ボトムアップで「業務改革」はできない。失敗学としてITProに掲載されている記事である。

個別の部署の単位での業務改善ならばボトムアップで十分対応可能だ。しかし全体の最適化を考え、経営戦略にそって行う業務改革はボトムアップの視線ではまったく実現できない。当然のことである。業務改革は経営の意思をしっかりと反映したトップダウンの考えで実現しなければならない。

これから実現するシステムは業務改善を狙ったものなのか、それとも業務改革を狙ったものなのか十分に理解した上で、要件をどのように決めていくのか、各部署との調整をどのように行っていくのか考えていく必要があるだろう。

タグ：業務改善 業務改革 ボトムアップ トップダウン

要件可視化のためにプロトタイピングを活用

ZDNet Builderの記事：「プロジェクトの要件を可視化するためにプロトタイピングを利用する」

内容はタイトルの通りなんですけど・・・・。

わざわざ作らなくても”ペーパープロトタイピング”という手法もありますので、ぜひご検討くださいませ。
要件可視化のためであれば、ペーパープロトタイピングが負荷も小さく良い方法ではないかと私個人は思っています。

ペーパープロトタイピング 最適なユーザインタフェースを効率よくデザインする

• 作者: Carolyn Snyder
• 出版社/メーカー: オーム社
• 発売日: 2004/06
• メディア: 単行本

タグ：要件定義 可視化 プロトタイピング ペーパープロトタイピング

"金額決めて中身を決めず”・・・

”金額決めて中身を決めず”・時代に遅れるシステム契約（NikkeiNet）

まさに最近のITシステム構築の契約内容を示す言葉ですね。

しかしこれではユーザ企業にもIT企業にもよくありません。
ユーザ企業はITの投資効果がはっきりしません。投資効果がはっきりしないからその投資が正しかったのか評価もできない。
またあいまいな条件にして、あとから仕様を追加するといったことができるかもしれませんが、請負企業側はどこかでその追加分を省力化します。それは品質であったり、納期であったり・・・。結局ユーザ企業へ跳ね返ってきます。

IT企業はあいまいさから想定以上の作業を受けなければならないリスクが高くなります。IT企業としては品質や納期、機能削除などで対応したいところですが、なかなかそうもいかない。IT企業がその負担を負わなければならないこともあります。
さらに今後導入される工事進行基準の適用ができない。適用しない、という選択肢もありますが、あれもこれも工事進行基準を適用しないとなると外部の評価にも影響します。とするとあいまいな契約はできない。

結局はユーザ企業にもIT企業も好ましくない慣例です。今後改善していきたいと私たちは考えています。

タグ：契約 IT投資

IT企業の工事進行基準は発注側にも影響が

今までIT企業の工事進行基準適用はIT企業の視線で見てきましたが、今回は発注企業側の視線から。

工事進行基準が適用されると従来うまくできていた契約も「今回の案件は引き受けられません」と言われる可能性があります。
というのもIT企業側は工事進行基準適用のため、進捗度の正確な把握のできない契約内容では受けることができないからです。

従来は要件定義からテストまでの各工程を一括で契約するというスタイルが多かったのではないでしょうか。
また、要件定義が終わらないまま開発作業に着手するといったこともままあったのでは。

こうしたことは工事進行基準とは相容れない部分があります。もちろん工事進行基準を適用しないという逃げ道もありますが、IT企業側は「プロジェクト管理が甘いとみなされ逆に信頼を失いかねない」としてこうしたことは避けると考えられます。
とにかく曖昧さを如何に排除した契約とするか、がポイントとなるわけです。

ですから契約相手である発注側にもある程度の影響が出てくるわけです。
IT企業側もバカではありませんし、工事進行基準を素直に解釈していたのではアジャイル開発などはうまくできません。そのあたりは契約条件を付与したり、分割契約にしたりといろいろな手段を取ってくるでしょう。

発注側もこうした提案を吟味し、すべての作業を最初に一括発注したいならすべての作業項目を明確に提示する、定時できないのなら分割発注する、要件定義と設計・実装作業の契約形態を変えるなどの措置が必要になります。

2009年度には工事進行基準が会計監査が行われるすべてのIT企業に適用されます。大手IT企業ではすでに適用が始まっているところもあります。発注側も今回の動きに注目して、自分たちに影響のないように勉強していかないといけないと思います。

タグ：IT企業 工事進行基準 発注企業側管理

『「要求定義」の現場』

非常によくまとまっている要求定義の本です。一度は買いたいという衝動に駆られました。
実際読んでみても本当によくできています。いわゆる超上流工程の業務要件確認から、システム要件定義までしっかりカバーされていて、とてもいい。


しかし、どこか読んだことがあることが多い・・・。
何故かと考えたら今まで読んできた多数の本が1冊にまとめられているのです。
すでに多数の本を所有している私にとっては二重の投資になる・・・。
ということで購入はしませんが、まだあまり要求定義に関する書物をお持ちでないという方はぜひこの本を購入して読んでください。価値のある1冊です。
どれだけ多数の本をまとめたものか、下記の本のリストをご覧いただければわかると思います。

「要求定義」の現場 成功する要求分析と文書化のメカニズム

• 作者: 佐川 博樹
• 出版社/メーカー: ソフトバンククリエイティブ
• 発売日: 2008/03/27
• メディア: 単行本

タグ：要求定義 要件定義 要求開発 超上流工程 業務要件 システム要件 書籍

上流工程の本、一気に紹介

「ドキュメント・レビュー！」に限らず上流工程の書籍は多数出ています。それを一気に紹介しておきましょう。
みなさんの趣味に合う本を探してみてください。

「ドキュメント・レビュー!!」
QCDトータルの品質を考えた場合、上流工程での品質が非常に重要になってきます。
では上流工程の成果物である要求仕様書・設計書の品質を上げるにはどうすればよいか。その解がこの本だと思います。
要求仕様書や設計書のレビューのポイントをしっかりと押さえ、もれなくだぶりなくシンプルに、そして的確に内容を記述することが重要です。
そうしたポイントがこの本には書かれています。
私はソフトウェアの品質を考えるとき、この本に何度も立ち返り確認するようになっています。

ドキュメント・レビュー!!要求仕様書・設計書のレビュー実践と

• 作者: 青島 弘幸
• 出版社/メーカー: ソフトリサーチセンター
• 発売日: 2007/06
• メディア: 単行本

タグ：要求仕様 要件定義 上流工程 書籍

”非機能要求を可視化したい”

”非機能要求を可視化したい”。再び大手SIベンダが結集。

”実践的アプローチに基づく要求仕様の発注者ビュー検討会”で基本要件のガイドラインをまとめたSIベンダが再び結集。今度は非機能要求をターゲットにしました。
非機能要求は可視化が難しい領域。これを可視化するガイドラインができると発注者としても受注者としても非常に助かります。
非機能要求のガイドラインができると発注や要件定義のガイドラインがひと揃えできあがるのではないでしょうか。成果が早くでることを期待したいです。

タグ：基本要件 非機能要求 ガイドライン

部下の業績はコントロールできるか？

IT Mediaの記事にあった営業での話です。部下の業績はコントロールできるか？

一般的にはコントロールできない部類になるそうです。結果業績の8割は2割の営業担当によってあげられる・・・。
あれ、どこかで聞いた話だぞ・・・と思ったら先日の「実践SFA」での話でした。

2割の営業担当が好業績なのは何か理由があるはず。そうした暗黙知を引き出して活用するのが本来のSFAです。
コーチングとSFAという手段を用いて営業全体で業績があがるようにしましょう。

そのためにも「実践SFA」はとても役に立つ本ですよ。

「実践SFA」
SFA（Salesforce Automation）とは企業のフロントオフィス改革の手段です。フロントオフィス改革とは主としてビジネスや営業スタイルを見つめなおすことを行います。SFAを冠した製品はいくつもありますが、その製品を導入したら何かが改善されるかといったらそうではなく、やはりフロントオフィス改革というちゃんとした考えを持たなければなりません。

SFAを導入するにあたって重要なのはそれが営業担当者に適切な情報を与えてくれるものであること、がポイントとなります。
第一に営業担当者が日報を入力する手段として考えてしまうと大抵は失敗するそうです。営業担当者がSFAを利用し、便利だと認識したならば日報も入力するようになるでしょうし、営業担当者が日報を入力していくとさらによい情報が営業担当者に与えられるという循環を生まなければ成功はしません。

今回紹介する「実践SFA」はSFA導入とはどういった意味があるのか、どうすればうまくできるのかといった概念を説明したものです。特定の製品での利用方法は書かれていません。1999年発行ですが、概念を基本としているためどんな製品でも適用でき、現代でも十分役にたつ本だと思います。

最近Salesforce.comがSaaSとして有名になりましたが、あれもSFAの製品です。
導入したら改善するだろうか、と考えている経営者や情報システム部門の方もいるのではないでしょうか。
そういった方はまずこの本を読んでみてください。何のためにSalesforceを導入するのか、どういった効果を期待しているのかを考えるいいきっかけになると思います。それからSalesforce.comを導入しても遅くはないでしょう。もしかするとSalesforce.comではなくほかのやり方のほうがよいという場合もありますよ。
Salesforce.comは月額使用料金なので、とりあえず小規模ではじめて試してみるということもできるので本を読みながら試すのもいいでしょう。

実践SFA―究極の営業革新セールス・フォース・オートメーション

• 作者: 前川 春樹
• 出版社/メーカー: 日科技連出版社
• 発売日: 1999/04
• メディア: 単行本（ソフトカバー）

タグ：営業 SFA

発注者ビュー・システム振舞編／データモデル編

情報大手9社で構成される発注者ビュー検討会は「発注者ビューガイドライン」の「システム振舞い編」および「データモデル編」を公開した。

以前の「画面編」に加え今回の２つのガイドラインで一通りのものが揃った状態となる。今後はIPAが継承し普及にあたるという。

発注者もさることながら、受注者側もこのガイドラインに添った形で顧客と情報のやりとりを行うべきであり、内容を十分に理解すべきである。

発注者ビュー検討会

要求仕様の発注者ビュー（画面編）

NTTデータなどの情報系大手が共同で作業を行っている「実践的アプローチに基づく要求仕様の発注者ビューの検討会」から最初の成果物『要求仕様の発注者ビュー（画面編）』を発表した。


このガイドラインにより、ユーザ企業とSIerとが誤った理解を防いだり、認識のずれがおきないように活用するもの。
検討会には情報系大手企業が多数参加しており、検討会で作成されるガイドラインが今後業界の標準となっていくだろう。

タグ：発注者ビュー 要件定義 システム振舞 データモデル ガイドライン IPA

SOAを理解してもらうには、まずBPMから

SOAを理解してもらうには、まずBPMから

SOAは「どのようにして」システムを構築するかなのです。BPMは「何か（この場合はビジネスプロセス）をマネジメントする」システムなのです。
経営者にとって、意図したことを実行してくれれば「どのようにして」システムが構築されようとも一向に構わない。だからSOAに興味がない。ところがBPMは「ビジネスプロセスをマネジメントする」という経営目的・手段を提供するものであり、経営者にとっては重要な概念なのです。ですから経営者はまずBPMというものは理解します。その中でSOAを利用するかどうかは、結局はどうでもいい。
しかし、SOAを使うとより効果的ですよと説明すると費用対効果を考えてSOAに興味を持つ。

IT企業の提案は「どのようにして」つまり技術先行で説明してしまうことが多いですが、「何を解決するか」を理解してもらいその後に「どのように」を説明しないといけない。その一例がSOAとBPMの関係だと思います。

タグ：BPM SOA 提案型SE