in Think

現状の事情と要件と設計と時間とIMO


自分どこにかぎらず現場にはいったところで気にかけていることがある。現状にたいしてどうアプローチするか、という話。

現場って二つあると思ってて、「0 -> 1」と「1 -> 100」みたいなあれ。(100でよかったっけ?)どっちにも違いはあるのだが、大体僕が問題だなあと思うのは最初と最後ではなく途中で発生することが多い。

1以上になっている現場、割と混沌としていたとしても動じることあまりない。昔は「作り直ししろ!ウラァ!」みたいな話をしたことも結構あった気がするが、最近そう思うことがなくなった。基本的に技術的な正しさより事業開発としてのスピード感の方が大事だよなーと思うようになったからってのが大きい。(ビジネスが100でもまかされた領域が0だった場合は容赦はしないが)

僕は自分を「広く浅く時々深く」な人間だと思ってて「そういうものでこう書けばいいとまではわかるんだが、具体的な実装として望まれているスピードは出せないかもしれない」というのが存在する。なので、そう言うところは「こちらの領域、相当なスピードを求めているのであれば違う人に任せたほうがいいかもしれませんが、僕でよければ最大限の力で頑張ります」というのは事前に必ず伝えてる。

設計/実装ベースでいくと、当然他の人と意見が食い違ったりすることはある。僕はその場合相談する機会を必ず設けるようにしていて「その箇所はこちらで実装することはできるけど、そちらでこう言う風にしてもらうこともできると思う。どっちがいい? ちなみに僕はそっちでやってもらうほうがありがたい」っていう伝え方はする。「いやこっちじゃこういう理由で無理っす」って言われたら「わかった」っていう答えをしていい落とし所見つけたりする。

っていうのを続けたんだが、どうも最近はそこで終わらせて実装はいるのまじ危険だと思う機会が多い。口頭で「こう言った」というのは大体あとで「そうは言ってない」になることが大半だってことに気づいた。し、それの指摘はだいたいプルリクエスト出してからくることが多い。そしてそれは大なり小なり、ある程度やばいものが飛んでくる。

最近は小さな機能だとしても実装前設計書を必ず書いて、責任者なりのエンジニアに確認と合意をとるようにしている。シニアエンジニアはやっぱりいて、彼らと合意をとらないとPRで「そもそもの設計が間違っている」という指摘を受けるからだ。それ一番辛い。設計が間違ってればまず実装の差し戻しが発生する。設計が間違ってなければコードレビューで「ここ書き方こうしてほしいで」ってので済む。

最後にIMOについて触れたい。

とはいっても時間や予算は有限なわけで、その中でやりくりはしなければならない。僕はそう言うのは本気でどうしようもないとは思ってる。だから「時間的な余裕がなくて、最速がこれだったからこうした」っていうのは大体受け入れるようにしてる。0-1のフェーズならリリース後直せばいいし、運用中なら改善issueだせばいいと思ってる。

一方で視点の食い違いは誰にでもあるもので「要件を聞いた当時ではこれが必要でこれがベストだと判断した」ものが他人から見たらただのクソコードクソシステムだとしか思えない場合はある。それももう仕方ないと思う。見ている視点の違うはどうしても発生する。

ただ、存在するものを一方的に否定するのは、やめた方がいいと思ってる。

作った本人が「これはその時時間や予算的にやばくてそうしなければならなかった。そしていつか直さないとと思う。だから改善策を提案してほしい」と思ってるなら、ちゃんと「自分はこう思う。だからこうしてみたらどうか」というのを丁寧に説明する必要はあっていいんじゃないかと感じる。僕はエラーが吐いている箇所は「こういうエラー吐いているように見えるが、ここは仕様なのか修正していいのか」というところからまず聞くようにしている。「どうしようもなくてそうした。改善できるならしたい」という返事がくれば「わかった」と応えて改善issueと、できるなら改善PRだすところまでやる。それならまだいいかもしれない。が、システムを根底から覆す設計をするなら、話は別だ。

ある程度の検討と話をチームと、一番は設計した本人と話をしたほうがいいと思う。それも一定の時間をかけて。それは本当にシステムを覆すほどの設計をする必要があるのか。今修正しとかないとあとでつらいことになるのか。とかいくらでもあると思う。設計した本人のスキルセットにもよるとは思うけど、なぜその場所にそのエンジニアがいて、その設計を行ったかなどは話がいくらでもあるはずだと思う。間違ったり要件をうまく飲み込めなかったり、話が通じない人間ならまず最初を任されることはないと個人的には思う。それで時間と予算が問題なく、かつチームで合意形成が取れたら覆す系設計に入っていいんじゃないかな。

まとめにいきます。

いろんな経験をしてきて、僕は「提案->メンバーと口頭で合意->小さな設計書を書く->設計書レビュー->実装->PR->デプロイ」がチーム開発の中では最速だという結論にいたってる。これでスプリントからもれてもしかたないとも思ってる。そうしないとPRでなんども差し戻されるたびに実装が「システムやビジネスのため」ではなくて「ポイント稼ぐためにさっさとPRを通してデプロイ するため」に変わってしまいそうな気がするからだ。(実際過去にそういう経験はある)結果バグを生んで障害発生するほうが正直時間やお金のロスになる。できるひとは提案してissueを作ったらさっさと実装してPRまで持ってくのかもしれない。そしてそれはマージされてすぐに出ていくという自信があるんだろう。僕は正直、その自信はない。自分が周りの人間以上に解釈違いを起こす人間だということをずっと生きてきて知っているから。

技術的負債やクソコード、クソシステムと呼ばれるものはあるし、視点の違いではなんでもない、普通のあるべき姿だった、ということもある。そういうのを僕はいっぱいみてきた。これからもいっぱいみるだろう。そこに対しては否定ではなくIMOから入っていくのを心がけたい。

現状の事情と要件と設計と時間の問題で本当にどうしようもなくなるべくして発生したものはどこにだってあるものだとは思う。