TriTry

今年から新たなコンテンツとして、ITの現場におけるケーススタディを記事にしたいと思います

プロジェクトを一つ終えた初級以上の方が対象にしますが、多くの場合マネージャクラスの知見が必要になりますので参考にしてみてください

依頼内容は下記の通り

データ集計部のNさんから依頼だ。Nさんはエクセルでの集計とSQLでセレクトは実務で経験があるといっている。ビジネス部であるため開発経験はない。趣味でPythonを書いているらしい。

Nさん「エクセルで毎日作っているレポートがある。業務ではまぁまぁ使っている。新しいDWHができたと聞いた。そのDWHからデータを引っ張ってきてこのエクセルのレポートを作成してほしい」

Nさん「計算式が乗ったエクセルのサンプルとどのデータベースからデータをとって結合しているかのER図はある」

さて、まずは何を疑い、どの確認から始めるべきか

非エンジニアの人の中で「プログラミングできる」と自称する方と仕事をする機会がよくあります。

たいていの場合「プログラミングできる」とは「動くPythonかマクロのコードが書ける」というところで、「実装フェーズ」ができるというレベルではない方がほとんどです。

「実装フェーズ」のコードをうち動作確認まではできるというところで、実装に必要な一貫性や可読性、ひいては実装方式で決まる効率やパフォーマンスまでは考慮できないことを想定しなければなりません。

この人の場合、ER図とありますが「1体多」「多対多」などは分かっていないですし、結合条件もわかっていませんでした。ただただカラム同士が同じとしか書いていませんでした。

依頼からいつどこにどのようなファイル形式で出力してほしいかが不鮮明であるため、ここを確認する。

それと同時にエクセルのテーブル名、カラム名がシステム内部の論理名と一致しているかを確認する。非IT部が持ち出す「テーブル名」はたいていの場合一致はしていない。これはBIツールの名称になっていて、ビジネス上必要となる隠れた結合が存在しているためだ

そうなると提示している結合条件が誤りになるため、次にすることは、設計書を見ながら、業務部と連携して、見えているデータがどう作られているのかを再発掘する作業となる。

ここで見るべき設計書は下記

• ＥＲ図（ＩＴ部作成）
• データ項目的定義書
• ビジネスロジック定義書（あるいは機能概要書）

上記が存在しない場合は、ここから作成するつもりでヒアリングが必要となる。つまり、工数が大きくなる。

真っ先にやってはいけないことは、一番めんどくさい計算方式を確認だ。ここは最後の確認でよい。その上流で誤りが多いからこの計算方式は見ないでも誤りと判断してよい。

要件を詰めなおす場面で再定義するので時間の無駄になる。

「プログラミングできる」人から依頼を受ける場合、たいていの場合、すぐに「実装」の話に入りがちです。

もっと言えば、サンプルまで作ってくる場合があります。ここが話が難しい点でもあるのですが、あとはこれをシステムの中で動かせばいいだけと思っています。プラモデルのパーツのようにくっつくと思っているのです。

これが大きな誤りであることはITエンジニアであればすぐにわかることだと思いますが、こういった方の場合、この「インターフェイス」が難しいことが理解できていないケースがほとんどです。

このケースの場合はBI用のインターフェイスになっていて、バッチ用にはなっていないことが挙げられます

このまま無理やりにでも実装すると欠落するものは代表的には下記のリストに挙げたものになります

• データの正当性の担保の方式
• 連携のファイル方式や暗号化方式
• 連携タイミング
• 連携後の保管場所やライフサイクル
• バックアップの有無
• エラー時の連絡手段
• エラー時の再実行の実施可否

この中で最も重要なものは一番上のデータの正当性の担保の方式です。

来たものを無理やり実装するので、連携時にうまくいっていないもので数字は出てしまうのです。そして「たまたま出た数字」でOKサインを出して隠れている障害に気が付かないことは大いにあり得ます

何が正しいのかの定義ができないまま実装を進めることほど危険なことはありません

プログラミングできる人の言いなりに作ると正当性の担保ができないことは確認しました。ではこの正当性の担保はどこでするのでしょうか。

答えはケースバイケースです。

ITエンジニアの方であればVモデルはご存じでしょう。このVモデルに照らし合わせて、要件定義まで戻るか設計でよいかを判断します。

今回のケーススタディも含め、多くの場合「要件定義」が必要になります。何がしたいのか、どんなデータを用いたいのか。というのは要件定義です。

しかし、こういった方の場合は「要件は実装だ」とかっこつけて言うことでしょう。おそらく要件定義には耳を貸さないでしょう。

実際職人の域に達しているエンジニアはこのように言います。ただ、ITへの理解が全く異なります。

そのため、必ず要件が欠落するのです。上のリストで見たものもほとんどが要件です。

この場合は「実装に近い設計を経由する」ことが最も重要な手段になります。つまり「詳細設計」です。

自信のある「実装」に対して不備を指摘することで一個前のフェーズに戻ります。そのまま欠落している要件を一つ指摘することで、ほかも探さなければならいという話にもっていきやすくなります