他にはない、Mimir Yokohamaの開発とは (動画あり)

• トップページ
• ミーミルヨコハマについて
• 他にはない、Mimir Yokohamaの開発とは (動画あり)

実は根本的に違う「手法と内容」

「開発」というのは、プログラムを作ったり、ウェブサイトを作ったりすること…なのですが、実はその内容には結構な違いがあります。

ウェブ開発を考えてみましょう。

現在主流なのはWordPressとRuby on Railsです。 並べましたが、これらは全く異なる概念です。

WordPressは最も人気のあるブログソフトウェアです。 WordPressが動作する環境をつくるところまではまた層の異なる作業ですので置いておくとして、多くのウェブページ公開環境ではWordPressが動作するようになっています。 あるいは、多くのウェブページはWordPressを動作させ、WordPressによって記事を公開しています。

これはブログに限りません。 ブログの形式を取らないページでも大部分はWordPressによって書かれています。

ウェブ開発ではもうひとつ有力な選択肢があります。 それがRuby on Railsです。

Ruby on Railsではプログラミング言語Rubyに大幅に機能を追加し、 ほとんど「設定を書く」という感覚でアプリケーションを作ることができます。

Ruby on Railsを使わない場合でも、各言語に応じたRuby on Railsのようなソフトウェアを利用するのが常識となっています。

ところがMimir Yokohamaの開発はこのようなソフトウェアを使わないのが基本です。

Mimir YokohamaのウェブサイトはPureBuilder Simply(PBS)というソフトウェアによって作られています。 このソフトウェアはWordPressよりもずっとページの作成・更新が楽になる、というのが大きなメリットですが、 PureBuilder Simply自体がMimir Yokohama代表が個人的に作っているソフトウェアなので開発にかかる労力は非常に大きいと言えます¹。

それでも、「目的を実現するために」あるいは「無駄な労力と時間を払わないために」必要だと考えるからこそ独自のソフトウェア開発・運用を行っています。

同様の理由から、ページ内のJavaScriptでも今では当たり前になっているJQuery²を使用せず、JQuery以外の同様のライブラリも一切使用しないPureJSになっています。

「最小の開発で最大の効果を得る」はMimir Yokohamaの基本的な考え方です。

決して楽ではない道のり

IT業界では可能な限り機械的に構築することを是とするのが常識となっています。 これは人員に代えが効きやすいようにということであり、エンジニアに技術力を問わず、画一的な方法で達成できるようにしている、ということです。

それに抗うということは様々な困難を抱えることになります。 なによりも、「技術力なくしてはできないことになる」ということでもあります。

決まりきった手法に関しては情報はたくさんあります。 これは、単に情報の多寡の問題には留まりません。 例えば検索すればRuby on Railsの情報はいくらでも出てくるものの、Ruby on Railsで使われている(もしくは使うことのできる)テクノロジーをRuby on Railsなしで使う情報は少ないだけでなく、検索したところでRuby on Railsの情報ばかりが並び、情報があったとしても完全に埋もれてしまいます。

PureJSについてもそうですが、「前例はない、情報はない、自分で開拓するしかない」という状況から始まります。

楽をする、ということで言えば既製品を使うほうがずっと楽です。 そして、ビジネス的に見れば儲けとしてもはるかに効率が良いのです。

しかしながら、私達はそれでは成長はない、と考えます。 そして、そのような考えに立っていてはお客様が本当に必要としているもの、本当に望んでいることを蔑ろにしてしまう、とも考えています。

楽をすることを望むのではなく、常により高い技術力を目指し、そして得たものを人々の幸せのために行使する。 それが私達の選択です。

わざわざそうする理由とは

PureBuilder Simply編

WordPressは遅い

ページ表示面でも遅いのですが、管理画面がとにかく遅いというのが致命的です。 実際にどれくらいかかっているのか見てみましょう。

まず、見方から。

青字のDOMContentLoadedはここに到達したとき表示を始められます。 つまり、この時間は前のページが表示されたままか、もしくはまっしろな画面のままです。

Loadはコンテンツのダウンロードにかかった時間です。 基本的に表示はごく短時間で行えるものが多く、Loadが完了したときにはページは見られる状態になっていると考えることができます。 この値が基準になります。

Finishは表示まで完了するのにかかった時間です。 コンテンツによってはLoadではなくFinishにならないとページが読めないものもあります。

874msですので、0.87秒です。

一瞬に感じるかもしれせんが、実際はコンピュータの部品操作(クリックなど)においては50msもかかればかなり遅いほうでひっかかりを感じますし、100msを越えるようであれば遅いコンピュータだということでイライラすることになります。 約900msというのはとてつもなく遅いです。

一番時間かかるのがここで、ログインしたあと管理ページが表示されるまでです。

なんと30秒近くかかっており、そもそも最初の19秒(Waiting (TTFB) と書かれている部分)はただひたすら応答待ちでダウンロードもしていません。 ここに時間がかかっているのは「WordPressが遅いから」で、そのあと8秒以上かかっているのは「WordPressがゴテゴテと重いページを返すから」です。

30秒って途方もなく長いです。 明らかに人生を無駄にしているレベルです。 30秒もかかるようでは、ログインを開始してからログインされるまでに他のことをはじめる人も多いのではないでしょうか。

さらにここには罠があります。私はSlimstat Analysticsを入れているのですが、このウィジェットのせいでFinishまでは倍の60秒もかかっています。 しかしこのウィジェットは完了しなければメニュー操作ができません。なので、結局60秒待つことになります。 もちろん、Slimstatを入れなければ30秒程度で済みます。

これは管理ページに入ってからですが、だいたい管理ページからの変遷は2秒程度です。 ものすごく遅いですね。 投稿やメニューの更新など送信を含むものに関しては8から30秒ほどかかりますし、カスタマイズページのエントリーはやっぱり30秒はかかります。

PureBuilderを使用する場合、投稿や画像の追加などは単なるローカル環境での「ファイルの保存」にすぎないため、こうしたラグは存在しません。 投稿反映時はプログラムを実行する必要がありますが、この実行によって反映が完了するためユーザーは何らかの操作のために待つ必要はありません。

WordPressは重い

管理画面では3.8MBほど。

まさに通信容量を食いつぶすといっていいでしょう。 ネットサーフィンくらい軽いものだと思っているかもしれませんが、普通にページを見ていたら月に数GBは必要でしょう。

これはユーザービリティを損ないます。

Mimir Yokohamaのページは最初期はWordPressで運用されていました。 PureBuilderに移行したときの容量及び速度変遷としては

となっています。

WordPressではトップページが極端に重く、遅くなっていますが、 これは「一度呼んだページは期限内でかつ更新されていなければダウンロードはしない」という仕組みがあるためです。 この機構が働かないケースでは2ページ目移行もトップページと同等以上となります。

さて、「トップページ」と「サービス」の2ページには画像があります。 また、「マルチサポートサービス」のページには多くの文章が書かれています。 一方、「ミーミルってなに」のページは短文にとどまります。

容量的にはさすがに画像を含むトップページ, サービスページはPBSでもWordPressの「ミーミルってなに」のページよりは大きくなっています。 もちろん、これはキャッシュによって削減された量ではあります。

しかし、WordPressの「ミーミルってなに」のページは22.2kBですが404msであり、PBSでは72.1kBあるトップページでも281msとより高速です。

もちろん同一ページの比較ではPBSが明らかに軽くなっています。 WordPressはいずれも潜在的にはトップページ並に重いことを考えれば、著しい差であるといえます。

なお、Mimir Yokohamaのページはなるべく容量を削減する考えに基づいているため、WordPressでは710kBほどですが、一般的にはWordPressのページは2MB前後、重いものでは6MB程度あります。

これは後述のアクセシビリティ問題にも関係あります。 容量を使い切ったスマートフォンなどの低速環境では、大きなデータはダウンロードしきれず、タイムアウトしてしまうため結局見ることができません。

そのようなことがないようにMimir Yokohamaのページは軽量に作られています。

実際にWordPressからPureBuilder Simplyを使った現在のサイトに移行したときに計測した動画をこちらで紹介しています。

アクセシビリティ問題

「誰でも分け隔てなく利用できる」、それがアクセシビリティです。

WordPressは現代的で複雑な構造と、JavaScriptを使用した高度なページを持っています。

結果的に、最新の環境でなければ表示自体できないようなページができあがります。 これはテーマによって差がありますが、どのテーマを選んでも基本的に最新ではない環境では表示できません。

私達は、訪れてくれた方がけんもほろろに追い返されるようなことがあってはならないと考えています。 私達の基本的な考え方は

• 古い環境
• 限定的な環境 (例えば機能の低いウェブブラウザなど)
• 特殊なブラウザ (点字、音声、コンソールベースなど)
• 低速な回線
• 不安定な回線
• 低機能なディスプレイ (色数、ドット数など)
• 小さなディスプレイ
• 色盲

といった条件に対応することです。

現在、ユニバーサルデザインとは特定のデザイントレンドを指す言葉として使用されていますが、 私達の目標は利用者を制限しない真のユニバーサルデザインです。 (ただし、言語的部分は本質的に対応が困難であるため、除いています)

これはWordPressとは対極的ですし、現在は(HTML5と称して)最新ブラウザの機能を前提とすることが圧倒的に多いため、 このようなユニバーサルデザインを実現するには全てイチから作らなくてはいけません。

これはWordPressで構築するよりも多くの労力を必要としますが、その価値はあります。

実際に現在は多くのウェブサイトを見ることのできない限定的環境でみてみましょう。

w3mとElinksはコマンド入力などを行う端末上で動作するウェブブラウザです。

端末は基本的に行単位で文字を表示することしかできません。 とくにElinksはレイアウトに対する機能などが限定的です。

しかし、Mimir Yokohamaのページは問題なく読むことができています。

Dilloは非常に軽量ですが、機能は極めて限定的なウェブブラウザです。

機能的にはおおよそ20世紀のブラウザであるNetscape Navigator 4.8程度と言えるでしょう。

Dilloの機能的制限として透過色を含むPNGが背景色ではなくDilloの無色に透過されてしまう、代替されているために無視して良いはずのobjectタグを表示してしまう、サイドバーを横に表示できず下に表示される、といった違いがあるものの、閲覧には全く支障がありません。

取り回しの問題

WordPressの場合、一度WordPressで作ったサイトをプレーンな状態に復元する、というのは極めて困難です。

画像も、一応画像フォルダには収まるのですが、結構複雑な取り扱いをしており、MySQL/MariaDBのデータベースレコードとセットになっていたりして取り扱いは大変です。私なら、正直WordPressで直接的に書いていたサイトを別のプラットフォームで扱えるようにするというのは考えたくもない部類になります(実際、かなりお仕事でもやってたいますけどね)。

PureBuilder Simplyはわかりやすく簡単な手順、汎用性のあるフォーマット、変換に適した状態による高可用性・高可搬性を実現することもまたひとつの目的です。

また、この更新時に不安を抱えられる方も多いので、サービスとして展開した場合に、不安なく更新作業ができるように、という意図もあります。

こちらも動画で更新の様子を公開しています。 非常に簡単で、パソコンが得意でない方でも不安なく更新できるものであることがわかるでしょう。

なお、動画にちらつき、およびキーボードの反響音があります。ご注意ください。

PureJS編

JQueryは本当に強力なライブラリです。

実はMimir Yokohamaでも「JQueryは絶対に使わない!!」というわけではありません。 そこそこ複雑になってくるとJQueryを使うことは普通にあります。

それでもJQueryを使わない理由は、主には容量です。

JQuery 3.3.1の容量は271751バイト。266kBというサイズは大きい画像並であり、軽量性を大幅に削いでしまいます。

ただし、これはあまり重要な理由ではありません。 特にCDN経由で使用する場合、ダウンロードは非常に高速で、かつあらゆるサイトで使用されているためにCDNにあるJQueryはキャッシュされている可能性が高いためにユーザーはあまりダウンロードしないのです。

また、速度面の理由もあります。 Mimir Yokohamaで書くスクリプトは現代のブラウザが極めて高速に動作させられるように調整されています。 ただし、これも現実的な意味はありません。JQueryでもそれを知覚できるほど遅くないからです。 むしろJQueryはコンパイルに少し時間がかかるため、非常に非力なコンピュータでは³ロードしてからもしばらく機能しない、という問題のほうが重要です。

JQueryを使用するデメリットはあまりありません。 だからこそ必要だと考えれば使用しています。

ではなぜMimir Yokohamaのページでは使用していないのか。 理由は「少しでも軽くするため」です。

現在、Mimir Yokohamaで使われている辞書機能は1330バイト、ライトボックス機能は1742バイトとJQueryと比べ非常に小さいです⁴。 また、この小さいスクリプトすら常にロードしているわけではなく、必要なページでのみロードされます。 ロードする容量が少なくて小さく済む上に、ロードした以上はコンパイルするためにコンピュータが使われますが、JQuery全体をコンパイルするような負担を避けているわけです。これにより非力なスマートフォンなどでも負担にならないようにしています。

「不必要なものを載せない」はMimir Yokohamaの基本的な方針です。 ときには不必要なものを取り除くためにより多くの労力が必要になる場合もあります。 しかし、不必要なものがより多くのデメリットをもたらすのであれば困難を伴ったとしてもやるのがMimir Yokohama流です。 同時に、あまりに困難を伴い無用なコストを発生するよりは上手にバランスを取るのもまた、Mimir Yokohama流です。

ツール編

ユーティリティ・ツールは目的を補助する小さなプログラムです。

普通はプログラムを書くよりも手作業でやったほうが速いのですが、これが繰り返される場合繰り返されるほどに時間の短縮になっていきます。 また、場合によっては1回目から時間の短縮になります。

ハッカーであれば息をするように日常的な行為ですが、エンジニアやプログラマの場合、作る人と作らない人がいます。 また、ITでの業務では明らかに作ったほうが効率化になる場合でも制作・使用が許可されない場合も多々あるそうです。⁵

ほとんどの場合、内部の人が気を利かせて行うものですが、このようなツールの開発もMimir Yokohamaは行っています。

もちろん、この場合にはなにをどうすべきか分かっている内部の人が開発する場合と比べれば、調査も必要ですし、書類も発行しなければなりませんし、それなりに費用もかかります⁶。

しかしMimir Yokohamaでやるからにはもちろんより優れたものを開発します。

優れたツールを作るために必要なのはなんでしょうか? それは、

1. 問題を定義し
2. 解決方法を定める

の2ステップです。

問題をどのように定義するかは重要です。このステップが間違っていると非効率的な、あるいは硬直したツールが出来上がります。 そして、問題が定まっていても、よくない解決方法であれば余計な労力、困難な保守、硬直した仕様が待ち受けます。

いかに問題を定義するか、それはMimir Yokohamaにとって最大の見せ所です。 PureBuilderもまた、「いかにしてページを生成するかという問題である」(決してユーザーのリクエストをいかに受け付けるかを問われているわけではない)という定義から誕生しました。

お問い合わせフォームも、一般的にはお問い合わせフォームアプリケーションはお問い合わせフォームを含むページを生成します。 しかしながら、お問い合わせフォームを表示するとき、ユーザーは何も情報を入力していません(これから入力するのですから!)。ですから、お問い合わせフォームはただのページで良いのです。

また、送信後に表示されるページも普通はフォームアプリケーションが生成します。 しかし、考えられる結果は「成功」or「失敗」のどちらかです(失敗はバリエーションがありえますが、それは有限です)。 であれば、これもただのページで良いはずです。

このことから、Mimir Yokohamaのフォームアプリケーションはメッセージを受け取り、送信し、次に見るべきページを示す、ということだけを行います。 成功した場合に送信した内容を再表示するのは無意味です。それは、「確かに送信できた」という安心感にはなるかもしれませんが、送信に失敗したからといって送信内容を表示できないわけではありません。 そんなことをするくらいならば、送信内容を入力されたメールアドレスに確認メールとして送信したほうがよっぽど有意義です⁷。

このような問題の定義能力はツールにおいては極めて大きな意味を持ちます。 素朴な方法⁸で実装した場合に200行を越えるようなコードになる内容が、問題をうまく定義することにより一行で書ける⁹場合も多々あります。

可能な限りシンプルに解決するのはいくつものメリットがあります。 もちろん、費用や納期においても有利ですが、なるべくシンプルにすることで保守や管理もしやすくなり、あとあとの苦労も減ります。 また、シンプルなもののほうがバグが少ないという¹⁰点もメリットでしょう。入り込む余地が減りますから。