社内勉強会

こんにちは。福岡です。

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

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

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

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

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

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

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

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

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

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

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

無駄にしないために

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

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

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

楽しく、まじめに

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

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

WebClass で使えるサーバOS リリースとサポート状況

RHEL8がリリースされたようです。

いつも通り、評価版は期限付きで無料で試せるようです。

v7 からの違いをまとめたブログ記事を見つけました。

ntp パッケージが消えて chrony に統一されたり、出来たと思ったところの firewald が早くも消えたりと、また変化がありますね。

CentOS については、まだ v8 のアナウンスはありません。いつも少し遅れて出てきます。

Server OS Lifecycle

RHEL

RHEL のバージョンとサポート状況はこんな感じです。

いろいろフェーズがありますが、WebClass がサポートを続けるのは Maintenance Support 2 までです。この後のEnd of Extended Life-cycle Support フェーズは、RHELのサポートサイト上でドキュメント等は残っていますが、セキュリティ修正も提供されないフェーズです。RHEL6 はEnd of Maintenance Support 2 の期限が 2020/11/30 までとなっています。

WebClass についてはこれ以降は RHEL6 を考慮した実装やテストは行いません。また、実際の利用状況や、技術的な状況を加味して早めに切り上げることもあります。

Debian

Debian は2年の周期でメジャーバージョンが上がります。メジャーバージョンが1つ古くなってから1年は通常のサポートに含まれます。つまり、メジャーバージョンがリリースされてからだいたい3年のサポート期間があります。

その後は LTS (Long term support) が2年カバーします。

つまり、最長で5年程度のサポート期間があります。

現在カレントバージョンである Debian9 は 2022年6月末まで、1つ前の Debian 8 は 2020年6月末までとなります。

Debian は apt システムによりメジャーバージョンのアップグレードが可能です。入れ直しを必要としないので、あまりLTSをあてにしすぎずにアップデートしていくことを考えています。

いずれにせよ、WebClass は LTS の切れたバージョンはサポート外としています。

WebClass の対応

RHEL8 にはまだ対応していませんが、対応させていきます。ただし、現時点ではまだ具体的な予定日等は確定していません。

一方で、OS ベンダーの方でサポート切れになっている OS もまた、WebClass のサポートから外れていきます。

稼働しているシステムの更新・アップデートについて

WebClass もだんだんと大学の授業で広く使っていただけるようになり、サービスの停止時間を確保することが難しくなってきている学校もあります。

一方で、安心して利用し続けていただくためにも現在の技術動向に対応していったり、セキュリティアップデート等のメンテナンスは必要になります。

やりくりの難しいところもあるとは思いますが、システム管理者や利用者の方々と協力して、維持していけたらと思います。

古いコードとの闘い

こんにちは。福岡です。

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

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

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