勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

ポジティブな客先常駐システム開発を考える

株式会社アクシアさんのブログで、常駐開発バッシング(?)記事が最近掲載されている(http://axia.co.jp/2017-08-01)ことについて考えている。指摘されているような「不適切な常駐開発」というのは確かにあるのだろうけれども(ちなみにあまり目撃したことはない)、適切に運用すればポジティブな常駐開発も有りえるはずだし、自分は一応そうやってきたと思っている。じゃあ、注意すべきところは何だろうか。

何が問題なのか?

常駐や多重請負が問題なのではなくて、請負という形態において受注者が「裁量を持っているか」というのが最大の論点だと思っている。例えば以下のようなもの。

  • 作業プロセスについての裁量(やり方を一定の範囲で自由に決定/変更できる)
  • スケジュールについての裁量(マイルストーンまでの進め方を自由に決定/変更できる)
  • リソースについての裁量(目標達成に必要なリソースを自由に決定/変更できる)

これらが制限された時に批判されるような不適切なプロジェクトになるのではないだろうか。逆に言えば、裁量の範囲について受発注者が事前に合意出来ていれば、ポジティブな常駐開発が実現できるのではないかと考えている。

もちろん多重請負の構造において、特に途中段階の契約会社がポンコツだった場合は裁量を維持するのは相当な努力を要するだろう。「発注者が**と言っているのでその通りにしてください、反論は受け付けません」という契約関係は論外である。もちろん請負側も「すべて指示してください、自分たちでは考えられません、教えてください」というスタンスではいけないのは言うまでもない。

ところで非常駐開発は常駐開発に比べて上記の裁量を得やすいというのは事実だと思う。
ただし、非常駐開発が裁量を得られているのは非常駐開発が優れているからではなく、顧客に対して透明性が無いからにすぎない。

  • 客から見えないから、作業プロセスを変えてもいいだろう
  • 客から見えないから、スケジュールを変えてもバレないだろう
  • 客から見えないから、リソース変更してもOK

はたしてこれが、常駐開発より優れているのかというと疑問である。

ポジティブな客先常駐システム開発

適切な裁量が確保されているのであれば、あとは常駐開発を選択するかはメリット/メリットの比較だと思う。

メリットとして最も大きいのはコミュニケーション効率化である。利害関係者が一箇所に集まって開発に従事することを、「缶詰」(組織パターン)や、「ウォールーム」と呼ぶのだが、このメリットは非常に大きい。またファシリティコストのメリットもあるだろう。

組織パターン

組織パターン

一方でデメリットとしては、最初に紹介したブログ記事にも書かれている通り、顧客の拠点を間借りするためにドレスコードや勤務時間などの制限を受けることはあるだろう(交渉次第だと思うけれど)。また見える場所で作業していることから余計な割り込みの問合せ、コミュニケーションが発生するということもある。

このあたりを冷静に比較して、どのような形態でシステム開発するかは判断すればいい。
というわけで、どちらにしろ常駐開発=悪というのは、ちょっと違うのではないかと考えたのだった。