
コンサルでも、SIerでもない。その間を埋める
ITプロジェクトには、それぞれ異なる役割を持つ専門家がいます。
戦略や構想を描くコンサルティング会社。
システムを設計・開発するSIerや開発会社。
製品やサービスを提供するITベンダー。
どれも、プロジェクトには欠かせない存在です。
私たちが担うのは、そのどれかに代わることではありません。
発注側に立ち、それぞれの専門家をつなぎながら、構想を実行へ変えていくこと。
そこに、オーシャン・アンド・パートナーズの役割があります。
違うのは、「どこに立つか」
私たちと他のIT企業との大きな違いは、技術や方法論ではありません。
どこに立ってプロジェクトを見るか。
私たちは、発注側に立ちます。
特定のシステムを売ることも、開発そのものを目的にすることもありません。
経営と現場の意図を整理し、必要なITを考え、ベンダーを選び、プロジェクトが始まれば一緒に動かす。
必要なのは、発注側とベンダーのどちらが正しいかを決めることではありません。
それぞれの専門性を活かしながら、プロジェクト全体を前へ進めることです。
役割の違い
| ITコンサルティング会社 | SIer・開発会社 | オーシャン | |
|---|---|---|---|
| 主な起点 | 経営・IT戦略、課題 | システム・要件 | 何を変えたいか |
| 主な立場 | 助言・支援 | 受注・開発側 | 発注側 |
| 主な役割 | 分析・構想・提言 | 設計・開発・導入 | 整理・判断・実行支援 |
| ベンダー選定 | 支援する場合もある | 選定される側 | 発注側として支援 |
| プロジェクト実行 | 支援範囲による | 開発を中心に実行 | 発注側として伴走 |
| 特定製品 | 会社による | 取り扱う場合あり | 販売前提の製品なし |
| ゴール | 構想・課題解決 | システム完成・稼働 | 変化が実際に動くこと |
どれが優れている、という比較ではありません。
プロジェクトには、考える人も、作る人も、製品を提供する人も必要です。
私たちはその中で、発注側に不足しがちな役割を担うことを専門にしています。
「発注側」にも、専門性が必要です
ITプロジェクトでは、ベンダー側には多くの専門家がいます。
営業、コンサルタント、プロジェクトマネージャー、エンジニア、製品の専門家。
一方、発注側では、ITプロジェクトが本業ではない担当者がプロジェクトを任されることも珍しくありません。
その状態で、
「何を作るのか」
「この見積は妥当なのか」
「どの提案を選ぶのか」
「この仕様で本当にいいのか」
を判断しなければなりません。
結果として、悪意がなくてもプロジェクトの主導権がベンダー側へ寄ってしまうことがあります。
だから私たちは、発注側にもITプロジェクトの専門家が必要だと考えています。
ベンダーとは、対立しない
発注側に立つというと、「ベンダーをチェックする会社」と思われることがあります。
私たちの考えは少し違います。
良いベンダーが力を発揮できるプロジェクトには、良い発注者がいます。
目的を伝える。
決めるべきことを決める。
必要な情報を渡す。
責任の境界を明確にする。
発注側がその役割を果たすことで、ベンダーも本来の専門性を発揮できます。
私たちはベンダーと戦うために発注側へ立つのではありません。
発注側とベンダーが、それぞれの役割を果たせる状態をつくる。
それが、プロジェクトを前へ進めると考えています。
「作る」前にも、「作った」後にもいる
私たちの仕事は、システム開発が始まる前から始まります。
何を変えたいのかを整理する。
投資すべきかを考える。
要件をまとめる。
RFPを作る。
ベンダーを選ぶ。
そして、開発が始まれば発注側としてプロジェクトに入り、必要なら問題の立て直しにも関わります。
さらに導入後、自分たちでITを使い、変化を起こしていける状態まで支援することもあります。
構想と実装の間。
経営とITの間。
発注側とベンダーの間。
その「間」に入り、つなぐことも私たちの仕事です。
【参考】役割の違い
SIerとの違い - 作る立場ではなく、判断を支える立場
SIerはシステムを設計・開発する専門家です。
技術を実装し、システムを完成させる役割を担います。
一方で、SIerは
- 自社の得意分野
- 提供する技術
- 開発体制
を前提に提案を行います。
これは自然なことですが、発注側の視点から見ると
「本当にそれが最適なのか」
を判断するのは簡単ではありません。
私たちはシステムを作る立場ではなく、発注側の視点で判断を整理する立場として関わります。
ITコンサルとの違い - 正解を出すのではなく、判断を支える
多くのITコンサルティングは、
- 戦略を描く
- 最適解を提示する
- 実行計画を作る
といった形で、「答え」を提示するスタイルです。
しかし実際のITプロジェクトでは、必ずしも一つの正解が存在するわけではありません。
- 組織の事情
- 経営の判断
- 現場の状況
によって、選ぶべき道は変わります。
私たちは正解を提示するのではなく、判断に必要な材料を整理する役割を担います。
PMOとの違い - 管理ではなく、判断を整理する
PMOはプロジェクト管理の専門家です。
- スケジュール
- 課題管理
- 進捗管理
といった管理機能を担い、プロジェクトを円滑に進めます。
しかしITプロジェクトが停滞する原因は、管理の問題ではなく判断が整理されていないことである場合が少なくありません。
私たちは管理機能ではなく、判断の論点を整理する役割として関わります。
私たちは、「変革屋」です
ITコンサルティング会社という肩書きだけでは、私たちの仕事をうまく説明できないことがあります。
- 考えるだけでもない。
- 作るだけでもない。
- プロジェクトを管理するだけでもない。
企業が「変えたい」と思ったところから入り、複雑な状況を整理し、必要な判断を支え、ITを使って実際に動かす。
そして最後は、自分たちで変え続けられる状態を目指す。
私たちは、この仕事を少し親しみを込めて、「変革屋」と呼んでいます。
ITは目的ではありません。
変わるために、ITを使う。
そのために発注側へ立つのが、オーシャン・アンド・パートナーズです。
まだ、誰に相談すべきか分からない段階でも。
「システム会社に相談するには、まだ早い気がする」
「コンサルを頼むほど整理できていない」
「そもそも何を変えるべきなのかから考えたい」
そんな段階でも構いません。
何を作るかが決まる前だからこそ、一緒に考えられることがあります。
まずは、今いちばん変えたいことをお聞かせください。
▶[変えたいことを相談する]


















