【はじめに】
初めまして！
株式会社ネクスウェイの医薬情報事業部で企画職をしている、@ayanonnです。
今回技術広報プロジェクトに入り、エンジニアの方々に囲まれて私の業務の効率化ツールを作成することになりました。
業務の中で、隔週で薬剤師さんに向けて、弊社のプラットフォームで受講できる研修をまとめたメルマガを配信しているのですが、たくさんの研修の中から一つ一つ確認して作成していくのに時間がかかっていました。
これまでは、メルマガを1回作成するのに約1時間かかっており、対象となる研修を確認するために何度もサイトを見る必要がありました。
今回のツールを作成したことで、この作業時間を1回約15分まで短縮することができ、サイトを何度も確認するストレスも軽減することができました。
【実施したこと】
私がこのプロジェクトの中で携わった部分は以下です。
- 該当の業務において、どんな課題があるのかをヒアリングしてもらい必要な機能を検討
- 決まった大まかな機能から、要件定義作成
- 画面遷移図作成
- 一部プログラム修正
- テスト内容の検討、確認
要件を考える際には、例えば以下のような条件を決めました。
- 新着研修は、フォームに入力した開始日と終了日の間に研修登録日が含まれるもののみ表示する
- メルマガ配信日として入力した日付を基準に、14日前以降に研修開催開始日が含まれる研修を表示する
最初は「対象となる研修を表示できればよい」くらいのイメージでしたが、実際には、
- どの日付を基準にするのか
- 境界の日付を含めるのか
- 入力されていなかった場合はどうするのか
など、誰が見ても同じ解釈ができるように要件を決めていく必要がありました。
【体感した3つの気づき】
①「全体像」と「要件定義の深さ」がわからない
最初にぶつかったのが開発の全体像が見えないことでした。
何から始めて、期日までに完成させるにはどのくらい作業が必要なのか？
今は順調なのか、遅れているのか？
がよくわかりませんでした。
また、
要件定義ってどこまで書けばエンジニアさんに伝わるのか？
というところも難しかったです。
詳細を伝えようと細かく書きすぎても、必要ないことに大事な部分が埋もれてしまいそうで。
開発を進める中では、「なんとなくこうしたい」という状態から、誰が見ても同じ動きを想像できるくらいまで条件を具体化する必要がありました。
例えば日付を条件にする部分では、指定した日付そのものを含めるのか、その前後はどうするのかといった境界部分まで考える必要があります。
実際のテストでも、こうした境界線で想定通りに動作するかを確認しました。
②機能以外にも決めること、確認することがある
機能（〇〇ができる）を考えるのと同じくらい、あるいはそれ以上に非機能要件が重要だということを知りました。
ただ動けばいいのではなく、どの程度のサービス品質を担保するのかといったことも決めなければなりませんでした。
今回の開発を通して、
- SLA
- 非機能要件
- 例外
- バリデーション
といった言葉についても知ることができました。
そもそも作り始める前に、
- 「安全なのか」
- 「元サービスの規約に反していないか」
という前提条件を調べることから開発が始まっているのだと痛感しました。
また、実際に作る中でも、
- 取得した研修をどのように一覧表示するのか
- メルマガ配信用のツールで必要のない処理をどこまで持たせないようにするのか
- 多重リクエストをどのように最小限にするのか
といったことも検討しました。
研修情報を取得するために何度もリクエストを行うのではなく、できるだけ必要最低限のリクエストで処理できるようにする、といったことも考えられていました。
③デザインと設計
素人目線だと、ついつい見た目が見やすく、綺麗な画面を作り込みたくなってしまいます。
しかし、開発を進める中で学んだのは、あえてリッチにしすぎない判断の必要性でした。
- この装飾や機能によって、ページの重さにどう影響するか？
- そもそも「誰向けのプロダクトなんだっけ？」という原点に立ち返ったとき、本当に必要な装飾なのか？
見た目の美しさだけではなく、ユーザー体験やパフォーマンスまで含めて引き算をする設計の深さを知りました。
また、画面を作るということは、その画面単体だけを考えればいいわけではありませんでした。
どの画面からどの画面へ移動するのか、どのタイミングで入力や処理が発生するのかを画面遷移図として整理することで、初めて全体の動きが見えてくることも知りました。
↓実際に作成した画面遷移図の一部↓
【実際に業務はどう変わったか】
今回のツール作成によって、これまで1回約1時間かかっていたメルマガ作成業務を、約15分まで短縮することができました。
| 項目 | Before | After |
|---|---|---|
| メルマガ作成時間 | 約1時間 | 約15分 |
| 研修(イベント)の確認 | サイトを何度も確認 | ツール上で対象研修を確認 |
| 作業負荷 | 手作業で一つずつ確認 | 確認作業を軽減 |
単純な作業時間だけでなく、メルマガの対象になる研修を探すために何度もサイトを確認する必要も減り、作業中のストレスも軽減されました。
【さいごに】
日々新しいツールや用語が次々と登場する中で、それらを学び続け、安全で高速なシステムを作り上げるエンジニアのみなさんには尊敬しかありません。
今回開発に携わったことで、単に仕様を渡して作ってもらう関係から、エンジニアが裏で何を考慮してくれているのかを理解し、同じ目線で会話する重要性を学ぶことができました。
また、これまで自分の業務だけでは触れることのなかった単語や考え方についても知ることができました。
実際に、今回のプロジェクトの中で「バリデーション」という単語を学んだのですが、その後の事業部の開発ミーティングで会話に出現し、「あ！これ〇〇ゼミプロジェクトでやったところだ！」となりました。
専門用語をちゃんと理解していると、認識齟齬が起きないので大事ですね。
事業側として「こういうものが欲しい」と考えるだけでなく、依頼を受けて実際に開発する側が、どのような情報を必要としているのかという視点も少し持てるようになったと思います。
「なんとなくこうしたい」をそのまま伝えるのではなく、極力誰が見ても同じ解釈ができるように要件を定義することの難しさと重要性を体感できたことは、今回のプロジェクトの中で特に大きな学びでした。
- もっと他の記事も読んでみたい方
- 当社に興味がある方はこちら👀
- 当社のサービスに興味がある方はこちら👀