こんにちは、クランチタイマーでインターンエンジニアをしている懸川です。
先日、自社の勤怠システムの要件定義・UI設計をはじめて経験しました!
とにかく初めての経験で失敗だらけでしたが、せっかくなので今回の失敗を通じて学んだことをまとめていきたいと思います。
これから要件定義やUI設計にチャレンジするという方は、ぜひ参考にしてください!
今回開発したシステムについては、同じチームのメンバーが記事を書いてくれているので、そちらもよければ見てみてください。
インターン生の仕事紹介【Ruby on Railsを使った勤怠システムの開発】
心得1. 相手に正解を求めない。
まず要件定義の段階で、僕は勤怠システムを使う予定である自社プログラミングスクールのスタッフに「どんな機能が欲しいですか?」と質問しました。
この時、僕はユーザーが正解を持っていて、それをただ聞けばいいと思っていました。
しかし何人かに聞いても、相手が抱えているのは「時間がかかる」「手間がかかる」というようなぼんやりしている課題であって、こんな機能が欲しいという明確な希望はまだ見えていないことがほとんどでした。
そこで、「スタッフがアナログで行っていた勤怠をもっと効率的に、楽にする」というシステムの目的に立ち返り、現状の手作業の流れを細かく聞くことから始めました。
そうすることで、システムに落とし込む時にどんな機能がどのページにあったら良いかが見えてきて、スクールのスタッフにとっては慣れていてベストと思える形も、僕たちが客観的に聞くことでもっと改良できるなと思う箇所を見つけることができました。
このことから、最初から正解を求めるのではなく、ユーザーのぼんやりした課題を明確にし、課題の解決方法を自分達で提案することが大切だと痛感しました。
心得2. UI設計は必要最低限ではなく、しっかりと具体的に練る。
UI設計の段階で僕は、どうせ実装する時に見た目も作るのだから必要最低限だけ作ればいいと思っていました。
しかし、この考えは手戻りの原因となりました。
紙に簡単に書いただけのデザインだと、完成形は頭の中でイメージするしかなく、実際に出来上がってみるとやっぱり微妙ということが度々あり、結局修正しなければならないというケースが多かったのです。
UIを練る時間をしっかりととることで、具体的な操作のシミュレーションを何通りも考えることができ、さらに必要な部分や設計ミスにも気づくことができました。
また、細かい部分まで作り込むことで、これからどんな実装をすればいいかも見えてくるので、スケジュールも立てやすくなりました。
心得3. デザインは最終的な装飾と線引きせず、設計の段階から十分に意識する。
これはエンジニアあるあるなのかもしれませんが、設計の際に必要な情報や機能ばかりに注意が向いてしまい、ユーザーが実際にどう使うか、どうしたら使いやすいかなどをイメージするデザイナー的な視点が欠けていたことが多々ありました。
そんな中ある日、
というデザインに関する素晴らしい記事を見つけて、実際に参考にしてみると実際にデザインが改善され、チームのメンバーと感動したのを覚えています(笑)
「ユーザーがどう使うかをとことん考える」ことがとても大切であり、設計の段階からきちんとデザインへの意識をもっておく必要性に気づくことができました。
心得4. 感覚的に操作できるかをチェックする。
チームのメンバーだけでUIを作っていると、どうしても設計者側の考え方に寄ってしまい、ユーザーが初見で分かるかどうかというのが、見えにくくなってきます。
そこで、担当が違う他のエンジニアに実際に画面を触ってもらい、その時に詰まったところやわかりにくく感じたところを教えてもらうことで、ユーザーが負担なくわかりやすいUIを実現することができました。
心得5. いろんなサービスを触ってみろ。
普段何気なく利用しているサービスも作る側の観点で見てみると、参考になるところが山ほどあります。
ストレスなく使えているものほど細かいところまで作り込まれていて、実際に自分たちのシステムに応用できるところがありました。
そして、このいろんなサービスを触るべきという点は実は社長に日頃からよく言われていることでもあります。
終わりに
インターンの立場でありながら、クライアントへのヒアリング、仕様やデザイン決め、スケジューリング、これらをさせていただいたのは、とても貴重な経験でした。
このシステム自体も、最初のリリースからアップデートを繰り返し、ヒアリングからリリースまでのサイクルを何回か回してきていますが、社長からもだんだんと上手になってきていると言っていただけて、成長しているのだと実感します。
しかしながら、まだまだ甘い部分だらけなので、これからもっと経験を積んでもっとうまくプロジェクトを進められるようにがんばりたいと思います!