「SIをダメにする負のスパイラル」

きしだൠ(K1S) @kis

「SIをダメにする負のスパイラル」っていうタイトルのブログ思いついた。だれか書いて

きしだൠ(K1S) @kis

SIの、元請はユーザー企業の業務をよりよくするために、プロダクトを作るんじゃなくて契約書をつくる。で、元請はそれを下請けにつくらせるんだけど、そのときはユーザー企業の業務をよりよくするためではなく契約を満たすためにプロダクトを作らせる。これが負のスパイラルの発端。

きしだൠ(K1S) @kis

契約を満たすことが目的でプロダクトを作ってるから、実装段階で気づいたアイデアや欠陥は報告されない。納期や金額なんかの契約は満たさないといけないのに追加仕様や変更が発生してやぶへびだもん。品質は悪くなる。

きしだൠ(K1S) @kis

品質が悪くなってとられる対策は、技術向上ではなく契約の厳密化。設計書を「きっちり」つくるとか、テストのエビデンス(画面キャプチャのかっこいい言い方)をとるとか、不具合報告をきっちり書くとか。手間ばかり増えて品質向上にはほとんど寄与しない。品質あがらず手間がふえるからデスマ常態化。

きしだൠ(K1S) @kis

契約のためのプログラミングで技術向上のモチベーションがなくなってるところに、デスマ常態化で教育の時間がとれない。事実、IPA調査での2011年度の人件費に対する教育研修費の割合は、1割の企業が0%。全体の3割が1%以下。これでは技術力は向上しない。もちろん品質も向上しない。

きしだൠ(K1S) @kis

品質低下→契約厳密化→生産効率悪化→技術力悪化→品質低下。くりかえす。これで「SIをダメにする負のスパイラル」が完成。結局、契約をみたすことだけにたくさんの時間が使われて、ものが作られない。

きしだൠ(K1S) @kis

元請ベンダーから下請開発企業に渡される「設計書」というのは、中間成果物ではなくて、契約書なんだよな。「こうやって作りなさい」ではなく「これを作りなさい」。そうすると、ちゃんと開発できる「設計書」を作るためにはあらかじめ実装しておく必要がある。非現実。開発できない「設計書」ができる

きしだൠ(K1S) @kis

まとめてもらってた。「じゃあどうするのさ」てコメントついてるけど、1兆円規模の業界全体がこういう体質なので「どうにもならない」が答え。この枠組みに入らない新しいSIerが力をつけて業界を侵食するしかない「SIをダメにする負のスパイラル」http://t.co/J6eFVOfhx4

きしだൠ(K1S) @kis

ユーザー企業・元請け・下請けだけの問題じゃなくて、人材派遣、資格学校、そういうの全部含めての業界エコシステムだからね。これを変えるのは並大抵じゃないと思われ。であれば、そのエコシステムから外れたところが競争力をつけてシェアを奪っていくしかない。