「ぼっち開発」から「アジャイルチーム」へ、断捨離の10カ月

古い資産の悪いところを10カ月かけて断捨離したCTOの経験談。チーム開発体制を整えるために「文化をつくる道具」を取り込んだという。その真意は？

[林田幸一，あしたのチーム]

本コラムは2018年6月29日に掲載した「『ぼっち開発』から『アジャイルチーム』へ、断捨離の10カ月」を再編集したものです。

　今回は、私たちのチームが技術的負債から脱却し、アジャイルな技術集団に生まれ変わるための、最初のステップを紹介したいと思います。

　ことの発端は、現在当社が提供するクラウド型の人事評価サービス「コンピテンシークラウド」の、実に2年にわたる開発プロジェクトです（プロジェクトを振り返る前に、要件設計者、開発者などの関係者の尽力には本当に感謝してもし切れません。ローンチできたのも彼らのおかげです。まずはお礼を記させてください。皆さん、お疲れさまでした）。

脱・独自実装を目指して

　実は現在のプロジェクトをローンチする1年ほど前、一度サイトリニューアルを機に、従来の独自PHPフレームワークをオープンソースのWebアプリケーション開発フレームワークである「CakePHP」に変更するプロジェクトを進めたことがあります。

　そのプロジェクトは海外のメンバーも入れて大々的に始めたものの、当時は結局、要求仕様をうまく作ることができず、「前のソースコードを基に『いい感じ』に作り直し」という形になってしまいました。

　その結果、せっかく開発効率をよくするためのWebアプリケーション開発フレームワークを採用したにもかかわらず、その利点を生かせない実装にせざるを得ず、リリース自体を取りやめることになってしまったのです。

断捨離の10カ月

　このときの反省を踏まえて、新たに仕切り直したプロジェクトでは「旧サイトの仕様は一切引き継がない」と覚悟を決めて挑んだのです。

　要求仕様、要件定義は「ゼロから完全に作り直し」を徹底し、この部分だけは10カ月をかけています。

　相手は当社がサービスを始めてから約7年間のノウハウを全て詰めた独自のシステムです。当初は、途方もない作業に感じられ「終わる気配がしない」と思ったこともあったのですが、何とか10カ月で要件定義に落とし込みました。

　こうさらっと書くと簡単そうに思われるかもしれませんが、旧システムのドキュメントは不十分でしたし、人事評価の仕組みを理解してプログラムコードに落とし込める「魔術師的な」技術者は1人しかいない状況です。実物から仕様に落とし込んだり、あるいは「あるべき設計」について議論するだけでも相当な労力がかかりました。

　結果からいうと、この苦労を経た結果、仕様をまともに整理できたのはもちろんですが、新旧システム間のデータテーブルの実装がほぼ同じ形でいける、という確信を持つことができたのです。ゼロから考えた割に、根本の部分は実は同じだった、というオチではありますが、この事実を突き止められたことこそが、重要だと考えています。

事業先行で「取りあえず開発」文化がはらむリスク

　さて、こうしたプロセスを経て「今度こそシステム移行が可能である」と確信した私たちは、いよいよ新システムの設計を開始しました。

　要求仕様を書き終えた私たちがまず行ったのが、開発言語やフレームワークの選定でどうするかについての検討です。検討の大前提として掲げたのが、前回ふれた通り「技術的負債の解消」です。

　（私自身がRuby on Rails信者ということもありますが）前回の失敗や事業会社にありがちな「事業先行での取りあえず開発」の文化を辞めなければ、今回は取りあえず構築したとしても、機能を追加していくごとに設計思想が薄れ、設計が崩れていき、技術的負債をまた負うことになると直感的に感じていました。

　そこで、RubyやPythonなどのWeb技術周辺にある「ちゃんと開発する、あるべき形や効率、論理的正しさを愛する」的な考え方を取り入れたいと思うようになり、またフレームワーク導入がもたらす効能の1つでもある「まずはゴチャゴチャ言わず、先人の設計手法を習う」というレールに乗るところから始めるべきだと判断しました。

アジャイル文化圏のツールからも

　ただ単純にRuby on Railsのフレームを使って簡単に開発するのではなく、開発文化も取り入れたかったため、振る舞い駆動開発のためのテストツールである「Rspec」や、継続的インテグレーション（CI）ツール、コーディングルール準拠を徹底し、プログラムの品質を維持するためのツール「Rubocop」など、関連するツール群が提供する開発文化そのものを取り入れました。

　開発環境が丸ごと変更になるため、慣れるまで大変な労力と時間がかかりました。しかし、このプロセスを経たことで技術的負債を解消したのと同時に、多くの自動化や効率化のための選択肢が用意されている環境を獲得できました。結果として、現在は多くのプロセスを自動化できるようになり、「自然な形」で開発が回る理想的な状況が生まれています。

　規模の大小はあれども、手組みのプログラムや複雑すぎて触れられないシステムを抱えている企業は少なくないことと思います。業務の基幹に近いところに作者不明の怪しいマクロプログラムが走っているくらいのことは多くの企業が体験したことがあるのではないでしょうか。

　この文化を崩さない、さらに新しいカイゼン文化を取り入れることが、さらなる楽しい、効率な開発に変わっていくと強く思っています。

　苦労話になってしまいましたが、これが実際の開発現場で起きた状況です。

　私もRuby on Railsをベースにしたサイト制作を100以上こなしてきましたが、サイト規模としては中規模だと思います。ただ、今回のプロジェクトの難易度はなかなかのものでした。その理由は、人事業務プロセスの難解さもありますが、文化を丸ごと作り替えたところにもあると思っています。

　単純な技術の問題でもなく、開発費用の問題でもなく、やはりトータルの開発文化、技術力、気合いが必要だということだと思っています。

　さて、ツールと環境が用意できたところで、新しい文化をどう定着し、運用していけばよいのでしょうか。次回は、私たちが経験したマネジメントの課題、その解決までの道のりを紹介したいと思います。

著者紹介：林田幸一

官公庁システムの開発やスタートアップ企業の技術コンサルティングに従事。自身もスタートアップ企業のCTOを経験した後、Rubyに特化したシステム開発会社を起業。大手企業に事業売却の後、あしたのチームにCTOとして参画。現在、同社執行役員 クリエイティブ事業本部長。