泥沼プロジェクト振り返り

　はじめに

ちょっと前まで結構激しく泥沼化したプロジェクトにいた。
その頃はプロジェクトも僕も相当疲弊していて、何も考える時間がなかった。

ある程度、月日が経って今なら
もう少し客観的にあの頃のことが考えられるかなと思い書いてみることにする。
振り返りをし、自分としてもプロジェクトとしてもどうあるべきであったかとか
そういう立派なことが考えられればいいのだが。



とかく、Slide Shareとか世の中は成功事例は多く発信される。
けど、失敗事例のほうが共通して当てはまったりする。

　前提

・古典的なウォータフォール
・古典的なStruts1系ベース内製フレームワーク
・Java SE 6
・QAとかいない
・デザイナーとかいない
・フロントエンドエンジニアとかいない

　アンチパターン

当時のプロジェクトを振り返って、明らかにこれは駄目だっただろというところ。



◆プロジェクト全体

・決定者がいない

方針を決める人が誰もいない。みんな何が正しいんだろうね、悩んで終わる。
とにかくお客さんに言われたから…が理由のことが多い。

・役割が不明確

誰が何をするか不明。リーダーは何をするのか。PMOは何をするのか。
プロマネは何をするのか。
どこまでの範囲の責任を持ち、決定権を持つのか。
責任の所在が無いので、なぜそれがその当時決定されたか誰も理解していない。


・組織図がコロコロ変わる

あっちのチームのリーダーやったり、こっちのチームのリーダーやったり。
あっちのチームの作業をやったりこっちのチームの作業をやったり。
2ヶ月か1ヶ月ごとに発生していた。


・作業プロセス（手続き）が多かった

チケットを切って解析して、修正して、レビューして、テストして、テストレビューして、
エビデンスをスクリーンショットとって試験項目表作って、資産管理表作って…。
作業が複雑なほど、人間は細かい部分には目が行き届かなくなる。
また、手続きの途中でのミスが増える。
作業遅延や品質の悪さで顧客の心象が悪くなり、
プロセスを分厚くしてなんとかします！証跡残します、
と日に日にプロセスは膨らんでいった。


・共通ライブラリを作る時間がなかった

差分プログラミング的な共通ライブラリ作成の時間がなかった。
すでに内製のフレームワークはある状態だったが、本プロジェクトに
最適化されている状況ではなかったので、粗があった。
それを理解されておらず、軽視されスケジュールも立てられず
片手間で作業しているかのような状況になった。


・突然始まる横並び作業

障害が見つかるとそれが関連しそうな業務ロジックは一斉に調査し修正をする。
各人の時間を割いて担当箇所を修正させる。

ヨコ展開、横並び作業とか呼ばれるものだが、かなり愚かしいと思う。
なぜ、横断的な作業が増えるのか。AOPが足りてない。
共通処理に不足がある。
修正するにしても自動化(最低限、グレップや置換)とかは考えないのか。
その単純作業は機械的すぎやしないか。

・激しく入れ替わる人員

フェーズごとに細切れに人員を増やしたり減らしたりする。

・フェーズごとに途切れる当時の情報

結果的に前任者の情報は不十分、設計思想や設計の不備などもわからなくなる。
実装に関してもめちゃくちゃなものが作られてそのまま去ってしまう、と言った感じ。

多分人員コスト的な問題だろうが、逆にプロジェクトが遅れてコスト高くなってた。


・顧客ドリブンタスク

お客さんに言われたから調べて！直して！
あーして！こうして！

付け焼き刃じゃなくて、知識は予め準備しとこう。
まぁ分からないことがあるのはしょうがない。


要件定義とか設計でこうだったから直しません。そう言われるならわかりました直しましょうとかなら分かる。
言われるがままだった。

ココらへんで感じてたのは
方針、ポリシー、契約がないと、そうなってしまうということ。

論拠となる芯が根本的にないから、スキをつかれてあれもやれこれもやれ。
その代わり金額は変えるなと。



・喧嘩腰になる

これは僕の反省でもある。
でもわりかし荒れてくるとキレる人は増える。

キレても良いことはない。冷静に論理的に話す。記録を残す。
その人の特性を知る。思いやりを持つ、人間として。

余裕がなくて思いやりは持てなくても最低限暴言ははかない。
順序立てて話す。冷静になる。



◆テスト

・ユニットテストを書かなかった

テストに工数を割けないという理由。
画面から打鍵でテストのみする。

テストを意識した設計はこのあたりで
されなくなっていたのかなぁと推測する。


・品質の曖昧な定義


どのフェーズでどこまでは保証しますよというやつがない。
C0とかC1とか根拠とするところもなく、いつまでに何をやるのか
（どの観点でここまで保証するとか）決まってない。



・テストの曖昧な定義

なんのためのテストか。品質を定義して保証するのかとつながるところ。



◆設計とか

・そもそも使うフレームワークに理解がない

事前にフレームワークは決まってて、実現可能なことも限られていたのに、 フレームワークを知らずに設計してたっていうのがもうアウトだ



・詳細設計書が死んだ

詳細設計書には1ステップごとにプログラムをそのまま日本語にして
説明するかのようなものが並んでいた

じゃあもうコンパイルすればいいじゃんと。
詳細な設計の定義は必要だけど、それはいらないなと。
結局出来上がったものは仕様としては読み取りにくいし、それをそのまま
プログラムとして実装するには不充分すぎた。
詳細設計書は結局信用出来ないハリボテドキュメントとなって
実装も基本設計書を中心にすることになった。


・自動生成でゴミが出来た


自動生成で設計書からJavaのクラスを作るという
よくある話。単純なJava Beansとか大枠のクラスを作るぐらいならいいと思うのだけど。
その結果誰もタッチしないクラスとかが出来た。これはベースとなった設計書が不要になったからなのだけど。
実際作ってみてこのクラスは不要だった、この設定ファイルは不要だったという管理が難しくなった。
その辺りも含めて自動生成は考えるべき。


◆プログラミング的なところ

・そもそもJava書けない人がJava(コピペ)書いてる

Javaは書けるようになってから出なおしてこい。
Effective Java全部知ってますレベルじゃなくて良い。せめて

・インデント
・Javaの型を理解している
・無駄なくif文とfor文が書ける
・参照渡しと値渡しをある程度理解している
・voidとString型の戻り値のメソッドの使い方が分かる

とかそのぐらい。まだまだ要求としては足りないけど
それも出来てない人がいて。




・各業務チームで出来上がるユーティリティクラス


各業務がファンタスティックなクラスを作り始める
徐々に統率が取れなくなってきたなぁというところだった


・各クラスを彷徨う定数

ロジックのクラスに定数があったり
定数クラスがポンポン出来たり、
でも使ってなかったり。



・publishedインターフェースの変更が多かった


共通のライブラリとしてすでに提供してしまっているメソッドやクラスの変更が多かった。
変更はライブラリ利用者のモチベーションを下げるし無駄な修正作業に時間を取らせることになる。
最小限にすべき。

　改善

なんか思いつく限りずらーーっと書いてみたけど
改善するには反面教師になるしかないなぁと思う。

・テストにしろ、システムにしろ、ポリシーを決める
・責任範囲を決める
・ゴールを決める
・複雑な作業を人間がしない
・プロトタイプを作るか何かしてとにかく確かめる
・机上の空論で設計しない。
・学習コストを考慮して時間をかける
・どうしてもJava分からない人には書かせないか、レビューを通さない
・DRYを考える横断的な作業をなるべく発生させない



あとQAチームは必要だと思う。
このプロジェクトではあとから出来たけどちょっとはマシになった。

　まとめ

ということで、アンチパターン潰していけば、銀の弾丸じゃないにしても
ある程度プロジェクトは良くなっていくのではないかと思う。

Strutsだったとしてもね(もうそろそろStrutsいらんけど)。




プロジェクトが上手く言ってない時ほど、忙しくなる。
忙しさを打開しようと目の前の作業に必死に食らいつくと中長期的な展望が見えなくなる。
プロジェクトがデカイほど空気は伝染して盲目的になっていく。

というのが、僕が感じた悪循環だった。


忙しい時ほど時たまフッと定時で帰ることをオススメする。


悪循環から強制的に離脱するタイミングを作ったほうが
作業効率上がると思う。

仮に定時後、終電まで残業したとしてその5〜6時間でそんなに効率よく仕事出来てるのかな。


その作業は本当に今日までにやらなければならないのか？
自分がやる必要はあるのか？自分がやったらもっと生産性が上がる作業はないか。
案外他の人は手が開いていないか。


品質もタスクも結局人が決めることなので、
矛盾してたり無駄が多かったりすることが非常に多い。


疑ってかかるべきだと思う。




お客さんがどうしても、自分の会社がどうしてもとか政治的な問題はつきまとうけど
本当に必要な物は何かと考えたら案外要らないことばかり何じゃないかなと思う。