今日は一部の人に刺さるであろう新機能の紹介をします。学習記録ビューアの組織管理権限を、学習記録ビューア システム管理者から他ユーザーに引き渡すことできるようになりました！これまではシステム管理者が組織を一元管理するしかなかったのですが、一部の組織の管理をその組織専任の監督に任せてしまうようなことが可能です。

運用例

教職過程コースを履修している学生に、活動記録と自己評価をさせる、教職履修カルテ プラグインを利用している場合。

管理者は上位組織（上図の「教職履修カルテ」）で全体を管理しています。指導教員が各学年ごとの組織（上図の「1年生」等）で、担当する学年の学生にアドバイスしています。こういう場合、指導教員に、担当する学年の学生の追加・削除を行って欲しいことはままあると思います。

そこで、各学年の指導教員に、担当する組織で、今回実装された「組織管理」権限を付与します。

すると、「組織管理」権限を付与された指導教員は、担当する組織で、メンバーの変更や権限設定を行うことができるようになります。

このように、現場の人に権限を渡して一部の作業を任せてしまうことで、学習記録ビューア システム管理者が全てを管理する必要がなくなり、お互いに仕事がやりやすくなるかもしれません。ぜひ有効に活用してみてください。

「組織管理」権限は、学習記録ビューア v4.2 でご提供予定です。後ほどマニュアルで詳しい使用方法をご案内します。

こんにちは。福岡です。

私がいる事務所は調布ベースという名前になりました。調布の駅近にありますが、具体的な場所は非公開です。

大学に入った時に調布に来て以来、ほぼ調布にいます。駅、市役所や病院など町の機能がコンパクトに収まり、かつ混みすぎないので快適な町と思って気に入っています。開発でも、近くにある電通大の学生がアルバイトに来てくれていて、とても助かっています。

そんないい町、調布のお店を紹介します。今回は「海南記」という中華料理屋さんです。

たぶん中国の人がやっています。中国語はよくわかりませんが、たぶん中国語で店員さんが話していたり、たぶん中国語の音楽がかかっていたり、回転する丸テーブルがあったりと、雰囲気もそれっぽいです。

夜は行ったことありませんが、ランチは680円でしっかり食べられます。日替わりメニューといつものメニューがあります。

食レポみたいに上手いこと書けませんが、美味しいので週一くらいで行ってます。

こんにちは。福岡です。

調布ベースでは、だいたい月に１回、社内で勉強会を開いています。開発等に関して、みんなでネタを持ち寄って発表しています。今日も夕方というか夜にやっていました。

私は好きでネタも考えますが、こういうのは好きな人そうでない人、また意味があると考える人もいれば無駄と考える人もいます。そのあたりを少し整理しようと思います。

勉強会で何を狙っているか

私は「やろうよ」と声をかけることもある身として、以下を考えています。

• 見つけたネタを共有できたら楽しい。自分もそうだし、同じように考える人がいたら聞いてみたいな
• まっすぐに自分の業務の内容だけ調べていると刺激が薄れるので、変わったネタを仕入れたい。他の人にもそんな刺激ができたらいいな。
• 普段は、特に学生は時間がばらばらなことも多いので、たまにみんなで集まって楽しく話したりしたいな

ネタと言っても、私はあまりクオリティの高いネタを用意できないので、緩くでいいかなと。

一方で、他に参加する人にはその人たちの思惑もあってしかりと思います。

一般に「勉強会は無駄」と言われることもある

ときどき気になるのが、他の人は負担ばかりで出たくないと思っているんじゃないか？ という点です。

ちなみに、うちでは自由参加で時給が出るので、決して自主性を重んじて云々みたいな綺麗ごとだけの会ではないと信じています。ですが、それより作業を進めてさっさと帰りたいと思うこともあれば、みんな出てると断りずらいなと思うこともあると思います。

技術力向上させたいと思って会をひらくなら、研修の形をとるのが良いはずです。もう少し研修も充実させたいとも思っています。その点、「研修やるぞ」と構えるほどではなく「こんなのあるよ」と伝える機会が持てているのは、ありがたく思っています。とはいえ、研修にするならするで、私自身も時間の使い方に気を付けないといけませんね。

無駄にしないために

結局のところ、活かすかどうかはその後どうするかだと思います。特に聞くだけだった人は、その後で自分で実践したり練習したりして自分のものにする時間と労を投入しない限り、ただ聞いただけになります。

ただ、「その後」が次の日でなければいけないと考えすぎると、しんどいですね。半年後に「そういえば」でつながることもあると思います。その点を考慮して、時間や頻度など調整していく必要があると思っています。

緩く行けるといいなという点と、やるからにはという点と、いつも考えています。

楽しく、まじめに

うじうじ考えるだけの駄文になってしまいました。

僕としては、学んだり挑戦しようとする人は支援したいです。そういうところはまじめに行きたいです。でもできたら、楽しくできたらいいなと思います。

こんにちは。福岡です。

WebClass の画面は一昨年にデザインを改めましたが、まだまだ古いままの画面も残っています。利用者からは統一感のなさを指摘いただく機会も多々あり、至らなさを感じるところです。

ここでは画面の置き換え、もしくは機能の入れ替えについて、開発チームで共有しておきたい全体的な方向性についてまとめておきます。一番に想定している読者は開発チームです。また新機能の開発についてはここでは扱いません。

直すつもりはあるのか？

もちろんです。使いやすい・わかりやすい画面、もしくはより便利な機能に改めていきたいと考えています。

ただし、小さなチームでの開発ですのでリソースの問題は常に付きまといます。また、いざ取り掛かるにあたり、どう直したらいいのかというのが次にぶつかる問題です。

残念ながらやみくもに手当たり次第に取りかかれるわけではない中で、どう切り崩していこうかと常に考えたり、情報収集しています。

改善の方向性

WebClass の開発で常に意識している点は以下です。

1. できる限り多様な環境で利用できること
2. わかりやすく汎用性の高い、シンプルな画面・機能であること
3. 素早く変化し続けること
4. 安くあること
5. 連携

コース画面のデザインを改めた際に目指した、主に利用者目線の点は以下です。

1. スマホ・タブレット・PCといった現在の利用環境へ対応
2. あっさり使う利用者がすんなり使えるように単純化

画面を直すにあたり、コードの設計も改めていっています。開発目線の点は以下です。

1. 画面・機能とURLのマッピングの整理
2. パラメータチェックやセキュリティ対応の詳細化

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年後には利用環境と乖離して使い物にならなくなっている可能性もあります。それどころか、後になって昔の機能の価値を再発見してしまうこともあります。そういう意味で、コードベースの改善も画面・機能の改善も果てがなく、あまり考えすぎてしまってもしょうがないところがあります。

なので私たちはアジャイルなソフトウェア開発の仕方を取り入れています。小さく手堅い修正を素早く重ねて行く作戦です。画面の置き換えも、表には見えないリファクタリングだけ先に進めたところもあります。その中で、試したけど捨てたコードも多数あります。いいと思って採用したけど、思ったようには行かなかったコードも多数あります。ですが、これらは「うまくいかない」ことがわかった成果として無駄ではなかったと思っています。

いずれにせよ、多くの利用者が使うシステムでは「パパッと作って何とかなる」とは行きにくくなります。タイムリーに新機能や改善を提供し続けるためにも、普段からリファクタリングや試行錯誤を常にやり続け、そして学び続け、堅実なコミットを積み重ねていきます。