読者です 読者をやめる 読者になる 読者になる

Shut the fuck up and write some code

グダグダ言わずにコードを書きたいブログ

クソプロジェクト案件と向き合う・その後

クソプロジェクト案件と向き合う - Shut the fuck up and write some code

前回の続きです。

課題の対応

  • コードを書くよりもドキュメントを書くことに集中する
  • Readableなコードを書くことを最重要とする。

上記二点を守るように実装するコード書きつつコメント周りを充実させていった。これにより自分自身の理解度も深まったと思う。 しかしそれでも元々のコードが持つ実装意図がつかめないし、そもそもDBのテーブルが何を表し、そのデータは何の使われているのか、理由も意図も分からないのは変わらない。コードを動かしつつ、出力結果を見てひたすら判断する作業を続ける。ドキュメントやソースに実装意図のコメントがあればこの作業もだいぶ軽減されるはずなのだが・・・一番キツイのはある程度動作するように実装して仕様の理解も深くないので「この実装で問題ないでしょうか」とレビューを依頼したところ「正しく動いてるかどうか自分で判断しろ」と返されたことだ。いや自分の判断が間違ってないかを確認してもらいたくてレビューをお願いしているのだが・・・。私は「あなた」ではないから、正しいかの判断は100%のレベルでは出来ない。こんなブーメランが返ってくるとは想像つかなかった。

  • スケジュール

前回から仕事の進捗状況を観察するに、自分のスケジュール管理がされないということは、こちらもそれほどスケジュールに関して意識しなくても良いということらしい、という点に気づく。

観察

このプロジェクトが成功することは望ましいが、冷静に判断するに、ここから大きくステップアップする状況は現場にいる人間からは想像するのは難しい。プロダクトの質も決して高いものが担保されているとも思えないし、いま開発している人間が誰かがいなくなる可能性を全く想定していない時点で、短期的な計画プランだろうなと想像しやすい。

クライアントが求める立場であることが自分の仕事だし、上記の問題は声高ではないが進言してはいるものの改善されないので、自分の判断が決して正しいものと決められるものではないでしょうか、おそらく自分の意見は求められてないところなんだろうなと思う。一言で言えば「こっちの思うような動き方をしてもらえればそれで良い。それ以上もそれ以下も求めてない。」

結論

クライアントの関係がWIN-WINであるために、こんなプロジェクトの中で自分はどう立ち振る舞うべきか。「 プロジェクトの成功率を高めるのではなくクライアントの満足度を高める」という点に着地するのだと思う。プロジェクトの動きを観察するに、どう見てもプロジェクトの成功を目指した動きはしていない。そもそも、このプロジェクトもまた上にクライアントがいる。そして彼らの動きは自分から全くブラックボックスだ。彼らの言葉は自分の耳には届かないが、彼らの言葉でこのプロジェクトは回っているのは確かだ。そして、その大クライアントの満足度を高めることが目的となっている時点で、自分は手の打ちようがないのである。目の前の敵を倒しても、もっと大きな敵がいる。

生き残るために

自分個人のQoLを高める施策に走る。

  • 自分自身の工数削減
  • ナレッジを貯める

この2つを徹底的に掘り下げていくことだろう。とにかく時間をかけない。自分の時間を切り売りはしない。

そして少なからずとも今の仕事で得た知見を他にどう活かすかを考える。正直活かせるようなものではないが、コードを書く量を増やして経験値として積み重ねる。


一番の課題がこのプロジェクトを途中でドロップアウトするが終わる前に次の案件を見つけることだ。年齢的にも本当に大変だ。この戦いが終わっても、戦いはまだ続く。