GLOBAL SHIFT’s Blog

IT・WEBエンジニアのキャリア相談/転職支援サービス【TechLeadCareer|テックリードキャリア】(career.techlead.jp)を運営するグローバルシフト株式会社のブログ

経営者や事業責任者なら知っておいて欲しい、単価150万円と70万円のIT系エンジニアの違い

グローバルシフト株式会社、代表の小川です。

弊社のエンジニア・デザイナーの皆さんの働きで、なんとか直近のシステム開発プロジェクトも納期通りのリリースを迎えられそうなので、1週間ぶりにブログ更新します。

今回は、少し前のはてブで盛り上がっていた、以下の記事について考察して行きたいと思います。

togetter.com

*いつも通り、このブログにおける「エンジニア」とは、IT・WEB系の開発業務に従事されているエンジニアを指します。

件のつぶやきは何を伝えたかったのか?

オリジナルのTweetは、以下のように呟かれていました。

概要は「人月単価150万円のエンジニアの方に依頼したら2週間で終わった仕事が、単価の高さを理由に調達部門から取引先の変更を指示され、変更した取引先の人月単価70万円のエンジニアの方は(恐らく)同じ仕事に6ヶ月かかった」という事かと推察されます。

【人月単価】: エンジニアの方と期間による業務委託契約した際の、一ヶ月あたりの費用。期間契約ではなく、成果物作成の請負契約の場合、人月単価を平均稼働日数20日で割った人日単価の場合もあれば、単発作業のためそれよりも人日単価が高額になるケースもある。

人月単価150万円のエンジニアの方が2週間で終えた仕事について、「75万円の費用で済んだ or 150万円の費用を払い残り2週間の仕事はなかった」の言及がないため正確な比較は難しいのですが、仮に前者だとすると「75万円/2週間 vs 420万円/24週間」と言う比較となり、恐らく小学生でも前者の人月単価150万円のエンジニアを選択するのではないでしょうか?

中立性を保つために補足をすると、Tweetを行なった方は以下のように注記を入れられており、現実には「75万円/2週間 vs 420万円/24週間」という単純比較ではない事も付け加えておきます。

”別ツイートでも言ってるけど、発注の継続性が安定したのでトータルコストが上がったとは言い切れないし、管理費やリスク考えると損とは言い切れないんだよ”

恐らく、人月150万円のエンジニアの方はフリーランスか非常に忙しい方で、いつも仕事の委託が可能なわけではなく、また大きな法人でないため取引の安全性も低い、と言うことが示唆されていますね。

多くのエンジニアが同意する「優秀と凡庸の間にある数倍のパフォーマンス差」

このTweetは非常に多くの反響を呼びました。

コメントの記載内容やそのニュアンスから、多くの方がエンジニアの方である事が推測されますが、大半の方が優秀なエンジニアとそうでないエンジニアとのパフォーマンスの差に共感を示すと共に、その事実に対する非エンジニア職種(決裁者や調達部門など)の理解の無さに対する嘆きにも似たコメントが多数寄せられていました。

私も上記について全くの同意見です。
ここで、私が上記のような意見となるきっかけとなった過去の体験を共有したいと思います。

【過去の体験】

  • 概要: WEBアプリケーションの開発プロジェクト (私はOJTで未経験として参加)

  • 状況: 業務委託の開発リーダーが顧客をファシリテーションできず、要件定義・基本設計で計画に対し3ヶ月遅延。計画上の開発フェーズ期間はテストを含め4ヶ月で、遅延を考慮すると残り1ヶ月しか残されていなかった。

  • 結果: 当時の所属は大手企業で、社内向けの技術開発グループから優秀な若手エンジニア3名が火消し役として派遣された。まともな設計書もない中、ホワイトボードを中心に座席を配置し、大まかな構成と仕様をホワイトボードに記載。主要なクラス設計や共通モジュールの作業分担を口頭で行い開発着手、わずか3週間で開発完了。

  • 所感: 初めてのシステム開発プロジェクトでしたが、一口にエンジニアと言ってもそのスキルやパフォーマンスに大きな差がある事を深く理解しました。

  • 補足: 人月単価は、火消し役2名は若手のため150万円前後、もう一名はリーダークラスで200万円前後だったと記憶。一方、業務委託の開発リーダーは90万円前後でその他委託メンバーは70万円前後であり、今回のTweetのケースと比較的に近い状況だったと思います。

私が過去のシステム開発に纏わる仕事において、大きな失敗もなく進めてこられたのも、優秀なエンジニアがプロジェクトに与えるインパクトの大きさを、この体験から身をもって学んだからに他なりません。

なぜこの様な事が起きてしまうのか?

Tweetにも「調達部門」と記載がある通り、呟かれた方も一定の規模の組織に所属されている方かと推測されます。

調達部門などが出来ると、社内規程で「必ず3社に相見積りを行い、合理的な理由が無ければ低価格の取引先を選択」のようなルールが生まれ、ほぼ強制的に従わなければならなくなるのは容易に想像がつきます。

また、個別のエンジニアのコストパフォーマンスを合理的に説明出来れば良いのですが、そもそも決裁者が低コストを重視し過ぎていたり、調達部門がエンジニアの技術評価を適切に出来ない事がほとんどのため、発注を依頼するエンジニアの方の社内における発言力がよほど強くない限り、Tweetの様な不幸な出来事が生まれてしまうのです。

そして、その様な不適切な意思決定の影響を受けた社内のエンジニアの方のモチベーションが著しく下がり、いずれ退職してしまうであろう事も容易に想像がつきます…。

ではどうすれば良いのか?

この問題を解決する事は、非常に簡単です。

まず、自社のエンジニアの方の目利きを信じてあげて下さい。少なくとも、技術理解の無い経営者や調達部門よりは精度の高い選択をされるはずです。

自社にエンジニアや、技術の分かるスタッフがいない場合は、外部の方に技術顧問という形で、部分的に業務をアウトソースすると良いと思います。因みに、私たちグローバルシフト株式会社でも、技術アドバイザリーサービスを提供しておりますので、お困りの際は是非ご相談下さい。

globalshift.co.jp

また、初見の取引先・エンジニアの方の場合、期待した成果が上がらず選択を誤る事が、私たちも含め少なからずあります。

これは、一定程度発生する事は仕方がないのですが、この様な初見の方との取引についても、出来る限り小さくすぐに評価しやすいお試しの仕事を依頼してみて、本当に自社が求める取引先なのかどうかを判断してはいかがでしょうか。

最後に

いかがでしたか?

Tweetに対するコメントでも、現役のエンジニアと思われる方々から「よくある!」といった声が多かった事からも、多くの企業・開発プロジェクトで起きている事ではないかと思います。

もしあなたが経営者・事業責任者・調達部門担当者などの決裁者であったなら、このような事が過去に無かったか胸に手をあてて振り返ってみてはいかがでしょうか?

日本のエンジニアの給料を上げるために必要な事

グローバルシフト代表の小川です。

「エンジニア*の給料上がらない問題」が話題となっているようです。

president.jp

*ここでは、日本のIT・WEBエンジニア、WEBアプリケーションエンジニア、ソフトウェアエンジニアなどの、IT系エンジニアを「エンジニア」として表記し、話を進めます。

IT・WEBエンジニア専門のキャリア相談・転職支援サービス ”TechLeadCareer” を提供する私たちも、この問題について考察してみたいと思います。 

 

日本の「エンジニア」の給料が低い、という意見の前提に関する考察

日本の「エンジニア」の給料を、中国の一部の超大手企業の「エンジニア」給与や、アメリカ国内の「エンジニア」と単純比較をする前に、比較の前提を整理すべきではないでしょうか?

  • 中国やアメリカの超大企業やユニコーン企業との比較

大前さんの記事で比較対象として挙げられていた中国の「ファーウェイ(華為技術)」や、優秀なインド人をヘッドハンティングする「グーグルやフェイスブック、Amazonなど」が、高い報酬で世界中から優秀な「エンジニア」を集めていることは事実です。

しかし、「給料が上がらない」と比較対象に挙がった日本の「エンジニア」というのは、本当に日本における「ファーウェイやグーグル、フェイスブック」に位置付けられる企業に所属する「エンジニア」なのでしょうか?

(とは言え、前述の外国企業の給料はかなり高騰していると思いますが...)

  • VCやエンジェルなどのリスクマネーの規模の違い

記事では言及されていませんでしたが、日本とアメリカで生まれるスタートアップ企業の数や、VCやエンジェル投資家からの資金調達規模の違いも大きな違いがあると思います。

近年では、日本のスタートアップでも数億円規模の資金調達は珍しくなくなってきたものの、アメリカのスタートアップと比較すると一桁、二桁金額が違いますし、スタートアップ企業の数自体が、その背景にあるリスクマネーの規模と比例して、日本とアメリカで大きな開きがあると感じています。

当然、資金調達金額の大きなアメリカのIT系スタートアップでは、初期の段階から「エンジニア」にも高い給料を支払う原資があるため、給料の差に表れるのではないかと思います。

  • 「エンジニア」が所属する企業属性の違い

日本とアメリカの「エンジニア」がそれぞれ所属する企業には、その属性に大きな違いがあります。日本の「エンジニア」は、受託開発企業に所属する割合が相対的に高く、人月単価の上限が給与水準を規定する傾向にあります。

逆に、アメリカでは事業会社に所属する「エンジニア」の割合が多く、グーグルやフェイスブックなど世界的に事業展開する巨大で高収益な企業が多いため、事業収益の規模や人材の需給バランスで「エンジニア」の給与水準が押し上げられていると思います。さらに、付加価値の低い業務はインドやフィリピンなど、英語圏の人件費が安い国にオフショアで業務委託するため、アメリカ国内の「エンジニア」の平均給与をさらに押し上げる要因になっており、企業属性を揃えた比較を行う必要があると思います。

  • 解雇規制の違い

日本とアメリカで比較した場合、日本は労働者が強く保護されており、昔から存在する企業では退職金制度も充実しているため、見えない報酬や採用ミスのリスク回避の観点から、相対的に給与が低く抑えられる傾向があると思います。

逆に、アメリカでは企業業績や景気の動向によって、比較的多くの雇用調整(レイオフ)が可能な環境であり、業績が良く成長の展望がある企業は優秀な「エンジニア」を、高い給料や福利厚生で積極的に採用しやすいため、単純な比較が難しいと思います。

※法規制・解雇規制の詳細なファクト調査は行っていないため、誤った認識があるかもしれません。その場合、ご指摘いただけると幸いです。

 

前提条件が揃えば、日本の「エンジニア」の給料も上がるのか?

結論から言うと、日本の「エンジニア」も給料上がります!

と言っても、まずは比較対象となる「エンジニア」の企業属性の絞り込みや、現在の日本のような正社員にとって安定した雇用環境を劇的に変える、という前提の話ですが...。

  • 比較対象とする「エンジニア」を都市部の事業会社だけに絞る

日本でも近年、空前の「エンジニア」不足の状況にあるため、事業会社における「エンジニア」の給与は上昇を続けていると思います。

恐らく、東京の事業会社に所属する「エンジニア」に絞れば、平均給与は600万円前後まで上昇するのではないでしょうか?

  • 解雇規制を緩和し、「エンジニア」雇用の流動化を実現する

解雇規制が緩和され、企業が雇用リスクを感じなくなれば、現在多くの事業会社で一般的に活用されている、社内常駐の業務委託エンジニアに支払うフィーと同程度の給料まで引き上げられる可能性が高いと思います。

月額60万円の委託費の場合:年俸660万円 = 60万円 x 1.08* x 12ヶ月 x 85%*

月額80万円の委託費の場合:年俸881万円 = 80万円 x 1.08 x 12ヶ月 x 85%

*消費税(1.08)、及び企業の社会保険負担率(15%)

つまり、アメリカと同様に雇用の流動化が進めば、理論上、現在の日本企業でも業務委託費用に近しい水準で報酬を支払うことが可能であると思います。(その分、レイオフリスクは当然高まります)

 

前提条件を揃えても、アメリカの3/4程度。日本の「エンジニア」の給料を、世界のトップ企業レベルまで引き上げるためには?

比較対象とする日本の「エンジニア」を給与水準の高い都市部の事業会社に絞り、解雇規制の緩和まで行っても、まだ日本の「エンジニア」の給料はアメリカの3/4程度までしかポテンシャルがありません。

では、どうすればアメリカや中国の超大企業やユニコーンに所属する「エンジニア」と、同じレベルの給料水準に引き上げることができるのでしょうか?

  • 海外と同様、海外市場を見据えたスタートアップの増加とそれを支えるリスクマネーの拡大

当たり前の話になってしまいますが、日本の「エンジニア」にも高い水準の報酬を支払えるようになるためには、それに見合った企業収益をあげる将来的な超大企業・ユニコーンが増加する必要があると思いますし、チャレンジする起業家を支えるリスクマネー・エコシステムの広がりも必要となるでしょう。

  • 付加価値の高い「エンジニア」の増加

付加価値の高い「エンジニア」の増加には、 2つの視点があると考えています。

一つは、既に現時点で十分な付加価値を創出しているにもかかわらず、正当に評価されていない「エンジニア」の評価を是正することで、付加価値の高い「エンジニア」を増加させる、ということです。

企業経営者や「エンジニア」の評価者にあたる人の技術理解度の問題で、あるいは「エンジニア」自身が、創出した価値をビジネスにおける価値に置き換えて説明できていないと言った要因で、正当に評価されていない「エンジニア」が日本にはまだまだいるのではないでしょうか?

こちらのブログでも、「エンジニア」が自分が創出した価値をビジネスにおける価値に置き換えて説明できていない、と言うことを非常に分かりやすく解説されています。

なにがエンジニア(の書くコード)の価値を決めるのか - NAEの仕事効率化ノート

 

もう一つは、現在の日本における「エンジニア」の中に、企業が求めるレベルでの付加価値の高い仕事をされている方がまだ少ない(と感じる)ため、付加価値の高い仕事の出来る「エンジニア」の数そのものを増加させる、ということです。

私たちは、IT・WEBエンジニア専門のキャリア相談・転職支援サービス ”TechLeadCareer” を提供しております。先ほど”空前の「エンジニア」不足”と記載したものの、有名企業や成長企業の「エンジニア」採用では、「エンジニア」であれば誰もが簡単に転職できるわけではない、という現実を日々目の当たりにしています。

これまでの日本では、受託開発を中心とした「相手の要望に沿ったシステムを作る」と言う仕事が多かったためか、事業会社におけるビジネスの戦略や目標を理解し、その実現や達成に貢献すると、という視点・姿勢を強く持った「エンジニア」の方がまだまだ少なく、世の中の需要に対して不足していると感じています。

最後に

いかがでしたか? 

もしあなたが、現状の評価が不当に低いと感じているようでしたら、一度 ”TechLeadCareer” に相談に来ませんか?もちろん、転職前提でなくてもOKです。

私たちは、付加価値の高いIT・WEBエンジニアを一人でも多く日本に増やすため、あなたのキャリアを徹底的にサポートします!

career.techlead.jp

 

防火シャッターでも防げなかった?文化シャッターのシステム開発プロジェクト炎上の考察

グローバルシフト株式会社、代表の小川です。

2月13日のはてなブックマークの人気エントリーに、以下のような衝撃的な見出しが踊りました。

▼はてなブックマーク b.hatena.ne.jp

▼元記事
[特報]27億円の賠償巡り新たなIT裁判始まる、文化シヤッターが提訴 | 日経 xTECH(クロステック)

私たちが提供する、IT・WEBエンジニアのキャリア相談・転職支援サービス「TechLeadCareer」のtwitterアンケート企画「#エンジニア世論調査」でも、時を同じくしてシステム開発プロジェクトの状況についての調査を行っており、その調査結果でも今回の記事と同様に多くの開発現場でプロジェクトが炎上していることが推測される結果となりました。

上記の調査結果や、私が過去に体験した炎上プロジェクトの経験を併せながら、今回の記事に登場した文化シャッターのシステム開発プロジェクト炎上を考察してみたいと思います。

システム開発プロジェクトにおいて遅延・炎上は決して珍しくない

2003年10月〜2008年8月の間、私はIBMビジネスコンサルティングサービス株式会社(現日本IBM)という企業に所属していました。その間、参画した数件のシステム開発を伴うプロジェクトは、大半が大幅な遅延もしくは炎上と呼ばれるような手がつけられない状況に陥っていたと記憶しており、同期が配属された他のプロジェクトも似たり寄ったりでした。

また、私たちが実施したtwitterアンケート企画「#エンジニア世論調査」によると、「現在開発しているプロジェクトの状況は?」というテーマに対し、全体の約80%(全8,506回答中)が”遅延 or 炎上中”という回答が寄せられました。

さらには、日経コンピュータによるプロジェクト実態調査が2003年と2008年に実施されていますが、クライアント視点で失敗と評価されたプロジェクトは約70%という調査結果も出ています。

これらを見る限り、システム開発プロジェクトを行う際には、遅延・炎上が発生する事は決して珍しいことではない、という事が言えるのではないでしょうか。

なぜシステム開発プロジェクトは炎上するのか?

当然の事ながら、プロジェクト毎に開発内容や体制など前提条件がそれぞれ異なるため一概に論ずる事は難しいのですが、私の経験やブックマークのコメント欄で言及されていた内容を整理すると、以下の3つの内容に要約できるのではないかと思っています。

  • 過剰なセールストークで決まる、安易な流行の採用
  • ゆるふわな企画(計画)が引き起こす、要件バブルと不良債権問題
  • 欠落したベンダーのプロフェッショナリズムと、不十分なクライアントのオーナーシップ

それでは、それぞれの内容について詳しく考察を行っていきたい思います。

過剰なセールストークで決まる、安易な流行の採用

システム開発の営業・提案活動において、システム開発に関する経験・深い理解の無い営業担当者が行う、クライアントへの過剰なセールストークや技術的な裏付けの無いその場だけで決まった口約束は、その後の開発プロジェクトをスタート前から失敗に導くことになります。

今回の記事に「セールスフォース(SF)の導入にもかかわらず95%をカスタマイズ」「開始当初はアジャイル+ウォーターフォール(WF)」といった内容が記載されています。

技術選定の背景やその目的が定かでないため一概には言えないのですが、「はやりのクラウドで開発したい(しましょう!)」「アジャイルやりたい(やるべきです!)」といった感じで、これまでの開発プロジェクトとの差別化を図ろうとした結果、話の流れの中で手段が目的にすり替わり、最終的にプロジェクトがキックオフされるに至ったのではないかと推測しています。

一方、大手の開発ベンダーであれば、社内に提案内容を精査するリスクマネジメント部門・機能があると思います。

当然リスクマネジメント部門は「95%をカスタマイズするならパッケージ・クラウドの意味がない」など、真っ当な指摘をされたことかと思いますが、大規模なシステム開発案件が少なくなってきている昨今、受注を確実なものにするため、様々なリスクヘッジ策を講じることを条件にGoサインを出してしまうのではないでしょうか。

残念ながら、リスクヘッジ策が適切に講じられることはほとんど無いに等しく、システム開発現場のエンジニアやクライアント担当者が疲弊し、最終的にプロジェクトは頓挫することになります。

ゆるふわな企画(計画)が引き起こす、要件バブルと不良債権問題

ここで言う「企画(計画)」とは、プロジェクトの目的やゴール、対象システム(サービス)の内容と開発範囲、マスタースケジュールや各開発フェーズの定義、ステークホルダーの役割と責任、及びトレードオフを伴う意思決定事項の基本方針などが取り纏められたものを指します。また、ゆるふわな企画(計画)とは、要件定義を行う前の段階で「前述のような企画内容がシステム開発の要件定義を行うのに、十分なレベルで明確になっていない」という事を意味しています。

この「ゆるふわな企画(計画)」は、まずプロジェクトの序盤である要件定義フェーズで”要件バブル”を引き起こします。

プロジェクトの根幹となるしっかりとした企画(計画)が固まっていないため、要件定義を進めていく中で「あれもやりたい、これもやりたい」「こんなユーザーがいるかもしれない、こんな使い方も用意しなければ」と、無限に要件(の候補)が膨れ上がることになります。その結果、本来時間をかけて詰めるべき大事な要件に対して、十分な調査・検討時間をかけられず、要件定義が緩いまま次のフェーズへ進まざるを得なくなるのです。

今回の記事の中でも「要件定義フェーズ、設計フェーズの遅延に伴う開発フェーズの期間圧縮・テスト検証不足」がバグ発生の原因として挙げられています。この「要件定義フェーズの遅延」を生み出している大きな要因の一つが”要件バブル”であり、「企画(計画)」が不明確なままに要件定義フェーズを進めている事に他ならない、と私は考えています。

また「ゆるふわな企画(計画)」の影響は、要件定義フェーズにとどまりません。

”要件バブル”の影響で生み出された、”要件定義の不良債権”という名の様々な隠れた要件・仕様が、やっとたどり着いたプロジェクト終盤のユーザーテストであぶり出され、勢いよく一気に火を噴くことになるのです。

欠落したベンダーのプロフェッショナリズムと、不十分なクライアントのオーナーシップ

ここまでは、システム開発プロジェクト炎上の要因が、より上流の営業・企画(計画)策定フェーズから生み出され、プロジェクトの炎上にどのような影響を及ぼすのかを整理してきました。

しかし、システム開発プロジェクト炎上の最も大きな要因は、もっと根本的な別の要因にあるのではないかと私は感じています。それは、このトピックで言及する「欠落したベンダーのプロフェッショナリズム」と「不十分なクライアントのオーナーシップ」に他なりません。

「欠落したベンダーのプロフェッショナリズム」とは、前述した「過剰なセールストークで決まる、安易な流行の採用」と「ゆるふわな企画(計画)が引き起こす、要件バブルと不良債権問題」において、開発ベンダーがプロフェッショナルとしての役割を十分に果たせていない、という現状を指しています。プロジェクトの目的に即していない技術の適用方法や開発アプローチの提案はもってのほかであり、仮にクライアントから不合理なソリューションの提案を求められたとしても、プロとしてメリット・デメリットを整理し、正しい意思決定をサポートすべきであると考えます。

では、システム開発プロジェクト炎上の要因は、全て開発ベンダーにあるのでしょうか?

私は決してそうは思いません。

過去、私が開発ベンダーサイドの人間としてシステム開発プロジェクトに参画していた時に、炎上プロジェクトに共通して感じるある違和感の存在に気付いた事があります。それは、クライアントサイドのプロジェクトメンバーの中に「自分達のシステムを作っている。絶対に成功させるんだ」という当事者意識を持ち、主体的にプロジェクトを進めているメンバーの比率が圧倒的に少ない、という事です。

もちろん、クライアント全てがそうと言うわけではないのですが、ここで言う「不十分なクライアントのオーナーシップ」とは、炎上プロジェクトには必ずと言って良いほど「主体的に意思決定できず、問題を先送りにする」方や「建設的に議論を進めずに、常に批判的な姿勢で悪戯に検討を長引かせる」方々の存在があり、クライアントのプロジェクト成功に対するコミットメントが不十分である、と言わざるを得ない状態を指しています。

今回の記事に対するブックマークコメントでも「クライアントの丸投げ体質」に関する言及や、「既存システムをそのまま新システムにリプレイスしようとしていたのでは?」といった、プロジェクトの目的自体が正しかったのかについての問題提起が見られました。クライアントサイドに十分な当事者意識・オーナーシップがあればこのような事態にならないのではないか、という意見には私も同感です。

どんなに課題を抱えたプロジェクトでも、ベンダー・クライアントのいずれかが責任を持って行動していれば、納期のリスケジュールやスコープの縮小、あるいはプロジェクト途中での開発ベンダーの変更など、開発プロジェクトが頓挫する前にできる対応は多々あると思います。

本件は恐らく、双方が課題を抱えたままプロジェクトを進め続けてしまったがために、修復不可能な状態まで大炎上してしまった、典型的な失敗プロジェクトであると推察されます。

どうすればシステム開発プロジェクトは炎上しないのか?

私たちグローバルシフトでは、所属するエンジニアの技術力向上・経験の蓄積を目的として、スタートアップやベンチャー企業の新規システム開発・システムリニューアル開発の案件を中心に、事業の一部としてシステム受託開発を行っています。

その際、私が過去に経験した炎上プロジェクトの要因分析から、各要因に対して以下のような考え方・取り組みでシステム開発プロジェクトを進めています。

「過剰なセールストークで決まる、安易な流行の採用」 への対策

私たちから、クライアント受けを狙った流行の技術・アプローチを、過剰なセールストークでお勧めすることはありません。

最近は「クラウド」「アジャイル」という流行りのキーワードをやりたいとご相談頂く事もあるのですが、プロジェクトの目的や開発内容の特性をヒアリングした上で、安易に適用すべきでない場合にはその理由と共にはっきりとお勧めしない旨をお伝えします。

確実にプロジェクト炎上リスクを高めるだけの場合には、開発のご依頼自体をお断りする事もありますし、クライアントが新しい技術・アプローチを適用したい理由がリーズナブルな場合には、しつこいと思われる程に想定されるリスクや影響をご説明した上で、両者合意の下で開発プロジェクトを進める事もあります。

何れにしても、提案を行うベンダーもそれを評価するクライアントも、耳障りの良さや目新しさに高い価値を置くのではなく、本質的なプロジェクト価値に目を向け、その実現可能性を最大限高めるアプローチを共に策定・合意できない限り、今後も本件のような不幸な開発プロジェクトは後を絶たないと思います。

「ゆるふわな企画(計画)が引き起こす、要件バブルと不良債権問題」 への対策

「サービスを早くローンチし事業を推進したい」という本気の意気込みで、見積依頼をいただく事があります。経営者・事業責任者の意思は本物なのですが、企画(計画)に曖昧な部分が多く残っていたり、アイデアレベルという事も少なくありません。そのような場合私たちは、企画・構想策定支援のコンサルティング(2週間~1ヶ月)をご提案させて頂き、クライアントの想いやアイデアを明確な企画(計画)に一緒に落とし込んでいきます。

企画(計画)を一緒に策定する中で、システム・サービスの目的や機能の重要性・優先度の確認、トレードオフが発生した場合の優先するQCDの観点などについて合意形成を行うため、要件定義フェーズで”要件バブル”が発生しそうになっても、「これらの要件(候補)は重要性も低く、納期を優先させるためには初期リリースの範囲から外し、リリース後の検討にしましょう」といった形で、クライアントとの共通認識のもとに”要件バブル”を防ぐ事が出来るようになります。

また、要件の不良債権を後続フェーズに残さないため、プロジェクトの上流工程(企画や要件定義)であっても、可能な限り仕様の定義を具体的且つ明確に行うように心掛けています。この点は賛否両論あると思いますし、クライアントによっては実際に動かせるプログラムがないと、イメージが湧かず定義しづらいという声も実際にあります。

しかし、クライアント自身が開発を望んでいるシステムに対し、自分事として具体的なイメージを早期に持っていただく機会を作ることは、開発サイドとの認識齟齬や隠れた開発要件の炙りだしに有効であると私たちは考えており、クライアントの皆様には時折面倒に思われながらも、ご理解とご協力を頂いています。

「欠落したベンダーのプロフェッショナリズムと、不十分なクライアントのオーナーシップ」 への対策

自社のメンバーに要求する高いプロフェッショナリズムは当然のこととして、私たちはそれ以上にクライアントのオーナーシップや本気度、根拠に基づくリーズナブルな意思決定を許容されるタイプかどうかの見極めに重点をおいています。

極論・暴論にはなりますが、クライアントのオーナーシップが低かったり、根拠のないこだわりや気分による意思決定に固執されるタイプのクライアントの場合、プロジェクトの炎上・失敗リスクは飛躍的に高まります。そして、何よりも一緒に仕事を行うパートナーとして、このようなタイプのクライアントと仕事をする事以上に、自分達のモチベーションを下げる事が他に無いからです。

グローバルシフトは2015年の創業以来、幸いにも友人や知人、クライアントの皆様に恵まれ、全ての受託開発案件をご紹介・追加発注という形で継続的にいただいております。

また、過去にプロジェクトをご一緒したクライアントからは、さらにその友人・知人の会社をご紹介頂く事も多く「これほど信頼できる開発パートナーはこれまで会った事がない。ここに任せればスムーズにプロジェクトが進み、サービスをリリースできないという事はない」と、最高のご推薦文と共に繋げていただく事もありますが、このような評価が頂けているのも「システム開発炎上の要因に対し、課題が顕在化する前から一つ一つ丁寧に課題解決に取り組んでいるから」ではないかと考えています。

最後に

システム開発プロジェクトの炎上や失敗は、クライアント・ベンダーなど全てのステークホルダーにとって不幸な事であると思います。そして、プロジェクトがスタートを切る時点で、システム開発プロジェクトの炎上・失敗を望んでいるプロジェクトメンバーは、誰一人いないはずです。

今回の考察が少しでもシステム開発プロジェクト関係者の目に触れ、今後の開発プロジェクトにおいて少しでも遅延・炎上の解消に寄与すれば幸いです。

本件のプロジェクトメンバーの皆様、特に現場で日々残業・長時間労働を行い、なんとかプロジェクトを成功させようと身を粉にされたエンジニアの皆様、本当にお疲れ様でした。