はじめに

@cosmeのAndroid向けアプリ開発グループのuchiyamamです。

アイスタイル Advent Calendar 2019の12/5投稿枠を担当させていただきます。

今回、なうでヤングな技術情報は持ち合わせていなかったので、
私がここ数年悩んでいた問題についてお話しします。

文量も多くないので、身構えず紙芝居感覚で読んでいただけたらと思います。

私がお話しするのは、みなさんもよく聞く&やりがちな「いい感じで実装」についてです。

エンジニアだけでなく、クライアント側でご活躍されている方々にも是非ご一読いただきたい内容です！

いい感じで実装ってなに？

細かい仕様については実装しやすいしにくいもあるだろうし、エンジニアの判断で決めて実装しちゃって!
といった意味で扱われることが多いです。

クライアントからエンジニアだけでなく、エンジニアからエンジニアの話し合いでもよく使いがちです。

エンジニアの判断で仕様決めてガンガン実装できるし、そのおかげで細かい調整のやりとりしないで済むし、爆速で開発できるから効率が向上するので互いにとってwin winですし、何も問題はないのでは？

。。。と思っているあなた。（いやいないと思いますが）
プロトタイプならその道理は通じますが、多人数で長年運用していくシステムだと後で痛い目に会いますよ。。。

では、私が直面した問題についてお話ししていきます。

意図がわからない謎のコードが生まれる

皆さんも一度は遭遇したことがあると思います。
仕様書には書かれていない謎なロジックで組み上げられたコードを。。。
例えばこのようなコードです。

var hoge int
var res int
hoge = getHoge()
res = customHoge(hoge, 372617)
return res

極端な例ですがマジックナンバーと言われるやつですね。

?< 372617って何だろう。。。？
?< 仕様書にも書いてない。。。
?< 当時のメンバーはいないから経緯がわからない。。。

よくあると思います汗

特に決まった数値を仕様として落とし込まず、エンジニアが数値を調整しながらいい感じに実装した結果です。

こうなってしまうと１年後の自分や後任のエンジニアは困ってしまいます。。。

対策

• マジックナンバーを回避し、コメントやドキュメントに経緯を残す
• 仕様要件として調整し、仕様書に落とし込む
• 別のアプローチを検討する

などなど回避方法は色々ありますが、この問題はいい感じで実装した時によく起こりがちです。

仕様書レベルで定義していない数値をハードコーディングした時には、一度立ち止まって考え直してみましょう！

リリース前やテスト段階で仕様変更が入る

仕様変更と書いていますが、正確にはクライアントとエンジニア間の認識齟齬です。
エンジニアが思っている「いい感じ」と、クライアントが思っている「いい感じ」は異なることが多々あります。

例えばスマホアプリのエラーダイアログの表示について見てみましょう。

エンジニアの「いい感じ」とクライアントの「いい感じ」が見事に相違してますね。

伝えれば良いのに！！！と思うのですが、
案外こんな細かいこと大丈夫でしょ！と思って伝えないことが現場ではよくあります。

対策

この問題に関して完全な対策は難しいです。
仕様の粒度は突き詰めれば突き詰めるほどほぼ無限に細分化できてしまうからです。

この実装はどんな仕様にしたらいいんだろうか。。。？
と思ったら都度確認にすることである程度対策はできると思います。

細かい確認事項がたくさん出てきた！もういい感じで実装してしまえ！
と思ったら、スコープを見直しましょう。
もしかしたら別プロジェクトに分けてもいいレベルかもしれませんよ？

素晴らしいプロダクトを作るためにも仕様要件は突き詰めていきましょう！

最後に

いい感じで実装した先に何が待っているか伝わりましたでしょうか？

いい感じで実装することを撲滅できればいいのですが、
止むを得ずいい感じで実装してしまうことはあると思います。

そんな時は今回読んでいただいた内容をぜひ活かしていただき、
あなたのより良いサービスを開発のお力添えになれたら幸いです！

我々も「いい感じ」を使わずに、より良いサービスを開発していきます！