あじゃりもち です。

いわゆるエンタープライズの領域でシステム開発をする場合、所属組織の異なる様々な関係者でプロジェクトが結成される事が多いです。

• ビジネス部門の人
• IT部門の人
• 一次受けのベンダー
• ベンダーから開発を請け負う二次受けベンダー
• etc…

そして所属の違いがプロジェクトに対する異なるスタンスを生みます。なぜなら所属組織によって業務目標(ざっくり言うとKPI)が異なるからです。

スタンスが異なると何が悪いのか？

スタンスの違いが”価値あるプロダクト”の開発の阻害要因になる事が問題です。

ここでの価値とは、プロダクトが利用され収益や費用削減効果といった効果を生み出す事を指します。それらはプロダクトを開発する目的であり、例えどれほど良く出来ていても、利用されなくては目的を果たせないからです。

新しいプロダクトを作り、サービスをユーザに提供する事で、対価としてユーザからお金を頂いたり、広告料という形でお金を頂く。そのお金がシステム開発費を上回る見込みがあるからこそ、プロダクトを作るのです。

バックオフィス系のプロダクトであれば、業務をオートメーション化する事によって経費を減らす。即ち、開発費を上回る経費削減効果が期待できるからこそ、プロダクトを作るのです。

公共事業の場合、「金銭的な利益」は追求しないかもしれませんが、社会的な利益は追求します。即ち、利用者や社会全体として得る利益（例えばe-TAXの利用によって申請にかかるコストの削減効果や、申請に伴うCO2などの公害要因の削減効果）が開発費を上回るから、プロダクトを作るのです。この考え方は、ビジネスの基本です。

だから本来、開発に関わる人は皆、”自分の作ろうとしているものが作る費用以上に価値を生むか？”の観点を軸にして、”いかに価値を生み出すか”というスタンスで働くべきだと思います。

この時、プロダクトを作る目的と、関係者の業務目標が一致していれば、価値あるプロダクトを開発する事に集中する事が出来ます。

しかし現実ではプロダクトを開発する目的と業務目標が一致している関係者はプロジェクトのごく一部であり、業務目標が異なる者同士で構成されたプロジェクトは、利用されない機能がふんだんに盛り込まれたチグハグなプロダクトを生み出してしまいます。

これはアジャイル開発に限った話ではありません。
アジャイル開発が、、ウォータフォールが、、と議論する以前に、プロジェクトの関係者のスタンスを出来る限り合わせる努力が必要です。

もし、プロジェクトの関係者全員がこのスタンスの上で仕事をしていれば、作ったけど使われない機能や、開発者と運用者の揉め事、「早く仕様を決めて欲しい〜」などと言う愚痴は、生まれないでしょう。

組織構造や多重委託といった文化が複雑なスタンスを生んでいる

ユーザ企業で働いてみて痛感したのが、SIer時代とのスタンスの違いです。
あじゃりもち の働いている会社は歴史が浅く、まだベンチャー企業と言えるかもしれませんが、特徴としてプロダクト/プロジェクト単位で組織が作られています。即ち、”ビジネス側”、”開発側”という垣根がありません。プロダクトマネージャという立場は存在しますが、ビジネス的な要件を考えると言うより、役員やスポンサーに掛け合って開発資金を調達したり、収益の管理をするといった仕事が主になっています。
あじゃりもち はエンジニアとして実装をしますが、チームメンバと一緒に要件も考えますし、エンドユーザにヒアリングをしたり、イベントでプロダクトを宣伝したり、もちろん保守運用の作業もやります。
チームメンバ全員の関心ごとは”如何に自分達のプロダクトでユーザを喜ばせ、収益を伸ばすか”であり、プロダクトマネージャ含むチームの評価も、収益で決まります。

前置きが長くなりましたが、あじゃりもち のチームの場合、チームメンバのスタンスが本来あるべき”いかに価値を生み出すか”という一つのスタンスに共通化されているのです。

一方、SIer時代を振り返ると複数のスタンスが存在しました。

まず、システム発注者のお客様内部でスタンスが別れている事が普通でした。具体的に言うと、顧客のシステム部門がビジネス部門から社内発注を受けてSIerに外注するというケースが多く、その時点でシステム部門、ビジネス部門の２つのスタンスがありました。
　当然、ビジネス部門は”いかに価値を生み出すか”というスタンスを持っていますが、システム部門は”いかにビジネス部門を満足させるか”というスタンスを持っていました。（システム部門もある程度価値に対するスタンスを持っていたと思いますが、”ビジネス部門を満足させるか”のスタンスの方が強い印象を受けました）

お客様の時点でスタンスが２つに別れていますが、ここから更に、スタンスが増えていきます。

受注したSIerは”いかに発注者である顧客を満足させるか”というスタンスを持っています。そして、言わずもがなSIerの多重請負によって、２次受けは”１次受け（＝案件を受注したSIer）をいかに満足させるか”というスタンスを持っていて、３次受けは”２次受けを満足させ、かつ１次受けからクレームが出ないように”というスタンスを持っていて、４次受け以上が存在する場合も繰り返しです…

決め付けたように書いていますが、4次受けだろうと5次受けだろうと”いかに価値を生み出すか”というスタンスが”ゼロ”だと言っている訳ではありません。組織としてある程度は持っているはずですし、人によっては一番に考えているかもしれません。しかし、あじゃりもち の目線では”発注者をいかに満足させるか”というスタンスがどうしても優先される印象がありますし、実際に契約形態がそれを助長するカタチになっています。

問題は、ばらばらのスタンスでスタンスが統一されたチームや組織に勝てるのか？　という点

全員が”いかに価値を生み出すか”というスタンスで仕事をしているチームと、スタンスがばらばらで”いかに価値を生み出すか”というスタンスの人がそもそも開発プロジェクトにほとんど関われていない（顧客のシステム部門が発注者になっている場合、開発期間中にビジネス部門が開発に関わる機会はほとんどない事が多かった）チームや組織があった場合、どちらがより利益を生み出す（＝稼げる）サービスを創ることが出来るでしょうか。

言うまでもなく答えは想像できるでしょう。スタンスが統一されたチームや組織ですよね。

この点で、システム開発を外注している企業の人や、SIerは危機感を感じるべきだと思います。今はまだ、特に日本において、”いかに価値を生み出すか”と言うスタンスに統一されたチームや組織と、大きな企業やSIerのビジネス領域が比較的別れているので問題が深刻化していませんが、内製化が騒がれる昨今、更にAmazonやNETFLEX（恐らく”いかに価値を生み出すか”のスタンスで統一された組織のはず。）といった海外勢が勢いを付けている昨今、スタンスの変更と統一化は急務だと思います。

ではスタンスを”いかに価値を生み出すか”に変更し、組織内で統一するにはどうしたら良いのか？？

１案としては組織構造の見直しが有効だと思います。

システムを外注している企業はビジネス部門とシステム部門を統合し、あじゃりもち の会社のようにプロダクトやプロジェクトの単位で組織を区切る。当然、ある程度人材の再教育は必要になると思います。そして、組織のKPIをビジネス目線でのけKPIに統一するのです。そうすれば役割の垣根を超えてスタンスの統一が図れるはずです。

つづいて、SIerは顧客のビジネス的な成果に対しても責任を持ちます。即ち、システムを納品したら満額もらえるビジネスから、システム開発費を満額もらわない代わりに納品したシステムから生まれる利益の何％かをもらうビジネス（つまり成功報酬型のビジネス）に変更するのです。

これは非常に勇気の必要な変革だと思いますが、
いずれ、こういった組織、ビジネスモデルに変革しないと顧客共に共倒れになる日が来るかもしれません…