「何を頼むか」が決まっていなくても構いません。

「今のやり方を変えたい」
「システムをそろそろ何とかしたい」
「プロジェクトがどうもうまく進まない」
「ベンダの提案を、このまま受け入れてよいのだろうか」

ITの相談は、最初から「RFPを作りたい」「PMOを依頼したい」と整理されているとは限りません。

むしろ私たちは、そんなまだ整理されていない段階からご相談いただきたいと考えています。

何を変えたいのか。
何が問題なのか。
ITで何ができるのか。

発注側に立ち、一緒に整理するところから始めます。

変えたい

基幹システムを、そろそろ何とかしたい

「もう10年以上使っている」
「仕様を分かっている人がほとんどいない」
「改修を重ねすぎて、どこに影響するのか分からない」
「ベンダから刷新を勧められているが、本当に今なのか判断できない」

基幹システムの刷新は、単なる入れ替えではありません。

これまでの業務を見直し、これからの会社に必要な仕組みを考える機会でもあります。

現行システムをどう置き換えるかではなく、これから何を変えたいのかから構想します。

業務を効率化するだけでなく、仕事のやり方そのものを変えたい

「Excelとメールで何とか回している」
「同じ情報を何度も入力している」
「この人が休むと仕事が止まる」
「昔からこうしている、以外に今のやり方を続ける理由がない」

システムを入れる前に、業務そのものを見直した方がよいことがあります。

現状を整理し、何を残し、何をやめ、何を変えるのか。

そのうえで、必要なITを考えます。

AIを使えと言われた。でも、何に使えばいい？

「経営からAI活用を考えるよう言われた」
「いろいろ試してはいるが、業務利用まで進まない」
「AIで何ができるかより、そもそも何をやらせるべきか分からない」

新しい技術を導入すること自体を目的にはしません。

経営や業務の課題から、AIを使う意味があるところ、ないところを整理します。

ITを使って、新しいサービスや事業をつくりたい

「アイデアはある。でも、どうシステムにすればいい？」
「開発会社に相談したら、まず要件を決めてくださいと言われた」
「そもそも、いくらくらいかかるのか見当がつかない」

まだ要件が決まっていなくても構いません。

事業の構想から、必要な機能、実現方法、投資規模、進め方まで一緒に整理します。

整理したい

「DXを進めろ」と言われた。さて、何をする？

「DX推進という方針だけは決まった」
「各部門からDXのアイデアを集めている」
「ツールはいくつか導入した。でも、何が変わったのかよく分からない」

DXそのものを目的にせず、

会社として何を変えたいのか。

そこから具体的なテーマに落としていきます。

要望はたくさんある。でも、要件にならない

「各部門から要望を集めたら、とんでもない量になった」
「全部必要と言われて優先順位がつかない」
「ベンダに渡したら、もっと要件を整理してくださいと言われた」

現場の要望をそのままシステム要件にはしません。

何のために必要なのかを整理し、プロジェクトとして実現すべきことを絞り込みます。

3,000万円。高いのか、安いのか分からない

「相見積を取ったけれど、提案内容が違いすぎて比較できない」
「社内から『もっと安くならないのか』と言われている」
「そもそも、このシステムにいくらかけるのが妥当なのか分からない」

IT投資は、金額だけを見ても判断できません。

何を実現するための投資なのか。
その効果に対して妥当なのか。

発注側の視点から、判断材料を整理します。

会議をしている。でも、決まらない

「毎週会議はしている」
「議事録も課題管理表もある」
「でも、なぜかプロジェクトが進まない」

問題は進捗管理ではなく、誰が何を判断するのかが曖昧なことかもしれません。

論点を整理し、必要な意思決定をテーブルに戻します。

動かしたい

ベンダの提案が正しいのか、誰も判断できない

「説明を聞くともっともらしい」
「でも、社内に技術的に評価できる人がいない」
「結局、ベンダの言う通りに進めるしかない」

ベンダの提案を否定することが目的ではありません。

発注企業が、自分たちの目的に照らして提案を判断できる状態をつくります。

いつの間にか、ベンダがプロジェクトを仕切っている

「会議ではベンダから説明を受ける側になっている」
「次に何をするかもベンダから指示される」
「『御社で決めてください』と言われると会議が止まる」

ITプロジェクトの主導権は、本来、発注企業にあります。

発注側のプロジェクトチームに入り、論点、課題、意思決定を整理しながら、主導権を取り戻します。

社内に、プロジェクトを動かす人がいない

「業務を分かっている人はいる」
「ITに詳しい人もいる」
「でも、全体を見て動かす人がいない」

必要に応じて発注側PM・PMOとして入り、経営、現場、情報システム部門、ベンダをつなぎます。

立て直したい

要件定義が、半年たっても終わらない

「会議をするたびに新しい要望が出る」
「要件を減らそうとすると、全部必要だと言われる」
「いつになったら開発に入れるのか分からない」

要件定義の問題に見えて、実は目的や優先順位の問題であることも少なくありません。

何を実現するプロジェクトなのかに立ち返り、整理し直します。

課題管理表だけが、どんどん長くなる

「赤い項目が増えていく」
「担当者と期限は書いてある」
「でも、翌週になっても同じ課題が残っている」

課題を管理することと、課題を解決することは違います。

何が意思決定を止めているのかを見極め、プロジェクトを動かします。

「もうここまでお金を使ったから」が、続ける理由になっている

「今さら止められない」
「もうかなり投資している」
「ここで方針を変えたら、これまでが無駄になる」

しかし、本当に考えるべきなのは、

これからも投資する価値があるのか。

続ける。変える。場合によっては止める。

一度立ち止まり、判断材料を整理します。

発注側とベンダの空気が、だんだん悪くなってきた

「そんな話は聞いていない」
「それは御社の要件変更です」
「契約範囲に入っているはずだ」

こうした言葉が増えてきたら、技術以外の問題が起きている可能性があります。

どちらか一方を責めるのではなく、契約、役割、要件、意思決定、コミュニケーションを整理し、プロジェクトを正常な状態へ戻します。

自分たちでできるようになりたい

何をするにも、ベンダに聞かなければ分からない

「この変更はいくらかかりますか？」
「できますか？」
「どのくらいかかりますか？」

その答えをすべて外部に聞かなければ判断できない。

私たちは、企業自身がITを理解し、自分たちで考え、判断できる状態を目指します。

内製化したい。でも、全部自分たちで作るのは違う気がする

その感覚は正しいかもしれません。

内製化とは、何もかも自社で開発することではありません。

自社で持つべき能力と、外部の専門家を使うべき領域を整理し、自社に合ったIT体制をつくります。

プロジェクトが終わるたびに、また外部に頼る状態から抜けたい

「前回のノウハウが社内に残っていない」
「担当者が変わると、またゼロから始まる」
「次のプロジェクトでも同じ問題が起きている」

プロジェクトを成功させるだけでなく、その経験や判断の仕方を社内に残す。

外部の専門家がいなくても、自分たちで次の一歩を踏み出せる状態を目指します。

ITプロジェクトの現場では、こんな言葉が飛び交います。

「で、誰が決めるんですか？」

「それは御社で決めていただかないと……」

「全部必要です」

「今さら止められません」

「前回の会議でも同じ話をしていませんでしたか？」

「その仕様を決めた担当者は、もういません」

「ベンダを変えれば解決するんでしょうか？」

「そもそも、このシステムで何を変えたかったんでしたっけ？」

一つでも心当たりがあれば、私たちがお役に立てるかもしれません。

どこからでも、ご相談ください。

変えたい。
整理したい。
動かしたい。
立て直したい。
そして、自分たちでできるようになりたい。

どの段階からでも構いません。

完成した要件書も、RFPも必要ありません。

「会社を変えたい」でも、
「このままで大丈夫だろうか」でも、
「何となくプロジェクトがおかしい」でも構いません。

まず、何が起きているのかを一緒に整理します。

そこから必要であれば、構想策定、投資判断、RFP・ベンダ選定、プロジェクト推進、実行まで。

必要なところから入り、必要なところまで伴走します。

発注側に立ち、ITで「変革」を動かす。

まずは、いま一番気になっていることをお聞かせください。

では、私たちはどんな立場で関わるのか。

変えたいことも、抱えている問題も、企業によって違います。

ただ、私たちの立場は一貫しています。

ベンダ側ではなく、発注側に立つ。
システムを導入することではなく、その先にある「変化」を目的にする。

では、具体的にどんな役割を担うのか。

次に、私たちの役割についてご紹介します。

▶[ 私たちの役割｜発注側に立ち、ITで「変革」を動かす]