先に結論を書くと、モノづくりをするとき、全体像が見えないうちに手を動かし始めるのはよくないよ、という話。

とあるシステム開発のプロジェクトで、「目的不明」「存在意義不明」「結果がどうなれば正解なのか不明」というほとんどが謎に包まれた機能の設計・開発を担当することになったことがある。
その機能に関する情報といえば、その機能に関連するいつくかのテーブルに対してデータを登録すれば良いよ。という情報だけがある。それだけ聞くと案外簡単なのでは？と思うけれど、そのデータがどこでどう使われるのか、そして結果的にどうなっていれば正解なのか、という情報はない。また、更新対象のテーブルが全体でいくつあって、それぞれがどのタイミングで更新され、どの程度の数のデータ更新されるのか、といった情報も断片的にしかない。この状態から何をどう進めれば良いの？というのが最初に話を聞いた時の感想。とはいえ、会社としてその機能の開発をやることは決まっており、他のメンバーにも空きがない状態だったので、断るわけにもいかない。とりあえずやってみる。

まずは断片的で少ないながらも既にある資料を見て概要を理解しようと試みる。そして、結局何もわからないので、わからないことをいくつかまとめて担当者に質問をしてみる。質問を重ねることで、最初2%ぐらいしかわからなかったことが、25%ぐらいはわかるようにはなった。とはいえ分かったことは所詮その程度。その機能は外部の別システムと連携するために必要となる機能らしいのだが、その外部のシステムがどんなシステムで何がしたいがためにこの機能が必要になるのかという情報は一切出てこない。質問を重ねることでどういう処理をすればいいのかはなんとなく分かってきたのだが、結局のところ「目的」「存在意義」「結果の正解」は最後までわからない。

ということで、理解度が100%に到達することはないということがわかったので、そこは一旦諦める。仕事だと割り切り、言われたことをそのまま遂行する思考停止モードで進めることにする。
ただ、25%しかない理解度は少しでも上げておきたい。この25%の理解度を上げていくには質問を重ねていくしかないのだが、質問のやりとりにも意外と時間がかかる。まず質問をまとめる時間が必要。そしてQAのやりとりはミーティング形式でやるのだが、そのミーティングに参加している分だけ時間を取られる。そして、回答を聞き取ってその内容を咀嚼するのにも時間がかかる。ミーティングした結果、知りたいことは明確にならず、疑問点がさらに増えてしまう場合もある。このままでは埒があかない。進捗を上げるため、疑問点を解消する場としてQAミーティングの場を作ってもらったが、ミーティングに時間がかかりすぎて逆に開発の進捗を阻害している。本末転倒。そこで質問することを一旦停止して、自分が持っている情報を駆使してなんとか動かせる形の状態を作り切る方向にシフト。他にも手が空いていた2人のメンバーと協力し、3人で開発を進める。そして、エラーなくそれっぽく動く状態まではなんとか持っていくことができた。

実際にはこの後にも色々と問題が起こるですが（当然といえば当然。正解がわからないまま作り終えたので。）テーマとはズレるのでその話はいずれ機会があれば別の記事で。。

とりあえず動く形に作り上げることはできたものの、作り終えた後、プログラムの作りといして明らかに効率の悪い作りをしていたなとかなり後悔した。

そのプロジェクトのシステム構成は
・フロントエンド：Vue.js
・バックエンド：Laravel
・DB：MySQL
という構成だった。システム開発をする際、欲しい機能を実装する上でどの部分で頑張るかを決めるのは開発者のセンスが問われるところである。
例えば、バックエンドは単純なデータを渡すだけにして、フロントエンド側で画面に合わせてゴリゴリ処理を書く場合もあれば、バックエンド側で処理を頑張って、フロントエンドは受け取ったデータを表示するだけに徹する場合もある。もちろん、機能によってフロント側でしかできない処理、バック側でしかできない処理というのもあるが、フロントとバックでデータの受け渡しを行う場合、データの変換や加工をどこで行うかは、開発者のセンスと好みによるところが多い。また、DBに対する複雑な処理を行う場合、バックエンド側でプログラムをゴリゴリ書いてもいいのだが、DBでストアドプロシージャを作ってDB内で頑張ってもらうという手もある。

この時に担当した機能は、基本的にDBに対しての更新処理がメインだったのだが、Laravelを使って機能を実装した。しかし、後になって後悔。DB側でVIEWやストアドプロシージャを使って実装した方が明らかに低コストで開発できたと気づいた。なぜ最初からその方針で実装を進められなかったのか、と、自分にとても腹がたった。しかも、この機能は自分1人ではなく、他2人のメンバーにも手伝ってもらっていたので、効率の悪い作り方を手伝ってしまい、無駄に時間を奪ってしまったなと強く後悔している。非常に申し訳ない気持ちでいっぱいです。まあ、効率が悪いとはいえ、クラスや関数はいい感じに分けてそれなりにメンテナンスやバグの切り分けはしやすいように作っているので、プログラムとしては悪くはなかったと思うのだけど。ただ、後になって全体像がある程度把握できた状態で冷静に考えてみると、どう考えてもDBのVIEWとストアドプロシージャ使うべきだったなと思う。

敗因は、
・機能の全体像が把握できていなかったこと。
・DB設計の全体像が把握できていなかったこと。
この２つにあると思う。特に後者のDB設計は重要。その機能で実装した処理は、様々なテーブルからデータを取得する必要があったのだが、テーブルの関連性を最初から全て把握していたなら、DB側で実装する考えに至ることも出来たのだろうか、と考える。開発をする時には、まず実装を始める前に全体像を把握することに徹しよう。何もわからない状態だとしても、やはり実装の前にきちんと設計をすることは重要だなと改めて思った。後悔は大きいけど１つ教訓を学べた。

１つ余談。MySQLはどうしてここまでストアドプロシージャの情報が少ないのだろう。長く使われ続けているDBのはずだが。。プロシージャとか誰も作ってないのだろうか。他のDBのプロシージャは割と作ったことがあるが、MySQLのプロシージャは作ったことがなかったので、どんなもんかと検索したけど、情報少なすぎ。Web系のエンジニアの人たち、DBの機能ももっと有効活用しようよ。この辺りも色々思うところがあるので、機会があれば別の記事で書いていこうと思う。