開発基盤部会 Blog

開発基盤部会 Blog >> 記事詳細

2019/02/04

サプライサイドとデマンドサイド以外の対立軸を分析してみる。

Tweet ThisSend to Facebook | by:nishino
 前回、(サプライサイドだけでは限界だよ。と言う)AS-ISを書けた気がするので、ダメだダメだと言って、対案が無いってのは、アレっポイので、この代替案は何か?というTO-BEをことをチョット考えてみたのですが、書いている最中に、前提の定義が必要になってきた気がするので、今回は、その分析と定義を行いたいと思います。

 具体的な分析対象は各種「対立軸」となりました。これを見つけ出すと面白い(と言うか、回答に近づいて行く)と思います。一応、今回の分析で洗い出した対立軸は以下になります。
  • サプライサイド・デマンドサイド
  • プロジェクト・定常業務
  • プロジェクト型組織・機能型組織
  • アプリ開発・システム構築 / 運用
  • アプリ開発 / システム構築・システム運用

 コレって、

  • アジャイル
    サプライサイド・デマンドサイド対立の解消
  • DevOps
    アプリ開発・システム構築 / 運用 対立の解消
  • 脱製造
    マーケティング、設計、調達、生産、物流、販売を一体でやる

 の辺りとも関連していますよね(?)
 以下、其々の対立軸について定義していきます。



<一般的なプロジェクトの概念図>



<サプライサイド・デマンドサイド>

 前々から言っている対立軸です。簡単に言うと、ユーザとベンダになります。上記受注では明確に書いていませんが、ビジネスからプロジェクトの上流側がデマンドサイド、プロジェクトの下流側がサプライサイドになると思います。

 基本的に、ユーザはユーザの、ベンダはベンダの利益を求めますが、ソレだけだとプロジェクトが上手く廻らないので、組織内には、ユーザ側にもベンダ・テイストのある人達(例えば情報システム部とその配下)と、ベンダ側にもユーザ・テイストのある人達(コンサルやPM)が必要になると思います。

<プロジェクト・定常業務>

 プロジェクト・定常業務とは、プロジェクトの定義を読むと理解できるのですが、要するに業務には、プロジェクト性の有る業務と、そうで無い業務があります。

<プロジェクト型組織・機能型組織>

 上記のプロジェクト性を組織レベルで見ると、ココに書かれたような「プロジェクト型組織」と「機能型組織」に分けることができます。

 プロジェクトで、顧客毎、別のオンサイトに行くような組織は、主にプロジェクトを遂行する「プロジェクト型組織」に参画する事が多いでしょう。保守・運用などの定常業務の合間にプロジェクトに参画している組織は、主に定常業務を遂行する「機能型組織」に所属しているでしょう。

<アプリ開発・システム構築/運用>

 こちらは、アプリ・システムで切った場合になります。上記の図中に示したとおり、システムのほうが下位スタックのためビジネスやプロジェクトから距離があると思います。

 このため、組織的にも、アプリケーション系は、プロジェクト毎に新設される「プロジェクト型組織」に参画することが多いと思いますが、インフラ系は(、ケース・バイ・ケースですが)、IT部門などの「機能型組織」の配下である事が多いように思います。

<システム構築・システム運用>

 よくよく考えると、インフラ系には、構築系と運用系がいる気がします。その昔、ソリューション系は構築系なので運用が出来ないと嘆いてユーザ系に転職した人材がおったりしました。構築・運用で、プロジェクト・定常業務の比率がカナリ違いそうですね。

 ちなみに、SIのアプリケーション系にも保守・改修の仕事があるケースがありますが、インフラ系と異なり、作業量は少ないです(大きな改修は、別プロジェクトとして立ち上がる)。ただし、Webサービスのアプリケーション系には、CI、DevOpsなど、頻繁なリリースを繰り返すプラクティスがあり、この場合は、この限りではありません。



 如何でしたでしょうか?こういう定義は、ネット上を見ても見つからなかったので、某弊部会で分析・定義してみました。界隈の人であれば、身近にに似たような構造を確認できるのではないか?と思います。また、コチラにも書きましたが、プロフィットセンター・コストセンターなんていう対立軸もあるかと思います。

 しかし、昨今の、「アジャイル、DevOps、脱製造」なんかのトレンドを垣間見ると、これらの対立軸で対立しているのは、ワリとダメな人なのかもしれません。

<身近な問題を考えてみる>

 例えば、インフラ系は、技術単体で事業になっていたり、機能型組織の配下であったりすることを考えると、インフラ屋がバック オフィスのサポート・エンジニアに転身しても、フロント オフィスからの要求が少なかったり、コントロールするポジションが無かったり、現状そうなっているので何となく解ったりします。なので通常、インフラ系のバック オフィスは事業企画をサポートして、それを事業部に渡すような R&D 系のスキームが中心になります。

 一方で、上モノのアプリケーション系は、周辺のアプリケーション開発技術の商用サポートも少なく、ホボ、ビジネスサイドにコミットしたプロジェクト型組織のPMが主体でコントロールするので、バック オフィスのサポート依存があり、コレを生産技術系の組織が担っていると思います。ただし、このコントロールのポジションは集約されているので球数は少ない気がします。
09:00 | 投票する | 投票数(0) | コメント(0) | ご報告