過去経験してきた現場のなかで、それぞれに違った「複雑」な事例がありました。
最近自分がやらかした事例も含めて振り返ってみたいなと思います。
(色々アレなのでぼかして書いています)
事情が複雑
医療系の現場で諸々要件を整理していく段階で、「この場合はこういうパターンなんだけどこの値があったらこうなって、その時に値がどうたら...」ってわかるかー！！！となりました。笑
紐解いていくと、そもそもそれを定めている法律やそれによって決まった業界内での規程などがあってそうならざるを得ないという状況。
これはどんな業界にも言えることかも知れませんが、業界特有の事情で要件が複雑になる場合、実装する人は大変だけどその分乗り越えれば他社が簡単に参入できない障壁にもなるわけで。
ドメインエキスパートが社内にいてガンガン活躍できるのであれば、あえてその道をいくのもアリなのかもしれません。
施策が複雑
ビジネスの目標としてある数字を達成したいとなった時、そのために行う施策の設計（これは企画サイドが行った）が複雑であったために、以下のような事象が起こりました。
- 施策の内容が複雑なため、ユーザーに意図が正しく伝わらない
- ↑の状況から頻繁に問い合わせが来るため、サポートチームが適切な説明をする手間を取られる（しかも、施策の難しさ故に説明がまた難しい)
- 施策が複雑なため実装自体にバグが混入しやすい（実際した。そうするとまたユーザーから問い合わせが...という負のループに)
振り返ってみると、最初に立てたビジネス目標を達成するために本当にこの施策であるべきだったのかは多少の疑問が残ります。
特に、ユーザーに意図が伝わっていないというのが大きな問題で、両者のキャッチボールが正しくできる施策をリリースするというのはめちゃくちゃ大事なんだなというのが個人的に学びでした(今まであんましこういった事例にあったことがなかった)。
「こうありたい」という目標に対して、できるだけその意図を正しく簡潔に伝えるにはどうしたら良いのか？に拘らないとそのあとの工程、運用で苦しむことになる。
実装が複雑(設計ミス)
これはプログラミングの話で、ある要件があった時にそれをシンプルな形で実装できていないというケース。
例えば、本来レコードは1対1で結びつけたいモデル(has_one <-> belongs_to)があるんだけど、様々な事情によりそれを直接は実装できない、となった時。
間にもう一つテーブルを置けばある程度簡単にクエリのやりとりができそうですが、それをやらずにクエリを複雑に組み立てることでテーブルを置かずに実装した。という事例がありました。(そうです私です...orz)
簡単に正規化できないモデルが現れた時、それを無理やりどうにかするんではなくよりスマートに解決できる方法はないか？と考える姿勢、大事です。またそれを個の力ではなく組織の力として発揮できる状況にあるか？というのも大事だなと思いました。
実装が複雑(責務が分離できていない)
こちらも割とプログラミングの話。
とある現場にて「サイト全体のSEO(検索エンジン最適化)を強くしたい」という要望が過去にあったそうで、その際にSEOのコンサルティング会社から「自サイト内の検索に使えるタグを増やすのと、そこへのリンクやコンテンツを増やしていくべき」という助言を受けたそうで。
結果生まれたものが、「既存のサイト内の地域別検索に、SEO用の検索とコンテンツロジックを組み込む」というもの。
お前は何を言ってるんだと突っ込まれそうですが、僕も何言ってるのかよくわかりません笑
初めて実装を見た時に本当に何がしたいのかよくわからんかった。。。あれほど闇深いElasticSearchはなかなかないと思う。
ここから学んだことは、「SOLID原則って本当に大事なんだなあ」ということ。
やりたいことを一つのクラスにそのまま実装してあげればそんなに難しくならないはずのものが、一つのクラスに色んな振る舞いを実装してしまうからおかしなことになってくる。
この事例について言えば、検索ロジックが複雑だからSEOでも使いまわしたかったという事情があったのかなと思いますが、それをやったが故にとても難解なコードになり、結果SEOのトレンド変わる際にメンテを入れてくのが余計にしんどくなったという悪循環がありました。
原理原則と呼ばれるものの大事さを身にしみて感じた事例でした。
顧客の要求が複雑
これはどの現場にも共通して言えることかなと思いますが、BtoBで大きな売り上げを持つ顧客がいるとどうしても「個社対応」が出てきます。あるいは、「個社対応」することがサービスの売りであったりする場合もあるかなと。こういった部分の実装はどうしても複雑になりがちだなと思います。
これに関しては、「ある程度共通化できる部分は残しつつ、DBも使って柔軟に個社対応の部分を変更できるようにしておく」みたいなアプローチをとる現場が多いのですが、これまで見てきた経験からはこれが本当にいいのかは微妙だなという気持ちになっています。
メリットとしては、ある程度共通化する部分を残すことと大規模な実装->デプロイをなるべく防ぐことで工数を減らすということが考えられますが、大体このての実装が入る時ってイレギュラーだったり詳しい人が突貫対応するということが起こりがちで、時間の経過と共に個者対応した実装のキモの部分を知る人が組織にいない（いても捕まらない）みたいな事例が多々ありました。(知識経験が属人化してしまうというのはコレに限った話ではないですが)
なので、最近の僕はこう言った実装が入る場合はできるだけGit管理できる方に寄せていく、冗長になってもいいから個別にUseCaseを切り出す、というアプローチの方がいいのかなと思っています。
とまあこんな感じです。どこかの本に書いてあることではなく、敢えて自分の経験を言葉にしてつらつらと書いてみました。
全体通して思うのは「人間」の事情が立ち入るところに複雑さがあり、その要望を解決した結果の実装が複雑になるのかもしれないな、と。なので、そもそも人間の気持ちをできるだけシンプルに解決するにはどうしたらいいのか？(ライトついてますか的な)、というのを最初に頑張るのがいいのかなと思いました（できるとは言ってない)。
来年は人と向き合って問題を解決していけるように頑張りたいなと思います。