「『納品のない受託開発を支える レガシーコードを作らない仕組み』を読んで」へのご返信

しーばさん（@bufferingsさん）から先日の「納品のない受託開発を支える レガシーコードを作らない仕組み」についてご質問をいただいたので、お答えしたいと思います！

経緯

という流れで、

というブログを書いていただきました！　フィードバックをいただけるの、嬉しいです。

そういう訳で、ご質問にお答えできる範囲でお答えしたいなと思います。

「プロジェクトの規模とかチームの人数とかメンバーのスキルってどれくらいなんだろう？」

プロジェクト規模について

基本的に1人がメインで開発を進めるプロジェクトです。状況に応じて増員もしますが、基本的には1人で開発を進めます。ただ、1人1人がバラバラな流儀でコードを書いていると、サービス全体として保守が難しい状態になっていってしまうため、プロジェクトをまたいで相互レビューを行っています。

（※ 開発自体は1人がメインですが、プロジェクトのサポートにもう1人つくため、体制上は2人体制になります）

スキルレベルとしてはある基準を超えているメンバーのみで運用をしているので、基本的に高いと思います。新人レベルのメンバーが開発に参加する場合は、必ずプルリクエストを投げてもらうようにして、マージ可能なレベルになるまでレビューをします。

参考記事：プログラマは職人、力なければ淘汰されて然るべき―ソニックガーデン倉貫氏が問う、プログラマの覚悟。

プロジェクトのタイプについて

プロジェクトは全て新規開発です。既存のシステムを引き継ぐ場合でも、新しいコードにリプレースさせていただいてから運用をスタートするようにしています。

社内システムか事業システムか？という点では、「納品のない受託開発」というサービス自体が、社内の業務改善を目的としたシステム開発よりは、新規事業の立ち上げを目的としたシステム開発のニーズにマッチしているので、新規事業の立ち上げを目的としたお客様にお声がけをいただくことが多いです。

参考記事：「納品のない受託開発」で解決できること

変更の難易度よりは、新規事業という性質から仕様がどんどん変わるので、テストの新陳代謝が激しくて捨てるテストが多くなるというのが開発から見たときの難しさかなーと思います。ただここも、テストの書き方とかそういったテクニックで解決するというよりは、お客様と事業の計画／目的を共有して、必要となる仕様を先読みし逆に提案していくことで、コードから見たときに仕様が歪になってしまうといった問題が起こりづらくなるようにしています。

「レガシーコードを作らないようにするためにどれくらいの時間をかけてるんだろう？」

常にソフトウェアを利用できる状態にする、という価値を提供しているので、特別「今月のXX%の時間は改善活動をしています」というお伝えの仕方はしていません。どうしても時間がかかるときは、正直に相談をするケースもあります。

お客様に特別お伝えすることはないですが、継続的にコードレビューをしたり、案件の状態をレビューすることでレガシー化しないようにしています。そのコストはサービス内に含まれています。飛行機に乗るお客様が、飛行機自体のメンテナンス状況を気にしないのと同じ、というイメージです。

アプリのデプロイ時に環境立ち上げ→その環境でアプリのテストを実行→展開というところまで自動化しているか？という意味のCIであれば、そこまでの自動化はしていませんが、

  • 基本的にイミュータブルな設計（Chefで設定情報を管理）にしているのでバージョンアップ作業などが省力化されている
  • アプリ自体ミドルウェアのバージョンアップによっていきなり動かなくなるような設計に極力しない

という工夫で、全体的なコストを抑えているという感じです。

お客様に何を見せるか？という視点では、作業した分だけお金をいただいているわけではなく、サービスを提供することでお金をいただいているということが一番重要な部分で、その視点に立つと改善活動の時間を報告することにあまり価値はないのかなと思います。お客様のサービスにとって何が一番の価値になるか、ということを常に考えてサービスを提供しています。

というわけで、お答えになっていれば幸いですー！