読者です 読者をやめる 読者になる 読者になる

プロマネブログ

とあるSIerでプロマネやっているオッサンです。主にシステム開発ネタや仕事ネタ、気になった三面記事ネタの解説なんかしてたりします。

クラウドではなく、ダメな営業がSIerをダメにする理由のような。。。

テクノロジー

クラウドでSIがダメになる本当の理由 - ベテランIT営業が教える「正しいITの使い方、営業の使い方」 - ZDNet Japan

別にアジャイルもDevOpsもオンプレでもやっているし。。。ホスト、オープン系、Webとシステム開発の姿は代わり続けたけど、システム開発自体を続けてきた事実を考えれば、その中堅会社が言ってることも間違いじゃないよ

 

正直、全体的に内容が発散しており、「言いたいことはわかるが何を言っているのかよくわからない」典型的な文章となっているので、感想を書きづらいのですが、部分ごとにコメント欄で書ききれなかった感想を書きます。

 

クラウド技術でSIerの仕事は減るのか?

開発や運用に関わる工数を大幅に減るでしょう。また、求められるスキルやテクノロジーも変わります。予算についての常識もかわるでしょう。開発・テスト・本番以降のワークフローやライフサイクルも変わります。 

 

個人的な予想ですが、おそらくクラウドの導入事例の増加に伴い、SIerの仕事が増加するかと思います。

正確には「単発案件での開発工程での工数が減少するものの、全体としては増加。」を予想しています。

 

正直なこと言うと、現在のIT業界はまだまだ飽和状態に成ってないです。大企業でもシステム化しきれてなかったり、中小企業ではそもそもシステム導入できてないなんてのもザラです。

となると、ツールが洗練化され、開発工数を減少させた結果、単発の仕事は小さくなりやりやすくなる反面、空いた枠を埋めるように今までシステム投資を行えなかったような案件も対象となってくるのではないか、と思われます。

ただし、小規模と言っても、開発工程での小規模軽量化はツール導入などで比較的容易ですけど、要件定義、システム化投資判断、オンプレミスやIaasとの費用対効果比較やアーキテクチャ選定、Saasやパッケージ導入のためのフィット&ギャップ分析等、所謂上流工程については自動化が難しく、工数減少は難しいです。

 

つまり、小規模多量の形で案件をこなすようになり、上流工程については人手不足、開発工程についてはあまり変動なし、ってのが実際のところでは、と考えております。

 

そう考えれば、

「うちはシステム開発しかやっていないので、クラウドになってサーバーが売れなくなっても、あんまり影響ないと思いますよ。」

という中堅企業の意見は妥当かなと。

 

この人はきちんと営業の仕事はしてなかったのだろうか。。。

全体的にですけど、本当に営業の仕事をしたのだろうか、マネジメントをきちんと行ってきたのだろうかと疑問になるぐらい、ヒドイ事例です。

 

クラウドだ、新たな開発手法だと言う前に、営業のスキル向上を行ったほうがはるかに効率的ではないだろうか、と思えるぐらい。

以下、部分部分を指摘します。

 

それを情報システム部門に提示すると、かかる工数と単金の内訳を求められますので、リスク分の工数を膨らませて「これだけかかります」となります。情報システム部門はその数字の妥当性を評価できないまま、「工数がかかることは仕方がない」としか言えず、しかし、「予算もあるので、単金を少し下げてあわせてくれないか」となりSI事業者も結局はその予算の中で請けるしかありません。

オッサンも要件調整することはあるのですが、単価を減らしたことはありません。

※と言うか、単価や工数を提示したことすら無いです。提示するのはちょっとオドロキ。工数や単価など、手の内さらしたら交渉にならないかと。

 

基本は、確度の低い要件を減らす方向で動くべきでしょう。そのための要件調整なわけで。この段階で要件を減らさずに、工数を減らすことが営業として如何なことかと思うのですが。。。

 

要件減らせば、必要になった際に再度追加受注になって売上アップになる、と言った営業戦略は考えても良いかと思います。

 

そんなやり取りを経て、ようやくできあがった要件定義書にSI事業者は合意を求めるわけです。合意といえば美しい響きですが、「この仕様通りに作ります。もうこれ以上変更しませんよ」という宣言で有り、最後通牒でもあるのです。

要件定義後の仕様変更も当然受け付けますよ。。。

大体の場合、追加予算無しでのタダ働きはしないってだけです。

 

元記事にあるように請負契約で契約を結んだのであれば、ゴールを決めた段階=要件定義完了段階で契約締結となります。つまり、要件を変える=ゴールを変更するってことは、契約を変更するってわけですので、追加費用が必要であればそれを請求して開発となるわけです。

 

そして、一通りシステムができあがると、ユーザーも交えたテストが行われるのですが、「もうそんな機能はいらない、これでは使い勝手が悪くて使えない、こちらが要求した機能とは違う」ということになり改修を求められます。

 

上記の通り、機能を減らす方の要求であり、かつ予算に響かないのであればさっさと減らす再契約を結ぶなんてのもザラだったりするわけで。。。最終納品の段階でいらない、なんてなる前に対応をうつなんてのは普通です。こういった変更管理を含めて、顧客との意思疎通を行うためにも営業の顧客コミュニケーションと、プロジェクトマネジメントがあるわけですが。。。

 

要件が変わる、決められない時代、このようなやり方は、本質的に無理があるのです。(中略)

しかし、情報システム部門には、瑕疵担保責任という免罪符があります。しかも、検収・支払いという人質があります。結局は、SI事業者が改修を引き受けることになってしまいます。工数は嵩んでも請負ですから支払いが増えるわけでもなく、利益を減らし、時には赤字になることもあります。

請負契約ですから、要件定義で定めたことについては対応の義務がありますが、そこから外れた変更要件については対応は不要です。逆に対応したら契約違反なわけですが。。。検品段階でユーザともめた場合には、必ず要件定義に記載されている内容かどうかを検証いたします。書いてなければ、前述のとおり改めての契約を締結し、追加対応となるわけです。

こういったトラブル解決のためにきちんと要件定義書などのドキュメントをユーザと合意し、着実に工程を進めるわけですが。。。コレって営業の仕事ですよね。

 

 

まとめ

まあ、いろいろ感想書きましたが、今回の内容は疑問と突っ込みだらけでした。。。

 

SIerへの危機感と、クラウドへの期待が高まりすぎて、微妙な文章となってしまったのでしょうが。。。

 

ふと気になったのが、イマイチSIerの現状認識が古いこと。アジャイルやDevOps云々のあたりとか微妙な記述が気になりました。

この方の経歴を見るに、20年前にIBMを退社されたそうですが、もしかしてその当時のイメージで語られているのではないのかなあ。それじゃあ、今の現場を知っている、中堅SIの話とズレるのもなんとなくわかります。

 

まあ、いくらクラウドや新たな開発手法を導入して生産性を上げたところで、要件定義やマネジメントがダメなら生産性向上を生かせないわけですので、もうちょっとシステム開発全体を見通してクラウドとどう付き合っていくのか、考えたほうが良いかと思います。

 

以上

広告を非表示にする