にしし ふぁくとりー:西村文宏 個人サイト

Presented by Nishishi via Movable Type. Last Updated: 2023/07/17. 21:26:12.

Sakura Scope (2023年05月)

ちょっと倒錯気味な、ただの日記です。(^^;)
これはやばいと思われた場合は、お早めに閲覧を中止されることをお勧め致します。

地震保険に入っていない理由

地震保険には入っていなくて、火災保険の契約を見直した際に再検討したのだけども、やはり地震保険は契約しないことにした

元々日本は地震の多い国ですけども、最近も妙に多いですよね。大きめの地震が。

で、うちの家は一戸建てなのですけども地震保険は契約していません。火災保険の契約を見直した際(※)に、ちょいと本格的に地震保険のことを調べ直してみて再検討したのですけども、その上でもやはり「地震保険は契約しない」という結論に至りました。
この考え方が本当に正しいかどうか明確な自信はないので、「この考え方が正しいかどうか?」を後から見直すためにも、地震保険に入らないことにした理由をちょいと備忘録的に書いておきたいと思います。

※地震保険は単独では契約できない制度で、火災保険にオプションとして加える形でしか契約できません。(どこの保険会社でも)

簡単に言えば、地震保険の保険料が補償額と見合うかな、と考えてみたときに、あまりそうとも言えないな……、という結論に至ったので契約はしないことにしたんですが。
以下はその話(=地震保険を契約するかどうかを検討するために調べた内容の話)です。

※実際に地震保険を検討するために検索してきてこのブログ記事を読んでいる場合は、(私は専門家ではありませんし、この考え方が正しいのかどうか分からないので)以下の話はあくまでも参考程度に留めて下さい。

「時価」と「再調達価格(新価)」の違い

まず、何らかの物体に掛ける保険の補償額には、「時価」と「再調達価格」という2種類の額がありますから、この違いを知っておく必要があります。なお、「再調達価格」は「新価」と表記される場合もあるようです。この2点の違いは下記の通りです。

  • 「再調達価格(新価)」: 同じ物をもう一度買い直すときに必要になる額のこと。住宅の場合なら、同じ規模の住宅を再度新しく建てるときに必要になる額のことです。
  • 「時価」 : その時点での価値から判断された値段のこと。住宅の場合なら、基本的には築年数が経てば経つほど額は減少していきます。

で、ここで重要なポイントは、

  • 火災保険の補償額は、再調達価格(新価)がベースでも
  • 地震保険の補償額は、時価がベース

という点です。
要するに、地震保険での補償というのは、たとえMAXの支払いを受けられたとしても、「同じ規模の住宅を建て直すのに必要な額」にはならないんですね。

火災保険とは違って、地震保険はそもそも再建資金にはならない保険

火災保険は主に、被害のあった住宅を元通りに再建(または修復)するため(の資金を得るため)の保険です。
まあ、そりゃそうですよね。元通りにできなかったら困るわけですし。もしものときに「修復や再建に必要になる額」を補償してもらうために掛け金を払って契約しているのですから。
なので、再調達価格(新価)をベースにした補償になっています。(常にMAXの支払いが受けられるわけではなくて、被害状況に応じた割合での支払いになりますが。)

※「火災保険」という名称で呼ばれるものの、たいていは火災以外にも水災とか風災とか土砂崩れとか、(地震以外の)様々な被害に対応する総合的な住宅保険です。(地震による火災が原因の場合は、火災保険では補償されません。)
※建物そのものだけでなくて、家財も補償の対象にできるので、保険契約で家財も補償対象にしていれば「家財を買い直すための資金」も補償されます。

では、地震保険もそうかというと、そうではないんですね。
地震保険は、時価をベースにした補償にしかならないので、築年数が結構経っている場合、元の建物を再建築するのに必要な額には全然足りません。
なので、地震保険とは主に、被害を受けてしまった後の「当面の生活資金」を得るための保険という位置づけに過ぎないようです。

▼地震保険は民間企業だけでは運営しきれず、政府との共同運営になっている

なぜそんな違いがあるかというと、

  • 火災は基本的に1件単位で発生するのに対して、
  • 地震は同一地域の広い範囲でまとめて発生しますから、

地震の発生時には一気に莫大な支払いが発生する可能性があるために、「民間保険会社が単独で地震保険を運営するのは無理だから」なようです。(詳しくは知りませんが、地震の発生確率から保険料を算出するのが困難なのか、算出しても非現実的な保険料になってしまうとか、なんかそんな理由でしょうかね?)

なので、地震保険はあくまでも(再建ではなく)当面の生活資金を補償する位置づけとして、保険の補償額を「建物の時価」に抑えた上で、しかも民間保険会社と政府が共同で運営する形態になっています。
財務省のウェブサイトに「地震保険制度の概要」というページがあるのですが、そこには以下のように書かれています。

  • 地震保険は、地震等による被災者の生活の安定に寄与することを目的として、民間保険会社が負う地震保険責任の一定額以上の巨額な地震損害を政府が再保険することにより成り立っています
  • 地震等による被災者の生活の安定に寄与することを目的として、民間保険会社が負う地震保険責任を政府が再保険し、再保険料の受入れ、管理・運用のほか、民間のみでは対応できない巨大地震発生の際には、再保険金の支払いを行うために地震再保険特別会計において区分経理しています。

ちなみに、2011年にロイター通信が「東日本大震災による損保各社の業績影響」という記事を公開しているのですが、それによると、民間保険会社と政府の地震補償割合は、地震保険法という法律で以下のように決まっているようです。

  • 1150億円まで保険会社が100%負担
  • 1兆9250億円まで保険会社と政府で折半
  • それ以上の部分は政府が95%負担し、残る5%を保険会社が負担

上記のように、大規模災害の場合には政府がほとんどを負担するような仕組みがないと、とても運営できないのが地震保険だということなんでしょうかね? たぶん。

地震保険で掛けられる保険金額は、火災保険の保険金額の30%~50%限定

地震保険の補償は時価がMAXだと述べましたが、それとは別にもう1つ別の上限があります。
それは、地震保険として掛ける保険金額が、「火災保険の保険金額の30%~50%の範囲内に限る」という制度になっている点です。(なぜその制限があるのかはよく分かりませんでしたが。)

火災保険の保険金額は、当然、「今の建物と同じ規模の建物を再建する際に必要になる額」として決めますよね。(=再調達価格)
地震保険で掛けられる保険金額は、その「火災保険の保険金額」の50%が最大額です。

なので、

  • 「時価」と
  • 「火災保険の保険金額の50%」の

どちらか低い方が、補償額の上限になるということでしょう。

そもそも、地震保険での補償額は常に100%というわけでは全然ない

地震保険での補償額が時価ベースだからといって、常に「時価の100%」が支払われるわけではありません。
地震保険では、損害割合に応じて下記の4段階で支払うよう決まっています。(どこの保険会社でも同じです。)

  • 全損 :地震保険の保険金額の100%(時価額が限度)
  • 大半損:地震保険の保険金額の60%(時価額の60%が限度)
  • 小半損:地震保険の保険金額の30%(時価額の30%が限度)
  • 一部損:地震保険の保険金額の5%(時価額の5%が限度)

で、例えば東日本大震災による保険料支払いでは、「だいたい全体の7割くらいは『一部損』だと判定されて、5%の補償しか受けられなかった」という情報もありました
まあたしかに、本当に何もかも完璧に潰れるケースって(もちろんあるにはありますが)滅多には見かけないですしね。

なので、地震保険を考える際には、以下の2点も考慮する必要がありそうです。

  • 補償額は、時価がMAX。(ただし、火災保険の50%が上限)
  • 実際に支払いを受けた地震被災者の7割くらいは、「一部損」として5%だけの補償。

※保険会社によっては、地震保険の保障額を2倍にする特約を設けていたりしますが(その分だけ保険料は増えますけども)、掛けられる最大保険額が「火災保険の50%」だからといって、特約で「補償額を2倍」にしたところで、実際に支払われるのは「時価」が上限なのですから、よほど建築して間もない場合を除けば「再建できるだけの資金にはならない」という点では同じように思います。

時価はいくらなのか? →固定資産税の評価額が参考になる(?)

一戸建て住宅では(※マンションについては詳しく調べていないので一戸建ての話だけをします)、所有者が固定資産税を毎年支払う義務があるので払っているはずです。(土地と住宅のそれぞれに固定資産税が課せられます。)
その明細が毎年5月頃に届きますが、そこに「固定資産評価額」という項目があって、市区町村が認識している評価額(時価)が掲載されています。
地震保険での「時価」が、この固定資産税の計算根拠になっている評価額と同じなのかどうかまではよく分かりませんでしたけども、1つの参考にはなるでしょう。

築ウン十年と経っていると、たとえ最初に数千万円で建てたとしても、建物の評価額はずーいぶん下がっていて、数百万円くらいになっているっぽいです。
suumoの固定資産税解説記事にあるグラフによると、木造住宅の評価額は築10年で約半分になり、築20年では5分の1くらいになり、築25~6年を過ぎれば10分の1を下回るのだとか。
新築から四半世紀を過ぎるだけで評価額がわずか1割をも下回るというのもすごい話ですね……。そんなに下がるものなのかと。(まあ、その分だけ固定資産税が安くなるのなら良い面もあるわけですが。)

なので、築うん十年と経っている場合は、「この家は当時3千万円で建てたのだからまだ1千万円くらいの価値はあるはずだ!」みたいな考えはしない方が良いと思います。^^; その場合はむしろ土地の価値の方が高いくらいにまで下がっている可能性もあります。

▼地震被害4段階でのだいたいの補償額が計算できる

で、地震保険では、保険金額のほかにこの「時価がMAX」という限定条件があるわけですから、先の4段階「全損・大半損・小半損・一部損」で具体的にいくらの補償額になるのか、だいたいの計算ができます。

仮に築40年とかで建物の時価が200万円だとすると、大半損なら60%なので120万円、小半損なら30%なので60万円、一部損なら5%なので10万円ですね。

地震保険料の何年分でその額を超えてしまうかも計算してみると良いと思います。(時価は年々減っていくので、今の時点で「何年分」と計算しても、実際にはそれよりも短い年数で超えてしまうと思いますが。)

このように考えると、(築年数が相当経っていてローン等が残っていない場合には特に)地震保険を契約するメリットが見えてこないな……というのが実感でした。

地震保険に入っておくべきかどうかは、築年数によっても変わりそう

もちろん、家を建てたばかりなら、地震保険も契約しておく方が良いでしょう。
時価が高いうちは、それだけ補償額も高いわけですし。
ただし、先程もちょっと述べたように、「時価の100%」に設定できるわけではなくて、「火災保険での保険金額の50%」がMAXですけども。なので、時価の高い頃(=建築して間もない頃)に地震で倒壊した場合でも、立て直すだけの資金は得られません。
しかし、建てたばかりの頃なら住宅ローンだってずいぶん残っているでしょうから、たとえ半額であっても受け取れるように契約しておかないと、借金の負担が余計に大変なことになるでしょうからね……。

※そもそも、ローンを組んで建てた場合、火災保険なり地震保険なりの保険を家主の意思で自由に契約できるのかどうかよく分かりませんけども。(詳しくは知らないんですが、ローンを組んで建てた場合は、ローン提供元側の指示で指定の保険に入らないといけないとか、そういうこともありそうな……?)

しかし、築うん十年……という場合は、先程述べたように建物の評価額(時価)はかなーり低くなっているでしょうから、補償額もかなーり低くなります。

なので、築うん十年という建築物の場合、安くはない保険料を払って契約するかどうかは微妙なところなんですよね……。
ちなみに、日本での地震保険の加入率は33%くらいで、火災保険の加入率は82%くらいだそうです。(※ソースがどこだったか失念してしまいましたが。)
地震保険の加入率が33%程度しかない理由は、この辺(=建物の時価が低ければ補償額も低い点)にあるのだろうな、と想像しています。

あと、貯蓄が苦手な性格の場合には、入っておくメリットはあるかもしれません。
地震被害に遭ってその家に住めなくなってしまった場合には当面の生活資金が必要になりますが、貯蓄がなかったら保険に頼る以外にありませんから。

当面の生活資金を貯蓄できているなら、地震保険は不要と考えて良い?

地震保険とは「建て直すための資金」ではなくて「当面の生活資金」を得るための保険、という位置付けなので、結局のところ、

  • 当面の生活資金は貯蓄から出せる
  • 築年数が長いために時価が低い

……という2条件に当てはまっている場合には、地震保険に入る意味は薄そうだな……という結論に至りました。

当面の生活資金くらいの貯蓄ができるのなら、地震保険の掛け金に費やすよりも、「いざというときの生活防衛資金」として自分で貯金(運用)しておく、という方が良いのではないか、と思います。

というわけで、地震保険は契約しない選択をしています。今のところ。
この考え方が正しいのかどうか、そこまで絶対的な自信はないのですけども。

とりあえず、今後に再検討することもあるかもしれませんので、そのときにまた同じことを調べ直さなくて済むように、備忘録的に考えを書いておきました。

日本は地震が多いですし、いつどこに(建物倒壊レベルの)大地震が来るかは分からないので心配はあるのですけども、その心配を補えるような「建築し直せるだけの補償を得る手段(保険)」というのは用意されていない世の中なのですねえ……。

感想文の極意に気付いたかもしれない話(たぶん気のせい)

文章を書くことは苦ではないのに、感想文が苦になるのは……

文章を書くこと自体は全然苦にならないのですけども、読書感想文は昔々(小学生時代)から凄まじく苦手で苦痛でした。
読書に限らず感想文全般がそうなのですが。
これは今でもそうです。

その理由は何かな……と考えて思いつく理由の1つ(たぶん最大の理由)が、「まず、あらすじを教えて差し上げないといけない」という気になるからではないかと思います。
だって、その作品を知らない状態の人に感想だけを述べたって何も伝わらない気がするので……。

感想文を読む人が、自分と同じ作品を既読だとは限らないわけですから、まずはどんな話だったのかを説明して差し上げる必要があるだろう、と昔から考えていました。
例えば人物名を突然出したって、実在・歴史上の偉人ならともかく、フィクションな作中の人物なら、まずその人物がどんな人なのかを説明しないと、読者(=感想文の読者)は確実に何も分からないわけですから。

なので、まずは(感想文の読者のために)当該作品の内容を要約(紹介)して差し上げないといけない(と思い込む)わけですけども、「感想を書こう!」と思い立つくらい面白かった作品なら、そう簡単に要約できるほど単純な内容ではないのですよね。

  • あれもこれも面白いポイントは全部教えて差し上げたい。
  • しかし、あれもこれもを書いてもその作品の面白さのすべてを書き切ることはできない。
  • だって、面白いところがたくさんあるんだから。
  • それに要約してしまったら臨場感も何もなくなるので面白さが低下する問題もある。
  • そうなると、もう「全部自分の目で見て(読んで)くれ!」としか言いようがなくなる。

……となるために、「感想を述べる段階」にまで行き着かないのではないかと思います。(笑)

すると結局、何か言うとしたら「おもしろかった」以外に言えることがなくなるというか。
だから、読書感想文は凄まじく苦手なんですよね。たぶん。
その辺が最大の理由ではないかと思っています(違うかも知れませんが)。

気付いた

で、ネット上には「感想文が上手い人」(というか、感想文がおもしろい人)の文章が多々あって、昔からちょくちょく読む機会があったわけですけども、最近になってようやく気付いたことがあります。

➡ 感想文という文章の中には、別に作品そのものの紹介は要らない……!

感想文を読む相手が(当該作品を)既読だろうが未読だろうがそんなことは知ったことではなくて、ただ思ったことだけを書けば良いんですよね。自分の思ったことだけを。
「感想文」は、「解説文」とは異なるのですから。そこが分かっていなかった気がします。

読書感想文に関しては、読者(=自分の書く感想文の読者)は置いてきぼりで良いのです。たぶん。
いや、違うかもしれませんけども。
なんかそんな気がしています。

ハマっている対象は不明確なままでも、おもしろい感想文はおもしろい

オタク業界には「何かよく分からんが沼にハマっている人を端から眺めるのは楽しい」みたいなのがよくありますが(笑)、この「何かよく分からんが」の部分はよく分からんままで全然問題ないのですよね。
(いや、現にハマっている人からすれば、他者を同じ沼に引きずり込みたいと思っているかもしれないので「何かよく分からんが」で済ませては欲しくないかもしれませんけども。^^;)

少なくとも「端から見て楽しいかどうか」の要件には、ハマっている対象が既読である必要もなければ、あらすじすら知っている必要もありません。
沼にハマって狂ったように幸せそうにしている人を見るのは、その沼に何が沈んでいるのかを知らなくても楽しいわけです。

それが「感想文」なんだな、と最近気付いた次第です。
違うかもしれませんが。

例えば、カードキャプターさくらの感想を書くなら、決して「カードキャプターとは」から始めてはいけないわけです。
心が感じたままに、「はにゃーん!😍 ぐへへ、ぐへぐへ。さくらたーん!」みたいな感じで始めないといけないのでしょう。(違うかも)
読者(=感想文の読者)が居るかどうかとか、感想文の需要とかを気にしてはいけないし、読者が理解しやすいように気遣って解説してもいけないのです。
むしろ、自分の狂った様子を狂ったまま記録するのが(おもしろい)感想文というものなのでしょう。(違うかもしれませんけども!!)

どうせ書くなら、楽しい感想文を書きたいものです。

てがろぐVer.4をリリースした話

2年半ぶりのメジャーバージョンアップ

てがろぐうちのサイトで配布しているフリーCGIの中で、いま一番ユーザさんが多いように感じられるのが「てがろぐ」です。今のところ私が一番製作に力を入れているのもこれです。
先月(4月)末に、2年半ぶりにメジャーバージョンを上げて、Ver 4.0.0 をリリースしました。

前回(1月)の正式リリースバージョンが 3.9.0 でしたから、次は 3.10.0 にしても良かったのですけども、ちょっと大きめの機能として「ログインセキュリティ機能」と「予約投稿機能」を加えましたので、メジャーバージョンも更新して 4.0.0 にしました。

▼過去との互換性は100%、UIも変更なしで、操作感はそのまま

大きめの機能を加えたといっても、

  • UIは変わっていないので(※追加はあっても変更はないので)使い勝手が突然変わってしまうようなことはありませんし、
  • データファイルや設定ファイルの仕様も変わりませんから、動作環境にもバージョンアップ手順にも変更はありません。

過去との互換性は100%ありますから、必要なら(※必要性はないと思いますが)一度 Ver 4.0.0 にUPした後で、3.9.0 に戻すようなバージョンダウンも問題なく可能です。なので、気軽にバージョンアップして頂けます。

てがろぐの開発では、その辺(UIの維持とか互換性とか)も特に気を遣っているポイントです。
もし、バージョンアップによって「仕様や操作感が大きく変わります」みたいなことにしてしまうと、バージョンアップをためらう要因の1つになってしまいますよね。WordPressとかのCMSを古いバージョンのまま使っている方々は、たいていその辺のことを気にしてバージョンアップしないまま使っているのではないかと思いますが。
なので、そうならないように、システム的な「過去との互換性」も、UIの「無変更性(一貫性?)」も極力維持できるようにしたいと思っています。

今のところ、

  • 過去のどのバージョンからでも最新版にバージョンアップできますし、
  • 最新版から、過去のどのバージョンへもバージョンダウンできるハズ

です。
※もちろん、バージョンダウンすれば新機能は使えなくなりますが、バージョンダウン先で設定が読み込めなくなったり、投稿データが読み込めなくなったりはしないハズです。

▼メジャーバージョンの変遷

今回は2年半ぶりのメジャーバージョンアップだったわけですが、それ以前はもうちょっと間隔が狭くて、だいたい1年半間隔でリリースしてきました。
Ver 3.x.xでは細々した機能をちょくちょく加えていったからかな、という気もしますが、バージョンを重ねるごとに「大規模な機能」というのは少なくなってくるから、という理由もあるかもしれません。

  • Ver.1 初回リリースは 2017年12月。
  • Ver.1→2では、主に画像投稿機能を搭載。(2019年3月)
  • Ver.2→3では、主にカテゴリ機能を搭載。(2020年10月)
  • Ver.3→4では、主にログインセキュリティ機能・予約投稿機能を搭載。(2023年4月)

なお、Ver.2→3のときの話は、2020年10月のブログ記事「てがろぐVer.3開発とリリースの裏話」にちょっと書いています。

こんな感じの「今回の開発について」みたいな小話を、てがろぐの正式版をリリースするたびにブログ記事としてまとめようかな……と毎回思ってはいるのですけどもね。結局は、「今日のひとこと」(てがろぐ)とかに書き散らかすだけで、まとめることなく終わっています。
「これはブログネタとして一応メモっておくか……」みたいな感じで「今日のひとこと」に書いておくことがよくあるんですが、そこに書いた時点で満足してしまって、ブログ記事にしないことが結構あります。これはTwitter全盛期にもよくありましたけども。「ブログネタだな」と思った場合には、公開場所には書かずに留めておく方が良いのかもしれませんね……。^^;

ちなみに、最初の Ver 1.0.0 はこんなのだった、という話を今年の3月に「てがろぐ Before&After」に書きました。設定画面を比較してみて、「最初はここまで設定項目が少なかったのな……」と自分でもちょっと驚きました。

てがろぐ Ver.4 の機能

さて、Ver.4になった「てがろぐ」の主な新機能についてもちょいと語っておきます。
作った理由とか、今後の話とか。

▼ログインセキュリティ機能

てがろぐログイン制限設定最近は(ありがたいことに)ユーザさんも増えてきましたので、ちょいとセキュリティ周りの機能を加えておきたいな、とずっと思っていまして、それを加えました。

てがろぐにはこれまで「IDをロックする機能」がなかったんですよね……。
なので、ログイン画面からはパスワードの入力を無限に試行できました。
つまり、IDとパスワードの組み合わせをテキトーに試し放題だったわけです。(とはいえ、ローカルで動作するソフトウェアとは違って、Webサーバの反応速度はそこまで高速ではありませんから、1秒間に何百回ものログインを試行することはできないと思いますが。)

何にしても、さすがにその仕様はセキュリティ面でよろしくありませんから、

  • ログイン試行頻度を制限したり、
  • ログイン失敗回数に上限を設けたり、
  • ログインを試せるIPアドレスを制限したり

……できる3機能を用意しました

デフォルト設定では、1つ目の「ログイン試行頻度の制限」だけが有効になっています。
これは、パスワードを間違えてログインに失敗したら、その直後に最大2秒間だけIDをロックすることで、機械的なログイン試行の頻度を制限するセキュリティ機能です。1分間に最大30回しかログインを試せなくすることで、パスワード総当たり攻撃(ブルートフォースアタック)を難しくしよう、という機能です。

パスワードを人力でキー入力する場合、よほど短くない限り1秒くらいはかかるでしょうから、最大2秒間のロックが掛かっても(人間が入力する限りは)不便にはならないと思います。そもそも、てがろぐはログインしっぱなしで使われるケースが多いでしょうから、ログインフォームを使う頻度自体が低いでしょうし。

あとは、さらに(設定画面から設定すれば)「パスワードを指定回数ほど連続で間違えると、指定時間ほどIDをロックする機能」を有効にしたり、「ログインを試せるIPアドレスを制限」したりもできます。全部併用できるならそうすれば、より安全になるのではないかと思います。使えるセキュリティ設定はすべて使うのがお勧めです。

▼予約投稿機能

てがろぐ予約投稿設定てがろぐでは従来から投稿日時として「未来の日時」を指定することはできましたが、それは単に「未来の日時が表示される」というだけのことでした。
そのように投稿日時として未来の日時が指定された場合に、(従来通り)そのまま表示するのか、または予約投稿扱いにするのかを選べる設定機能を追加しました

そこで「予約投稿扱い」に設定しておけば、予約投稿機能が使えるようになります。予約するための特別な操作方法はなくて、ただ「未来の日時を投稿日時にしておけば、その日時が来るまで表示されない」という動作になります。

とはいえ、「予約投稿」という機能名から得られるイメージとは少々動作結果が異なるかもしれません。

  • 予約投稿という機能名から想像される機能はおそらく、『あらかじめ設定しておいた本文が、指定時刻になったら新規に投稿される』という機能だろうと思いますが、現状の機能はそうではありません。
  • 実際の機能は、『非表示状態になっていた投稿が、指定時刻になったら表示状態に切り替わる』という機能です。

つまり、予約していても、掲載位置(掲載順序)は元の投稿順のままで変わりません。

例えば、「Ⓐ予約した投稿」の後に何か別の「Ⓑ予約ではない普通の投稿」をしていれば、ⒶはⒷよりも下(=本来の掲載順の位置)に表示されます。
なので、「Ⓐ予約した投稿」の後に多数の「Ⓑ普通の投稿」を投稿していると、予約時刻が到来してもⒶの存在が閲覧者に気付かれない可能性が高くなります。

※予約投稿を絶対に先頭に表示させたい場合は、「先頭固定」機能を併用する必要があります。予約投稿をする際に「先頭固定」にチェックを入れておけば、その予約投稿は(予約時刻が来たら)先頭固定投稿として先頭に固定表示されます。(その場合、予約時刻の後にその投稿を再編集して「先頭固定」チェックをOFFにしないと、ずっと先頭に表示されたままになります。^^;)

▼将来的には……?

将来的には予約投稿らしい動作にしたい、という気はあるにはあります。一応は。今のところは。
開発予定の中には、「全投稿を指定日時順に再整列させる機能」もありますので、その機能が実装できた際には、「予約投稿の表示時には全投稿を自動で日付順に再整列する」というような設定機能も加えることで、予約投稿が必ず最新投稿として表示される、という仕様にもできる気はしています。そうなると、たぶん予約投稿らしい動作になるのではないかな、と思っています。

とはいえ、現状でも予約投稿としては機能しますので、急いで実装する必要性は高くはないと思っていますけども。
何にしても、投稿を日付順に並べ替える機能の実装はまだまだ先だと思います。^^;
何もかもを一気に実装することはできませんので、気長にお待ち頂ければ幸いです。

▼上書き用CSS登録機能

てがろぐ上書きCSS登録設定スキンのCSSを直接テキストエディタ等で書き換えなくても、管理画面から「上書き用CSSソース」を登録できる機能を用意しました

「配布スキンをほぼそのまま使っているが、配色等のほんの一部分だけは独自にカスタマイズして使っている」というケースもありますよね。そのとき、スキンに付属しているCSSファイルを直接編集すると、スキン側がバージョンアップしたときに、再度同じようにカスタマイズしないといけなくなって面倒です。

この機能を使うと、配布スキンをバージョンアップさせた場合にも、自分でカスタマイズした部分だけはそのまま維持し続けられる(可能性がある)メリットがあります。なお、スキン側には特別な工夫は要りませんので、いつ作られたスキンでも、この機能でCSSを追加できます。

※ここで登録した上書き用CSSソースは、基本的には「</head>タグの直前」に挿入されます。この機能のメリットは、「</head>タグの直前に追加CSSを挿入するので、スキン側に何の準備がなくても強制挿入できる点」です。既存スキンを何も編集しないままの状態で使えます。

ただ、複数のスキンを併用したい場合に調整が面倒になる可能性はありますけども。
どのスキンに対して上書きCSSソースを挿入するのかを設定で選択する機能がありますし、複数スキン併用時に強制挿入対象を絞りたい場合に使える専用記法も用意していますので、それらの機能を併用して頂くと、うまく運営しやすいのではないかと思っています。

▼その他いろいろ

そのほかにも追加機能は多々ありますが、あとはリリースノートをご覧下さい。
リリースノートは、めちゃくちゃ毎回がんばって書いていますので……!!
読んで……!!!

書くのが大変なので、書かずに済ませられるならそれに越したことはないんですけども。
でも、こういうドキュメントがないと、バージョンアップ時に「何が新しくなったのか」が分からないので、やっぱり用意するしかないよな……と思って、毎回用意しています。需要がどれくらいあるのかはよく分かりませんけども。^^;;;

ああ、そうそう。YouTubeとSpotifyの埋め込みサイズを管理画面上から設定できるようになりまして、特に(従来は縦長固定だった)Spotifyはもっと見やすく掲載できるようになったと思います。デフォルト設定を突然変更してしまうと不都合がある場合もあると思いましたので、デフォルトでの掲載サイズには変更ありません。しかし、たいていの場合は、横長に見えるサイズにする方が見やすい(+配置が楽な)のではないかと思います。(例えばここのように)。

ヘルプドキュメントをどうやって簡単に作るか

リリースノートも必要には違いないですが、それよりももっと必要なのはヘルプドキュメントですよね。これがないと、どんな機能があって、どんな設定ができるのかが分かりませんから。
基本的な機能を使うだけなら何も読まなくても使えるのではないかと思ってはいるのですけども、機能が多いですし、特にカスタマイズしようと思うと、「できるのかどうか」・「できるなら、どう書けば良いのか」みたいな情報を調べる必要がありますから、ヘルプドキュメントは必要ですよね。

ほぼ最初に1回参照すれば終わる「セットアップ(設置)方法」ページを除くと、主なヘルプドキュメントは以下の3ページあります。

たった3ページなのに、この3ページに書かれている文字数を調べると、ラノベ文庫本2冊分以上あるのが不思議なんですが。(笑)
半角文字を無視して全角文字だけをカウントしても27万文字超あります。改行なしで詰めて原稿用紙に書いたら680枚分くらいです。半角文字も含めると、だいたい35万文字くらいあります。(なんで……?)
私が過去に書いた文庫本は1冊だけですが、これで文字数は10万文字くらいでしたからね……。たしか。いや、もしかしたら12万文字くらいあったかもしれませんが。(昔のことすぎて正確には覚えていないのですけども。^^;)

▼β版公開の時点でヘルプドキュメントも更新する方針に変えた

で、バージョンアップで機能が増える度に、このヘルプドキュメント群にも追記していく必要があります。
基本は追記だけなんですが、機能が増えた結果として設定画面の構成が変化した場合には、過去の説明用画像も差し替えが必要になるケースもあります。
これらの作業もなかなか大変なんですよね……。

従来は、正式版リリースに合わせてヘルプドキュメント群を一括更新していたのですが、それだと(作業量が多すぎて)めちゃくちゃ凄まじく面倒くさすぎて大変なので(^_^;)、Ver 3.9.0リリースの後からは、β版で搭載した機能であっても最初から本番のヘルプドキュメントに解説を加えておく方針にしました。それによって、毎回のβ版公開時にちょっとずつヘルプドキュメントを更新していけるので、正式版リリースの際に大量の更新作業をする手間が減らせるだろうということで(減らせるというか分散するだけですけども)。

ヘルプドキュメント内の所々には、その機能がどのバージョン以降で使えるのかを示すためにバージョン番号が記載してあります。
従来は「Ver 3.8.0以降」とか「Ver 3.7.0以降」のように最後の1桁は「0」だったのですけども、3.9.0以降に関しては、細かく「Ver 3.9.2以降」とか「Ver 3.9.5以降」とか書かれているのはそのため(=β版の時点で記載したから)です。
この方針に変えたおかげで、今回の Ver 4.0.0 リリース時点では、そこまで大変にはならずに済みました。

▼検索しやすいFAQができれば良いのだけど

ヘルプドキュメントが縦長の長大ページになるのは仕方がないとしても、FAQは「1件1ページ」の構成で検索性を高める方が便利な気がしてはいるのですよね。できれば、FAQはそういう構造にしたいと思っています。
(縦長の長大ページでも、一覧性が増すメリットはあると思っているのですが。あと、すべての項目が繋がっていると、求めていた情報に関連する隣接情報も目に入りやすいですし。)

てがろぐのFAQ・豆知識ページを、てがろぐ自体を使って生成すれば、

  • 現状のような「まとめて閲覧」もできるし、
  • 「1ネタ1ページで閲覧」もできるし、
  • 全文検索もできる

……ので望ましそうに思えるのですけども。
ただ、あのFAQを作るにはHTMLソースを自由に書けないとまず無理なので(できるかもしれませんけどもかなり大変そうに思えますので)、てがろぐで生成できるようにしようと思うと、まず、てがろぐ上に自由なHTMLソースをそのまま書ける機能を実装する必要があるんですよね……。

あと、「FAQのHomeページ」もどうにかして生成する必要がありますね。
FAQ用のHomeページというと「カテゴリ別にFAQタイトルが並ぶ」という形態が定番だし分かりやすいと思うので、そんな感じのHomeを自動生成できる機能があると望ましいのですが。

今回のVer 4.0.0では、新着投稿リストをカテゴリ別に出力する機能も追加されましたので、それを使ってスキンを作れば、「カテゴリ別にFAQタイトルが並ぶ」というHomeは作れそうに思います(※新着順に掲載される順序仕様を良しとすれば)。ただ、その方法だと、カテゴリを新たに追加したときには(スキンHTMLの)手動修正が必要になるので運用がちょっと面倒になる問題がありそうです。

「すべてのカテゴリについて、カテゴリ別に分けつつ、各カテゴリに属する投稿タイトルだけを並べる」みたいな自動生成機能があれば良いのですけどもね。「カテゴリ別タイトル掲載機能」というような。FAQ以外でも何か需要はあるでしょうかね? FAQにしか使えなさそうなら、かなりニッチな機能になってしまいますが。(^_^;)

あと、FAQの場合は新着順で並べるよりも自ら掲載順や掲載対象を選択できる方が望ましい気もします。ただ、そうなってくると、てがろぐの管理画面では対処できなさそうな気もしますけども。まあ、並べたい順に投稿日時を手動で修正しておく手はありますが。もしくは、「下げる」機能を併用して、「下げられていない投稿だけがリストアップされる」みたいな感じにすれば良いかもしれません。

欲しい機能(?)

ご要望を頂いている他に個人的に欲しいと思っているのは、だいたい開発放言のてがろぐカテゴリに書き散らしていますけども、直近で欲しいのは(※作るとは言っていません^^;)「掲示板モード」かな、と思います。てがろぐを、不特定多数が利用できる掲示板として使いたいな、と思うことがありまして。現状だと、IDを事前に割り振る必要があるので不特定多数を対象にはできませんし、どうしても不特定多数を対象にしたい場合はゲスト投稿用のIDを1つ用意しておいてそれを使ってもらうくらいしか方法がありませんから。

具体的な機能としては、

  • ➊ IDを持たない不特定多数でも投稿者名をその都度入力して投稿できる機能。
  • ➋ 本文以外の入力欄(名前欄、タイトル欄、URL欄、SNS欄など)を好きなだけいくつでも入力フォームに追加できる機能。
  • ➌ IDを持たない投稿者が、自らの投稿を削除するためのパスワードを設定しておける機能。
  • ➍ 投稿があるたびに投稿された内容を管理者へメールで送る機能。

とかですかね。
どれも大きめの機能追加になりますから、作ろうと思うと時間が掛かります。本腰を入れて計画しないとまずできませんけども。(^_^;)
ただ、欲しいのは欲しいんですけどもね。個人的に。

掲示板CGIは世の中に山ほどありますけども、今でもメンテナンスされているように見えるCGIとなると結構少ないですしね……。まあ、もう完全に完成されていて「メンテナンスが不要になっている」という可能性もありますけども。

上記の ➋ があると、自分だけで使う場合でも、本文とは別にタイトル入力欄を用意して、よりブログ的に使う方法も採れるようになるかな……という気もなんとなくしています(そうしたい需要があるかどうかはともかく)。
上記の ➍ があると、一言メッセージ送信フォームみたいなのをサイドに掲載する機能の実装にも流用できるでしょうね。

作りたい機能(?)

なんとなく作りたいと思っている機能としては、「埋め込み専用モード」があります。

うちのサイトもそうですけども、「最新の1件だけを別ページに埋め込む」という需要がそこそこありますよね。
今は、埋め込み専用のスキンを作って、それをSSIやPHP等で埋め込む、みたいな方法が必要です。
しかし、その「専用スキンを作る方法」だと、仕様上「Powered-by表記」の掲載が必須になります。それを避けられる方法としては、RSSフィードとして出力された1件分のデータをJavaScript等で読む方法がありますけども、どちらにせよちょっと面倒ですよね。

なので、「最新の1件だけを出力できる」という埋め込み前提の専用モードがあればいいかな、という気がしています。
?mode=embed みたいなパラメータで。
この場合、?mode=embed&cat=info みたいに、パラメータにカテゴリID等を加えれば、その条件に合致する投稿の中で最新の1件が出力されるような。

この場合の出力フォーマットは管理画面上で登録できるようにしても良いですし、?mode=embed&skin=umekomi みたいに直接スキンを指定できるようにしても良いかもしれません。スキンを使う場合は、外側スキンは無視して、内側スキンだけを使って1件だけ出力する感じになるでしょうかね。

上記のような感じの「埋め込み専用モード」があれば、他ページへの埋め込みが楽になりそうな気がします。
SSIでもPHPでもJavaScriptでも何でも好きな方法で埋め込める(or読み込める)でしょうし。

要望を受けている機能も

要望を受けている機能もいろいろ多々ありますので、需要の高さや作りやすさ等を勘案して加えていくつもりでいます。
一部だけを先に実装していて、残りの機能は先送りしている機能としては、

  • 個別鍵での鍵付き(パスワード保護)投稿機能
  • 新着投稿リストのオプション指定機能

……などがありますかね。

ご要望があればお気軽にお知らせ下さい。作れるとは限りませんが、考慮はします。
あと、ご要望を頂く際にはその用途も一緒に説明して頂けると、直接ご要望の機能を実装できない場合でも代替手段を提供できる可能性があります。できるだけ詳しめに教えて頂けると望みが叶う可能性を上げられるかもしれません。

まだ開発は継続する予定

というわけで、まだまだ「てがろぐ」の開発は継続するつもりで居ます。
需要がそこそこありそうな点もそうですし、自分自身が日常的に使っているという点もそうですが。
今のところ、まだ開発モチベーションは維持できていますので。^^;

Ver.4になったてがろぐもご愛用頂ければ幸いです。

今後もできるだけ3ヶ月に1回ペースでの正式版リリースができるような感じで開発を進められると良いな……と思っています。
β版は随時公開していきますので、よろしければ開発進捗状況報告サイトでチェックして頂ければ幸いです。ここでフォロー頂くと(てがろぐCGIの最新β版や正式版の公開時に)メールで連絡を受け取ることもできるほか、私の開発モチベーションが向上するメリットもあります。😇

あと、てがろぐベースで開発したスケジュールカレンダー表示CGI「さんごよみ」もぜひ一緒によろしくです!

2023年05月
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      

他の月

--- 当サイト内を検索 ---