どこかのだれかへ

職業ゲームプログラマ。気になったニュースのピックアップや開発日記などを書いています。

さっきの会議で決まった仕様を覆す勇気

gigazine.net

新しい機能を実装する時、企画から関係プログラマー・アーティストに仕様説明会があり、その時、技術的にも可能かどうかとかの判断して、仕様の調整をしたりします。

こっちのほうが便利じゃないかとか、この方法だとコスト高いからこういう風にしない?とか、時にはいやいや無理だよ!って突っぱねたり、逆に企画はコスト高いと思って妥協案出してきたけど、むしろ理想を実装した方が楽だったりとか、色々あります。

たまにあるのが、会議ではいい案だと思ってたけど、いぜ席に戻ってコードを睨んでいると、きつい事に気付いたパターン。実装できなくはないけど、絶対あとで「なんでこんな面倒な実装しているんだろ」って思ってしまうのが目に見えている場合です。

さっきまでやっていた会議で「大丈夫です、この方がいいです」とか言っていたのに「やっぱきつい」という気まずさ。 さらに実装方法が変わると実装担当が変わったりという場合もあるので、申し訳ない気持ちにもなってすごい言いづらい。

今日もそんなのがありました。会議では、A案を断念しB案を採用したのですが、会議終わってから「あれ、B案のほうが面倒だし保守性悪くない?」となり、色々考えた結果、A案で行きませんか、と関係各所に相談に回ることにしました。

昔の自分だったら、「まあ自分で行けるって行っちゃったししょうがねー」と思ってそのまま面倒な実装で行ってしまうパターンも合ったんですが、経験上、絶対に後悔するので、最近は気付いた時点で行動するようにしています。

ちなみにこの後悔、というのは

  • 工数が無駄に増えて辛い
  • 保守性最悪
  • 後の追加仕様がそのダメな仕様を前提で組まれる(負の前例、負の連鎖)
  • バグが生まれやすい

などがあります。

そんなことがあって、先日読んだ冒頭のGIGAZINEの記事を思い出した今日でした。