🤦‍♀️

レガシープロジェクト改善失敗反省会

2020/12/23に公開

執筆時点までで3回、レガシープロジェクトに参加しました。
レガシーなのは嫌なので、率先して可能な限りモダンなプロジェクトにしようと試みました。
ですが、最初のプロジェクト以外、見事に失敗しました・・・
なので、最初はなぜうまく行ったのか、他2回はなぜうまくいかなかったのかを反省してみます。

「レガシープロジェクト」「モダンプロジェクト」の定義

人によってレガシー、モダンの線引は異なる(そもそも、厳密な線引ができない気がする)ので、ここでは以下のプロジェクトをレガシープロジェクトと呼ぶことにします。

設計書がない、または不完全である
- 設計書が不完全な状態というのは、ソースコードと設計書が一致していない状態です(以下、例)
  - フロントエンド、バックエンドどちらも改修対象なのに、画面設計書だけまたはDB設計書だけ等、設計書自体が不足している
  - いずれかの改修内容がプログラムだけに反映されて、設計書には反映されていない
  - テスト仕様書がない
テストが自動化されていない
成果物(各種設計書、ソースコード等)のレビューがされていない
ローカル環境で開発ができない(開発環境等、共通の環境でプログラマが改修する様な体制)

上記全て解消されたとき、そのプロジェクトを「モダンプロジェクト」と言います。
CIを入れてないのにとか、インフラのソースコード化をしていないとか、そういうのを入れてないのにモダンプロジェクトって言うな!っていうマサカリが飛んで来そうですが、この記事の便宜上そうさせてください・・・

モダンプロジェクトに成功したプロジェクト

まずは、成功したプロジェクトから振り返ります。

前提

ソースコードやチームの状態など、大体こんな感じです。

チームは立ち上げたばかり
- 立ち上げたばかりだが、後にリーダークラスになる方々は自分を含め元々同じチームだったので、面識はめちゃくちゃある
- ある程度、お互いの業務スキルをもちろん知っていて、技術力は高水準だと思います(自分の体感ですが・・・)
- 私の立ち位置はプロダクトマネージャー、テックリードあたり
チームの主な担当は設計、開発、単体テスト
- 基本設計は基本的には1から作ることはなく、別チームから来る基本設計書に目を通して、仕様について確認や要件定義や要望を確認して別案の提案などをしていた
ソースコードは旧プロジェクトからの引き継ぎ
- 全体で1M行は軽く超えている
- 一部のファイルは2k行を超えていた
- テストコードはなし(=テストが自動化されていない)
けど、設計書等のドキュメントは一切なし
- 最初に口頭で、主に改修する画面に関わる基本的な運用の流れや利用用途などを聞いたくらい
ドキュメントもないので、ローカル環境の作り方すら手探り状態
- あとから、ローカルでも動くようにできましたが・・・
前任者もいなかった
- 仕様や運用把握のため、先行着手していた方がいらっしゃったが、多分、自分よりも1～2ヶ月くらい早く参加したくらいなので、年単位所属している人はプロジェクト内ではいなかった・・・はず・・・

最初に聞いた仕様とソースの規模的に、明らかにソースが肥大化しまくっている状態でした。
なので、かなり細かい仕様が入り乱れているなーっていう印象だったと思います。

成功要因

詳細については後述しますが、大体↓になると思います。

協力者が多かった
ソースコードや業務中に聞く用語を順次ドキュメントにした(できた)
定期的に日々の開発運用を見直した
何かをし始めるとき、優先順位をつけていた

協力者が多かった

多分、成功要因の大半を占めていると思います。
何をするにおいても、私だけがやるということがなかったと思います。
基本的に私がメインに動いて、私が作った雛形やドキュメントができたら、他の人も率先してドキュメントや雛形に目を通してもらっていました。
誰かが躓いた事に気づいたら私はもちろんですが、理解した人も協力していく印象です。
いわゆる分報をしていたので、1人あたりの躓いたことに気づいた件数が多かったのかなと思います。

ソースコードや業務中に聞く用語を順次ドキュメントにした(できた)

一気にドキュメントにするのではなく、優先順位をつけて順次ドキュメントにしたのが成功の秘訣です。
そもそも、全体で1M行、1ファイルだけで1k行を超えるソースコードを一気にドキュメントにする気力すら起きませんでしたが、小規模でも順番にドキュメントにするのが良いと思います。

順次ドキュメントにするメリットは大まかに↓になります

負荷が分散するので、極端にドキュメント化に対するコストが減る(定常工数として加算しやすい)
誰かが最初に改修する際、一緒に仕様書を作る選択肢ができる
ドキュメント作成スキルが未熟な人は小規模、成熟している人は中～大規模を担当する選択肢ができる

ドキュメントを作る時、優先順をつける要素としては↓になります。

画面やAPI、用語の利用頻度(業務運用時の重要度に直結しやすい)
改修するついでに
ソースコードが小規模
手が空いたとき

3と4でドキュメント作成することはほぼなかった(ドキュメント化終盤くらいだったと思う)ですが、少なからず影響を与えたので一応記載しました。

定期的に日々の開発運用を見直した

改修の進捗にもよりますが、大体1ヶ月に1～2回は開発運用の見直しをしました。
具体的には↓の様な内容になります。

今の運用の問題点をベースに改善策を策定
- 問題点は事前にSlackで共有していました
- 全体の司会はリーダークラスの方がしていましたが、各問題点の司会は提案者がしていました(さり気なくメンバーの司会力を育てる)
改善策を実施している場合、どう影響したのかを見直す
- 運用にかっちり乗った(自然と続けていける状態になっている)レベルなら、今後も続けていく
- 別の問題が出たり効果的ではない場合、改善策を微調整したり、別の改善策を出す
問題があるからと言って、その場で改善策を出すことを強制しない
- 今後の活動で改善策が見つかる可能性もある
- だからと言って、雑には考えない(改善策を考える最低限の時間を決める)
基本的に全ての意見は受け入れる体制で臨む
- いきなり否定ではなく、どういうメリットがあるか?というところから考える

チャレンジをしてみては、だめならやめる、良さそうなら微調整、完璧ならしばらくやる、という感じです。
全体の開発工数が少なくなったり、同じ開発工数でも品質が高めになったりするのが体感できました。
最終的にはちゃんと数値化していますが、定期的な見直しで足止めした分、見返りが効果的にもらえました。

ちなみに、このときに見直した方法はKPTですが、KPTの詳細はいろんな記事があるので割愛します。
ただし、結構KPTのやり方というか、雰囲気などはプロジェクトで依存しているので、もっと細かいのを知りたい!っていう声があったら、別記事で書こうと思います。

何かをし始めるとき、優先順位をつけていた

開発運用の見直しの時点でチャレンジ精神旺盛さがにじみ出ています。
しかし、残念ながら本番にリリースする時刻はあるので、時間とその間にやれることは有限です。
なので、何かし始めるときは必ず優先順位をつけて、順次、改善策を実施したり、ツールを導入していました。

早めやればやるほど、最終的なコストダウンや効率化アップが見込める
- 例えば、単体テストのソースコードは最初は学習コストがかかるけど、時間経過で少なくなっていき、結果的にはテストの再実施やデグレ発見等のコストが減ったり、短時間で品質保証がしやすくなる等
チーム全体で繰り返し行われる操作の自動化、運用の見直し
ドキュメントがネット上にあるかどうか
- 大体は検索件数や検索推移を参照
- 件数が多い分、情報が多い可能性が高いので、何らかの問題が発生した場合、すぐに見つけて対処しやすくなる

モダンプロジェクトに失敗したプロジェクト

次に、失敗したプロジェクトを振り返ります。

前提

ここでも、ソースコードやチームの状態などを中心に挙げると、↓になります。

チームに途中参加
- 立ち位置は開発、テックリードが主で、余った時間で開発運用の改善を任されることがあったくらい
自分以外のメンバーはソースコードのことや仕様をよく知っているっぽい
- 「っぽい」というのは、詳細設計書がないので、メンバーの言うことが本当に正しいのか不明
- 概要としては信頼できそうなレベルくらい
- とはいえ、不明な箇所は最終的には「ソースコードに書かれている内容が正しい」というレベル
ソースコードや作られた設計書をGit等のバージョン管理ツールで管理をしてない
- 設計書は、ファイル名に更新年月日を書いて、いつのものかを管理していた
- ソースコードは厳密にはGitを使って管理している形跡があるが、多分、Gitの性能の1割も引き出せてない
開発メンバーが複数人(5人位)だが、ローカル環境が存在しなかった
- チームメンバーだけが触れる環境にあるソースコードを直接触って改修していた
- しかも一斉に改修しては、テストはDBを直接操作する様な体制だった

失敗要因にも書きますが、今思えば、モダンプロジェクトに持っていく以前の問題が多い気がします。

失敗要因

こちらも、詳細については後述しますが、↓になると思います。

協力者、理解者があまり増えなかった
メンバーのレベルに合わせて、新しいツールや運用方法のサポートが不十分だった
モダンプロジェクトにする以前の問題を解消しきれなかった(理解していなかった)

協力者、理解者があまり増えなかった

多分、一番の要因の1つです。
協力者、理解者がいないと、どれだけ理にかなっていることを言っても、数の暴力でもみ消されるが如く、なかったことになります。
失敗要因にもある、ドキュメント作成が下手だった以外にも、増えなかった要因は他にもあります。

チームメンバー全体で、向上心があまりなかった
そもそも、モダンプロジェクトに持っていくリソースがなかった(時間がない、各人に支給されているPCのスペックが低い等)

特に、理解してもらえることに失敗してしまうと、「また駄々をこねている」とか「屁理屈ばかり」等、マイナスな印象に繋がるので、もっと協力者、理解者を増やすことが困難になります。

メンバーのレベルに合わせて、新しいツールや運用方法のサポートが不十分だった

ドキュメント自体は作成していましたが、ローカル環境を用いた開発や、Git-Flowを使った開発運用等の知識が0に近いメンバー目線だったのかと言われると、微妙だった気がします(本当にそうなのかは判断できないですが、メンバーに理解してもらえなかったのは事実)。
成功したプロジェクトは、ちゃんと理解していたどころか、その運用について一緒に経験しているので、ここに専念することがなかったので、単純に私のドキュメント作成能力が低かったを言わざるを得ないです。
一応、作成したドキュメントを元に勉強会のようなことをしたり、勉強会やドキュメント内で不明な箇所や理解できない箇所は個別で説明しますと、各人のレベルに合わせてサポートする努力はしました。
ですが、前述にある通り、向上心があまりないので、暖簾に腕押しでした。
もっと自分から積極的にサポートに行くべきでしたが、おせっかいになってしまうので、難しいところです。

モダンプロジェクトにする以前の問題を解消しきれなかった(理解していなかった)

そもそも、モダンプロジェクトにいきなり持っていこうという考えが間違いだったと思います。
他にも問題があったなぁと思う箇所は↓になります。

クライアントとの会議等があるはずなのに、議事録がない
チームでの会議がない
PCのスペックが極端に低い
- メモリが2GBというメンバーもいた(これが要因でローカル環境が作れない、作っても激重で使い物にならない)
何か問題が発生した時の対策で「しっかり〇〇する」と言った努力目標で対策することが根付いていたのを改善できなかった(具体的な対策を引き出すようにできなかった)

議事録がないとどういう要望で改修するのか、チームでの会議がないと誰がどこまでするのかの線引が曖昧になったり、いま面倒なことを放置して、将来的にもっと面倒なことが起きそうな状態を解消できませんでした。
もちろんですが、議事録を書いてほしいとか、話し合いの場を定期的に設けましょうとかは提案していますが、三日坊主で続きませんでした。

また、ローカル環境を構築するにもメモリが2GBでは、そもそも各ツールにある必須スペックすらクリアできない状態であることは理解していませんでした。
~~逆に今までそのスペックでどうやって仕事ができたのか知りたいくらいですが、~~ 流石にこの状態でのローカル環境構築はできませんでした。

対策方法についても、結構突っついた(具体的にはどうするんですか?、何を持ってしっかりしたことになるんですか?)のですが、すでに上で決められたことということで、覆すことはできませんでした。

次からやってみること

以上を踏まえて、次レガシープロジェクトに遭遇したとき、以下のことを実践してみようと思います。

チームメンバーの向上心を理解する
- 向上心がなれけば、芽生えさせる様にする
  - どう芽生えさせるかは今後の課題
モダンプロジェクトにする以前の問題を解消する
- 以下のような内容を確認する
  - 議事録を作成する
  - チームでの会議や話し合いの場を設けて、定期的に振り返りや現状の確認をする
  - ローカルで開発することが前提なので、支給されているPCが要件を満たしているか確認する
- 物によっては政治的な理由により改善不可能、または時間がかかることも考慮したほうが良さそう
メンバーの理解度に合わせたドキュメントの作成を行う
- Gitのコマンドはよく知っているけど、運用は全く知らない方が多い場合は、プロジェクトで使う運用を先に作成する
- こちらからのサポートは、メンバー各々の向上心によるところがあるので、基本的には依頼してくれたらめっちゃやりますよ!くらいがベスト?(これで失敗しているので、最適解かどうかは今後の課題)

未知の領域がいくつか出てきたので、事前に調査したり、調査した結果から自分なりにアレンジしてやってみる箇所は別記事にしたいと思います。

最後に

1日寝かせて読み返したら、「協力者が多かった」項目が語弊しかないレベルで頓珍漢なことを書いていたので修正しました
~~こういうのがあるから、レビューしてほしいし、ドキュメント作成うまくなりたいとも思いました。~~