フォームの enter key の振る舞いと制御

1時に寝て3時に起きて5時までだらだらしてて8時に起きた。季節の変化のせいかな?夜眠れない生活が普通になってきた。最近セブンイレブンのマスカット紅茶をよく飲んでいるのでカフェインの摂り過ぎなのかもしれない。

vuetify の v-form の enter key 無効化

あるフォーム画面でテキスト入力欄で enter key を押下すると xhr リクエストが送信されてしまう。これがフォームのデフォルトの振る舞いかどうか、私はフロントエンドに詳しくないからよくわからない。検索などはその方が便利なときもあるだろうからそういう振る舞いがあることは知っている。業務の重要な情報を誤って確定してしまってはいけないから、画面によっては禁止した方がよい状況もある。vuetify の v-form を使っている画面だとデフォルトで enter key を入力すると submit 処理が実行されてしまう。パラメーターに渡される event 情報からもマウスクリックとキー入力の見分けがつかない。

それぞれのコンポーネントの events をみると、v-form は inputsubmit しか対応していない。v-form の設定で直接 enter key 入力のイベント制御はできない。Binding Native Events to Components によると、そういった状況のために .native を使うと直接イベントをフックできるらしい。ここで v-text-field は keyup ではなく keydown のみを提供しているせいか keydown を次のように prevent してあげることでテキスト入力欄で enter key を押下しても submit 処理は呼ばれなくなった。但し、副作用として v-form の slots にあるすべてのコンポーネントの enter key の keydown イベントを prevent してしまう。

  <v-form
    @submit="submit"
    @keydown.native.enter.prevent
  >

vuetify の issue をみていると過去には無効だったものを有効化したようにもみえる。なにが正しい振る舞いなのかよくわからないし、どうやって制御するのが正しい方法なのかよくわからなかった。

gitlab を使う開発のお仕事

0時に寝て何度か起きて、なぜか寝坊して9時に起きた。おそらく休日以外で9時まで寝ていたことはこの日記を書き始めて初めてだと思う。

次のお仕事の意識合わせ

来月から新しい取引先のお仕事を手伝う。先方と業務内容の確認のための打ち合わせを行った。先方はパッケージベンダーになる。私の大先輩にあたる方々が働いている会社だし、当社が目指すパッケージベンダーとしてのお手本のような会社でもある。大いに学ぶところがある業務になるだろうと想定している。私はここ数年 web 業界で働いてきたせいか、やり取りをしていても勝手の違いを少し感じる。それは web 業界が緩過ぎるからだと思う。気を付けないと先方からみて失礼になってしまうかもしれない。契約や初期のオンボーディングも兼ねて10月31日から1週間ほど東京出張する予定になる。

またリポジトリに gitlab を使っている。課題管理や ci/cd も基本的には gitlab で行うことになる。私のもっている github のドメイン知識はまったく活かせないが、gitlab の機能を学ぶよい機会でもある。gitlab と聞くと私は一番先に Remote Manifesto を思い浮かべる。

  1. Hiring and working from all over the world (instead of from a central location).
  2. Flexible working hours (over set working hours).
  3. Writing down and recording knowledge (over verbal explanations).
  4. Written processes (over on-the-job training).
  5. Public sharing of information (over need-to-know access).
  6. Opening up documents for editing by anyone (over top-down control of documents).
  7. Asynchronous communication (over synchronous communication).
  8. The results of work (over the hours put in).
  9. Formal communication channels (over informal communication channels).

https://about.gitlab.com/company/culture/all-remote/guide/

私の考える課題管理とも相性がよく、時間よりも成果、書くことや非同期コミュニケーションの重要性、組織の透明性を簡潔に表現したマニフェストとなっている。うちの会社はまだ社員採用できる状況ではないが、社員を採用する時期になったらこういったマニフェスト的なものを自社でも作りたいと思う。そのときの最も参考になるものだと思う。

SECI モデルのワークショップに参加した

0時に寝て、2時、3時、5時に起きて7時に起きた。夜中何回も起きる。

データ移行スクリプト

あるテーブル間のデータ移行のために久しぶりに python のスクリプトを書いた。python の文法を忘れるぐらい最近は書かなくなってしまっていた。1時間ほど書いていると興がのってきてそれなりに書けた。書いていれば体が覚えているので自然に動く的な。dump データ (insert 文) から json 文字列を含むデータを移行しないといけなかった。json 文字列を1つのカラムの値としてパースするのが思ったより難しかった。とはいえ python だとこういう煩雑な文字列操作は得意なので1-2時間で実装して移行作業を完了できた。

SECI モデルのワークショップ

たまたま twitter でフォローされたアカウントのタイムラインでみかけた ゲームで体感!SECIモデル~チームビルディングの瞬間に迫る!~ に参加した。SECI モデルとは野中郁次郎氏と竹内弘高氏の論文で提唱された知識創造のフレームワークの1つ。私は実践知の本で知って、スクラム本でも紹介されていたのでよく覚えていた。

暗黙知と形式知がぐるぐるまわるんだよという頭だけで理解していて、違和感もなかったし、普通に理解していたつもりだった。SECI モデルを学ぶことを意識したワークショップに実際に参加してみると、知識で理解していた概念と実際に行動 (ワークショップを通してチームで学ぶ) を通して得たフィードバックのようなものがあって、参加前の私は SECI モデルを誤解していたことにも気付いた。単純に知識創造だけのことを言っているわけではなく、チームビルディングや人間関係も知識創造には影響を与えている。私が他人にあまり関心をもたない人間だから人間関係や多様性が知識創造にどういった影響を与えるかを軽視していたと思う。

このワークショップは有償なのもあるだろうけど、2時間で SECI モデルとチームビルディングを組み合わせた要点が学べるようによく練られたものになっていたと思う。チームビルディングの3要素として、目的・関係性・多様性をあげていた。SECI モデルは個人、チーム、組織、環境の集合の要素としてモデル化されていた。個人よりも大きい集合 (チーム、組織) の重要性を私は軽視していたから気付きが多かったという話し。SECI モデルで提唱されていることは、多寡はあっても開発者は普段の業務で普通にやっている。受講後に SECI モデルで実践していることをよりエンパワーメントする仕組みを課題管理もしくは課題管理システムの文脈でできないだろうかと考えたりもしていた。ふらっと参加したのに私にとって気付きが多かったのでこのワークショップを運営しているコミュニティのイベントに今後も継続的に参加してみようと思う。

備えあれば憂いなし

2時に寝て6時に起きた。眠り方がわからなくなってきた雰囲気。昨日に引き続き、淡々とリリース前の細かいバグ修正をしていた。フロントエンドの ux のよくないところを修正したりしていた。

m2 macbook air 購入

次のお仕事は東京出張もちょいちょい入る (自オフィスのデスクトップマシンで開発できない) ことからラップトップの開発マシンがあった方がよいなと気付いて M2 MacBook Air を購入した。2022年7月に販売開始されたそうなのでタイミングとしてはちょうどよかった。本当は macos である必要はない。linux が動くラップトップなら何でもよいのだけど、dell のラップトップをみても値段がそんなに安くない。数万円ぐらいの違いしか変わらないなら macbook にしようと思って決断した。1週間ほどで納品される。

いま macbook を使わなくなった理由の1つとしてバタフライキーボードが大きい。前職でも2台ほどキーボードのキー入力が一部受け付けなくなって交換してもらったりしていた。2016年モデルの macbook を持っているけど、もうバタフライキーボードを使いたくないという忌避感が強い。2019年からシザーキーボードが復活しているらしい。使ったことない他メーカーのラップトップに躊躇する理由もキーボードが気に入らないものだったらどうしようという不安がある。いまデスクトップマシンだから realforce の打鍵に慣れ親しんでしまい、キーボードの使い心地に敏感になっていると思う。

新しいお仕事、新しい挑戦、新しいマシン。気持ちを入れ替えて集中したい。

東京出張の準備

次のお仕事のキックオフのため、10月31日の週に1週間ほど東京出張しようと考えている。コロナ禍になってから約3年間ほとんど神戸を出ていない。大阪すら年に1-2回ぐらいしか行っていない。東京は約3年ぶり。新幹線やホテルの予約の仕方も忘れてしまった。せっかく行くので長い間、会っていない友だちや知人に挨拶できればと思う。

お仕事探しのふりかえり

2時に寝て7時に起きた。とくに可もなく不可もなく淡々とリリース前の開発の詰めや検証をしていた。大きな改修を先週末に終えていたので後始末的なタスクが主だった。

お仕事探し終了

いくつか選考して次のお仕事を決めた。8月からお仕事探しをしていた。いくつか求人プラットフォームのステータを更新し、途中まで選考が進んでいた会社には辞退メールを送った。昨年は1ヶ月ほどで次のお仕事をたまたまみつけたけど、今回は2ヶ月ぐらいかけて求職活動をしていた。探す期間が短いとどうしても妥協したり近視眼的な考えに陥ってしまいやすい。心に余裕があることの利点を考慮して2ヶ月ぐらいかけるのがちょうどよいのかもしれない。私は基本的に辞めると決めて関係者と調整してから次を探す人間なので転職活動に失敗すると無職になるリスクが高い。自分の会社に所属していると、最悪の場合、契約終了時に次のお仕事がなくても無職になるわけではない。この安心感が人生において重要なものだとわかるようにもなってきた。

今回は3つの経路を使ってお仕事探しをしていた。

  • 人脈
  • スカウト
  • エージェント

以前にも書いた が、私のような人間は普通の求職活動をしても、他者と比べて秀でたところがなく競争に勝つのが難しい。コミュニティやいくつかの会社で働いてきた人脈を駆使して、自分という人間を知っている人からお仕事をもらうしか生き残りの戦略はないのかもしれない。次のお仕事は課題管理を徹底的に実践して他社のお手伝いをする。うちの会社が今後ビジネスをやっていけるかどうかの分水嶺になるかもしれない。できるだけの準備をして臨む。

主に寝てた

2時に寝て8時に起きて、昼間はだらだらしてた。ここ最近は夜にあまり眠れてなかったので久しぶりによく寝た気がする。

web3 の信頼できる情報源

Web3を思い切りディスった上で褒めてみる を聞いた。キーワードとして技術動向はみておこうと昨年ぐらいから web3 関連の記事を読んだりコミュニティで議論したりはしている。最近はなかじまさとしさんの発言を全面的に信頼してみている。というのは開発者としても投資家としても成功をおさめた方なので信頼できる。

  • play2earn はすべてポンジスキーム
    • 入っていくお金より出ていくお金の方が少ない
    • 投資のようなスキームではない
    • トークンの価値を操作して一見出ていくお金を増えているようにみせることはできる
      • 先行者利益エコノミー
    • ネズミ講とまったく同じ
    • これを褒めるインフルエンサーは基本的にポジショントークか頭の悪い人たち
  • dao は株式会社を置き換えない
    • dao でやっていることの大半は安価な資金調達でしかない
      • ベンチャーキャピタルから資金調達するのは難しいが、ど素人から資金調達するのはべらぼーに簡単
      • 2-3年前の ico ブームと同じ、情報弱者からの搾取でしかない
    • もっとも dao らしいと言われる nouns dao ですら苦労している
      • 資金運用を多数決で決めるのはものすごく難しい
      • 賢い連中が揃ってないとうまくいかない
      • リーダーシップも必要となる
      • dao からお金がほしいためにアプローチしてくるメンバーもいる
      • 株式会社よりもきれいに運営できるとはまったく思えない
      • dao を運営するのはとても難しい
    • 非営利団体が寄付金を運営するには向いているかもしれない
  • メタバースと web3 は相性が悪い
    • 双方は独立したものである
    • メタバースのサービスはブロックチェーン上ではできない
      • web2 の技術で開発・運営されている
      • web3 アプリではまったくない
  • web3 がもたらす素晴らしい世界
    • スマートコントラクトに大きなポテンシャルはある
      • デプロイすれば未来永劫、勝手に動き続けてくれる
      • さまざまな開発者が作ったスマートコントラクトのアプリが協調してずっと動き続ける未来がくるはず
        • 人間が関与しないシステムが動き続ける仕組み
    • さまざまなスマートコントラクトが結びつく集合体やエコシステムに価値がある
      • 人手がかからないので中間業者が存在しない
      • クリエイターに大半のお金がまわる仕組みを実現できる
    • お金がまわるコストが極端に下がる、もしくは透明化されることの価値
      • apple store は30%の手数料をとっているが、スマートコントラクトなら2-3%という時代になるだろう
      • 中間業者が悪いことはできない

以前にも dao + nft を使って非営利団体で運用するのはよいのではないかとツィートされていた。非営利なコミュニティでお金の管理を透明化するところに私も関心をもっている。スマートコントラクトでさまざまな団体が低コスト且つ透明性をもったお金の管理ができるのであればそういう分野に挑戦する可能性はある。

バックオフィスの作業

1時に寝て7時に起きた。引き続き夜はあまり眠れない。とくにこれといったことをしていたわけではないけど、請求書を発行したり受け取った請求書の処理をしたりと溜まった雑務を捌いてた。lapras さん経由でバックエンドエンジニアのスカウトが届いた。ざっと募集要項をみたら選考を受ける程度にはよさそうにみえたけれでもこれ以上は増やさない。縁がなかった。

ストレッチ

今日の開脚幅は開始前156cmで、ストレッチ後159cmだった。先週に引き継いで数値が悪化していてよくなくなっているのかもしれない。大抵は右腰に張りがあるのだけど、今日は左腰に張りがあった。あとはふくらはぎに張りがあったかな。夜あまり眠れていないこと以外は体調は悪くない。とはいえ、夜眠れていないのがよくないのかもしれない。

上場時の有価証券報告書

たまたまみかけたので プログリット上場!ダウンラウンドの原因はここか!一の部かなり言いたい放題! を聞いてみた。k さんの経歴は公認会計士でニューヨークの4大会計事務所の1つで働いた後、帰国してベンチャーキャピタルで働いて、いまスタートアップを起業している。ベンチャー起業の財務諸表は見慣れているということなんだと思う。私も自分の会社で起こったことと財務諸表を見比べて勉強しつつ、他社の財務諸表を読んで勉強することもある。この放送はプレミアム向けなのでお金を払わないと聞けないのかな?会社をやっていると、こういった有償の情報ソースを経費にしやすい。単発でもサブスクリプションでも気軽に聞ける。

以前にも ある一般社団法人の会計監査 の記事を社内コミュニティで議論したりした。いま社内コミュニティも少しずつ育ってきて社外メンバーが6人いる。少数の閉じたコミュニティの方が気軽に発言できて濃いやり取りができておもしろかったりもする。

半稼働日

0時に寝て2時、3時と起きて5時に起きた。最近は夜に寝ているのか起きているのか、自分で分からなくなってきた。7時過ぎにはオフィスに着いてた。

サービス残業

今日は非稼働日なんだけど、半日ぐらいは開発していた。大掛かりなリファクタリングをするので今日中に主な修正をテスト環境にデプロイしておきたかった。スプリントが水曜日始まりの1週間なので運用に影響がありそうな大掛かりな機能追加やリファクタリングは金曜日中にはテスト環境へデプロイするように私はしている。そうすると、月・火で他のメンバーがテスト環境を触るのでリグレッションがあればバグをみつけやすくなる。さらにお小言を書くと、他の開発メンバーはこういう感覚がまったくない。大きな変更を伴うコミットを火曜日に普通にしようとする。「明日リリースですが、これをマージしてしまって検証できますか?」というツッコミを私が過去に何度もしている。大半は無理だと次スプリントへ持ち越しになる。残業しない開発者はタスクがスプリントをまたぐことになるので見た目以上のロスがある。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。いつも9時から雑談しているけれど、今日はお互いに歯医者があって15時に変更した。直近のお仕事探しの近況から情報共有をした。いまのところ、3社の選考が進んでいて、私の中の優先順位も明確になっていて、あとは実際に契約を締結するまでもっていけるか。ほんの2週間前までお仕事探しの書類審査すら通らない状況だった。最悪のケースとして11月からしばらくお休みすることも想定していた。現時点では3社もあればどこかに決まるだろうという楽観的な展望をもっている。

ある案件で react から next.js への移行の目的が seo 対策だという話しをしてたら、google のクローラーは spa アプリケーションも扱えるけれど、twitter, facebook のクローラーが全然ダメらしくて sns で記事をシェアするときにプレビューをきれいにみせたいといったときに課題があったりするらしい。spa の後にまた ssr (server-side rendering) やるというのは本当にあほみたいなことをやっていると私からは思えてしまう。

あと私はもうスクラムの議論には関心がなくなってしまった。昨日の日記にも少し書いた。いまは組織を変えられるかどうかに関心をもっていて、よいプロダクトにはよい開発文化が必要だ。そこで「よい開発文化」とはなにかを体系化しないといけない。そのうちの1つとして書くことをこれまで訴求してきた。その後もずっと考え続けてきて私の中では次の3本柱でいこうと決めた。

  • 書くこと
  • ワークフロー改善
  • 実践知リーダーシップ

いまはまだキーワードだけでその意図する具体的な内容は私の頭の中にしかない。この3つを軸に私のスキルと経験を詰め込んだ製品開発をしていく。

自分で自分を信用しない

0時に寝て5時に起きた。朝から2時間ほどドラクエタクトしてた。

ふりかえりのフィードバック

先日 5日以上かけて非開発者向けのドキュメント を書き終えた。労力をかけてわかりやすいように書いたせいか、評判がよいという噂があり、ふりかえりのときにも先方の社内で共有されていて、他チームでも読まれているといったコメントをいただいた。それ自体は嬉しいことだ。一方で先方の社内に閉じている議論なのでドキュメントを書いた私には一切フィードバックはない。同じチームのメンバーからもほとんどない。

私はあまり自分自身を信用しない人間で、私が作った成果物はよいものだと考えていない。とくに初期のバージョンはすべてそう。誤り・勘違い・怠惰・抜け・漏れがいくつもあって3世代ぐらいのアップデートをこなさない限り、運用に耐えるものにはならないという考え方をする。書き終えたばかりのドキュメントを褒められても、自分の中ではそれはおかしいと思ってしまう。あんなものがよいはずがない。もっとよくするための取り組みがあるはずで、そのヒントを他者に期待しているところがある。単純に褒められるよりも「どこがわかりやすかった」「どこがわかりにくかった」「ここをもうちょっと詳しく」とか、そういったインタラクティブな議論を他者に求める傾向がある。それは自分自身が欠陥だらけだから。今回はふわっとした手応えで業務を終えることになる。

開発方法論を議論するのに飽きた

エンジニアリングマネージャーのしごと 読んでみたけど、質問ある?(答えられるとは言っていない に参加した。ちゃんとしたイベントじゃなくて、書籍を読んだ感想を discord で気軽に雑談するようなイベントだった。雑談と言っても話していたのは主催者のみで、他のメンバーはチャットにコメントして、それを主催者がみて話題として取り上げるといった進め方だった。悪いイベントではないのだけど、コミュニティの内輪感が強くて初めての人が参加するようなところではないなと思えた。

この1年、スクラムを実践しながらずっと開発方法論やマネジメント/リーダーシップについて考えてきた。考え抜いた (と言ってもたった1年だけど) 結論として開発方法論そのものはあまり重要ではないと結論づけた。重要なのは、自分たちの開発にとって障害や課題を認識したときに改善していけるか。そんなの当たり前だと思うかもしれない。改善するにあたって組織も含めて変えられるかというところが最も重要だと気付いた。スクラムにおいても、簡単な問題はすぐ解決しようとするのに、複雑で難しい問題はなぜ解決への試みすらやらないのだろう?とずっと不思議に思っていた。それは既存の組織や制度のなにかを変えないといけないとき、それらを改善の対象とみなすか・みなさないかという視点が人によって大きく異なることに気付いた。多くの人はそこまでやろうとしない。それは越権行為かもしれないし、思い付きで組織の決めごとを変えられても困るかもしれない。一方で私は頭がおかしくて組織や制度そのものも変えようとする。まず組織を変えようとするかどうかが最初の分水嶺になる。そして、実際に組織が変われるかという最大の課題もある。開発のためだけに組織を変えてくれと経営者にお願いして「わかった」という経営者は稀かもしれない。組織にも歴史や文化があり、会社には開発以外の様々な業務もある。大規模スクラムが提唱されるようになったのは組織を変えていくアプローチがスクラムには重要になってくるという証左かもしれない。

組織さえ変えられるのであれば開発はいくらでもよくなる可能性がある。これは小さい組織や若い組織にとってはとくに有利な点と言えるだろう。開発方法論に何を採用するか、初期のチームがうまく開発できないといったことは些事でしかない。自分たちの開発をより良くすることを本当にやろうとしているかどうかが重要だ。そのことに気付いてからゾンビスクラムをみかけたときも、これは組織のこういった課題から派生していると深堀りするようになってきた。

url エンコーディングと uri の仕様

1時に寝ようとして、寝てたか起きてたかわからない時間を過ごして7時に起きた。

WebClient と query string のエンコーディング

以前にも WebClient の基本 について少し書いた。data={"x": 1, "y": 2} のような json 文字列を query string でリクエストしようとしたときに少しはまったので書いておく。java 標準ライブラリの URLEncoder を使ってエンコードするとスペースが + になる。これは html の仕様として正しいが、uri の仕様としては不正になる。そのため +%20 に置き換える必要がある。

private String encode(String data) throws UnsupportedEncodingException {
    // NOTE: the URI doesn't allow '+' character
    return URLEncoder.encode(data, StandardCharsets.UTF_8).replace("+", "%20");
}

このロジックで {"x": 1, "y": 2} を url エンコードすると次の文字列になる。

%7B%22x%22%3A%201%2C%20%22y%22%3A%202%7D

あらかじめ url エンコーディングした文字列を渡すと、今度は WebClient が %%25 にさらにエンコーディングしてしまう。Spring WebClient Requests with Parameters 6.Encoding Mode によると、次の4つのエンコーディングモードをカスタマイズできる。デフォルトは TEMPLATE_AND_VALUES らしい。

  • TEMPLATE_AND_VALUES: Pre-encode the URI template and strictly encode URI variables when expanded
  • VALUES_ONLY: Do not encode the URI template, but strictly encode URI variables after expanding them into the template
  • URI_COMPONENTS: Encode URI component value after expending URI variables
  • NONE: No encoding will be applied

もとの url エンコード済みの文字列が次のようなものになってしまう。

%257B%2522x%2522%253A%25...

既存の実装をあまり変えたくもなくてやや力技で実装した。局所的な変更だからまぁいっか。

webClient.get().uri(uriBuilder -> {
  var uriObj = uriBuilder.path(getControllerBasePath() + path).queryParams(query).build(pathParams);
  if (encodedData != null) {
      var uri = uriObj.toString();
      var connector = uri.contains("?") ? "&" : "?";
      uriObj = URI.create(String.format("%s%sdata=%s", uri, connector, encodedData));
  }
  return uriObj;
}).retrieve()

よいエラーメッセージ、わるいエラーメッセージ

タイトルに惹かれてちょっと期待外れ。art というと日本人は芸術と高度なものを期待しがちだけど、the art of だと技術の体系といった意味合いもあるのでちょとしたノウハウを解説する技術ブログのようなものでも誤っていない。

ユーザー体験をよくするためのエラーメッセージのコツとして次の3つを提案している。

  • 何が起きたのか、なぜ起きたのかを説明する
  • 次のステップを提案する
  • 適切なトーンで書く

この3つの具体例としてどのようなものかを説明している。私にとってはそう目新しいものではないが、エラーメッセージにトーンという概念はなかったので最近の流行りなのかなと思った。

そして1年が経った

2時に寝て7時に起きた。寝付けなくてタイムラインを眺めてた。1日を淡々と開発して淡々と業務を終えた。

日記を1年書き続けた

最初に日記を書いたのが 2021-09-26 なのでもう1年経ったことになる。時間というのは過ぎてみればあっという間に感じる。歳を取るごとに人生の生きている時間が長くなって相対的に1年の時間が短くなるという論理的な説明を私は気に入っている。私の記憶では1年も継続して日記を書き続けられたことは過去に1度もない。はてなブログを見返すと、もっとも書いた年でも65日だった。もちろん過去の自分は本気で毎日書こうと思っていなかった。そして、それ以上になんのために書き続けるかという動機もなかった。いま独りでお仕事するようになって「書くこと」の重要性に気付いたことは過去にも書いた。

一方で私は平均的な開発者よりも遥かに多くの文章を、日々の業務で書いている。それは課題管理システムに様々なことを記録しているし、チャットでやり取りすることも多いし、1日の半分以上はプログラムを書いている。嗜む程度に sns に投稿したりもする。これだけ書いていて、さらに日記も書くのだから書くスキルが相当に向上している。言い換えれば、毎日日記を書くのが大した労力に感じないぐらいの実務力が上がっているとも言える。日記を書くのは、課題管理システムに日々の積み重ねを書くのとはまた違った様子が伺える。それは1年も書いてみるとその内容から明らかになってくる。人間はわりと自分のことすら分からない。日記にはそのときでしか書けない雑感がある。それはおそらく自分で自分を知る手掛かりになる。

当初の動機づけは あんちぽさんの日記 に影響を受けている。あんちぽさんは20年も日記を書き続けている。どのぐらい続くのかわからないが、5年、10年と続けられるよう、私も書くスキルを磨いていこうと思う。