クラウドサービス時代の納入を考える

成果物を委託者に引き渡す行為を『納品』と使っているケースがあるが、『納入』の方が正しいと思うのだが。ここでは一旦、受託者が成果物を納める行為を『納入』と統一することとする。

さて、クラウドサービス時代の納入を考える前に前時代的に思える納入を知っているだろうか。調達仕様や慣習や受託者のプライドかどうかは知らないが、以下のいづれかだろう。

契約書に記載された媒体で正副の2枚を納めるケースもある。納入自体は、契約の完了のタイミングで行われるため、いわゆる年度末に近い2月から3月上旬に掛けて複合機が活躍することになる。

ただ、紙による納入は委託者側も保管場所を取ることと構成管理の手間が掛かるので媒体による納入へシフトしている。

さて、クラウドサービス時代の納入をどう捉えればいいか。

ここで、クラウドサービス上で構築するWebシステム、サービスなのだから、従来のような設計書ではないのだから納めようがないと脊髄反射してはいけない。

ヒントは前時代的な納入の例に記載してある。一部のエンジニアには、頭では理解できているが、実際の業務に落ちてきてから異論を唱える方が存在する。しかし、それではエンジニアが思っているような納入はいつになっても実現できないことをそろそろ学習しても良い頃だ。

バックログから開発テーマの優先順位付けを行い、チケット管理システムやカンバンを使ってタスクをアサイメントし、テストを書き、コードを書き、TDDし、デプロイさせてチケットをDoneする。

ドキュメントなんか書くより、動くコードを書くことを優先しているんだと言うかもしれない。アジャイルソフトウェア開発宣言に

「包括的なドキュメントよりも動くソフトウェアを」

と書いてあるじゃないかと言うだろう。契約の履行という意味合いでも動くソフトウェアを納入することは正しい。ただ、顧客が契約で成果物に対するオーダをしてきたらどうするのだろうか。

「契約交渉よりも顧客との協調を」

では受託者から委託者側に契約交渉をすると捉えることができるが、逆の場合はどうするのだろうか。つまり、顧客がこの成果物仕様で納入して欲しいと言ってきた場合である。

対価を支払う契約であれば顧客の指定する成果物を納入するのも顧客と協調しているのではないか。

もちろん、いまどき、詳細なプログラムの仕様をwordやexcelで書くよりツールを利用し、ツールのデータを納める交渉はした方がいい。

端的に言えば、契約時に成果物をエンジニアが納入したい形式で契約を締結しておくことが必要なのだ。その契約書にドキュメントを一切記載せず、ドキュメントはモデリングツールなど受託者のしているデータ形式で納めるとすればそれを納入すればいい。

ただ、次のことに配慮しなければならない。

契約書に記載された成果物は納めなければならない。契約には期限ある。そのため、納入する成果は必然と納入時点でのスナップショットになる。リポジトリは納入用に分けなければならない。

それは委託者側の外部監査、内部監査が行われた場合に、契約書に記載の成果物がビシッと揃っていなければ指摘、是正勧告されてしまうからだ。