受託開発していてもクリエイティブにはなれない

駒鳥です。

今、会社で自分が所属しているプロジェクト内には実質二つのチームがあります。

片方は、いわゆる受託開発のような形で、アプリの開発をしています。
リリース間近なので、忙しいのもそろそろ落ち着いてくるか・・・という状況。

もう片方、自分が担当しているチームは、法人相手の開発などしていますが、受託開発というわけではありません。
単に、作ったものを売っているようなイメージです。

すぐ隣で、（かつて前職で自分がやっていたような）受託開発の過程を見ていて思ったのは、

やっぱり受託開発の仕事は、クリエイティブになれないな

というものです。

複雑な受託開発

この受託開発は、いわゆるSIer複数の会社が複雑に絡み合って一つのプロジェクトに取り組むことが多い、ということです。

この、複数の企業が参加するプロジェクトでウォーターフローを採用することには、一つ大きな弊害があります。

それはコミュニケーションの量が激増するということです。

実際にプロジェクトの中でよく起るやり取りをまとめてみましょう。

もはや書いてるだけでも面倒で仕方が無いですね笑

機能追加ができるのかどうかを確認したいだけなのにこれです。
この例で言うと、実は必要な工数が多いので２次受け企業が追加でお金が必要だと言ったり、１次受け企業が発注元の意図を正しく２次受け企業に伝えられなかったり、ということが起きます。

不具合が発覚した場合なども、相当めんどくさい。
各会社のスタンスもあり、場合によっては責任のなすり付け合いに発展します。

さて、これだけコミュニケーションが発生すると、開発する側はたまったものではありません。

コミュニケーションが多いと言うことは、それだけドキュメントの量も増えると言うことです。
その作成もしながら、上から無茶な要望が降ってきたりすれば、現場は本当に大変です。

ちなみに、SIerの仕事の多くは、無駄なドキュメントを大量に求めます。
これも開発側には足かせです。

結果としてやることがどんどん増え、デスマーチに陥ってしまうプロジェクトは多いです。

そして、開発サイドから何かの要望を出すのは本当に難しいです。
例えば、いざ開発をしているなかで、

「この仕様は、いざ作ってみると不便そうだ。こんな風に変えてみてはどうか」

と思ったとします。

でもそれを元請け、発注元に提案するのには多大なコストがかかります。
上記のようなコミュニケーション量が多いのもその原因の一つですが、他にも、ウォーターフローモデルが邪魔をします。

既に前の行程については完了しているにも関わらず仕様をかえるとなると、スケジュールはどう考えればよいのか？
前行程で作成した（大量で無駄の多い）ドキュメントの修正もしなければいけません。

そんなコストをかけるのであれば、開発サイドは自らの意見を殺して、決められたことを淡々とこなすのが一番楽だと言うことになります。

でも、それって、ここまで読んでいただければ察することができるでしょうけれど、とにかく面白くないんです。

開発よりもコミュニケーションやドキュメント作成に多くの労力をさき、自分の意見はなかなか聞いてもらえない。
決められたことをただこなすだけの仕事でクリエイティブにはなれない。

それがあまりに息苦しくて、つまらなくて、僕は前職をやめました。

受託開発のビジネスモデルを、開発手法も含めてちょっと見直さないと、　SIerの人手不足は今後もなかなか解消しないのではないかと思います。

自分で考えたものを形にできてこそ楽しくなるんだろうな、と。
アイディアはどんどん形にしていきたいなと感じる今日この頃でした。

それでは。