a fledgling

駆け出しが駆け出してみる

炎上プロジェクトを振り返る

自分の備忘録というか戒めです。

9月から東京のとある会社で働く。

つまり前の会社を辞めた訳んだけど、
最後に関わった改修案件がよく燃える案件だったので何がダメだったのか・どうすべきだったかを振り返っておこうと思う。

概要

  • 既存業務システムの機能追加
  • 3月スタート、8月納品だった
  • 一つ一つは大したことがないが、数が多く全体でみると大きな案件だった
  • メンバーは10人くらい(自分とリーダーがメイン)
  • Java6, Struts, ibatis, freemarker, JavaScript(pure)など
  • ドキュメントはもちろんExcel

何が起きたか

  • 大量の設計漏れ・仕様追加/変更による実装工程の遅れ
  • 試験書が仕様通りでないのでスムーズに試験ができない
  • 当たり前だけど不具合の頻出
  • 再三のデグレ
  • 追い討ちの追加対応

オワタ... orz

と言ってても仕方がないので、同じような案件に巻き込まれないようにミスを犯さないように一つずつ振り返る。

大量の仕様漏れ・仕様追加/変更による実装工程の遅れ

仕様追加・変更については、お客さんとの折衝はしていないのでちょっとアレな部分があるが、やはり設計段階で詰めるべきだった仕様についてが多かった。
また、実装段階で気づいて決めた仕様が多すぎた。
そして設計不十分の影響は最後の最後までこの案件に大きな影を落とすことに。

これに関しては設計力の不足を思い知った。
業務知識に寄る部分が大きかったが、なんとなくわかったような気がしたくらいで設計をしていたような気がする。まぁこれでいけるやろ的な。
完全に漏れ無く完璧には無理かもしれないけど、ウォーターフォールで進めていた以上、もっと精度を上げていかないとお話にならない感。今後ウォーターフォールでやるかは知らない

チーム的な問題としては、業務知識を蓄えている人(=同じ現場にいる年数が長い人)がリーダー一人しかいなかったこと。
そして、その人に設計書・試験書のレビューが集中してしまったことがある。
一番わかっている人がレビューをするのは理にかなっていると思うけど、今回は数が多すぎたため一人で見切ろうとするとどうしても漏れが出る。
別チームの人でも、なんとかお願いして作業分担をしてもらうべきだった。
本当は自分自身が出来ると良かったのだけど、業務経験は1年くらいで、今回改修する部分については今までほとんど触ったことがなかった部分だった。
とはいえ、レビューなんかできませんなんてはずはなかったので、比較的業務知識に寄らない部分の作業の切り出しを自分から行うべきだったと思う。

試験書が仕様通りでないのでスムーズに試験ができない

設計書作成 → 試験書作成 → 実装 → 単体試験 → 結合試験
というフローで進めていたが、実装段階で仕様をいじりまくったおかげで、実装(=仕様)と試験書と設計書がそれぞれ乖離する状況になってしまった。
また、試験の少し前くらいにメンバーが諸事情で離脱。ほとんど経験のない人にテスターをお願いすることに。
試験書の通りに操作してもその通りの結果にならないし、設計書を見てもまた違うことが書いてあるしと、大混乱。テスターの不満も不具合件数も山積み...。
また、ある程度業務知識がある人が試験をする前提で試験書を作ることが通例となっていたため、ことあるごとにテスターの方に説明をしなければならず実装者もテスターも時間を奪われるという最悪の状況。
さらに上がった不具合から、仕様通りの動作なのか不具合なのかを実装者が都度判断しなければならず、見積もりを立てた時点で積んでいたバッファは単体試験の工程で無くなり利益を食う状況に。

これで悪かったのは、実装段階で追加・変更となった仕様をドキュメントに反映していなかったこと。そのルール・仕組みがなかったこと。
仮に、実装段階で見つけた仕様漏れや、仕様の追加・変更は設計書・試験書に反映してから実装を行わなければならないというルールが決まっていて、メンバー全員が理解していたなら、実装工程はもう少し遅れたかもしれないけども、その後の混乱や無駄な時間の発生は防げた。
でもどうやったら効率的なその仕組みが作れるかは思い至っていないところ。

こういうトラブルや課題が発生した時にどういう対処を取るかっていうのは、チームメンバーで意識を合わせておかないといけない部分だったんだろうなと。

ある意味納得意外だったのは、もっと誰でも試験できるような試験書を作るべきだったのでは?っていう意見を出したらテスターの方以外から賛成が得られなかったこと。
そんなにコストのかかるようなものではない気がするんだけど、今までのを変えるのはなかなか受け入れられないのだなと...。

当たり前だけど不具合の頻出

まぁ、上の2つを鑑みると当たり前。 もう一つの原因としては、Javaをメインで仕事をしている人たちばかりのチームだったのに、JavaScriptを使ってフロントでごちゃごちゃやりすぎたこと。

諸般の事情によりあまりプラグイン拡張機能を使えない状況で作業をしていたので、変数や関数のタイポなんてしょっちゅう。
そんな状況で1000行とか書くもんだから何が何やら、書いた本人でさえ理解できない状況に。しかも中には昔のコードからコピペしたようなものもあって、そのコードの質も良くない...。

そんなわけで、設計段階でこの処理はフロントで、これはサーバーでと設計をするわけだけども、チームのスキルの志向にあった設計をしなければ泣きを見ることがわかったよね。
もちろん、機能面でこれはフロントで、サーバーでやらなければいけないっていうのはあるので、そこは仕方ないけれどできるだけチームのスキルセットにあった設計をしよう。

再三のデグレ

不具合修正によるデグレ、不具合修正したソースに追加対応したソースをマージした際のデグレ、いつ起きたのかわからないデグレ...。
その度に手動による再試験。そこで別の不具合やデグレを見つけてまた再試験。その繰り返し。インフィニティ。

もうテストコード書けよとしか。
そしてなぜ自分は途中でテストコードを書くのをやめてしまったのか。
UIのテストまで書けとは言わないけど、大事なロジックのテストコードぐらい書いておけよ。
それで見つかる不具合・デグレがどれだけあったか。

確かに、テストコードを書くような工数はお金はもらっていないから書かないっていうのはわかるんだけど、それはある程度までの規模の小さな案件の場合に有効で、今回のように全体として大きい場合はお金をもらえなくても書いたほうが時間を回収できるし、利益が上がる。
お客さん的にも不具合件数が下がって、信頼できるようになるはず。

今回、一人でもテストコードを書くスタイルを崩すべきではなかった。
そうすれば、自分の書いた部分だけでも不具合・デグレは少なくなって、他の部分に割ける時間が増えただろうに。

ちなみに一人で書いてたのは誰もJUnitの書き方を知らなかったから。

追い討ちの追加対応

これはもう本当に勘弁してとしか...。
お客さんも自分たちも幸せになれないものに対しては、断る勇気も持とう。

最後に

もう全行程ダメダメで、二度とやりたくない。本当に。

でも設計段階で少し抜いてたのが全ての始まり。
不具合が多発した時も、それぞれにプライオリティ付けて処理をしなかったのが悪い。
影響範囲を対して検討もせずにその場しのぎな方法で直してたが悪い。
ドキュメントを軽視していたのが悪い。

同じことは繰り返さないようにしよう。
以上。