Qiitaから定期的に好評記事の一覧がメールされてくるわけですが、パラパラっと見ていたら面白い記事が
ウォーターフォールの反省とアジャイルの成功に必要なもの #SIer – Qiita
わかる。
実際に私自身、前職では自社パッケージの開発を行っていて、現在は準委任や請負両方とも関わっていたりするので、言わんとしていることはよく分かる。
そして、携わっていた準委任で参画しているスクラムの案件がそれなりに終りを迎えつつあって、色々と思うところがあったので多少乱雑ではあるけれど書いてみた。
あくまで個人の感想ではあります。
請負で契約に縛られるのは誰なのか
記事では、「問題の原因は請負開発」とあって、そのインセンティブ構造だとかに対して触れられている。
ベンダー側の立場で利益を案件単位での利益を最大化するのであれば、当初契約締結時の仕様を最低限満たすものを、最小の労力で作り上げる事になる。
作りながら「この機能はこういうケースも対応できたほうがいいのでは？」ということに気づいても、当初見積もりからずれる行為であれば事前の要件として明記されていない限りは基本実施しない。
それは、怠慢とかそういうことではなくて、見積もりの前提が崩れ、その見積もりを下に作られているスケジュールからずれ、納期に影響を与える可能性がある。
言い方は悪いが「余計なものを作っていたら間に合いませんでした」って話になりかねないのだ。
残念なところはユーザー側の立場からも話が出ることはある。
RFPのような形で契約を進めていく場合、そのRFP記載内容からズレたことを行おうとした場合にはユーザー側でも承認プロセスを巻き直す必要がある事が多い。
きっちりかっちりした企業・プロジェクトであればなおのこと、「仕様書にかかれているかどうか」を担当者も判断基準にしている。
このあたり、システムに対して明るくない担当者であるケースも多いのでしょうがないところではある。
ユーザー企業側でシステム全てに詳しい人を割り当てることができるのか？とか考え始めると大変だなぁと思うわけです。
請負におけるベンダー側のインセンティブ
すべての開発者がそうだというような性善説を唱えるわけではないけれど、開発者は基本的に良いものを作りたいと考えていると思う（作れるかは別として）。
お蔵入りするためのものを開発なんてしたくないし、大きいシステムや影響の強いシステムを稼働させるのに臆病になることはあっても、やるからにはいいものを作りたい。
先に書いたように、営利企業である限り利益を生まなければならない以上限界はある。
ただ、最低限請負開発を回していると、要件的に問題がなければそれはいいのだが、ユーザ企業側に不満が残る最低限開発だとリピートされるかが怪しい
請負をする以上、案件を取ってくると言うことが必要になるうえで、顧客満足度を高めて、多少高くてもリピートされることをインセンティブにするという考え方になるのかなぁ、と思う。
サスティナブル的な感じだろうか。
内製か外注かの選択
記事でも書かれている、内製化の流れというのは何となく分かる。
一方で、書かれているようにエンジニアを抱える以上、それに付随した組織改革とエンジニアを（数とスキルの両面で）維持する必要が生じてくる。
ベンダーであれば、様々なプロジェクトを通して色々な経験ができる可能性はあるけれど、ユーザ企業の場合は必ずしもそういう環境を提供できる企業ばかりではないと思っている。
このあたりは、ユーザ企業含めて業界の構造がどうなっていくのかは楽しみだ
自社で内製化のために雇用した人材が維持できず、結局は会社対会社でその部分を担保しようとしているのが今だと思っている。
記事では要件が固まっている場合には内製で行うメリットがないとしているが、これに関しては違和感を感じる。
内製でするべきかどうかは、その作るシステムが自社にとって競争優位を生み出すものかどうかなのではないかな、と。
作り上げる時点で何を作るのかの要件が定まっていたとしても、今後、そのシステムを元に戦っていくのであれば自社で抑えておく必要はあるし、その部分を他社に任せてしまうのは良くない。
「要件が固まっている」が”今後変わることがない”という意味であれば別だけど、変わることのないシステムなんてあるのだろうか？と思ってしまうのはエンジニアサイドの視点なのかもしれない。
一方で、要件が固まっていて特に自社の競争優位に大きな影響を与えないシステムに関しては外注を・・・と思ったけれど、よほどのニッチな領域でない限り、パッケージ導入やAI、ローコードツールによる簡易的なものづくりを内製で・・・ってなっていくんだろう。
数年で取り巻く環境は目まぐるしく変わっていくので、身の振り方は常に考えておかないといけないところですね。
