エンジニアとして社内で使うウェブアプリを開発しています。
僕の会社はIT担当の部が3人しかいません。そのため、細かい役割分担はされておらず、要件定義・顧客ヒアリング・ウェブデザイン・フロントサイド開発・サーバーサイド開発など、まんべんなく担当しています。
開発は概ね順調でしたが、今振り返ると色々な無駄が起きていました。その中でも、一番やってしまったと思ったことについて紹介したいと思います。
目次
前工程・後工程で利用されるデータの仕様をしっっっかりと確認する
結論からいえばこれです。字面だけを見ると「当たり前じゃないか」と思うのではないでしょか。僕もそう思っていました。しかし、まんまとハマってしまいました。
現在のウェブアプリ開発ではDOA(Data Oriented Approach)といって、データの構造や定義を中心に設計していくことが主流となっています。
まず、どのようなデータがあって、それをどのように処理して、それをどのようなデータでアウトプットするのか。それを決めた後、DBの設計→アプリの設計という順番で開発をしていきます。
そのため、データの構造や定義が後から変わると、修正に大変な手間がかかることが多いです。手間がかかるということは、それだけバグが生まれやすいということですね。
また経験上ですが、データベース設計の質が低いと、アプリケーション側のコードがグチャグチャになりやすい気がします。それだけウェブアプリにとってデータは大切なものになってきています。
そのため、どのようなデータが入るかについて社内の事業部としっかり確認することが重要なのは言うまでもありませんが、つい漏れが発生してしまいました。具体的には以下のような内容です。
そのカラムのデータはユニークか？
CSVファイルをインポートしてデータ処理するアプリを作っていたのですが、ここの前提の確認が漏れていました。
具体的に起きたこととしては、「過去に同じデータをアップロードしたか？」という判定をとあるカラムの中身を見て判定していました。
てっきり、そのカラムに入るのはユニークなIDだけかと思っていたのですが、「-」が複数入っているファイルをインポートしようとしていることが発覚し、急いで修正しました。
空になることはあるか？
これも非常に重要です。まず、そもそもDB設計の時点でnullを許すかどうか決めなければいけないので、これが分からないとアプリを作れないはずなんですが。。。
空になることが無いという前提でつくっていると、アプリケーションで使う際に空の配列が生まれるなど、予期しない動作が発生することがあります。
どのような要素が入るのか
これもDB設計の時点で確認しておくべきことです。絶対に数字しか入らないのか、それとも文字列が入るのか、最小どのくらいの長さで最大どのくらいの長さなのか。
細かく確認しないと、数字がオーバーフローしてしまったり、文字列が勝手に0にintキャストされてしまったりして大惨事になります。
その列は常に存在するか？
そもそもカラムが常に存在するかということも確認する必要があります。これは結構盲点でした。カラムが存在しないことがあると、データを登録する時点でエラーが出たり、抽出したデータを配列化して使うときに存在しないキーを使ってしまうなど。
そもそも列が常に存在するか？というのは、実際の現場に出てみると常に「YES」とはいえないこともあります。
前工程と後工程の理解の重要性
今回は前工程に関するものでしたが、後工程についても同様に重要です。
アプリで出力したデータが次の業務でうまく使えないなど、アプリの存在価値がないですからね…
前工程と後工程の深い理解は、もしかしたら事業部の人にとっては「なんでそんなことまで知りたがるの？」と思われるかも知れません。しかし、IT開発を成功させていくには必須のものだと思います。
