IT投資時の中小企業向けモデル契約書

中小企業がＳＩｅｒと交わす際のモデル契約書のひな形を経産省が発表

大企業向けとは違い、ＩＴや法律に詳しい人材が手薄な中小企業向けに、ＳＩｅｒに強く説明責任を求めている。
ＳＩｅｒとしては注意しておきたい内容であろう。

経産省はパブリック・コメントを求め3月末には正式版を出したい模様。
契約関連に携わっているかたは要チェック！！

タグ：ＳＭＢ 契約書 経産省

「ドキュメント・レビュー」

要求仕様書（要件定義書）・設計書を書く際のチェックポイントを整理した本です。特に上流工程でその力を発揮すると思います。
・どんな観点で書くのか
・どんな観点で書いてはいけないのか
・どんなレビューをすべきか
・どんなレビューをしてはいけないのか
が明確に説明されています。上流工程の重要性が見直されている今、この本はとても良書だと思います。

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

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

タグ：要件定義 レビュー 書籍

ITアーキテクト/ビジネスアーキテクト

ITシステムの提案・要件定義を行う際に重要な役割を担うITアーキテクトですが、狭義に定めると超上流を担当するビジネスアーキテクトとその下流（いわゆる上流工程）を担当するITアーキテクトに分けられそうです。

現状、主流は要件定義下流を守備範囲とするITアーキテクトですが、ITシステムがSMBに拡大するにつれて超上流を担当するビジネスアーキテクトの役割も求められてきています。

最近の雑誌『ITアーキテクト』ではこの流れを反映し、超上流を意識した特集が増えてきているような気がします。

ITアーキテクト Vol.15

• 作者: ITアーキテクト編集部
• 出版社/メーカー: アイ・ディ・ジー・ジャパン
• 発売日: 2008/01/24
• メディア: ムック

上流工程厳格化、東証次世代売買システムの場合

東証が次世代売買システムで厳格な要件定義を行ったそうです。

まずそのドキュメント量に驚かされます。
RFP：1,500ページ
要件定義書＋外部設計書：4,000ページ

数百億円のシステムですからこれくらいなのかもしれませんが、そこに投入されているエネルギーは相当なものですね。
システム開発までこんなに体力使ったら、その後の工程で疲弊してしまいそう・・・。

こんな大きなシステムでも開発を受託すれば進行基準で計上しなければならなくなります。それはそれで大変そうだな～。

タグ：上流工程 RFP 要件定義 外部設計 厳格化 ウォーターフォール 受託開発

情報システム・モデル取引・契約書

情報システムのモデル取引・契約書の説明がITProで掲載されています。

ソフトウェア業界では契約前から作業に着手するといった悪しき慣例が若干ながら残っていましたが、4月から情報システムの受託開発には工事進行基準が適用されるため、契約書締結などに関しては今まで以上に重要になってきます。

開発担当者もこうした情報にはアンテナを高く張って、きちんと整理しておくようにしたほうがよいと思います。

「図解 バランススコアカード第2版」

「提案力を高めるコンサルタントSEへのアプローチ」ではバランススコアカード（BSC)を利用します。BSCについては数々の本が出ており、個人の好みで良し悪しがあるとは思いますが私としては「図解　バランススコアカード第2版」をお勧めします。

「提案力を高めるコンサルタントSEへのアプローチ」
顧客志向などの本を読んで来ましたが、SIerの担当レベルでできる顧客志向はこれ。
「提案力を高めるコンサルタントSEへのアプローチ」
以前にも紹介しましたが、営業やSEといった担当者レベルでやるべきことは、この本の内容そのものです。
もちろん受注後のいわゆる超上流工程の作業もいろいろ必要な知識がありますが、半分くらいはこの本の内容でカバーできるのではないでしょうか。
なお、コンサルティングに関する知識を得たいなら「コンサルティング入門」という本がお勧め。わかりやすいです。上記の本の副読書としてどうぞ。

徹底的にこの内容を身につけるよう努力しましょう（半年に1回は必ず読むとか、実践時には手元に置いておくとか）。

図解 バランス・スコアカード

• 作者: 松永 達也
• 出版社/メーカー: 東洋経済新報社
• 発売日: 2006/02
• メディア: 単行本

タグ：バランススコアカード 書籍

「提案力を高めるコンサルタントSEへのアプローチ」

顧客志向などの本を読んで来ましたが、SIerの担当レベルでできる顧客志向はこれ。
「提案力を高めるコンサルタントSEへのアプローチ」
以前にも紹介しましたが、営業やSEといった担当者レベルでやるべきことは、この本の内容そのものです。
もちろん受注後のいわゆる超上流工程の作業もいろいろ必要な知識がありますが、半分くらいはこの本の内容でカバーできるのではないでしょうか。
なお、コンサルティングに関する知識を得たいなら「コンサルティング入門」という本がお勧め。わかりやすいです。上記の本の副読書としてどうぞ。

徹底的にこの内容を身につけるよう努力しましょう（半年に1回は必ず読むとか、実践時には手元に置いておくとか）。

提案力を高めるコンサルタントSEへのアプローチ―バランスト・スコアカードを活用して、経営課題でシステムを語ろう

• 作者: 安達 悟志
• 出版社/メーカー: 日刊工業新聞社
• 発売日: 2004/02
• メディア: 単行本

BBTシリーズ8 コンサルティング入門 (BBTビジネス・セレクト 8)

• 作者: 内田 和成
• 出版社/メーカー: ゴマブックス
• 発売日: 2007/07/04
• メディア: 単行本

タグ：提案型SE コンサルティング BSC 顧客志向

エンタープライズシステムの超上流工程

本日ITアーキテクトサミット2007 Winterに参加してきました。

その中の１つのセッションで「”ITの視点”によるビジネス・プロセスの最適化戦略」というものがありました。

内容としてはエンタープライズシステムの超上流（システム要件定義より前）でのITアーキテクトの役割というものです。
このブログでもビジネスインテグレータへということで紹介していますが、従来のSIerがシステム要件定義以降を担うのに対して、現在はその前の工程からの参画を求められています。ここでのITアーキテクトの役割は「ビジネスの仕組み」を最適化することで必ずしもIT化をしなければならないということではありません。スコープを要件定義からというと非常に曖昧なのでシステム要件定義以降なのか、それともビジネス要件定義まで含むのか、よくよく顧客と確認するようにしたほうがよいと思います。

システムインテグレータからビジネスインテグレータへ
従来、ITシステムを導入する業者をシステムインテグレータと呼んでいました。
システムインテグレータの範疇は、顧客の業務のIT化。顧客の要求を捉え、このIT化を最大の目標にしていたと思います。

今後のIT業界で目指すべきはビジネスインテグレータだろうと思います。
ビジネスインテグレータの範疇は経営戦略の実現。顧客の経営課題・経営戦略を把握し、戦略の実現を目指す。顧客の経営課題・戦略に注目し、それを実現するソリューションを提供するものです。
従来より一歩進むわけです。

最近のプロジェクトで発生する問題の多くは要求定義（要求開発）の不足です。従来は顧客がきっちりと要求を定義し、ITベンダーはそれをIT化することに専念していればよかったのですが、最近はそうもいきません。顧客側の要求が経営課題であったり、経営戦略（実際には事業計画）をどう実現するかといった今までにくらべ一段階高いレベルの要求が提示されていると思います。この段階からシステムに落とし込むには無理があります。顧客とともに課題や事業計画からさらに一歩ブレークダウンしてそれをどう実現するかを決定する要求開発というフェーズが重要になっていると思います。
そういった意味でITベンダーはシステムだけを対象とするのではなくビジネスを対象としてインテグレートする、という企業に成長しなければならないと思います。

このブログでもその傾向は読み取れるのではないかと思います。当初はソフトウェア技術者向けの記事を中心に、と思ってやってまいりました。しかし、要求定義（要求開発）からしっかりとやらなければならないとなれば、ITベンダー側も顧客の業務や経営について理解し、業務コンサルタントが担当している領域までカバーしなければなりません。そういったことから最近紹介する本の多くが経営に関連するものとなっています。決してソフトウェア業界と無関係なものを紹介しているわけではありません（たまに息抜きの本も紹介していますけどね）

ソリューションとは経営課題をITとその付加サービスを通じて解決するビジネス手法（JEIDAの定義）と定義されています。つまりソリューションプロバイダーを掲げる以上はビジネスインテグレータに成長すべきであると思います。

タグ：ITアーキテクト エンタープライズ ビジネスプロセス 最適化 超上流 ビジネスインテグレータ ビジネスアーキテクト

「仮説提案型営業の進め方」

以前「提案力を高めるコンサルタントSEへのアプローチ」という本を紹介しました。ここでは提案型営業のやり方、つまり提案内容（コンテンツ）そのものに注目して説明していたと思います。
今回ご紹介する「仮説提案型営業の進め方」は仮説提案型営業のプロセスに注目して説明しています。
いくら内容のよい提案をしてもそのプロセスが良くなければ提案が台無しになってしまうこともあります。ぜひこの本と前回ご紹介した本を読んで、仮説提案型営業のプロセスとコンテンツを理解してよりよい営業ができるようにしましょう。
　ちなみにソフトウェア開発企業においては営業だけではなく、SEもこのプロセス・コンテンツをしっかり理解しないといけないでしょう。ソフトウェア開発企業に属する人は全員これらの本の内容を熟読して理解して欲しいと思います。

仮説提案型営業の進め方―顧客の求めるソリューションを実現する!顧客との「仮説検証サイクル」をまわせる営業マンが実績を伸ばす!

• 作者: HRInstitute
• 出版社/メーカー: かんき出版
• 発売日: 2001/04
• メディア: 単行本

「提案力を高めるコンサルタントSEへのアプローチ」
以前紹介した「SEのための提案書のつくり方」が提案書作成の後工程、つまり実際の提案書作成を紹介した本ならば、今回の「提案力を高めるコンサルタントSEへのアプローチ」は提案書を作るまでの前工程、つまり分析等の手法を紹介した本です。バランススコアカードを活用して、顧客が何を必要としているか、どういった解決策（ソリューション）が提供できるかを分析するまでの過程を細かく紹介しています。この分析工程なくして提案型SEはあり得ません。SE・営業の方はぜひセットで読んでいただきたいと思います。

「SEのための提案書のつくり方」
「IT提案力」でも紹介しましたが、現在は”提案型SE”というものが求められており、SEも顧客の立場にたった提案書を作らなければなりません。そのためには、有価証券報告書等などから情報を読み取り、顧客が何に困っているか、どうしたいと思っているのかを理解していく必要があります。
　提案書が必要なのはわかったけど、じゃあどう顧客にアプローチすればいいの？という方もいらっしゃると思います。
そういった方には「SEのための提案書のつくり方」をお勧めします。提案書作成までの具体的なプロセスも説明されていますし、仮説が正しくなかった事例も含めて3社の事例も掲載されています。非常にわかりやすいと思います。

　さて、「提案型SE」とSEばかりに注目がいっていますが、私はこの手の内容は営業も身につける必要があると思っています。顧客が何に困っているのかといったことは、会話のほんの一言からわかってくることもあります。SEだけではなく営業もそうしたアンテナを張り巡らせ、何を提案すればいいかを考えていく必要があると思っています。ぜひ営業の方もこの本を読んで、”提案型営業”になれるよう頑張ってください。





提案力を高めるコンサルタントSEへのアプローチ―バランスト・スコアカードを活用して、経営課題でシステムを語ろう

作者: 安達 悟志出版社/メーカー: 日刊工業新聞社発売日: 2004/02メディア: 単行本

タグ：書籍 提案型SE

TISの業績下方修正にみるスコープ定義の重要性

TISが大型案件の開発遅れで業績予想を下方修正したそうです。

遅れの主たる原因はシステムテストフェーズのようで、顧客からテストの追加要望によるもの。
TISはスコープ範囲外と捉え費用を請求したが、顧客側は一括請負契約の範囲内としてこれを拒否。
TISは法廷闘争も視野にいれ調停を行い、顧客から費用の負担をとりつけたが全額とはいかなかった模様。

最近の開発案件でこうした請負契約範囲内か範囲外かの見解がベンダー・顧客間でずれる傾向にあり、ベンダー側はスコープ定義を重要視しています。TISも機能的なスコープは注意して定義していたと思います。しかし落とし穴はシステムテストにあった。どこの範囲まで、どのレベルでテストをするかといったことは厳密に注意していなかったのではないでしょうか（違ったら申し訳ありません）。自分の例でも、システムテストと費用を提示しますが厳密なスコープ定義を提案時には行った記憶がありません。全体像がわからないから大体こんなものだろう、とかあれはやらない、これはやらないとネガティブな内容になることが多かったと思います。最後はシステムテストは別見積もりとしてしまうことも。
　全体像が見えない段階でシステムテストまで一括請負契約してしまうと、どうしてもこうした問題がおきやすいのだと思います。開発開指示にシステムが見えている場合はシステムテストも契約範囲としてもいいですが、やはり今回の事例を教訓にそのスコープをはっきりさせるようにしましょう。

　といいつつ、本音は「最初からシステム要件が明確に決まるわけがない。」と思っています。不確定要素の多いソフトウェア開発なのですから、最初から明確な見積もりはできるはずがない。いろいろ見積もり手法はありますが、多くは”要求（スコープ）が決定している”ことを前提としています。しかし要求（スコープ）をこれから決めるプロジェクトでそれができるはずがない。仮にあらかじめ要求が出ていたとしても、世の中のスピードが早くなっているため途中での仕様変更がないなどありえない。そのたびに機能要求のスコープのみなおしとともにシステムテストの見直しをしていたのでは管理工数ばかりがかかってしまいます。ですから実際には
　　　・要求定義
　　　・開発
　　　・システムテスト
　と契約を３つに分割するのが一番安全だろうな、と思っています。そして従来のウォーターフォール型ではない開発手法（アジャイルな開発手法）で問題の早め早めの解決と、システムテスト内容の早期決定、という手段で顧客を安心させていくしかないでしょう。大規模案件でもアジャイル開発の適用が必須になってきているのだろうと実感しました。