皆さんこんにちは、システム部の中村です。
今回は、以前行われた「一気通貫２レコード廃止プロジェクト」という技術的負債の改善プロジェクトについて書いていこうと思います。プロジェクトを振り返り、大変だった点、反省点、良かった点など学んだことが多かったので、紹介していきます。
一気通貫とは？
GMOリサーチでの「一気通貫」とは、事前調査と本調査を一気に行う調査のことを指し、１つのアンケートでありながらも、事前調査＋本調査を用意し、最終的に欲しい回答を本調査で行うというものです。
※事前調査とは実際の調査を行う前に、母集団の中から、特定の条件で調査対象者を絞り込むために行われる調査のこと。また、本調査とは事前調査で対象者を絞り込んだ後に行う調査のこと。
事前調査と本調査を一気に行うことで、事前調査と本調査を別々に実施するよりも、スケジュール面のスリム化やコスト削減に繋がるというメリットがあると言われています。
例えば、本調査で普段吸ってるタバコの銘柄を聞きたいとします。
これは喫煙者をターゲットにする必要があります。
この場合、事前調査で「あなたはタバコを吸いますか？」という質問をし、「YES」の人だけ本調査に誘導し、「NO」の人はそこでアンケートを終わりにするというものです。
一気通貫調査の問題点
無駄な重複データがある
GMOリサーチでは歴史的な経緯（開発当時の事情や要件）で、事前調査・本調査を分けて管理するシステムとなっていました。
その結果、事前・本調査で分けて管理したい項目はほんの一部なのに対し、大部分で事前・本調査の中の同じ項目が管理されていました。
例えば先に挙げた対象国、調査の期限などは、無駄に重複してデータを２件管理していたのです。
そのため、アンケート配信を行うGMOリサーチのリサーチプラットフォーム「Market Observer（以下MO）」の新たな機能が追加されていくにつれ、調査データには属性がどんどん追加されていき、無駄な項目が膨れ上がっていくという事態が起こっていました。
処理の分岐を生んでいる
例えば下記のようなものです。
- データを作るとき、２件作らないといけない
- データを更新するとき、２件更新しないといけない
- データを参照するとき、２件見に行かないといけない
さらに、MOで機能追加が行われるときは、「一気通貫の場合」という考慮を各所で行わなければならなかったので、影響調査も広大なので、開発工数や調査工数も大きくなっていました。これがMOの機能追加のたびに必要で、大きな問題点となっていました。
解決方法
上記であげた問題点を解決するための方法として考えられたのが、シンプルにデータを１つにするという方法です。
※これがプロジェクト名の「２レコード廃止」です。
事前・本調査で分けて管理しないといけない項目を、１データの中に項目を分けて用意するようにします。
例えば、調査データを下記の構造と仮定します。
①調査名
②対象国
③調査期限
④設問数
2レコードの場合だと、④設問数は「事前調査の設問数」と「本調査の設問数」の２つを別管理しないといけません。
しかし①〜③は、分ける必要がなく、無駄に2つのデータで同じ値を管理しています。これを以下のように変更することで無駄な重複管理を無くします。
①調査名
②対象国
③調査期限
④設問数（事前）
⑤設問数（本調査）
「一気通貫２レコード廃止プロジェクト」で苦労したこと
プロジェクトで大変だったのは、次の４つでした。
①影響範囲の広さ
②仕様調整漏れ
③データ移行
④知らない機能
影響範囲の広さ
調査はMOのコアな部分の重要なデータの１つなので、MOの中のいろいろな機能が調査データを見ています。なので、プロジェクトにおける影響範囲がとにかく広かったです。
また、GMOリサーチにはMOだけでなく、モニターサイト（infoQ）やデータ分析の機能だったりなど、100を超える機能があります。
これらすべてを対象に、影響箇所の調査を行った結果、50近い機能に手が入ることがわかりました。
そのため当然、調査工数が本プロジェクトでも大きくなりました。
しかし、範囲が広かったとはいえ、影響箇所の整理はできていました。また、機能はたくさんあるけれど、それぞれが機能内で閉じているため、平行して修正することができました。
この解決法としては、単純に人を増やせばそれだけ対応スピードは上がるので、人員を調整してもらって色んな人に助けていただき、この問題点を乗り越えました。
仕様調整
リリースしてから、３点ほど仕様調整が発生してしまいました。
例えば、定期出力されるファイルに関してです。事前・本調査で別レコードとして出力していたのを１つにまとめる際、合算値だけでよかったり、内訳が必要だったりと、認識合わせが不足していたものがありました。
そのため、リリースされた後に、該当ファイルを普段参照している人と調整しなおすことになってしまいました。
しかし該当ファイルが月末だけに使われるファイルだったので、対応までに猶予があったのは、不幸中の幸いでした。
データ移行
ソース修正とは別に、長い間かけて蓄積された事前・本調査の２レコードを１つにまとめるデータ移行が行われました。
テーブルデータだけでなく、キャッシュ保存されているredisデータ、あるいはファイルデータもです。
実行順序に気を付け、同時並行で動いている別プロジェクトが止まってしまわないように注意しながら、移行専門のバッチ処理もいくつか用意しました。
また、ソースのリリース日に移行が完了できるよう、処理時間をあらかじめ予測して進めました。
予想を超えた処理時間に苦しめられましたが、移行データの抽出方法をチューニングしながら、なんとか期限に間に合わせることができました。
知らない機能
・一部の人だけが内容を理解している機能
・追加されたばかりの新機能
にも、苦しめられました。
ドキュメントが不十分で、ソースにしか情報がない機能は、「あるべき姿」がまずわかりませんでした。そのため、プロジェクトチーム以外の人たちにも都度確認しながら、進めました。
もし、設計書があれば、どんな処理をするための機能かわかるはずですが、設計書がなければ、ソースコードを解読していくしかありません。解読できればいいですが、中には
「何でこんなことをやってるかわからない」とか、
「昔は使われていたかもしれないけれど、どう考えても今は意味がなさそうな処理で、消していいものか判断できない」とか、
「そもそもこの機能で作成されるファイルを誰がつかっているの？」
などの情報を知るのに苦労するケースがありました。
ですが、「誰に聞けばいいかすら、まずわからない」。ソース変更の履歴から、人を特定できても、その人はもう会社にいなかった…ということもありました。見当がつかない場合は、知っていそうな人が誰かを周りに聞くしかありませんでした。
チームリーダー業務の引き継ぎ
大変だった点として、もう１つイレギュラーなことがありました。それは休暇に伴うリーダー業務の引継ぎです。
チームリーダーとして仕様調整、チームメンバーのサポート、開発スケジュール管理等を担当していた僕が、リリース直後から育児休暇を取得させていただくため、引き継ぎ業務が発生しました。
※育児休暇に関する記事はこちら「実態・感想聞かせて！リーダーパパの育休奮闘記」
出産日によっては、早めに育児休暇をいただくことも可能性としてありました。
事前にシステム部内で調整もしていただいていましたが、いつ生まれるかわからない不安を抱えながら、いつ生まれてもおかしくないよう、引き継ぎを準備しないといけませんでした。
周りの方は、僕が突然休みに入るかもしれないということを念頭に、率先して作業を進めてくださいました。
チームリーダーを引き継いだ仲間からのコメント
～チームリードの役割及びプロジェクトを引き継いだ宮島さんからのコメント～
※宮島さんの過去記事はこちら「信用情報に傷をつけないための注意点についてお話しします」
今回、中村さんの育児休暇取得に伴って、主に下記２つを引き継ぎました。
１．一気通貫２レコード廃止プロジェクトのテスト・リリース対応
２．並行で動いていた同規模以上のプロジェクトの開発・テスト
途中で推進役を引き継ぐことは決まっていたため、並行して走っていた別のプロジェクトの要件定義・設計についても深く理解していなければいけませんでした。しかし、「一気通貫２レコード廃止プロジェクト」の開発タスクを多く持っていたため、並行プロジェクトの仕様理解・引継ぎの優先度を下げてしまっていました。
勿論、ある程度仕様の理解はしていたつもりでしたが、成果物のチェック等も含め、今考えると並行プロジェクトの仕様理解・引継ぎが十分に出来ていなかったと思います。
結果的に、その状態から数日程度しか引継ぎの期間が取れなかったという反省がありました。
また、リーダー的な立場をGMOリサーチでは初めて担ったため、具体的な役割を把握しきれていない部分もありました。
最終的には様々な方の助けも借り、両プロジェクトは無事終了できましたが、多くの反省点が見つかるといった良い経験をさせて頂きました。
プロジェクトを振り返り良かった点
というように、苦労したプロジェクトでしたが、 何とか無事に、予定通りの期日にリリースできました。大変ではありましたが、よかったことも当然あります。
知らない機能を知れた
完全理解とはいきませんが、普段触らない色々な機能を知ることができました。開発メンバーの中には、入社して初めての業務がこのプロジェクトだった人もいましたが、社内の機能に触れるいい機会ともなったと思います。
また、誰がその機能を使っているかを知ることもできました。
リリース後に致命的なバグなし
リリース後に、仕様調整の不足による追加リリースが発生しました。しかし、データ移行も含め、致命的な問題は発生しませんでした。
最悪なケースでは、リリース前の状態に戻すということもあり得たかもしれません。
多岐にわたる機能修正、移行作業では、使われるプログラム言語もいろいろ。中には、AWSの知識を必要とする作業もありました。
結果的に得意分野の異なる開発メンバーが集まって、リリースまでもっていくことができました。得意な箇所をお願いしたら、責任を持ってタスクを完遂していただけました。
誰かが欠けていたら、予定通りのリリースはできなかったのではないかと思います。
以上、「一気通貫２レコード廃止プロジェクト」でした。読んでいただきありがとうございました。
