役所のシステム調達でソフトウェアの「納品」というと、キングファイルに綴じられた大量のネ申エクセルと、CD-RなりDVD-Rに収められたOffice文書やらZipにまとめられたソースコードだ。それらが動くように一からデプロイするだけで何週間もかかるし、そのコードが生きていた時期の試行錯誤は全て捨象されてしまっている。値段分の仕事をこなした「証」に過ぎず、開発時のレポジトリから引剥されて、文脈と実行環境を失ったところで本格稼働前のシステムの断面に過ぎない。
いまの時代ならわざわざDVD-Rに成果物を焼くのではなく、普段からツールのアクセス権限を共有しておき納品のタイミングで開発業者のアカウントを削除するとか、もっとモダンな納品の仕方がありそうだ。せっかく開発費を負担して知財を取得したコードだから倉庫に死蔵しておくのではなく、レポジトリを全府省で共有して他の案件で再利用し、他PJがバグを見つけたらPull Requestを送るといったことがあっていい。
設計書にしても死蔵されるネ申エクセルからは当初の文脈や論点が失われてしまっている。むしろ開発時の作業環境やチャットの履歴、コードの修正履歴そのものを残しておかないと、一体何のためにこんなコードを起こしたのか、あとから追いかけることができなくなってしまう。
開発段階からリポジトリやBTSといったツール群を発注者と受注者で共有し、電子メールではなくツール上で共同作業を行い、コントロールパネルでコードやテストの状況をリアルタイムで見られるようにする。そのために発注単位もツールチェーンの整備とソフトウェア開発は分離し、設計・実装・運用は一本調達とするか、タスク単位の分割発注で準委任契約を試みても面白そうだ。
DevOpsツールチェーンをベンダーの手からユーザー企業が取り戻せば、机上のWBSに書かれたジグザグ線ではなく、目の前で起こっている本当のことを探ることができる。コードカバレッジが実際どうなのか、何人のプログラマーがどれだけの生産性でコードを書いているのか、手戻りはどれくらい起きてるのか、バグの発生率やコードの重複率はどうか、コーディングの最中にモニタリングしていないと介入しようがない。次工程に進んでから先々月の品質を報告されても後の祭りじゃないか。
ほとんどの人が発言しない儀式のような定例会議は全て廃止して、生データに基づいてリアルタイムに可視化されたものを見て、必要に応じて決断できて発言する人だけで会議をやるべきだ。黙って会議に出ているだけの人たちはWebcastの向こうに追い出し、会議を流し聴きしながら手を動かしてもらった方がいい。
英GDSや米GSA 18Fのように役所やユーザー企業が自らエンジニアを雇って内製できれば面白いけれども、いきなりそこへ行く前に納品形態や連携の在り方を見直すだけで、今よりずっと効率的かつ俊敏なシステム開発をできそうなものだ。さりとて何から手を付けたら無理なく進め方を変えられるか、今日もネ申エクセルに押し潰されそうになりながらも悶々と悩んでいる。