ユーザー企業がシステム開発を発注するには、さまざまなハードルがある。企画やRFP(提案依頼書)の作成、ベンダー選定や見積もり評価、検収やユーザー教育などだ。プロジェクト中には品質、納期、コストをマネジメントするベンダーコントロールも必要となる。こうした役割をユーザー企業の立場で長年支援してきた永井昭弘氏が、システム発注の成功条件を明らかにする。

永井昭弘のそれって丸投げ?ユーザー責任を斬る
目次
-
情シスの枠にとらわれずIT精通ビジネス人を目指せ
この連載が始まったのはちょうど3年前である。初回のコラムで筆者は以下のように書いた。「情報システム部はもはや不要ではないかという議論がある。そして、ユーザー企業には明らかな変化が3つある。1つめは情シスのプロパー社員が減っていること。
-
人手不足のご時世、システム構築の希望時期を通すワザ
RFP(提案依頼書)の基本要素は「何を」「いくらで」「いつまでに」の3つ。従来は「何を」と「いくらで」のプライオリティが若干高かったが、最近になって「いつまでに」の重要度が高くなり、他の2つに並んだか、上回る場合さえある。この「いつまでに」の希望を通すには、頭をひねる必要がある。
-
悪い知らせこそ早く、フィードバックを怠らない
発注者側のプロジェクトマネジャーの大切な仕事の1つに、何かを依頼した相手に対してきちんとフィードバックすることが挙げられる。特に悪い知らせのフィードバックこそなるべく早いタイミングで丁寧に行ったほうがよい。
-
発注者は「分かる設計書」を求めるべきだ
発注者はどのような設計書をベンダーに作ってもらうのか、あるいは一緒に作るのか、議論すべきであろう。「納品物のための設計書」になってしまってはいけない。
-
悪質な開発者にご用心、怪人物に共通する5つの特徴
筆者はこれまでに何度か怪しいコンサルタントやフリーランスの開発者に遭遇してきたが、それらの怪人物には共通の特徴がある。1つでも該当するようなら、決して採用してはいけない。社長や上司がこうした人物を連れて来たら、なんとしても採用を思いとどまらせるべきだ。
-
敵か味方か?「声の大きい」エンドユーザー
RFP作成時の業務要求の洗い出しや要件定義など、業務寄りの調査や取りまとめをする場合、実際にシステムを利用し業務を行うエンドユーザーとの打ち合わせは必要不可欠である。エンドユーザーの誰に話を聞こうか、というときに問題になるのが「声の大きい人」だ。
-
意外と難しいエンドユーザー研修、いつ誰が何をやるべき?
システムに追加した機能や、従来版との違いをエンドユーザーに理解してもらう研修は、実施のタイミングや誰がどこで教えるのかといった段取りが案外と難しい。「たかが研修」と甘く見ないほうがよい。
-
提案書は求めるのは4社まで、理由は二つ
筆者が提案依頼書(RFP)の作成やベンダー選定のコンサルティングを実施する際、お客様である発注者には「RFPを提示するベンダーは4社以内にしましょう」とお願いしている。これには二つの大きな意味がある。
-
タコ壺に籠もっていない?情シスは外に出よう
某大手企業の元CIOは、事業部門から情報システム部門に異動したときに、情シス部員の内向きの思考と行動に驚いたという。「まるでタコ壺に入って、しかも底の方にへばりついているようだ」とその様子を表現した。
-
基本設計は準委任契約、重くなるユーザー責任
ベンダーとユーザー企業がシステム開発の契約を結ぶ場合、要件定義と受入テストは準委任契約、詳細設計から総合テストまでは一括で請負契約とするのが一般的であった。ところが、少し前から基本設計を準委任契約で提案するベンダーが増えている。ユーザーに主体的に参加してもらい、仕様を決めてもらう必要があるからだ。
-
コアな仕事は何か? 情シスの定常業務
情報システム部門にとっての「定常業務」をざっと分類すると、「1.システムの運用・保守・維持管理」「2.IT資産管理」「3.ヘルプデスク」「4.次のシステム案件の企画・調査」「5.エンドユーザーのリテラシー教育」がある。これらのうち、コアにすべき仕事は何だろうか?
-
情シスはAIの担当になれるか?
いま世間で最も注目を集めているIT関連技術といえば、AI(人工知能)だ。経営者からAIを活用した変革を求められる現場も増えている。しかし、情報システム部門(情シス)がその期待に応えられるかは疑問だ。もちろん応えられる情シスもあるが、そうでないところがほとんどだろう。
-
コストへの影響大きい、非機能要求の洗い出し
非機能要求は、以前からシステムに対する重要な要求であったが、昨今のクラウドを利用したシステム開発では、特にコスト算出に影響する事柄として適切な洗い出しが求められている。ところが、実際のプロジェクトでは二つの理由で、非機能要求が軽視されてしまうケースが少なくない。
-
何のためのマニュアル?発注前に真剣に考えよう
システム構築費用において「とりあえず入れておこう」といった感じで、甘く見られがちなものにマニュアル作成費用がある。システムにはマニュアルは必ず付いてくるという意識の発注者が多いのは確かだし、ベンダー側も標準的な費用項目として考えている。
-
重要な受け入れテスト、甘く見ずに主体となる
システム構築プロジェクトにおいて、発注者側の作業と位置付けられているのが「要件定義」と「受け入れテスト(ユーザーテストとも呼ぶ)」である。もちろんプロジェクトの性質や契約内容によって異なる場合もあるが、たいていの場合、この二つは発注者責任で行う作業となる。
-
会議の環境を整え、生産性を高めよう
システム構築にはたくさんの会議がある。例えば定例の進捗会議や要件定義といった各タスクの会議。あるいは重要な議題を審議するステアリングコミッティー(ステコミ)もある。これらの会議をどこで開催するかといえば、たいていの場合は発注者であるユーザー企業の事業所内だ。
-
発注者の最大の仕事は「決める」ことだ
筆者はITコンサルタントであると同時に、イントリーグという会社の社長を務めて20年になる。以前に、ある中学校で生徒を対象に講演をする機会があった。その時にある生徒から「社長の仕事で一番大事なのは何ですか?」という質問を受けた。それに対して筆者は「決める」ことと回答した。
-
発注者は「日時指定」をしているか?小事徹底が成功を生む
システム構築プロジェクトを成功させるには何が必要か。この問いに対して、「経営目標や事業計画を反映させたシステムグランドデザインを策定する」「RFP(提案依頼書)を用いて調達する」「投資対効果を定量的に評価する」「ステアリングコミッティーを設置する」「PMOによる第三者チェックを適宜行う」――といっ…
-
発注者の決断なくしてリカバリーはできない
このところ、スケジュール通りにプロジェクトが進まず、遅延が発生して困っているという相談をいくつか受けた。それぞれの案件を調査してみると、状況や遅延の原因はさまざま。このままの体制ややり方ではプロジェクトが確実に頓挫してしまう深刻なものもあれば、ユーザーとベンダーのコミュニケーションの取り方を工夫す…