に対する感想。
筆者に拍手
まずこの記事を書いた人にスタンディングオベーション。とてもきれいにまとまってる。そして「現状はどういう風に開発されているか」ってことがとても良く書かれてる。この通りに進めていれば叱られることはない。
ただし、困ったことに、この手順どおりに作っていてもおかしなことには起こる。
画面設計からというスタート
いきなり画面設計からスタートする。画面というのはユーザが目にする部分なので、正直画面さえ「握れていれば」そのさきの実装は本当はどうでもいい。なので、「画面で要件を握る」は契約上は正しい。ただ、顧客でさえも「どういう画面が必要か」ってことは分からない。
情報システムなので「情報」が大事
画面をベースにすすめるとどうしてもフォームをいっぱい作っちゃう。「たくさん入力させる」ってことばかり来ちゃう。情報システムって「コンピュータにいい感じに未来を教えてくれる」ってもののはず。なので、画面設計よりもなによりも、「コンピュータに何をしてもらいたいの？」ってことが大事。
究極はUIなんてなくてもいい。「定期的にメールで集計結果が来る」って情報システムだってあっていい。（というかそっちが便利なケースが多い）。
要件定義は何を作るかじゃなくて「何を作らないか」ってのがコツなので、既存の枠組みの中でも「UIレスでデイリーでメールが来るだけにしましょう」って提案もとおるはずなんだけど、なかなかそういう「空気」にならない。
データオリエンテッドという手法もある
画面単位ですすめるという一派に対して、「データから整理しましょう」って一派もいる。画面ベースからすると「手段」にこだわりすぎな気もするんだけど、情報システムなので「どう情報を整理するか」ってのはとても大事。先の記事の開発プロセスではいきなりデータベース設計から入る感じ。
「どういうデータがありますか？」って整理から入る。一件難しいようだけど、クライアント企業にはすでに山程エクセルファイルが転がってる。実はエクセルベースでこれでもかというほど、データベース設計は何度もやってる。なので意外とデータオリエンテッドの方式も顧客と会話はしやすい。
データに対して、そのデータはどこからやってくる？ってことを整理することが情報システムの設計そのものだったりする。
究極、今の業務フローが紙ベースであっても、伝票とか台帳は存在する。伝票がフォーム、帳票が一覧。
データの寿命は画面の寿命より長い
画面って徐々に改修ができるんだけど、データベース設計って一度入った過去データを変えるのはとても大変なので、データベース設計において、クライアント企業と食い違いがあるとマジで苦労をする。「従業員って複数の部署に所属できる」って仕組みをデータベースの改修からやるのはとても大変なのは、非エンジニアでも分かってもらえる。分かってもらわないといけない。エクセルベースでもしんどいことはわかるはず。
クラス図に対するオブジェクト図
UMLの中でも「サンプルデータを元に設計をしましょう」という発想がある。それがオブジェクト図ってやつ。クラス図だと項目名が並ぶだけなので、「で、その項目にはどういうデータが入るの？」って質問が毎回起こる。
そうなると、クラスに対するインスタンス（DBで言えば実データサンプル）を元にやった方がいいじゃないかという話。
あくまで「サンプル」なので、設計としてはかっちりした境界を作りにくいんだけど、圧倒的にコミュニケーションは取りやすい。 結局「エクセルのサンプルを元に進めましょう」ってことと対して変わらない。
phpmyadminむき出し
データオリエンテッドの良いところ（？）は、クライアントもデータ構造を分かってるので、dbを直に見せるということも可能。phpmyadminで参照権限で入ってもらって、あとはお好きなようにダウンロードしてもらってエクセルベースで集計してくださいなというやり方も可能。お行儀が良くない感じがして、誰もそういう方式をひな形にはしないのだけれど、DB直参照って結構多い。
だったら、最初からphpmyadminのむき出しのUIありきですすめましょう。必要なのはデータなのだから。
