9月23日に書いた記事「CMSの管理画面でクラス名を変更できるようにしたことを後悔している」の続きです。

この記事を読んだプログラマの友人に
「モジュールに設定したクラス名一覧を資料化すればいいのではないですか？」
と聞かれました。

当初はこれについても書くつもりでしたが、結論から言うと諸々の問題で難しいのと、ますます記事が長くなるので追記しなかったのでした。

この件について改めて書いてみたいと思います。

モジュールID一覧を作ったことはある

一時期、管理画面で表示されている「モジュールID一覧」のHTMLをPDFに書き出し、資料として納品時にお渡ししていたことがありました。

a-blog cmsは、CMS内の設定（IDがnewsのカテゴリーのエントリーを5件呼び出す）に名前をつけて「モジュールID」として使い回すことができます。DrupalのViewsも同様だったと思います。
これもクラス名と同様、管理画面でしか参照できないものです。なので友人の指摘の通り、資料化しようと考えたのです。

ですが、これには以下のような問題がありました。

予算がつかない

これはウェブ制作全体の問題ですが、「サイトマップ」「マニュアル」以外の資料には、あまり価値を見いだされません。企画を重視していない案件では「カスタマージャーニーマップ」さえ予算がつくのが難しいでしょう。それ以前に私は受注制作がメインなので、予算に関われる案件はまずありません。

もしこちらから「モジュールID一覧もお送りしますね」と言っても、たぶん「いやー、いらないですよ！」と返事が来ます。
なので、できるだけシステム化して、こちらの見積内に組み込むことになります。よほど効率化しないとタダ働きになります。

やっぱり使われない

そうやって頑張って作成しても、サイトの改修自体がないことが多いです。私自身も完全納品だと、その後は声がかからないので使うことはありません。前回の記事のように、常時改修をお手伝いさせてもらっている案件もまれにありますが、全体の一割くらいです。
もしかすると、多くの納品先が、このような資料を必要としていたのかもしれません。しかし何も言われないのでわからないのです。あー、SNSでつながっている方、その後必要だったかこっそり教えて下さい…

サーバーと同期されない

オフラインの資料にしてしまうと、管理画面の内容を更新したときに資料も更新しなければなりません。資料と最新の状態が食い違うのはまずいです。 これは友人も指摘していました。むしろ資料作成を重視するプログラマさんやSIerさんは、こっちを気にすると思います。

管理画面の情報を常に閲覧できればいいのでは

そこで「管理画面に、モジュール関連の必要な情報だけを一覧できるテンプレートを作ればいいのでは？」と考えました。
テーマ内に含むようにできれば、毎回資料を作成する手数もなくなります。

a-blog cmsなら簡単にできるかもしれないと、管理画面にざっと書いてみたテンプレートがこれです。

<!-- BEGIN_MODULE Admin_Module_Index -->
<!-- BEGIN module:loop -->
mid: {mid}<br>
モジュールID: {identifier}<br>
<!-- BEGIN status#open -->
<span class="acms-admin-label acms-admin-label-info admin-status-label acms-admin-text-nowrap"><!--T-->有効<!--/T--></span><!-- END status#open --><!-- BEGIN status#close -->
<span class="acms-admin-label acms-admin-label-danger admin-status-label acms-admin-text-nowrap"><!--T-->無効<!--/T--></span><!-- END status#close -->
<br>
	<!-- BEGIN_MODULE\ Admin_Module_Edit ctx="bid/%{BID}/mid/\{mid\}" -->
	説明: \{description\}<br>
	追加クラス: \{module_exclass\}<br>
	追加属性: \{module_exattr\}<br>
	<!-- END_MODULE\ Admin_Module_Edit -->
<hr>
<!-- END module:loop -->
<!-- END_MODULE Admin_Module_Index -->

Admin_Module_Indexモジュールは、モジュールIDの最低限の情報を一覧表示するモジュールです。
ループ内でエスケープされているAdmin_Module_Editモジュールは、指定したモジュールIDの詳細情報を出力し、GET送信すれば編集可能にするモジュールです。
いずれも管理画面専用です。

• mid
• 識別名
• 有効／無効
• 説明文
• 追加クラス（モジュールのカスタムフィールド）
• 追加属性（モジュールのカスタムフィールド）

ここまで一画面で表示できればかなり便利になると思ったのですが…
残念ながらAdmin_Module_Editに属性値でIDを渡すことができないようで、説明文やクラスは表示できませんでした。何か間違えているのかもしれませんが。

となると、PHPを書いて、データベースへの直接のアクセスが必要になります。さすがにそこまでする必要があるかは微妙です。

リッチCMSに備えないといけない

かつては汎用CMSとは、本格的なエンタープライズCMSではなく、ごくごくシンプルなものでした。
ですが利用者が多いWordPressであっても、納品後にもコーディングに関与できる「リッチCMS」の採用が当たり前になっています。

制作側もこれまでのように作るだけで終わらせず、納品から半年後、一年後の改修で無駄な工数を食わないよう、対策を講じなければならなりません。
消化不良ですがこの話題はまたいつか。

テーマの継承＝親子テーマの概念があるa-blog cmsでは、複数のブログで構成されたウェブサイトを製作する場合、子ブログのテーマはルートブログの子テーマとします。

フォルダ構造をざっと書くと以下のとおりです。子ブログ「ニュース」の親ブログには「sample」というテーマが指定されています。
a-blog cmsは「テーマ名@親テーマ名」でテーマの親子関係ができますから、ニュース用のテーマは「news@sample」とすればよいわけです。

            sample ┬ テンプレート
                         ├ テンプレート
                         ├ テンプレート
             　            ・・・

news@sample ┬ テンプレート
                         ├ テンプレート
                         ├ テンプレート
                         　・・・

ですが最近、他の人が製作した親子テーマを使わない「シングルテーマ構築」を見る機会があり、試してみたところ、開発者によっては、親子テーマよりもメリットが大きいかもしれないと感じました。

シングルテーマ構築とは

手法としては、特に凝ったものではなく、かなり昔からあったものです。私自身、Movable Typeで試したことがあります。

テンプレート内にインクルードを書き、ファイル名の一部に「ブログ名」もしくは「ブログID」を引数として渡します。
a-blog cmsで、詳細ページ用テンプレートの場合こうなります。

@include("/_entry/entry_blog_%{BID}.html")

コードネームを取得する変数「%{BCD}」を使って、より直感的なファイル名にしても良いと思いますが、a-blog cmsはルートブログではコードネームがない（NULL）ので「entry_blog_.html」というファイル名になってもよいのかは考える必要があります。

フォルダ構造は以下のようになります。画面ごとに「_top」「_index」「_entry」のフォルダがあり、現在訪問しているブログのIDをキーとして、表示するテンプレートを切り替えます。

シングルテーマ構築のメリット

やったことがない人から見ると複雑そうに感じますが、大規模なウェブサイトほどメリットがあります。

修正漏れが出にくい

親子テーマで構築したときに問題となるのが、子テーマの修正漏れです。親テーマと子テーマはテキストエディタや統合開発環境でファイル一覧を見た場合、かなり離れた場所に表示されます。このため、複数人で開発したり、数ヶ月語に改修をしたときに見落としが出やすくなります。

ファイルを探しやすい

テンプレートが画面ごとにひとつのフォルダに入っており、かつ一意のファイル名になっているので、ファイル名を検索して修正する作業がスムーズです。 親子テーマの場合、「index.html」を探そうとすると、テーマの総数分だけファイルがヒットすることになります。 カテゴリー単位でディレクトリを作っていると、ますます大変なことになります。

他の条件分岐を併用できる

親子テーマの場合、振り分けるのはあくまでブログ単位であって「ルートカテゴリーがitemsのエントリー」などのカテゴリー単位の振り分けは併用できません。
a-blog cmsの場合、「コンフィグセット」機能が追加されたので、カテゴリーごとにテーマを変えることもできるようにはなったのですが、テーマだけではなく同様にコンフィグに含まれている編集設定なども変わってしまうので、あまり現実的ではありません。

シングルテーマ構築のデメリット

説明が必要

CMS構築にそれほど詳しくない人には、事前説明が必要になります。最低でも、ブログIDとコンテンツの対照表がないと、ブログIDの調べ方がわからない人にはどうしてよいかわからないでしょう。

ルールはやはり子テーマ（a-blog cmsの場合）

スマートフォンではテンプレートを差し替える、などの「ルール」機能を利用する場合は、子テーマでなければなりません。

ELSE分岐が面倒（a-blog cmsの場合）

インクルード時にファイル名が一致していなければならないため、「ではない」を条件とした分岐が難しいです。

えっ？IFブロックを使って、こうすればよいのでは…と思うかもしれませんが、

<!-- BEGIN_IF [%{BID}/eq/2] -->
@include("/_entry/entry_blog_%{BID}.html")
<!-- ELSE -->
@include("/_entry/entry_blog_not2.html")
<!-- END_IF -->

a-blog cmsはIFブロックを使用した場合、条件に合致していないコードも処理されます。なので、このような書き方をすると、実質２ページ分の読み込みが発生して処理が遅くなります。

ELSE分岐はこのように、条件に合致しないテンプレートに、さらにインクルードを書くことになります。

_entry.html

@include("/_entry/entry_blog_%{BID}.html")

entry_blog_2.html 以外のブログIDのテンプレート

@include("/_entry/entry_not_blog_2.html")

なお、自作のグローバル変数を作成する知識があれば、 %{IS_NEWS} のような特殊な条件でtrueを返すグローバル変数を作ったり、特定のカスタムフィールドの値をテンプレートファイル名に使ったりできるので、大幅に有用性が上がります。
その場合はa-blog cmsのアップデートやサーバー移転の際に、オリジナルのグローバル変数を定義している /extension/acms/Hook.php を上書きしないよう、資料を書いて共有しておく必要があります。

まとめ：これでいいのか…？

メリットのところで書いたとおり、シングルテーマ構築は、私的には便利でした。途中、ディレクターさんが急ぎの文言変更でテーマを編集しましたが、フォルダ階層を登ったり降りたりしなくて良いので、作業しやすかったようです。

この構築手法は、a-blog cmsの公式テーマの管理画面のカスタムフィールドでは昔から使われています。ですが、公開側のテンプレートについては、ドキュメントでもこのような手法は解説していないので、オレオレカオステーマになってしまわないか、このまま採用し続けて良いものかという迷いがかなりあります。うぇびんたんいつも迷ってますね。

このへん、他の製作者さんの見解を知りたいので、SNSのコメントなどいただけると、とてもうれしいです。

電卓は使わないです

本年度分の確定申告も、今日、3月15日で締切となります。

開業してから11回、確定申告を経験してきました。経理の実務経験があるため、確定申告は毎年自分でやっています。
年によっては最終日の午後になったり、間に合わずに税理士さんに依頼したこともありますが、ここ数年は会計ソフトがとても使いやすくなっただけでなく「確定申告を楽にするためのコツ」のようなものを会得しており、あまり焦らなくなりました。

フリーランスになったばかりの人や、何年やっても苦痛だと思っている人のために、そのコツをご紹介します。
なお、あくまで個人事業主向けの知見です。法人には、かなり雑なものであることをお断りしておきます。

毎月経費を記帳しなくていい

世の中には、自己管理能力がひじょうに高い人たちがいます。そういう人たちは決まって「経費は毎月記帳している」「毎月やっておけばあとで慌てないですむのに」と言ってきます。
これは正論ですが間違いです。

順調に進むのは、自己管理能力がひじょうに高い人たちが、確実に記帳しているからです。むしろ、スキルが低い人が中途半端に帳簿をつけてしまうと、何ヶ月も経ってから金額のズレが出て、原因がどこかを探すのに手間取ってしまうことになります。
毎月お金の流れを確実に把握していないと震えるとかではないなら、年が明けてから一年分の取引を経費科目ごとに一気に入力してしまった方が早いですし、間違いを発見しやすいです。

同期・自動取り込みが使える銀行にする

私自身の経験では、やよいの青色申告オンラインが「スマート取引取込」に対応した二年前から、確定申告にかかる日数が大幅に減りました。freeeでは「同期」と呼ばれている機能です。

事業用の口座は当然持っていると思いますが、自動取り込みに対応している銀行に変更することを強くお勧めしたいです。そのくらい楽になります。手数料の関係で取引先に難色を示されるから…などの事情がある場合は、入金専用口座にして、細かい出金を別の銀行にする手もあります。

経費はスプレッドシートで作ってインポートする

freeeとやよいの青色申告オンラインは、弥生会計形式のCSVインポートに対応しています。それ以外のサービスは確認していません。すみません。

その他の会計ソフトから仕訳データを移行する（弥生会計形式を用いた方法） – freee ヘルプセンター

［弥生データのインポート］メニュー

消耗品費、水道光熱費、接待交際費などの現金の経費は件数が多く、会計ソフトに一件ずつ入力していくとかなりの手数がかかりますが、Excelなどのスプレッドシートで一気に金額と日付を打ち込んでいき、弥生会計形式に整えてインポートすると、大量の仕訳をスムーズに取り込むことができます。
片手入力ができる、消費税の計算に関数を使用できる、同じ金額の仕訳をコピーで増殖できるなど、スプレッドシートの機能を活かしたいところです。

私が実際に毎年使っているひな形を置いておきます。もちろんGoogleスプレッドシートも使用できますが、文字コードをShift_JISに変換してからインポートしてください。

やよいの青色申告オンライン対応CSVインポートひな形

レシートの写真を撮ると…

ここまで読むと気付くかと思いますが、freeeのアプリなどが搭載している「レシートの写真を撮ると仕訳が記録できる！」という機能は、年度末にまとめて仕訳するフローの場合は、全然便利にも早くもなりません。
あれは冒頭で触れた、まめに帳簿をつけられる「自己管理能力がひじょうに高い人たち」のためのものです。間違っても一般の人は手を出さないようにしましょう。

交通系ICカードは同じ金額をチャージする

フリーランスの経理取引で一番面倒なものが、旅費交通費です。ほとんどの人は、Suicaなどの交通系ICカードを持っていると思います。
これにチャージするときに、毎回同額でチャージするようにします。金額を揃えておくと仕訳が異常に楽になります。クレジットカードでの自動チャージにすることが考えられますが、クレジットカード払いは仕訳が複雑になったり、支払いが年またぎになったりするので、会計ソフトに自動で取り込めないカードの場合は現金で統一したほうが良いでしょう。

簡便法を活用する

先述のSuicaですが、チャージの際は一旦「貯蔵品」や「仮払金」として仕訳し、実際の交通費を都度「旅費交通費」として引いていくのが正しいと言われます。

ですが、一ヶ月分、一年分の交通費を残額から逆算してまとめて計上してしまう「簡便法」を使用することも認められています。

Suica,PASMO,ICOCAなど交通ICカードの仕訳・会計処理

↑↑一年分のチャージからICカード残額を引いた金額

この計算方法は、現金や普通預金の残額から12月31日付で年間の生活費にあてた分（事業主貸）を計上するのにも使えます。ひとつひとつ交通費を入力していくととんでもない手数がかかりますし、間違いが多くなります。簡便法が使えそうな仕訳は積極的に採用しましょう。

取引先ごとに補助科目を作る

交通費の次に面倒なのが、売掛金です。取引先によって源泉が含まれたり入金から手数料が引かれていたりするので、売掛が回収されているかの把握に手数がかかります（本当は引いてほしくないのですが、自社以外への振込に750円もぼったくる○洋銀行がうんこなので仕方ないですね）。

取引先ごとに補助科目を作るのが確実です。仕訳を取引先でソートすることで回収状況を確認できます。一度きりのお取引先はいちいち作っていられないので「その他」に入れます。
どうしても金額が合わない場合は、「売掛帳」を見るのも良いと思います。

売上を整理する

オンラインショップの売上や、ランサーズなどのクラウドワークによる少額収入が多いと、会計処理が複雑になりがちです。
オンラインショップの場合は商品の金額を揃えることである程度回避できますが、クラウドワークの場合はそうもいきません。

これは私の実際の経験からの話になりますが、少額かつ一度きりの取引が大量にある業態より、高額かつ安定した取引が定期的に望める業態に変えるよう努めた方が、経理的にも精神的にも良いです。
怪しい取引先が多いと、売掛金の回収不能＝貸し倒れのリスクが高まります。金銭的に損をするばかりか、「貸倒引当金」という経理の知識がない人には最難関の仕訳をすることになります。

まとめ

私が確定申告の負荷軽減のためにやっていることは、このようなところです。自動取り込みとCSVインポートは強くお勧めします。これらの機能のために毎年10,000円ちょっとの会費を払っていると言ってもいいくらいです。

freeeかやよいか、というのは完全に好みの問題です。ただ相性はあるようで、私はfreeeのUIは合いませんでした。なので両方試してみるのがいいだろうと思います。

来年からはe-Taxで申告すると所得の控除額が10万円増えます。そうなると導入したくもなりますがが、場合によってはせっかく楽になった分が無駄になりそうです…

e-Taxで確定申告するのに4日かかった件｜Takehito Tanabe｜note

勝間和代さんが今年のはじめころから、執筆を音声入力にしたらびっくりするくらい効率化できた、とレポートを書いています。

音声入力による生産性の向上は、ざっくり「３倍」くらいのイメージ - 勝間和代が徹底的にマニアックな話をアップするブログ

私はずっと、音声入力でブログを書くことに憧れています。だいたい、月旅行が実現するような未来に生きているのに、文字入力が未だに手でしかできないなんておかしいじゃないですか。

一年に一度のペースで何度も試しているのですがその度に挫折しています。今回また、何度目かの挑戦をすることにしました。

普段はブログ記事を、メイン機であるMacBook Proの2016年モデルで書きます。先日、OSをMojaveにバージョンアップしたばかりなので、Mojaveと Bluetoothヘッドセットでの音声入力を試しました。

占星術士の石井ゆかりさんの占いを読み上げてみたのですが…

散々な結果でした…これではSiriもまともに使えるか怪しいものです。Appleの純正イヤホンなら大丈夫ではないかと思い、まったく同じ文章を読み直しましたが…

(°言° )

精度が変わらないどころか悪化しました。

音声入力の精度はスマートフォンの方が高いといいます。なので今度は、ZenFone3+Google音声入力と、最初と同じBluetoothヘッドセットで試してみました。

おぉ。今度はほぼ正確に入力することができました。

ですが、文節ごとに半角スペースが入ってしまうので、入力後にスペースを削除しなければいけません。ちょっと面倒くさいです…しかも音声で入力された箇所はタップして別の候補に変更するか、削除するかを選べるのですが、句読点を入れるときにこの機能が仇となり、間違って文節を一個消してしまいました。

音声入力をするにあたって、もうひとつハードルがあります。それは、肝心の私の言葉が出てこないという、身も蓋もない話です。

私はかなり饒舌で、一般の人と比べると語彙も多いと自覚しています。ですが、私 の頭に浮かぶ文章は、通常100文字くらいのフレーズが多く、順番もバラバラで、しかもあっという間に忘れてしまいます。

日常会話やTwitterなどは大得意ですが、 セミナーのプレゼンや、こういった音声入力は、文章をまとめきれずに言葉に詰まってしまい、まるでうまくいきません。

勝間さんは、音声入力の精度の問題で実用化できなかったと記事に書いていましたが、どちらかというと一般の人は私のように、言葉をまとめることが苦手だからできない人が多いのではないかと思います。人前で話す機会が少ない仕事をしていると尚更でしょう。

実は、ここまでのブログ記事は音声入力で書いてから、あとでキーボードで加筆しています。

Google音声入力の精度はやはり凄いですが、先述の通り、文節ごとにスペースが入ってしまう問題があったり、句読点が入力できなかったりするので、いちいち戻って文章を直さなければなりません。

入力は一瞬ですが、キーボードと違って「とりあえず考えついた順に書き出す」ということができないので、少しずつしか進みません。スマートフォンのUIだと、文章を直すのにも時間がかかります。 やはり、人前でまとまった話をすることに相当慣れている人でなければ、長い文章を音声入力にするのは、なかなか難しいなと感じました。

ただ、スマートフォンの音声入力は完全に実用レベルになったと思うので、もっと積極的に使いたいです。常にメモアプリを起動しておいて、思いついたブログの記事のネタを、忘れないうちに音声入力するという手がありますよね。

スマートフォンをiPhoneXsに変えることにしたので、Siriや音声入力の精度が、以前使っていたiPhone 7と比べてどのくらい高くなっているのか期待したいです。