paiza times

paizaがお届けする、テック・キャリア・マネジメント領域における「今必要な情報」を届けるWebメディア

logo

paizaがお届けする、テック・キャリア・マネジメント領域の「今必要な情報」を届けるWebメディア

SIerの多重請負構造が続く限りプロジェクトの炎上は避けられないという話

f:id:paiza:20110713161732j:plain
Photo by Jeremy Weate
f:id:paiza:20180910132940p:plainこんにちは。倉内です。

サービスの開発では、企画段階からエンジニアに入ってもらい技術的な観点からアドバイスをもらうことで、無駄な手戻りや考慮漏れが減ってスムーズな進行につながります。

paizaの開発でも心がけていることなので、以下の記事の「企画の要件や仕様が決定事項になる前にエンジニアを巻き込もう」という内容はとても納得感がありました。

プロダクト企画にエンジニアを早めに巻き込む(嫌がられずに協力を得る方法) - ykmc09 blog

自社開発の企業では事業系もしくは企画系の部署と開発部署が協力して、目的達成に向けてこういった取り組みができていいですよね。

ところで私は前職でSIerのSEだったのですが、要件定義~設計を自社、開発を外注で完全に分業していたため、仕様を決めてから開発に渡すやり方でプロジェクトを進めていました。その結果、開発工程でいろいろと問題が発生して手戻りや遅延が発生していました。

そこで今回は、「要件定義~設計で開発担当者を巻き込めていない状態を改善すればプロジェクトの炎上を防げるのでは?」ということについて考えてみます。

仕様決定と開発を分業していることの問題点

「元請けもIT企業でSE(エンジニア)なんだから仕様決めて設計する段階で技術的知見が入るじゃないか」と思った方、確かにそのとおりなのですが自分が知る範囲ではなかなかそうは言えない案件も多くありました。

受託開発のプロジェクトでは、ユーザー企業から発注を受けたSIer(元請け)がいて、開発を外注(二次請け、複数社に分散させることも)し、その外注がさらにパートナーに出す(三次請け以降)という体制がよく見られます。元請けが顧客対応・プロジェクト管理・要件定義~設計を担当し、外注に開発を一任という分業制です。

ここで問題になるのは、要件定義~設計を担当する側の技術力が乏しくて、精度が低いまま開発に着手することです。

具体的には、実装工数の見積もりがハチャメチャで到底間に合わないスケジュールになっていたり、技術的に実現が難しい(現実的ではない、確実に予算感が合ってない)ものが普通に盛り込まれていたり、全然考慮が足りていない機能があったり…。

上記の問題に対して開発者から指摘が入ったとしても受託開発では納期が決まっているので、「そうは言っても納期はもうお客さんと合意取っちゃってるから」となります。

そのまま開発を進めていくとどうなるかと言うと……初めから無理があるので開発工程において長時間残業や休日出勤、とにかく人をかき集めてなんとか間に合わせようとするデスマーチ進行が発生するのです。

情けない話ですが、炎上プロジェクトの火消しに駆けつけてもらった、仕事がめちゃくちゃできる開発担当の方に「要件定義とは言わない、せめて設計段階でプロジェクトに入れてもらえればここまで酷いことにはならなかった。次回以降検討してほしい」と切実に言われたことがあります。

なぜこんなことになってしまうのか

上流工程の段階では外注先が決まっていないことが多い

特に期間が長いプロジェクトだと要件定義~設計で1年以上かけることもあり、その時点では開発をどこに依頼するか決まっていません。

外注先とは基本的に開発工程からの契約になっていることが多いのでその前の工程で相談することが難しいんですよね。なので「要件や仕様を決定する前に開発者を巻き込む」っていうことが多重請負の構造下では難しいです。

もちろん元請け側が技術力をつけて、上流工程でしっかり技術的に実現可能か、どんな技術や手法を採用するともっともよいかなど検討できれば問題ないのですが…。年次が上がるほどプロジェクトを管理する側になりプログラミングからは遠ざかっていくので厳しいと言えそうです。

受託開発は基本的にウォーターフォール型

ウォーターフォールが原因というより、ウォーターフォールかつ工程で分業しているからが正しいかもしれません。

ウォーターフォールでは、前の工程が完了してから次の工程へ進みます。つまりすでに決まったことをあとの工程で柔軟に変更することができません。そのため開発担当に渡す前に仕様は確定させておく必要があります。(現実には顧客都合で開発を進めてからの突然の仕様変更もありますが…)

1つめに挙げた内容と合わせて考えると、要件定義や設計をする段階では開発担当が決まっておらず、今の工程(要件定義~設計)を完了させないと次の工程(開発)へ進めないということになります。

実際のところほとんどコーディングをしたことがないという人が上流工程で工数やスケジュール、採用する技術や機能実装で考慮すべき点を正しく見積もるのはかなり難しいです。

開発者の意見を上流工程で入れる必要があると認識していない

開発を「SEが作った設計書に従ってPGが分担してこなすもの」「遅延は人を増やすことで回復できる」という考えの人は少なからず存在します。

そういった人がプロジェクトの重要なポジションにいると、そもそも開発工程で発生した遅延や手戻りなどの問題を上流工程が原因とは認識しないので、何度も炎上を繰り返すことになります。

合わせて開発側は「決まっていること・指示されたことをやるだけでモチベーションが上がらない」という状況に陥ってしまいます。

また、特に三次請け・四次請け…と階層の深い位置する開発者はシステムの全体像を把握できないまま細分化された一部分のみを担当するため、なかなかスキルアップが望めないという問題もあります。

プロジェクト費用を抑えて利益を確保するため

受託開発で高い利益を出せるかどうかは、いかにプロジェクトにかかる費用を抑えるかにかかっています。

そもそもの問題でもありますが構造的に元請けの単価が高く、下請けの階層がおりていくほど単価が低くなっているという現実があります。そのため単価の高い元請けの社員で作業をするより、外注したほうが費用を抑えられます。

また、システム開発のプロジェクトは常に一定の要員が必要というわけではなく、開発のピーク時だけ大量の人が必要で、それ以外では人を抱えておけない(抱えておきたくない)という事情があります。元請け側からすると、自社だけでプロジェクト要員を確保するのはリスクが高いのです。

自社開発と違ってリリースしたサービスのヒットに左右されることはないので、受注した金額内でどうやってうまくやるかがすべてです。

ということは…余計な原価がかかるようなことをわざわざしたくないというのが本音になってきます。

どうすれば仕様決定と開発を分業せずに済むのか

元請けで要件定義~設計~開発を担当する(外注しない)ことが一番いいはずです。

しかし現実には、開発を自社で担当するという決断をするのは難しいのではないでしょうか。大規模システムの開発で必要工数をまかなえる人数を確保できるか、そもそも開発できる技術力がある人材がいるか、など課題が多いと思われます。

もしくは開発担当者が上流工程から関わるというのも考えられますが、外注先の立場からするとそれを実現させるのは困難です。仕様決定も見積もりも終わった段階で突然プロジェクトに放り込まれる案件ばかりの場合どうしようもないからです。

今でも前職の同僚に会って話を聞くことがありますが、多重請負構造は簡単には解消されることはないと思いますし、個人がそれを変えていくというのは途方もないことです。

なので、もしこの構造の中でやりきれない思いをしているならエンジニアとしてスキルが評価され、またそれを生かして働くことができる環境を自分で探すことも大切です。

たとえば、多重請負でない受託開発をしているところ、もしくは自社でサービス開発をおこなっているところに転職するというのもひとつの選択肢になってきます。

paiza転職では、「自社製品/自社サービス」を条件指定して求人検索できるだけでなく、下図のように自分が興味ある分野に絞って求人を探すことができます。

プログラミングスキルチェック問題を解いて規定のランクを取得できていれば求人応募可能で、最初の書類選考なしで応募先企業と面談できます。

スキルチェック問題について、詳しくはこちら
paizaのスキルチェック
 

まとめ

システム開発プロジェクトにおいて、仕様決定と開発を分業していることの問題点とその原因について見てきました。

このブログで初めてIT業界の多重下請構造について言及したのは2014年です。確かにそのときから改善された部分もあるとはいえ、相変わらずな部分も多いですよね。

いずれユーザー企業が内製するようになり、SIerの仕事はなくなるとずっと言われてはいますが…おそらく直近で受託開発がなくなるとは考えにくいと思います。

自分が公共系システムを担当していたこともあってよく分かるのですが、公共や社会インフラに関わるシステムは規模が大きく非常に仕様が複雑なため、ユーザー企業が完全に自身で内製(保守・運用含む)できるようになるまでにはまだ時間がかかります。

ただ、内製を基本とするユーザー企業が増えてきたのは事実ですし、これまでシステム開発をSIerに依頼(SIerは仲介役)していた企業が、スマホアプリの開発やRPA導入を直接ベンチャー企業に依頼しているといったニュースもよく見かけます。

目の前の業務に追われているとなかなか難しいのですが、これから先どのような変化が訪れてもエンジニアとして活躍できるように備えておくことが大切です。


paiza転職は、転職時のミスマッチをなくし、エンジニアがより技術面にフォーカスしたやりがいある仕事を探せる転職サービスです。

プログラミングスキルチェック(コーディングのテスト)を受けて、スコアが一定基準を超えれば、書類選考なしで複数の会社へ応募ができます。

paiza転職について詳しくはこちら
paiza転職





paizaラーニング」では、未経験者でもブラウザさえあれば、今すぐプログラミングの基礎が動画で学べるレッスンを多数公開しております。

詳しくはこちら

paizaラーニング

そしてpaizaでは、Webサービス開発企業などで求められるコーディング力や、テストケースを想定する力などが問われるプログラミングスキルチェック問題も提供しています。

スキルチェックに挑戦した人は、その結果によってS・A・B・C・D・Eの6段階のランクを取得できます。必要なスキルランクを取得すれば、書類選考なしで企業の求人に応募することも可能です。「自分のプログラミングスキルを客観的に知りたい」「スキルを使って転職したい」という方は、ぜひチャレンジしてみてください。

詳しくはこちら

paizaのスキルチェック

paizaのおすすめコンテンツ

PPG proken プログラミングゲーム「初恋 プログラミング研究会〜海に行こうよ〜」 PPG Bingo プログラミングゲーム「コードレビューBINGO!!」
paiza転職 paiza新卒 EN:TRY paizaラーニング 記事内に記載している情報は、記事公開時点でのものとなります。 Copyright Paiza, Inc, All rights reserved.