これはMovable Type Advent Calendar 2018の、15日目の記事です。

Movable Type Advent Calendar 2018 - Adventar

Movable Type 7がリリースされてから、MTDDC HOKKAIDOやCMS Mixやパワーユーザーのブログを通して、一年間今後の事を考えてきました。その結論として、今後の業務での主力はMT7ではなく、ASP版のMovable Type.netにしようと思います。

https://movabletype.net/

誤解のないよう早めに論旨を書きます。消極的な意味で言ってるのではないです。

• .netの運用に特化した機能追加がすごいっていうかやばい
• パッケージ版と私とa-blog cmsの関係の変化
• 私とWordPressの関係の変化
• 原点への回帰

という理由です。

.netの運用に特化した機能追加がすごいっていうかやばい

MovableType.netはリリースから三年以上が経ちました。リリース当初はあくまでMovable Type6の軽量版に過ぎなかったのですが、現在ではMovable Type 6の主要機能をすべて引き継いでいるだけでなく、常に活発な機能追加・改良が行われています。

特に、パッケージ版のMTでは難しかった、外部連携と運用に関する機能には驚きます。「Movable Type.net活用ブログ」を見ていただくといいですが、特に「えええ？レンタルでそこまでできるの！？」と思ったのは以下です。

• CSVインポート・エクスポート機能を利用してウェブサイトの骨組みを作る - MovableType.net 活用ブログ
• IFTTT Webhooks 機能を使って記事の公開時に指定したSlackのチャンネルに通知する - MovableType.net 活用ブログ
• ワークフローの活用例　企業編（アカウントを持たない部長も参加） - MovableType.net 活用ブログ
• 終了日や件数でフォームの受付制限をする方法 - MovableType.net 活用ブログ
• 共有プレビューを使いこなして効率的で安全な運営を！ - MovableType.net 活用ブログ
• Google Home Mini だけでワークフロー機能の承認を行うプロトタイプを作ってみた - MovableType.net 活用ブログ
• ジャパリンガル連携を行うことで、作成済みの記事、もしくはウェブページのタイトルを選ぶだけで翻訳依頼を行えます

IFTTT向けのWebhookに対応しているのは大きいです。Slackに限らずなんにでも投げられそうです。.netではページを公開せず、何かのハブに使うという新しい運用もできるかもしれません。

パッケージ版と私とa-blog cmsの関係の変化

パッケージ版に関して、昨年はMT7を前にして駆け込み的案件が多かったのですが、今年は少なくなっています。おそらく各企業が様子を見ていて、安定した来年から増加するのだろうと予測しています。ただ、札幌市はMTを専門としている会社が多いので、専門ではない私のところにどのくらい相談が来るのかは不透明です。

そんな中、秋のa-blog cms Training Campで、a-blog cmsにコンテンツタイプ機能が実装されるという話が出ました。厳密には既存のブログのコンフィグをパッケージ化して、複数のブログで使い回せるようになるのですが、原理としては他のCMSとあまり変わりません。

a-blog cmsもリリースから10年が経ちます。機能追加や大型化が進んだことで、だんだんMovable Typeパッケージ版との立ち位置のかぶりが多くなってきました。

また、私の中で軽量CMSにどれを使うかというのが決まっていませんでした。Jimdoはブログに難がありますし、BaserCMSやCraftも悪くないのですが、私に来る案件（かっちり系のコーポレートサイトが大半）にいまいち合致しません。軽量なままで機能が増えて、かつこれまでのリソースを活かせる.netを推さない手はないと考えています。

もちろん、MT7も引き続き勉強するので、案件のお手伝いやバージョンアップは十分できると思います。

私とWordPressの関係の変化

推さない手はない、と書いたものの、私がCMSの種類を提案できる案件はとても限られています（以前より増えましたが）。相変わらず、WordPressになるケースが多いです。主に以下の理由です。

• 初期予算がない（というか抑えなければならない）
• クライアントがずっとWordPressを使ってきたので乗り換えたくない
• WordPressからの移行コスト（CMSを乗り換えると一年分の保守コストを上回ってしまう）

一方で、「補助金制度」というものがあることも知りました。それを活用するようなサイトであれば、初期予算がない問題はクリアできます。そしてWordPress5.0のGutenbergです。私は気に入っていますが、ざっとツイートを調べた限りでは一般ユーザーの混乱は大きく、これまでのセキュリティの問題もあって、以前より乗り換えの意識は強くなっています。

こうなると、あとは私の説得力になってきます。

原点への回帰

まあとにかく、正式なアカウントを取って公開サイトを運用して、インプット・アウトプットしないとと考えています。a-blog cmsでもそうしてきました。

個人的な理由になりますが、MovableType.netを見ていると、MTを使い始めた頃を思い出します。
15年前、当時はやっていたウェブ日記が不満で、手探りでMTをインストールしました。あの頃は自分が書いたコードや記事がHTMLで書き出されるのが本当に楽しくて、毎晩「これでどんなサイトが作れるだろう」と試行錯誤していたものです。

MovableType.netは、あの頃の私が望んでいた「MT3.0が成長した姿」かもしれないです。

.net案件は、既に何度か経験済みですので、いつでもサイトを構築できます。また、MT7に関しても良い会社をいろいろ知っていますので紹介可能です。お気軽にウェビングスタジオまでご相談ください。

これは、a-blog cms Advent Calendar 2018の12日目の記事です。
a-blog cms Advent Calendar 2018 - Adventar

今回は、かなり制作者向けの記事です。a-blog cmsを利用していても、運用やディレクションが中心の方には、少し難しい内容であることを前置きしておきます。ですが、テーマの制作をしている方は、ぜひ読んでいただけるとうれしいです。

• はじめに
• includeの変数渡し
  • 概要
  • 構造図
  • includeの特徴
• extendによるコードの継承
  • 概要
  • 構造図
  • extendの特徴
• いえズームでの活用
  • includeの変数渡し
  • extendによるコードの継承
• まとめ、使ってみての雑感

はじめに

北海道住宅新聞社さんの情報サイト「いえズーム」の管理をはじめてから、一年半くらい経ちます。

【iezoom】（いえズーム）北海道の住宅会社選び | いえズーム（iezoom）

いえズームの制作をはじめた頃は、「includeの変数渡し」「extendによるコードの継承」はリリースされていませんでした（バージョン2.8.0から）。 旧来のインクルードを使用したまま改修を重ねていたら、テーマがカオス化してきたこともあり、新しい機能を使用してコード整理をしています。

新しい機能のそれぞれの特徴と、いえズームでの実際の利用場面を紹介します。

includeの変数渡し

概要

旧来のインクルードは、SSI風の書式で、読み込むファイル名を指示するのみのシンプルなものでした。

<!--#include file="/path/to/filename"-->

しかし、2.8以降では、JSON風の書式で、読み込み先で使用できる独自変数を渡せるようになっています。

@include("/path/to/filename", {"key": "value", "key2": "value2"})

詳細な仕様解説は公式ドキュメントを参照ください。
インクルード | テンプレート | ドキュメント | a-blog cms developer

構造図

図で解説すると以下の通りです。 「sample_01.html」と「sample_02.html」は同じパーツ、module.htmlを読み込んでいますが、変数「button」の値が異なるため、実際に表示されるコードが一部変わります。 「sample_01.html」では、新着記事一覧の下に「詳しくはこちら」ボタンが表示されるはずです。

includeの特徴

includeの変数はグローバル変数ではないので、読み込み先以外に干渉することはありません。いくつでも渡すことができ、変数の初期値も定義できますが、長いコードを渡すことはできません（できたとしても可読性が著しく落ちます）。

extendによるコードの継承

概要

いっぽうextendですが、WordPressやa-blog cmsに実装されている「親・子テーマ」の「コードの使い回し」を、テンプレート間で実行することができます。

テンプレート冒頭で「@extend」を書くと、指定したファイルを丸ごと読み込むことができます。ここまではincludeと変わりませんが…

@extend(/path/to/filename)

指定した読み込み元のファイルに「@section(任意の英数字名) 」〜「@endsection 」で囲んだ領域があると、読み込み先のファイルでコードを上書きすることができます。

@section(sample)
  <h2>内容を書き換えちゃうよ！</h2>
@endsection

つまり、読み込み先では、差分コードだけ記述すれば良いのです。

詳細な仕様解説は公式ドキュメントを参照ください。
テンプレートの継承 | テンプレート | ドキュメント | a-blog cms developer

構造図

図で解説すると以下の通りです。
レイアウト用に作成した非公開テンプレート「_layout.html」のコードを３つの公開テンプレートで使い回していますが、それぞれ実際の表示結果が変わります。特にsample_03.htmlの「継承しつつ追記」はいろいろ便利です。

extendの特徴

extendは、前もってレイアウト用のテンプレートを作り、どの箇所を継承可能にするか定義することになります。

長いコードをテンプレート間で渡すことができるので、似ているけれど微妙に違うレイアウトが多いサイトでは、書くべきテンプレートの行数を大幅に節約できます。反面、includeとは異なり、条件分岐などに使える変数を渡すことはできません。

いえズームでの活用

includeの変数渡し

いえズームは一見シンプルなサイトですが、訪問者の導線を意識しているため、コンテンツごとに記事の表示件数や体裁、ページ内での表示位置などが細かく違っています。改修を重ねているうちに、モジュール部分のテンプレート数が肥大してしまっていました。

例えば「summary_sub_story_future」モジュールと「summary_sub_story_recent」モジュールは、IDが違うだけでコードがまったく同じなのに別ファイルになっています。

<!-- BEGIN_MODULE Entry_Summary id="summary_sub_story_future" -->
・・・
<!-- END_MODULE Entry_Summary -->

<!-- BEGIN_MODULE Entry_Summary id="summary_sub_story_recent" -->
・・・
<!-- END_MODULE Entry_Summary -->

これを、includeの変数渡しに書き換えることで、ひとつのファイルでidだけ違うコードを出力することができました。

さらに、なんと、読み込み先のincludeのファイル名に変数を引き継ぐことができることに気付いてしまいました。エントリーの繰り返し部分の体裁だけが違うテンプレートも共通化できそうです。

@include("/include/module/summary_sub.html", {"mid": "summary_sub_story_recent", "loop": "story_media.html"})

<!-- BEGIN_MODULE Entry_Summary id="{{mid}}" -->
・・・
@include("/include/module_loop/{{loop}}")
・・・
<!-- END_MODULE Entry_Summary -->

extendによるコードの継承

いえズームは、すべてのページのフッタ上部に、「いえズームとは？」というサイトの概要が記載されています。

ですが、一箇所だけ例外があります。地域別企業一覧のページでは、ヘッダの地域紹介の直下にあるのです。

札幌圏の住宅会社（ハウスメーカー・工務店）一覧 | いえズーム（iezoom）

地域ページは、冒頭に地域情報のパーツがあったり、地域名を変数に入れていたりと、かなりレイアウトが異なっています。以前は地域ページだけまったく違うテンプレートを用意していたのですが、extendを使うことで、他のテンプレートが利用している「/_layout_col2.html」との共通化ができるようになりました。

@extends("/_layout_col2.html")

@section(head_before)
（地域名を変数に取得）
@endsection

@section(pagehead)
（地域情報とサイト紹介パーツ）
@endsection

以下略

まとめ、使ってみての雑感

このように、わかりやすいところから少しずつコードの整理をしています。

使ってみての感想は、やはりテーマ職人としては、extendが手応えがある分面白いなあと感じています。大幅にテンプレートの数を減らせそうです。ただし、テーマ全体の構成を把握していないと実装できませんから、コーダーとテーマ制作者が違う案件では苦戦するかもしれません。

includeの変数渡しは便利な反面、インクルード先のテンプレートで、その変数がどこから定義されたものなのかわかりにくいという欠点があります（変数名でテンプレートを検索すればいいのですが）。 同じような変数名を使いすぎてカオス化しないよう、ルール決めが必要です。

いえズームは現在も、数週間に一度のペースでコンテンツの改修や追加が続いています。 このため、私も手早く対応できるようにしなければなりません。テンプレートを整理することで余裕が出て、より良い制作や提案ができればと期待しています。

WordPress5.0がリリースされ、噂のブロックエディタ「Gutenberg」が正式実装されました。

現在私は、同じ構成で構築された、いくつかのWordPressサイトの運用のお仕事をしています。 そのサイトがGutenbergの導入でどのような影響を受けるかの検証と、それだけではなく、今後CMSを扱う立場としてGutenbergとどのように関わっていくかを、この週末に、ざっくりですが検討していました。

Gutenbergさんとどう付き合うか

まず、投稿タイプなどを追加していない、WordPress5.0の基本の状態でGutenbergをひととおり試しました。

私は、10年前からブロックエディタを搭載していたことで知られる、a-blog cmsを長年使用しています。また、スマートなブロックエディタを実装しているブログサービス「g.o.a.t」を一年ほど利用していました。

その経験を含めての感想としては、
「思ったより怖くない」
「これは『ビジュアルエディタの次世代としては』かなり良いのではないか」
です。

基本的に、ブログ記事などでは、HTMLの要素は見出し・本文・リンク・強調・各種サービスの埋め込みくらいしか使いません。それらについては軽快に書けますし、以前のビジュアルエディタとの操作の差も意外と少ないです。 驚いたのが「既存のビジュアルエディタ」がブロックのひとつとして用意されていることです。重くなりそうですが、どうしてもあのエディタでないと、というクライアントへの説得要素にもなるでしょう。

ウェビングスタジオとしては、新規案件の緩いコンテンツなど、利用しやすいところでは積極的に受け入れていきたいし、カスタマイズを学習していきたいと考えています。

長年WordPressを使い込んで、多数のプラグインやPHP拡張を活用してきた人ほど、Gutenbergは厄介な存在でしょう。 WordPressはオープンで自由なCMSです。一切使わない選択肢も用意されていますから、個々の制作者の自由でいいと思います。

使いたくない場合

一方、コンテンツ・マネージメント・システムとしてWordPressを使う場合、「投稿タイプによって適しているエディタが異なる」という問題が生じます。

例えば私の件の運用サイトの場合は、以下の３つの投稿タイプを持っています。

• post・・・ブログ記事
• page・・・がっつりマークアップした渾身のメインコンテンツ
• works・・・カスタムフィールド職人らしいフィールドのみのコンテンツ

worksでは、「Advanced Custom Fields Pro」のリピートフィールドで、こんな感じの簡易なブロックエディタを作成しています。簡易な方が操作しやすく、更新の効率が良くなるということは往々にしてあります。

この場合、pageとworksでGutenbergを使うことはできません。

このように、第一に制作者が考えなければならないのは、現在運用しているサイトの各投稿タイプで、Gutenbergにしても問題ない箇所と、使ってはいけない箇所を明確にしておくことです。

では、特定の投稿タイプだけ無効にすることはできるのでしょうか。管理画面にもそういった項目は見当たりません。困っていたら、WordPressをはじめとするいろいろなCMSに詳しい安部さんがTwitterで教えてくれました。

これは違います？https://t.co/jZR2e7bLT6

— 海老庵? (@evian) 2018年12月8日

これです。ドンピシャです。 高橋文樹さんが、Gutenbergがベータ版の頃から各種回避策を書いてくださっていたようです。

Before Gutenberg アーカイブ - Capital P

pageとworksでブロックエディタを無効にすることで、これまでのWordPressと変わりない環境にすることができました。

function WS_remove_block_editor( $user_block_editor, $post ) {
    if (
        ( $post->post_type === 'page' )
        ||( $post->post_type === 'works' )
    ) {
        $use_block_editor = false;
    } else {
        $use_block_editor = true;
    }
    return $use_block_editor;
}
add_filter( 'use_block_editor_for_post', 'WS_remove_block_editor', 10, 2 );

プラグインとの衝突問題

次に考えなければならないのは、プラグインです。

一通りコンテンツを確認したところで、カスタムフィールドを管理している「Advanced Custom Fields PRO」の編集画面に入ったら、ページが真っ白になりました。 フォームプラグイン「MW WP Form」も編集画面だけ真っ白になっています。

プラグインは問題がないと思っていただけに慌てましたが、これについても高橋文樹さんがすでに原因を書いていました。 “エディターのない投稿タイプは動かない” そうです。

Before Gutenberg - カスタムフィールド職人の命運やいかに？ - Capital P

つまりプラグインの投稿タイプでも無効にしなければならないわけで、最終的に以下のようなコードになりました。

function WS_remove_block_editor( $user_block_editor, $post ) {
    if (
        ( $post->post_type === 'acf-field-group' )
        ||( $post->post_type === 'mw-wp-form' )
        ||( $post->post_type === 'page' )
        ||( $post->post_type === 'works' )
    ) {
        $use_block_editor = false;
    } else {
        $use_block_editor = true;
    }
    return $use_block_editor;
}
add_filter( 'use_block_editor_for_post', 'WS_remove_block_editor', 10, 2 );

あまりスマートじゃなくなってきました…postだけ許可する、ホワイトリスト方式にした方がいいのかも。

この不具合については、頻繁に更新されているプラグインであれば早い段階で解決されると期待していますが、しばらく混乱は続くのでしょう。 これを機に、プラグイン制作者に問い合わせる前に、まず検索する習慣を身に付けたいものです。

既出かもしれませんがQiitaに寄稿しました。

WordPress5.0でプラグインの新規追加画面・編集画面が真っ白になった場合の対処 - Qiita

発展途上？なUI

ざっと使ってまず気になったのが、「ブロックを追加・挿入するボタン」の表示がわかりにくいことです。

最後に追加するならEnterキーを押せばボタンが出るのですが、挿入の場合は、前のブロックにマウスを置くと出る枠線の「上の線」にカーソルを置かないとボタンが出てこないのです。これがかなりシビアな操作になっています。 それ以前に、感覚的には一般に「下に追加する」と感じるので、一つ前のブロックの下線にボタンが出るべきじゃないですかね…

ボタンブロックについても、色の選択があるのですが、よりにもよって背景色だけでなく文字色まで自由に選択できるUIになっています。

サイトを明るくしようとした更新担当者さんが、ボタンの色をピンクとかライムにする未来が見えます。

これがインラインスタイルで入るのか、クラスで入るのかまだ確認できていないですが、とにかく色は個別に選ばせたくないですし、外観についても丸と四角、塗りつぶしとボーダーはそれぞれどのような役割で使うのか決めておかないと、わけのわからないことになります。

また、WCAN 2018/10でたにぐちさんも指摘されていましたが、パーマリンク設定の場所もわかりにくいです。WCANに参加していなければ見つけられませんでした。更新担当者にパーマリンクをいじらせてはいけない、という禁止系インターフェース…と考えられなくもないですが。

たにぐちさんがさらに指摘されていた「なぜかテキストブロックの文字の寄せ方向だけ、クラスではなくインラインスタイルになっている」件は、私はあまり気にしていません。文字色などとは異なり、文字の寄せ方向はテーマやCSSが変わっても、同じであることが多いからです。しかし、UIのブレであることは確かですし、インラインスタイルは優先度が高いので、上書きしようとするとimportantまみれになる問題があるのですが…

少なくともこれまでと相当感覚が違うので、リモートで運用をしている場合は、更新担当者にどのように操作説明をするか考える必要があります。 a-blog cmsユーザーの多くがやっていたことですが、往訪できない場合はブロック一種類ずつに対して、操作している動画を撮って見ていただくのが確実と思います。

特定のブロックを使わない自由はあるのか

ボタンのところでも触れましたが、Gutenbergの「機能が多すぎる」ことも私の中で課題になっています。 多数のブロックがありますが、すべて対応していられないとか、コンテンツの性格上、使ってほしくないケースもあります。

私がa-blog cmsを気に入っているのは、コンテンツ（ブログ）ごとに、使用できるブロック（ユニット）を管理者が指定できることです。 もう少し情報を調べれば既に出ているのかもしれませんが、特定のブロックを使わない自由を公式に設けてほしいものです。

Gutenbergさんは悪くない、悪くないんだ

繰り返しますが、私はGutenbergが気に入っていて積極的に使いたいです。

ただ、日頃「すべての人が自由に気軽に使えるCMS」を謳っていながら、「ユーザーが、GUIを通して機能を選択（無効ではない。選択）できない状態でリリースした」強引さに若干呆れています。

今後各国のWordPressコミュニティは、一定のウェブ制作の知識を持たない人（いわゆる個人ブロガーなど）へのサポートを切り捨てるか、これまでのようにGUIで管理できるプラグインの開発やブログ記事などの情報を充実させるかの、大きな選択を迫られるのでしょう。

個人へのサポートを既にやめている私としては、前者が幸せじゃね…？と思ってしまいつつ、制作会社・企画会社との協業媒体としてのWordPressに、Gutenbergをどう活用していけるか、前向きに考えていきたいと思います。

先日のa-blog cms Training Campがはじまる前、北九州のデザイナーの、小佐々さんと話しました。
小佐々さんはXDのパワーユーザーで、来週のSaCSS Specialに登壇する田村さんと組んで、XDテンプレートとCSSフレームワークのパッケージを配布しています。
プロトタイプやカラーテーブルの使い方などが勉強になりますので、ぜひゲットしてください。

GitHub - tamshow/jwps: The Japan Web Production Standards is a production system for building fast

で、本題です。話の流れで、小佐々さんから「Bear」というメモアプリを薦められました。
Campの間、お試しで使っていたのですが、たった二日間ですっかり気に入ってProに課金してしまいました。

Bear - Notes for iPhone, iPad and Mac

Bearは、特にコーダー・ブロガーにお勧めしたいアプリです。特に気に入ったところを挙げてみます。

• 目に優しい
• ドキュメントが書きやすい
• マークダウン・HTML相互変換ができる
• 多彩なエクスポート
• マルチタグ
• できないこと

目に優しい

これが、私のBearの画面です。公式サイトの画面と違って黒くなっています。 BearはMacOS Mojaveからの新機能、ダークモードに連動していて、モードを切り替えると自動的にBearも暗色テーマに変わります。Proではさらにテーマが追加され、ブラウン系や色覚障害者向けなどもあります。

私は最近、目の負担を減らして集中力を上げる目的で、普段のアプリをできるだけ暗色に変更しています。Evernoteもすでにダークモードに対応していますが、Dropbox Paperはまだのようです。対応アプリがどんどん増えていってほしいですね。

ドキュメントが書きやすい

Bearは基本的に、マークダウン記法でノートを作成します。 と言っても見出しを作るときにいちいち#を書く必要はなく、ショートカットキーでサクサク見出しやリストを作っていけます。

私はメインのメモアプリはEvernoteでしたが、ここ一年はほとんど使用していませんでした。リッチテキストなので体裁が崩れやすく、レポートなどの長文を書く気になれなかったのです。Bearはそういう心配がなく、MacBookでもiPhoneでも思いついたときに書けます。

リンクについても、ブロガーに優しい仕様になっています。インターネットに接続している状態でURLをペーストすると、自動的にリンク先のtitle要素を反映したリンクを作成します。 Bear内の他のノートへリンクすることもできます。

なお、使いどころがわかりませんが、デスクトップ版は縦書きで表示・編集できます。本文を右クリックで「レイアウトの方向」メニューが出てきます。

マークダウン・HTML相互変換ができる

これは、Movable Typeの人気プラグイン「MTAppjQuery」の作者、奥脇さんのブログ記事です。MTAppjQueryの新機能について説明されていたので、Bearに控えました。
記事のHTMLをコピーしてからノートを右クリックし、Proで追加されるオプション「次からペースト＞HTML」で、貼り付けています。

MTAppjQuery v2.3.0 リリース - 深い入れ子の JSON データを効率よく扱う mt:Foreach、mt:NestVar タグを追加 | かたつむりくんのWWW

Bearでは、HTMLコードを貼り付けると、余分な要素や属性を除去して、Bearに適した体裁に変換してくれます。

もちろんその逆も可能で、選択した範囲を各種形式でクリップボードに入れることができます。

これが、コーディングやCMSのコンテンツ流し込みのときに活躍します。以下のように作業したところ、とても流し込みが捗りました。

1. 既存サイトの、新サイトへに引き継ぐ箇所のHTMLをBearにペースト
2. または、送られてきたDOCX形式ファイルをBearにインポート
3. 見出しレベル、文言などを再考
4. Sublime TextへふたたびHTMLでペースト

多彩なエクスポート

Bearに保存されたノートは、さまざまな形式で書き出せます。 無料版でも、プレーンテキスト・RTF・マークダウンが選択できますが、ProではPDF・HTML・DOCX・JPGがアンロックされます。

この機能はかなりうれしいです。先述のHTML変換と、これに課金していると言ってもいいくらいです。 JPG形式を選ぶと、ほんとうにすべてが一枚絵で書き出されてなんだか面白いです。一番考えられる使い道が、Twitterで長文を画像化してツイートすることでしょうか。

さらに、ノートを選択した状態でメニューバーの「ファイル＞メモをエクスポート」を選ぶと、EPUB形式でも書き出すことができます。これで作った電子書籍を販売してもいいのかはわかりませんが。

マルチタグ

Bearは、TwitterやInstagramのハッシュタグのようにタグを付けてノートを分類することができます。

それだけではなく、「cms/ablogcms」とスラッシュで区切ると、タグに階層を持たせることができます。 タグには識別アイコンをつけることができ、特定の名前のタグは自動でアイコンが付きます。WordPressだけアイコンがついて悔しいです。

なぜかアイコンにはポケ◯ンボールとか、◯ルダのトラ◯フ◯ースとか、ス◯ラト◯◯ンとか、◯ン◯ーダーらしきものが見えます…ジャパンのゲームだいすき！な開発者さんのようです。意味もなく使いたいです。

できないこと

高機能なBearですが、あくまで個人利用に特化したメモアプリです。
2018年11月時点では、他のユーザーとのノートの共有はできません。また、ノートにパスワードをかけたり、二段階認証を設定することもできません。サーバー情報などの保管には向いていないと考えた方がいいです。

アプリに関連づけられたアカウントを切り替えるのも難しいため、会社用は別のアカウントにしなければならない、といったケースにも適していません。

このあたりはやはり、引き続きEvernote、Dropbox Paper、Googleドライブの役割になるでしょう。

One more thing

そんなこんなで、このブログの原稿もBearで書いています。久しぶりに書くことが楽しくなっています。

もうひとつBearの良いところをあげるとしたら、

イメージキャラの、しろくまがかわいい。
かわいいは正義。
かわいいはモチベーション。

公式グッズショップがあるので、ぜひ、このしろくまのイラストのTシャツを販売してほしいです。

東京へ行くときにいつも利用しているビジネスホテルが、今回は予約できませんでした。いい機会なので、開業したばかりの超オシャレカプセルホテル「ナインアワーズ赤坂」にに連泊することにしました。開業直後の京都店に宿泊したことがあり、久しぶりでした。

結論から言うと、ナインアワーズ赤坂は、連泊や、荷物が多い旅行には全く向いていません。赤坂店には重要な問題が複数あり、かなり厳しいレビューをしなければなりませんが、敢えて正直に書きます。

睡眠が快適すぎる

開業時から変わらず、カプセル＝スリープポッドの性能がすばらしかったです。マットレスは薄いのに驚くほど柔らかく、照明・空調・防音も完璧。二晩とも横になった途端に爆睡しました。

枕元には交流電源だけでなく、USB電源があります。物が置けるスペースもありますが、ごく小さいものしか入りません。身の回り品は足元にカバンを置くことになりますが、充分足を伸ばせるので許容範囲かなと思います。

ハンドバッグひとつで寝るだけであれば、ナインアワーズは最高です。というか、それがカプセルホテルの本来の役割だったのですが。

シャワー

ナインアワーズには浴場はありません。そのかわり、充分な数のシャワーが用意されているため、満員になる心配はありません。

シャワーはオシャレですが、ハンドルのどこにも出っ張りがなく、手に石鹸がついているとひねるのがとても難しいです。場所が場所だけに写真を撮れませんでしたが、「デザインの敗北」といった感じです。

洗面所、アメニティ

シャワーは充分なのに、洗面所が足りていません。朝は混雑して大変でした。アメニティはハンドソープのみで、洗顔料、化粧水などは用意されていません。そのくらいは持参するので問題ないのですが、コップもないので薬も飲めません。

休憩できない

ポッドを外から見せる設計にした、赤坂店のみの問題と思いたいですが、明らかに共有部に対してポッドが多すぎます。人が多すぎて落ち着かないです。

休憩スペースは一階のコーヒーショップのカウンターのみです。玄関にベンチがありますが、人の出入りが頻繁なので落ち着きません。自販機は外なので、着替える前に飲み物を買っておく必要があります。

トランクを開けられない

ロッカールームが狭く、かつブロックごとに廊下のどんつきにあります。説明が難しいので雑な図を書くとこんな感じです。絵が下手でエレベーターの前が空いているように見えますが、実際は、壁際には海外旅行者の巨大なトランクがびっしり置かれています。

この構造だと、ロッカーの前でトランクを開けることになりますが、狭い廊下をトランクが塞いでしまうので、同じブロックの他の人がロッカーを開けられなくなってしまいます（つまり10人いたら2人くらいしか開けられない）。常に空気の読み合いが発生し、朝は戦場でした。

なお、公式サイトの写真を見た限りでは、神田店（ウーマン神田）はこの問題が出にくい構造になっています。

セキュリティ問題

これを書いて大丈夫かと思いますが…朝、洗面所に男性が入ってきて歯磨きをはじめました。スタッフともLGBTの人とも思えません（男性スタッフは午前3時〜4時に来ます）。男性の洗面所が混んでいたから女性用の方に来たのかもしれません。

男女のエレベーターが隣同士で、かつフロントから死角になっているので、異性のフロアに簡単に侵入できてしまうことに気付きました。今のところ問題が起きていないと思いたいですが、なんらかの見直しをした方がいいのではと思いました。

まとめ

「ナインアワーズ赤坂」の感想は以上です。二泊以上には今後利用しないと思います。そもそも連泊をするような施設ではない、としても、飲みすぎてかばんひとつで宿泊するような使い方では、今度はアメニティが少なすぎる問題があります。

ただ、夜や朝にポッドから出て見る幻想的な景色、美しく海外の人でもまったく迷わないサインボードなど、デザイン性についてはほんとうにすばらしいです。デザインと宿泊施設としてのユーザービリティの共存を願うばかりです。