あらすじ

• 前記事あるけど、読まなくても大丈夫
• 若手SEが初めての設計の業務をした
• その経験を元に設計に役立つ考え方を備忘録的に書いてく

前記事では下記のようなこと説明している。

• ユーザが使いやすい設計か
• 実装、テストを含めて納期に間に合う設計か
• 設計が既存の機能やデザインにどれほど影響があるか

依頼が来た

株式会社shine meibo(シャイン・メイボ)からの新規案件で「社員名簿を作って欲しい」と言われた。最近上場して知名度が上昇した影響で、社員数が爆発的に増加。紙での管理では大変だということである。せめてEXCELとかで管理しておこうか。

社員名簿にどのような情報を表示させるのか、決めていないので、決めてほしいとのことである。既存の社員名簿は名前、年齢、性別、電話番号しか入っていないそうだ。

まず、何の情報が必要なのか、どのように検討すれば良いのだろうか。

ユーザの用途を想定する

そもそも社員名簿を使う場面ってどんな場面だろうか。
いくつか列挙してみよう。

①社員が無断欠勤しているので、電話をかける(or家に伺う)
②社員が通勤含め、勤務中に事故等にあったので、家族に連絡する
③社員が増えたので、社員名簿に追加する
④社員が辞めたので、社員名簿に表示させなくする

株式会社shine meiboでは、社員名簿は日常的に使うわけではないらしい。今回は③が問題になっていたが、社員名簿を実際に確認するのは①と②であることがわかった。

※状況の発生頻度の高さについては考えないものとする。
※部署の異動等はないものとする。

ユーザがどんな風に使用するか想定したり、ヒアリングすることで用途を明確にすることで、名簿に必要な情報が絞りやすくなるだろう。

下記は私が名簿に必要だと考える情報である。あくまで一例と思って欲しい。

名簿に欲しい情報
顔写真
名前
名前(カナ)
性別
生年月日
年齢
電話番号
緊急連絡先
住所
入社日
備考

実際にDBのテーブルを作るときは

• 一意キーの数値型として「ID」
• レコードを更新した時刻である「更新日時」
• 在籍しているかどうかのフラグ「在籍フラグ」
• 論理削除フラグ「削除フラグ」

を追加した。実際に画面には表示させないかもしれないが、表示する条件や一意のキー、更新日時をDBにつけることはよくある。

情報をどうやって画面に表示させるのか

DBに「社員情報」テーブルを作成したのは良いが、ひとつの画面にこれだけの(しかも全社員の)情報を表示させるには、情報量が多すぎる。
それに今後、表示させたい情報が増える可能性はある。それらを踏まえた上でどのように画面に表示させるのが有効だろうか。

名簿で画像検索するまでもないが、名簿は「一覧表」である。

一部の情報を「一覧で表示」させて、一覧から詳細の情報を確認できる画面に遷移させることで、問題なく使えるはずである（よくある手法だと思う）

一覧にどのようなデータを表示させるべきなのだろうか。再度、ユーザの用途を想定してみよう。

例えば無断欠勤の社員がいた場合、ユーザは一覧から、該当の社員を探す。
ユーザが「何の情報を元に該当の社員を一覧から探すか」考えれば良いのである。

一覧には、顔写真、名前(名前(カナ))、性別の情報があると探しやすいはずだ。逆に各社員の「電話番号」や「入社日」等の情報はユーザが記憶していないと考えられる。

ソートはどうすべきか

一覧表示するので、ソートを検討しておきたい。どんなソートがかけられるのか、検討してみよう。

DBを元に検討した結果、下記の案が出た。

• 名前(カナ)の五十音
• 年齢
• 入社日
• ID

どのソートで表示させるべきか、という点もユーザの用途から検討できる。

• IDはユーザが把握できる値ではないので、却下。
• 入社日も同様である。全社員の入社日など覚えていられるわけがない。
• 年齢や生年月日も覚えられないだろう。
• 名前(カナ)の五十音が良さそう。

※発音が同じ名前の人がいた場合を想定して、第二ソートに生年月日昇順をつけても良いかもしれない。

このように「ユーザがどんな情報を元に一覧を見るか」を考えればソートは比較的簡単に検討できるだろう。

フィルターはどうすべきか

今回の依頼にはなかったが、社員数が多くなれば、一覧から「検索」する機能は必要になる。表示件数の上限(100件までしか表示しない)をつける可能性もある。
※そもそも通常の表示時には「在籍フラグ」がtrueで検索している。

フィルターも実装するなら、絞りやすくてユーザにわかりやすい条件である「名前(カナ)」が良いだろう。
※性別を検索条件に入れても良いかもしれない。

ユーザの言うことは絶対？

一覧、詳細表示に関する仕様は問題ないと言われたが、物理削除の機能は要らないと言われてしまった。

ユーザの要望だから絶対なのだろうか？

レコードが増えると、検索にかかる時間が増加し、一覧画面の表示が遅くなるかもしれない。辞めた社員の情報等がずっと残り続けても意味はないのである。

ユーザには要らないと言われたが、説明して削除フラグのあるレコードが50件を超えたら古いレコードから削除する機能を実装した。

ユーザはコードの中身やIT技術に理解があるとは限らないし、「将来的に必要になる機能」等に「要らない」という場合がある。要らないと言われたので実装しませんでした、ではダメなことがあるので、しっかり検討して、ユーザの抱える課題解決のために働く必要がある。

他に検討すべきことの例

• 社員情報の入力での入力項目で必須の値は？

DBで必須かどうか決めるのに必要である。用途や検索条件で考えればわかるはずなので、検討してみてほしい。

• 社員情報の編集で編集可能な値は？

これは、値が変わる可能性があるのかを考えるとある程度見えてくる。また、社員情報の登録画面にはなかったが、編集画面には表示する項目もあるはずだ。

今回の記事は内容を広げすぎないようにするため、抽象的なままで終わらせている（性別のフィルターを入れるかどうか等）
実際にはユーザに確認、質問をしつつ、認識を合わせた上で細かい実装内容を決めていくことになるだろう。

他にも、「これは検討が必要だろう」とか「ここの仕様は良くないんじゃないか」とか、意見があればコメントに書いて頂けたら嬉しい。個人的には在籍と論理削除を分けているが、根拠は弱いので、こういうところに修正が入りそうだなと感じる。（ユーザ次第なのかもしれない。在籍しなくなって1年したら削除フラグを立てるとか）

※随分と画像のない記事なので、実装イメージの画像を追加する予定。

まとめ

• ユーザの用途から検討する
• ソートやフィルターの条件を考慮する
• ユーザの言うことを全て実現することが正しいとは限らない