こんにちは。福岡です。
WebClass の画面は一昨年にデザインを改めましたが、まだまだ古いままの画面も残っています。利用者からは統一感のなさを指摘いただく機会も多々あり、至らなさを感じるところです。
ここでは画面の置き換え、もしくは機能の入れ替えについて、開発チームで共有しておきたい全体的な方向性についてまとめておきます。一番に想定している読者は開発チームです。また新機能の開発についてはここでは扱いません。
直すつもりはあるのか？
もちろんです。使いやすい・わかりやすい画面、もしくはより便利な機能に改めていきたいと考えています。
ただし、小さなチームでの開発ですのでリソースの問題は常に付きまといます。また、いざ取り掛かるにあたり、どう直したらいいのかというのが次にぶつかる問題です。
残念ながらやみくもに手当たり次第に取りかかれるわけではない中で、どう切り崩していこうかと常に考えたり、情報収集しています。
改善の方向性
WebClass の開発で常に意識している点は以下です。
- できる限り多様な環境で利用できること
- わかりやすく汎用性の高い、シンプルな画面・機能であること
- 素早く変化し続けること
- 安くあること
- 連携
コース画面のデザインを改めた際に目指した、主に利用者目線の点は以下です。
- スマホ・タブレット・PCといった現在の利用環境へ対応
- あっさり使う利用者がすんなり使えるように単純化
画面を直すにあたり、コードの設計も改めていっています。開発目線の点は以下です。
- 画面・機能とURLのマッピングの整理
- パラメータチェックやセキュリティ対応の詳細化
2000年代のころは大学で LMS を使っていただく方は、eラーニングや LMS の活用に積極的な方が多くありました。このような利用者から多数のご意見・ご要望を頂きながら WebClass も様々な機能をそろえることができました。
2010年代にはいって大学での LMS 利用が浸透し、先生方に教育でのシステム利用に興味があるなしに関わらず、学校設備の1つとして広く授業で使われるようになってきています。また、学生の方もとりあえずスマホでアクセスするのが当たり前になってきています。また、普段から利用する先生が増えるに従い、システムの不具合があった時に与える影響も大きくなっています。こうした変化に伴い、WebClass が先に取り組んでいたのは学生のスマホ利用への対応、ソフトウェア開発工程とソフトウェアテストの改善、セキュリティ実装でした。
そこからさらに一歩進める改善が、一昨年からの新画面の取り組みです。今ではあまり高度な機能がありすぎても、普段ちょっと使うにはかえって扱いづらいと感じられるケースが増えています。また、利用端末もスマホだけでなくタブレットが加わり、学生が使うかと思いきや先生もタブレットで利用するケースがあり、とても多様化しています。セキュリティについても、ますます重大なテーマとなっています。
コードベースの改善
先月、松川さんが「ソフトウェア設計 勉強の手引き」という記事をちょうど書いてくれました。
例えばある機能の画面をきれいに直すにあたり、見た目だけ直せればいいやと考えて HTML と CSS ＋ Javascript だけの書き直しでうまくいくかというと、経験的にはそう簡単に行きません。見た目の整理は取り扱う情報の整理になるので、結果的にはプレゼンテーション以前のデータ構造やデータの受け渡し経路を見直す必要が出てきます。特に Ajax を使った SPA にしたい場合、JSONデータインタフェースの実装が必要になるので、当然ながらインタフェースの拡張が必要になります。これらはセキュリティ実装でも同じことが言えます。したがって多かれ少なかれリファクタリングをすることになります。
利用者から見えないリファクタリングに時間を食われるのをもどかしく思うこともありますが、私は画面の改善でリファクタリングが必要になるのは好機と見ています。素早く確実にソフトウェアを改善し続けるためには、コードの保守性は重要です。これまで画面を変えられなかったのは、その様なコードの体制がなかったのも原因の1つです。ですがコードの問題は画面の改善だけでなく、テスト可能性やテストのコストにも反映されます。
幸いなことに、コードの設計は手本になる本やオープンソースのライブラリやプロダクトが多数あります。したがって、何を実現するかがはっきりしていれば解は比較的見つけやすいです。また、基本的には良いパターンを使いまわしていきます。なので、一か所で何とかすれば、同じような個所を一気に片付けることができます。そして、その後は維持しやすくなると期待できます。
見た目・機能の改善
コードベースの問題を乗り越えて実質的な機能修正に取り組むにあたり、一番問題になるのは「本当に使いやすいのか？」という点です。
コードの良さは計測しやすく、開発チーム内でコンセンサスが得られればOKという意味で、評価しやすいです。一方、画面や機能について利用者がどう思うかは計測・確認がしにくく、いろんな利用者がいてコメントの方向性が定まらないケースもあります。また、仮にいい画面になったとしても、慣れの問題が付きまといます。この点について個人的に印象深いのは Microsoft Office 2007 のリボンUIです。出た当時はいろいろ言われていましたし、私も「なんで？」と思いました。従来のメニューでは一通りの機能を本当に扱いきれなかったのかどうか私には評価できませんが、今では慣れて特に問題なく使っていますし、スタイルの適用などはUI表示域の広さと表示される情報とが程よく、便利だなと思っています。
真似しやすいコード設計に対して、UIや機能の設計は基本は考えてひねり出すのが良いと思います。利用者のコメントはありがたい参考資料になりますが、そのまま受け入れるだけだとブレます。特定の利用シナリオにぴたりと寄り添うほど汎用性を失って、オプションを必要としてしまいます。オプションも加えれば加えるほど動きがわかりにくくなり、テストやマニュアルの周辺作業が積みあがってしまい、機能を洗練させる時間を取れなくなります。
ではどうしたら良い機能や画面をひねり出せるか、これは私もいつも悩む問題です。やはりここは、いろいろ聞いたり試したりするしかないと思っています。特に、先生がどんな状況でどんなことをしようとしているか、というあたりでしょうか。WebClass のあるなしに関わらない、もう少し根本的なシーンやシナリオが見えてくると、考えやすいです。でも、特定のケースに固執しすぎては汎用性を失います。ここが難しいといつも思います。
取り組み続ける
利用者がいてくれる限り、WebClass の開発は終わりません。その時ごとにテーマや課題があり、常に変化・対応し続けていきます。今いいものも、2年後には利用環境と乖離して使い物にならなくなっている可能性もあります。それどころか、後になって昔の機能の価値を再発見してしまうこともあります。そういう意味で、コードベースの改善も画面・機能の改善も果てがなく、あまり考えすぎてしまってもしょうがないところがあります。
なので私たちはアジャイルなソフトウェア開発の仕方を取り入れています。小さく手堅い修正を素早く重ねて行く作戦です。画面の置き換えも、表には見えないリファクタリングだけ先に進めたところもあります。その中で、試したけど捨てたコードも多数あります。いいと思って採用したけど、思ったようには行かなかったコードも多数あります。ですが、これらは「うまくいかない」ことがわかった成果として無駄ではなかったと思っています。
いずれにせよ、多くの利用者が使うシステムでは「パパッと作って何とかなる」とは行きにくくなります。タイムリーに新機能や改善を提供し続けるためにも、普段からリファクタリングや試行錯誤を常にやり続け、そして学び続け、堅実なコミットを積み重ねていきます。
