「設計」で意識しておきたいこと 第03回 20年08月 / 最終更新：2020.08.04
前回はmockupのお話で、主に「要求仕様を(ある程度)握る」ようなお話をしていきました。
今回はその次に出てくる「設計」について、少しお話をしていきたいと思います。
システム設計は色々な切り口があるかと思いますので。
今回は、筆者が設計で気をつけている事をいくつか上げてみたいと思います。
一端「発注者と受注者」という切り口から書いていきますが、社内システムであっても「そのシステムが欲しい人(≒発注者)」と「そのシステムを作る人(≒受注者)」がいると思うので、その辺は自分の環境によって適宜置き換えていただければ、と思います。
個人的にまず重要視するのは「ヒアリング」です。
発注者の「こんな実装が欲しい」は、必ずしも十全に的を射る発言であるとは限らなくて、実は「もっとよい実装方法がある」事も、少なからずあります。
そういった時に。
「なぜ欲しいのか？」「それによって何を得たいのか？」といった、本質的な所をしっかりとヒアリングできるかどうか、は、とても重要になります。
「ウォンツではなくニーズを」というお話はマーケティングの世界で使われているようなのですが、システム設計におけるヒアリングも、これと同じ事が言えます。
お客様が「こんな実装が欲しい(ウォンツ)」をそのまま鵜呑みにするのではなく、その背景に根底にある「それによってどんなメリットを得たいのか？ デメリットを排除したいのか？」までがわかるようにしっかりとヒアリングをすると、そこから「そのニーズであれば、こういった実装はどうだろう？」という提案が、さほど的を外さずに出来るようになります。
逆に「ウォンツをそのまま鵜呑みで実装」すると、時々「言った通りの物ができあがってきたのだけど満足感が低い」という事が起きるので、注意が必要です。
そのためにも、発注者の要求についてのヒアリングは「もう一歩踏み込んで、その根底にあるニーズを聞き出す」事を大切にしていきたいものです。
次に大切にしているのが「データ」です。
発注者の様々なニーズは、それ自体は「よくわかる」んだけれども、いざ実際のデータを準備してみたら「そのニーズはこのデータでは難しい」といった事は、実は時々、起き得ます。
「アルゴリズム＋データ構造＝プログラム」という書籍がありましたが、実際、プログラムは「データ」を「処理する」もので、つまりデータは「プログラムの片割れ」です。
そのため、設計の時に出来るだけ「実際に本番で使うデータそのもの」を、質的にも量的にも揃えるようにするのが一番安全かと思います。
なぜなら、テストデータは「こうだといいな」という期待が多少なり入る事が多いため、時として「実データと乖離」する事があり。
しかし実際には「実データ」で処理を行う必要がある事から、「実データになってみて初めて気付いた問題点」というのが、時として起き得るから、です。
もしそれが難しい場合は「出来るだけ早く、テストデータではなくて本番用の実データを入手できるようにする」「実データが手に入ったら、一通り検証をする」というスケジュールを組み、もし「実データが当初の設計やニーズに対して問題があるもの」であった場合のヘッジの時間とプラン変更の想定も、しっかりと考えておくとよいかと思います。
「このデータがないと処理が回らないんだけど、実際にはそのデータはなかった」「データ量が想定よりも遙かに多かった」「データのフォーマットが想定と全く違っていた」など、データ周りは割と色々な事がおきやすいので。
ポイントは「テスト用のサンプルデータではなくて、実際に使う実データを出来るだけ早く入手する」事です。
ここには、十分、十二分なリソースを割いておくと、プロジェクトの後半でどんでん返し、といった事が減るかと思います。
次回は、設計の中でももう少し「実装寄り」の所のポイントについて書いていければ、と思います。
サービス・ソリューション
