Posts for: #2021/11

66日目

#life  #writing 

23時に寝て3時過ぎに起きて作業しようと思ったものの、やっぱりそのまま寝てしまって7時に起きた。前々日にあまり寝てなかったせいか、睡眠不足を解消したとポジティブに考えとく。

習慣化のための平均66日

前に GIG MINDSET ギグ・マインドセット を読んだときにロンドン大学が行った研究で習慣になるには平均して66日かかるというのをみかけた。「平均して」というのが曖昧なところで、直観的に理解できるけど、対象の難易度によって習慣化に要する日数が異なる。簡単なことはすぐ習慣化できるし、難しいことには時間がかかる。それらをいくつも試してみて平均したら66日だったという話し。66日仮説 でも言及されているようにこの手の研究はあまり鵜呑みにするのもよくない。とはいえ、何らかの基準や目安があること自体は悪いことではないので一般論として参考にするのはよいと私は考えている。日記を書くというのは比較的簡単なことだと私は捉えるが、66日続いたので習慣と化したとみなしていいだろう。

書くこと

日記に関連して「書くこと」そのものを研究対象としている。自分でも日記を書き続けて何が起こるのかを理解するために実践しているという意図もある。

日記だけではなく、私は業務の過程で普通の開発者より、平均的な文章量よりも大量に書く。課題管理システムに私以上にコメントを書く開発者を、この10年で1人もみたことがない。私以上に課題管理システムを使いこなす開発者もこの10年みたことがない。課題管理システムの使い方や応用をメンバーにアドバイスするし、メンバーも私の使い方をみて真似してくれることもあった。これまでそういった行動は無意識にやっていたことだけど、それを意識化して形式知として体系化したいという狙いもある。

書くことは メタ認知を活用して学びのスキルを磨く 手法の1つとして優れていると私は考えている。これを開発者にとって日常的な課題管理 (システム) に取り入れられないかというのが、私の持論であり今後の研究課題である。たまたま、はらさんとそういった話題で話す機会があり、共感してもらえて嬉しかった。

辞めるときの余裕

#career  #event 

2時半に寝て6時半に起きた。なぜか眠れなくて鬼滅の刃をみてた。本当は夜に bizpy の資料作りをしようと思っていたけど、前日にあまり寝てなかったせいかバテてそのまま寝てしまった。

お仕事の辞め方

たまたまお手伝いしているところである開発メンバーが今月いっぱいで辞めますという連絡があった。その方は今日お休みだったので明日で辞めますみたいな急な連絡となった。もちろん上司や関係者には前々から話しは伝わっていて、引き止めや調整をしていたのだろうけど、チームとして働くにおいてメンバーはショックを受けるというか驚くというのが普通の感覚だろう。私も少なからず組織を退職してきた。私の場合、有給休暇が余っていたので辞めると言い出すのは実際に辞める3ヶ月ぐらい前で、有給消化が1ヶ月、引き継ぎに1ヶ月、引き止めや調整に2週間、2週間ぐらいはバッファみたいな感じで辞めてきた気がする。組織の規模によるけど、大きい組織は順番に引き止めの打ち合わせがくるので時間がかかる。組織にもよるけど、私の場合は3-4ぐらい、上長、課長、部長、その上の偉い人みたいな感じか。少なくともメンバーが退職を知ってから1ヶ月以内に辞めるということはない。私は過程の記録が課題管理システムに残っているし、ドキュメントも普段からそこそこ書く方なので辞めるときにドタバタすることはほぼない。ドキュメントなくても課題管理システムにやったことはすべて残ってますからと説明できる。上長からも引き継ぎに困るという心配をされたこともない。

辞め方というのはその人の信義を表すように私は思っていて、どういう背景や事情があるにしろ、ひどい辞め方をするのは本人にとって百害あって一利なしだと思う。余裕のない辞め方というのはあまり推奨しない。

忘年会

【初参加大歓迎】三宮.dev＆bizpy 合同忘年会 の日程を12月10日に決定した。オミクロン株の不安などが出てきたところだけど、水際対策をがんばっているのでまだ大丈夫かなといましかできない飲み会をこのまま行うことにする。言うても参加してくれるメンバーは限定的なのでいつも人たちで労をねぎらうみたいな飲み会になりそう。

slack ペイロードの response_url にはまった

#bizpy 

1時に寝て8時に起きた。昨日は喋り倒して疲れてよく眠れた。午前中は溜まった日記を書き殴って、お仕事でやっているカスタム github actions で気になったコードを修正して、午後から bizpy の勉強会の準備を始めた。なんか気乗りせずにだらだらやって最終的には出来上がった。たいていだらだらやるときは頭の中ではもう出来上がってて集中したら2-3時間でできるのを脳が把握していて、まだ時間に余裕があるから怠けるみたいなときがある。そういうときは作業やめて散歩に出掛けるようにしている。

bizpy 勉強会の資料作り

次の Python で Slack のインテグレーションをやってみる勉強会 #3 のサンプルコードの実装をしていた。内容はだいたい次の通り。あとは資料をまとめるだけ。

  • slash command の設定と実装
  • ephemeral メッセージ (本人だけみえるメッセージ) の実装
  • block kit でモーダルダイアログに入力した情報を使ってチャットに書き込む

たまたまモーダルダイアログを取り上げただけなんだけど、モーダルダイアログを submit したときにチャットに書き込むのは、そのままではできなくて、なんらかの特別な処理が必要になって、そこにはまってた。response_url の扱いはわりとややこしいみたい。

まる一日喋り続けた日

#life  #event  #writing 

0時に寝て6時半に起きた。

ストレッチ

先週に引き続き、今週もお仕事でバテてストレッチは2日/週とあまりできなかった。ウォーキングもほとんどできなかった。とはいえ、先週の土日に観光案内でいつもよりかなり歩いたのでその休息と考えればそれほど悲観的にならなくてもよいかもしれない。ウォーキングしなかった背景は寒くなってきて21時頃に帰ってきて、また外に出掛けるのが億劫になってしまった。お仕事を早めに切り上げて早めに帰って来た方がよいかもしれない。

今日の開脚幅は開始前168cmで、ストレッチ後170.5cmだった。また170cmを超えるようになったのでよいサイクルに入ってきた。2週間に渡った中殿筋の張りはおさまった気がする。代わりに腰の筋肉に張りがあって、トレーナーさんも念入りにそこをストレッチしてくれた。生活していると、そのときどきで調子の悪い箇所は移動していて、ストレッチするとそのことに気付くので体調管理を意識する意図でもストレッチは役に立っている。

もくもく会

【三宮.dev】もくもく会 に参加した。今回はオフラインのもくもく会だった。私は bizpy の勉強会の資料作成の準備をしていた。ここ数回は主催者と私の2人だけしかオフラインに来ないといったことが多かったのだけど、今回は8人も参加していて、その8人中5人が勉強会コミュニティに主催者だったりしてちょっとおもしろかった。

コミュニティの主催者は、コミュニティ運営の苦労がわかるから他のコミュニティのよき参加者になり得る。私は 三宮.dev の運営には関わっていないが、コミュニティを盛り上げることに寄与する振る舞いはしていて、それは自分のコミュニティでもこういったやり取りが増えるといいなという願望を他のコミュニティで参加者としてやっていたりする。今回のオフラインの参加者が多かったのも、他の勉強会コミュニティでもオフラインでやりたいよねと思う人たちが集ったのではないかとか考えたりしていた。

ぷち飲み会

終わってからわたなべさんと立ち飲みに行ってきた。最近あまり行ってない はんなりPythonの会 の勉強会で (オンラインで) なんどか話したことがある方で、ずっと京都に住んでいると思っていた方がめっちゃご近所さんだった。わたなべさんは私より1つ学年が上で、世代における価値観に共感するところは多く、自身もマイクロ法人を営んでいた。研究者としてキャリアを積み重ねてこられて昨年、独立したようだ。はんなりPythonの会の運営にも最近入ったそうで、ついでというわけではないが、話していて気が合うなと思ったので bizpy の運営に入ってくれません？と尋ねたら快く了承してくれた。

bizpy の最大の懸念は運営が私1人で、私がお仕事で忙しくなったら休業してしまうという問題があった。なかなか勉強会のコミュニティの運営をできそうなメンバー (スキル、価値観、時間的余裕) をみつけるのは難しいので了承してくれてとても嬉しかった。わたなべさんは博士で研究者のキャリアをもっていて、いまは機械学習などに取り組んでいるのかな？私のキャリアとは全く重なりがないのでお互いに学ぶところがあってよい関係を築けるのではないかと思う。ビジネスパーソン向け機械学習入門みたいな勉強会をしてもよいと思う。

リーンキャンバスレビュー (後半)

前回 の続き。残りの半分を進めるのかなと考えていたけど、前回のおさらいから始めて、私の意図するプロダクトの価値やサービスの特徴の話しをしていたら、このサービスはすぐに顧客に価値が伝わるものでもなければ、急成長するようなビジネスでもないということが伝わって、リーンキャンバスをやる意味はあまりないねという話しで後半戦をやらずに終わったw。どうも新規事業=急成長やスケールするビジネスという考えでリーンキャンバスを持ち出したところがあって、私は最初からそんなことは一言も言ってないし、私が作った資料にもそういった懸念や展望は書いてあったんだけど、リーンキャンバスを通して話しているうちにその意図を理解してもらえたといった様子だった。

そういう意味でリーンキャンバスは急成長やスケールするビジネスを取り扱うときに投資家や顧客にわかりやすく訴求するためのフレームワークと言えるのかもしれない。仮にビジネスがうまくいったとしても、合同会社は投資を受けるのが難しいのでそのときは株式会社を別途作ってやるのかなぁみたいな、取らぬ狸の皮算用みたいな話も知った。

朝から晩まで多忙な一日

#morning activity  #book  #github 

0時に寝て5時に起きた。昨日 slack で質問していた内容に5時頃に返信があるのをたまたまみかけた。この時間に起きているんだと思って返信にコメントしてたら別のメンバーからもコメントが書き込まれて、早起きは三文の得みたいな感じで朝5時から slack でやり取りしてた。いま私はだいたい8時から始業している。開発チームの半分ぐらいのメンバーはそのぐらいから始業しているのが課題管理システムや git のコミットログからわかる。このチームは朝早い人たちが多いなと感心した。

朝活: アジャイル開発とスクラム 第2版

2021-11-26 AM 6 金曜朝6時開催のもくもく会 で第6章と第7章を読んだ。第2部は企業において実際にスクラムを導入していったときの四方山話が出てくる。私はあまり他社の事例に興味はないが、対談の過程で本質的に大事なことや難しいことなどがあぶり出されることもあるので、実務を通しての話題も参考になる場合があることは理解できる。大半の事例は実業務で使われているという結論がわかるだけでも十分だと思う。とくに大企業は様々な厳しい制約や要件の中で採用していると推測されるので、それだけで大きなメッセージをもつ。斜め読みでざっと読み進めながら興味のある話題があれば精読するといった程度で読んでた。

大企業あるあるな話しでスクラムイベントを通してお互いの距離感が縮まってうまくいったといった内容があった。開発者からすると距離感の遠近に関係なく、必要なら適切な相手を探し出してコミュニケーションを取るのが普通だけど、みんながみんなそうではないだろうし、(同じ会社の社員でも)よく知らない人とは話さないといった考え方をもつ人もいるだろう。ある人はこれを単純接触効果で説明していたけど、業務ではなく人間の側面からみてスクラムイベントが多いことにも意義があるのかもしれない。

顧問さんと雑談

隔週で打ち合わせをしている。最近はお手伝いのお仕事が忙しいので今回は雑談になってしまったが、近況としてリーンキャンバス、スクラム実践の話題などを話していた。わりと盛り上がって1時間で切り上げるつもりが1時間半に伸びてしまって、別のお仕事の時間を圧迫したけど、それはそれで意義のある雑談になったので収穫はあった。

ある組織で新規事業を行う上で AARRR (あー) モデル をすごく重視しているといった話題が出た。バケツみたいなイメージがあって、そこに現実の数字を当てはめていってプロジェクト/プロダクトの改善やふりかえりなどに活かしているという。サービスのグロースに責任をもつ人には重要な概念だという。うちのプロダクトはグロースしなくてもよいけど、なんらかのフレームワークに当てはめて抜け・漏れがないかをチェックすることにも使えるかもしれない。世の中でよく使われているフレームワークを調査しておいて損はないと思う。私はビジネスに全く疎いのでリーンキャンバスを通じて、AARRR モデルの話題になって、それがどういった用途で使われているかというお話しは興味深かった。

具体的には AARRR モデルの他に、スクラムの話題からは野中郁次郎氏のオリジナルの論文、大規模アジャイルの方法論などが盛り上がっていくつかキーワードが出た。そういった雑談の中で感性に従って気になったことを深堀りしていくとおもしろい調査や知見になったりすることを経験的に実感しつつある。今後もそういう機会や内容を大事にしていきたい。

カスタム GitHub Actions の開発

先日 調査していたものをベースに、普通にやる方法と カスタム GitHub Actions の compoiste action で実装する場合の検討資料などを作って、カスタム GitHub Actions を実装してよいといった許可をもらった。企業における唯一の懸念は (原則) public リポジトリで運用するところで、CI のような処理に社外秘は含まれないが、public そのものに審査や承認を必要とするような組織では腰が重くなるようなこともあるかもしれない。ロードマップにも private リポジトリでカスタム GitHub Actoins を動かせるようにしようという課題は作成されている。

コーディングスタイルの共通化

#java  #ide 

1時半に寝て6時に起きた

ソースコードのフォーマッター

go 言語の gofmt が成功をおさめたことからどんなプログラミング言語でもコーディングスタイルはツールで自動整形するのがよいという雰囲気が醸成され、とくに業務の開発においては統一すべしというルールを設けている組織が多いと思う。java はこの領域では後塵を拝していると言ってよいと思う。歴史的に java の言語仕様と ide は相性がよかったため、ide がコーディングスタイルを自動整形していた結果、ide ごとに互換性のない異なるコーディングスタイルが使われるようになってしまった。私がアリエルで開発していた頃、開発者はみんな eclipse しか使ってなかったので問題にならなかった。しかし、いまや私が知っている ide だけでも次のものがある。

この問題を解決するツールとして最もメジャーなのは google-java-format で、当初はこのツールを導入しようと考えていた。しかし、開発チームのテックリードから google-java-format のコーディングスタイルはひどい、一番優れているのは intellij idea だというお気持ちを表明された。導入を止めろと言われたわけではないが、チームに入ったばかりの私はテックリードのお気持ちに忖度して google-java-format の導入を断念した。代わりに intellij idea のデフォルトフォーマットをどうやって他の ide を共有するかを調べたところ、Manage code style on a directory level with EditorConfig で EditorConfig の設定 (.editorconfig) を intellij idea で再利用できることがわかった。

うちの開発チームのメンバーは intellij idea と vscode しか使っていないため、現状はこれで解決できるように思えた。intellij idea にはデフォルトで EditorConfig プラグインがバンドルされていて有効になっている。リポジトリのルートディレクトリに .editorconfig があれば自動的にそれを読み込んでくれる。そこで intellij idea のデフォルト設定を .editorconfig 形式でエクスポートして、それをリポジトリのルートディレクトリに配置することでコーディングスタイルのフォーマッターを共通化できた。

eLTAX 触ってみた

#scrum  #tax  #eltax 

0時半に寝て6時半に起きた。水曜日は朝活の日だったけど、申し込み忘れてカレンダーに入ってなかったから忘れてた。カレンダーの予定に従って生活していることがわかる。

ふりかえり

今日はお仕事でスクラムイベントのレトロスペクティブがあった。最近は日本語でそのまま「ふりかえり」と呼ぶみたいやね。他の用語が英語なのであわせて英語で読んでたけど、ふりかえりの方が日本人的にはしっくりくるのでそれでいいと思う。

開発の情報共有のやり取りが活発になったという意見が出た。私は11月から働き始めてまだ3週間ほどなので以前がどうだったのかわからない。2週間前に本格的にスクラム開発に移行して、POや開発者のリーダーが新任したり、開発者に新規メンバー (私のこと) が追加したりと、いろんな状況が変わっている。なにか特別なことをしたというわけではないけど、自然にコミュニケーションがよい方に改善されているなら全体としてよい傾向に思える。私はまだ業務のことが全くわからないのでインフラやテストなどの非機能要件のタスクをやっているだけ。開発者からみて負債というほど大きなものではないが、やった方がよい技術的な残タスクのようなものを私がどんどん fix しているので開発環境がよくなっている気がするといったコメントを名指しでいただいた。スクラムマスターによると、ふりかえりでは、個人名で問題を指摘するのはよくないが、個人名で感謝を伝えるのはよいという。なので、よいことには個人名が前面に出る。褒められて悪い気がする人はそうそういないので、このプラクティスはチームの雰囲気をよくすることに寄与するのだろうと思えた。

続: 年末調整と住民税の納付

昨日 の続き。eLTAX のソフト版をダウンロードして年末調整の給与支払報告書の申請、住民税の特別徴収の納付も行った。アプリケーションの操作方法と手続きのドキュメントは懇切丁寧な内容なので、アプリケーションそのものの使い勝手はいまいちだけど、とくに手続きに迷うこともなく、順番に操作していけば問題なく申請や納付を完了できた。この2つの手続きは、昨年は紙で申請したり納付したりしていたのが、今年は電子申告になったのでちょっとクラスチェンジしたような感覚で気分がよかった。定期的な行政手続きを毎年やりながら少しずつやり方を洗練させていったり、異なる手続きに挑戦してみたり、制度の仕組みを理解したり、そういう少しずつ改善して学びを深めていくことそのものに幸せ感がある。人に依るんだろうけど、わりと私はマイクロ法人の行政手続きを楽しんでいる。

スクラムの起源

#tax  #book  #eltax 

5時に寝て7時半に起きた。前週末は遊んでたので夜はいろいろ作業してた。朝起きる習慣がついてきたので何時に寝ても起きれる感じになってきた。うまく体調管理もできている。

年末調整と住民税の納付

年末調整は1月末まで、住民税の特別徴収は納付の特例を使うと6-11月の6ヶ月分を12月10日までに納める。年末調整も11月の給与を確定したら調整額を算出して12月の給与に反映する。必要な情報を入力したら会計システム (freee) で自動算出してくれて書類も一通り作ってくれるので難しくない。ここで出力される給与支払報告書を市役所と税務署のそれぞれに申請する。市役所向けの手続きは eLTAX で行い、税務署向けの手続きは e-Tax で行う。先日 Windows マシンを購入 したので、今回は eLTAX の DL 版で完全な手続きができるはず。ただし、e-Tax も eLTAX も祝日・日曜日は利用できないのでやろうと思ったものの、今日は祝日だからできなかった。

住民税の特別徴収の納付も今回が初めての試み。企業が社員に代わり住民税を納付するのが原則であり、これを特別徴収と呼ぶ。昨年は特別徴収への切り替え申請をしないといけないのを私が知らなくて手続きが遅れた結果、個人宛に届いた納付書でそのまま支払いした。納付自体はそれでも問題はない。おそらく徴税側からみたら源泉徴収して企業の担当者が納付した方が誤りがなく確実でサポートコストを削減できるという狙いなんだろうと推測する。住民税の納付も eLTAX でできるようなので後日挑戦してみる。

アジャイル開発とスクラム 第2版 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント

4日前から読み進めていて、第1部アジャイル開発とは何か、スクラムとは何か (第1章から第5章) を読み終えた。

冒頭の序論を読んでいて、スクラムは 1980 年代の日本の製造業の (革新的な) 製品開発スタイルの論文がオリジナルだというのを知った。ソフトウェア開発の文脈だと、米国から輸入した方法論のようにみえるが、もとは日本で編み出された方法論だったという。1986年に書かれたハーバード・ビジネス・レビューに投稿された論文がオリジナルらしい。

前に スクラムガイド2020 を一通り読んでいたので、スクラムについての内容はだいたい理解できた。補足でよかったのは、スクラムガイド 2017 から 2020 で改訂された内容やその背景や意図などがコラムで紹介されていた。それらを知ることで、よりスクラムで陥りやすい失敗や誤解されがちなところを理解できた。たとえば「開発チーム」という用語から「開発者」に改められた。スクラムチームの中に別のチームがあるようにみえ、プロダクトオーナー vs 開発チームのような対立構造にならないよう、チームはスクラムチームという1つしかないという意図だという。そして、開発チームの自己組織化 (Self-organized) というキーワードが、スクラムチームの自己管理型 (Self-managed) へといったように、主体である開発チームだけ自律的且つ協働するように読めたのを、スクラムチームという1つのチームしかないと強調されている。

コラム: 2020 スクラムガイド改訂とスクラムの3つの罠
  • スクラムが形式的、儀式的になってしまっている
    • 目的を理解せずにハウツーをなぞるだけのチームが増えたので抽象的な表現に変更した
    • 例) デイリースクラムがただの報告するだけになっている
      • デイリースクラムの目的は状況にあわせた再計画であるため、形式的な報告ではいけない
  • プロダクトオーナー vs 開発チームの構図に陥ってしまっている
    • チーム内の分断をなくし、ワンチームになることが強調されている
    • 開発チームから開発者へ、チームはスクラムチームが唯一
    • プロダクトオーナー vs 開発者が対立構図になることが多かった
      • 「開発チームの自己組織化」から「スクラムチームの自己管理」へ
      • スクラムは役割を超えて協力していくことが欠かせない
        • 問題 vs 私たち (スクラムチーム) という構図を引き出すことが重要
  • スクラムマスターがスクラム警察もしくは雑用係になってしまっている
    • スクラムマスターが「サーバントリーダー」とされていたが、単にサーバントになってしまうことがあった
    • スクラムマスターはプロダクトの成果や組織の目標にコミットメントしないといけない
      • ただスクラムルールを守らせたり、会議の司会役をするだけではない
    • 「真のリーダー」としての資質とプロダクトの成果や組織の目標にコミットメントしていくための熱量を重視して専任していく必要がある

これらのコラムを読むと、私が傍からみていたスクラムは本来の意図したスクラムの開発方法論ではなく、正しく運用されていなかったスクラムなのかもしれないとも思えてきた。本書の第1部を読み進めてみて、スクラムの意図している目的や価値には私が共感できるところが多々あった。

kustomize のパッチ適用の違い

#kubernetes  #writing 

22時ぐらいには寝て6時半に起きた。昨日はお出かけしてきてバテたんで19時頃からうたた寝を繰り返してずっと寝てた。実家に帰っていた期間を除いて、土日のどちらかを休むのはここ3ヶ月はなかったと思うし、土日の2日間ほとんど仕事をしなかったのは半年ぐらいはなかったと思う。久しぶりに土日に仕事しなかったなという印象で、その理由は業務委託のお仕事の契約が決まって余裕があるからだと思う。

kustomize の Inline Patch

Inline Patch に次の3つのやり方が説明されている。

  • patchesStrategicMerge: Strategic Merge Patch として解析されるパッチファイルのリスト
  • patchesJSON6902: 1つのターゲットリソースのみに適用可能な JSON Patch として解析されるパッチと関連付けされるターゲットのリスト
  • patches: 関連付けされるターゲットとパッチのリスト。このパッチは複数のオブジェクトに適用でき、パッチが Strategic Merge Patch なのか JSON Patch かは自動的に検出

patches は patchesStrategicMerge と patchesJSON6902 の両方を記述できる。運用上は patchesStrategicMerge か patchesJSON6902 を適用したいパッチの内容によって使い分けることになる。おそらく前者は base にない要素を追加したり、base の要素をすべて置き換えたりするときに使う。後者は base にある map や list の一部の要素のみを限定して置き換えたり、削除したりするときに使う。ちなみに patchesJSON6902 の 6902 というのは RFC 6902 JavaScript Object Notation (JSON) Patch に由来する。

patchesJson6902 の例として次のような設定にパッチを適用する。base から読まれた metadata の要素から namespace のみを削除したり、spec.metadata の1番目のリストの secretKeyRef が参照する Secret を my-secret で置き換えたりできる。こういったパッチを patchesStrategicMerge で実現することはできないのではないかと思う (詳しくないので私が間違っているかもしれない) 。

base.yml
apiVersion: apps/v1
kind: Component
metadata:
  name: my-component
  namespace: default
spec:
  metadata:
  - name: username
    value: user
  - name: password
    secretKeyRef:
      name: base-secret
      key: password
kustomization.yml
...
patchesJson6902:
  - path: my-patch.yaml
    target:
      group: apps
      version: v1
      kind: Component
      name: my-component
...
my-patch.yaml
- op: remove
  path: /metadata/namespace
- op: replace
  path: /spec/metadata/1/secretKeyRef/name
  value: my-secret

リーンキャンバスレビュー (前半)

前に作ったリーンキャンバス を使って友だちにプロダクトの設計をレビューしてもらった。私がリーンキャンバスを作ったことがなかったので、この項目にはどういった内容を書くか、それぞれの項目がどういった関連付けや粒度で整理するかといった、リーンキャンバスの書き方そのものも含めて教えてもらった。

私が設計のために作った40枚のスライドを話すと2時間必要とするが、リーンキャンバスを使えば要点のみ15分で話せるようになるのが狙いになるみたい。とはいえ、リーンキャンバスの書いてある内容の半分を確認するだけで今日は2時間弱かかってしまった。議事録を取りながらだったので話すだけならもっと短くなったかもしれないし、その背景や根拠を細かくツッコミしていくとそれなりの時間はかかるのかもしれない。リーンキャンバス上は数枚の付箋で簡潔に書いてあるが、これどういうこと？みたいな問いになると詳細を説明しないといけないので時間がかかったように思う。リーンキャンバスの精度や品質が上がれば、読み手が詳細を確認しなくても意図を理解しやすくて詳細のツッコミが不要になるのかもしれない。これまで使ったことがないツールでおもしろいので週末に後半を行う。課題管理の背景には実践知、認知心理学、情報共有、組織論といった様々な分野にまたがるのでそのコンテキストを共有するのはなかなか難しいのではないかという思いもある。

六甲山と灘五郷

#life  #kobe  #sake  六甲山と灘五郷

1時ぐらいに寝て6時に起きた。

オリックスレンタカー

昨日、9:00 - 17:00 で予約したものの、8時には出掛けられる状態になったので電話で確認したら早くてもよいと言う話だったので 8:15 から車を借りる。車種は トヨタ・ヴィッツ 1.3l だった。wikipedia によると、2020年3月31日で販売終了になっているみたい。六甲山のような山登りを普通に走る分にはコンパクトな車体で快適に走行できた。私は車に全くこだわりがないのでこのぐらいのサイズの車で十分だと感じた。保険やWeb割引を含めて8時間レンタルして7,700円だった。

神戸市立森林植物園

三ノ宮市内から約30分ほどで 神戸市立森林植物園 に着いた。8時15分ぐらいに出発したので比較的車が少なくて渋滞にあわずに行けたのもある。六甲山の山道は2車線しかなく、森林植物園の少し手前で渋滞になった。なぜ渋滞しているかというと、駐車場に入るところで料金の支払いが手作業だから。私が行った9時前の時間帯では駐車場のキャパシティは十分にあったが、駐車場の料金支払いで渋滞を引き起こしていたようにみえた。ネットワーク回線がどのような状態かわからないけど、ETC のような機器があれば渋滞を緩和できるのだろうと推測する。六甲山行くならなるべく朝早く出発した方がよいとわかった。

森林植物園全体の1/3ぐらいしかまわれなかったけど、写真とかでみる想像通りの場所でとてもよかった。11月は紅葉シーズンでライトアップもしているらしい。朝みても紅葉がすごくきれいだったのでライトアップも期待して見に行ってよさそうに思えた。時間があれば3時間ぐらいハイキングしても楽しめると思う。

六甲山牧場

森林植物園から10分ちょっとぐらいで 六甲山牧場 に着いた。ここも北エリアしかまわれなかったけど、山羊と羊と馬と牛に触れながらのほほんできるような場所。小さい子ども連れの家族が多かったので、子どもが動物と遊んでいるところの邪魔をしないように配慮しながら楽しむ感じ。

ちょっと前に山羊は草を食べてくれるという榛葉賀津也氏のツィートをみかけた。実家に草刈りのために定期的に帰るのが面倒だと常々思っていたので山羊を飼えばいいんじゃないかと考えている。そのためには山羊が生活する場所を作ってあげないといけない。田んぼの余っているスペースに柵を設け、一緒に山羊小屋も作ってあげればよさそう。六甲山牧場でも山羊はずっと草を食べていた。その辺に生えている雑草を食べるのかどうかわからないけど、確かに草を食べてくれそうな雰囲気はした。すぐに出来ることではないけど、段階的に実家で山羊を飼うための調査をしていこうと思う。

六甲山天覧台

六甲山天覧台 も行こうと予定していたが、道を間違えて辿り着けなかった。次回の機会があれば挑戦する。

菊正宗酒造記念館と櫻正宗記念館

お昼ごろに六甲山を降ってきたので 菊正宗酒造記念館 に行ってみた。お酒造りの道具や作業方法などの展示があって、お土産コーナーで無料試飲と有料試飲があって、無料でも2種類のきき酒ができる。お金を払うと4種類+つまみやアイスなどが付いてくるみたい。私は運転しないといけないのできき酒は飲めなかったけど、お酒が好きな人はいろんなお酒を試せておもしろそうに思う。

ついでにすぐ近くにある 櫻正宗記念館“櫻宴” にも寄ってみた。ここは菊正宗記念館に比べると展示類などは少ないが、お土産コーナーは充実していたのとカフェと食事処は充実していた。また無料試飲はなく有料試飲のみだった。

灘五郷にはこういった記念館がたくさんあるので 灘五郷酒蔵めぐり をしても楽しそうに思えた。

人と防災未来センター

レンタカーのレンタル時間がまだ少しあったので 人と防災未来センター に行ってみた。西館と東館に分かれていて、西館は阪神・淡路大震災の映像や展示など、東館は地震や津波一般の展示が行われているらしい。西館だけみてきた。10分ぐらいの阪神・淡路大震災の再現映像をみたけど、これはかなり迫力があって、震度7という地震の恐ろしさが伝わってきた。私は南あわじ市で15歳のときに震災を経験したけど、南あわじ市は震度4で大した被害がなかったと思う。震度7とか死んでてもおかしくないというのが再現映像から受け取れた。この映像をみて防災意識を高めるだけでも価値があったように思う。

レンタカーを予約した

#life  #food 

1時前後に寝て6時に起きた。前日から母が泊まっていて、母は5時ぐらい起きて作業し始めるので必然的に朝起こされる。部屋を掃除してくれたのできれいになった。

ストレッチ

今週もお仕事に忙しくてあまりストレッチもウォーキングはできなかったものの、前週から中殿筋 (ちゅうでんきん) の張りはずっと残っていて、今日もトレーナーさんによく伸ばしてもらったものの張りが強いなと言う印象がある。今日の開脚幅は開始前168cmで、ストレッチ後169.5cmだった。前週とほぼ同じで現状維持ちょっとよくなったぐらいかな。ボールを使った中殿筋のストレッチが気持ちよくて疲れたときによくやっているけど、やっぱり1人でやるストレッチには限界があって、誰かに押してもらったり伸ばしてもらったりする方がよく効く。

三ノ宮・元町観光

親族が来ているので観光案内してきた。うちの会社のオフィスなども紹介した。三ノ宮・元町でショッピングして、南京町で豚まんや小籠包を買い食いしてきた。お昼は 饂飩の四國 という老舗のうどん屋さんに入った。前からお店は知っていて、いつか入りたいなと思いつつ、やや価格帯も高いのでうどんだとちょっと高いかな？とも思っていたけど、今日初めて入ってみて食べたらおいしかったので価格は妥当と言える。私はおろし醤油焼きなすうどんを食べた。コシがあって長い麺はそれだけでもおいしかった。天ぷらが豪華だったので、接待などで天ざるや天丼をお勧めするのもよさそう。

オリックスレンタカー

住んでいるところに一番近いレンタカーに オリックスレンタカー がある。前に一度借りたことがあって、そのときは普通にお店に行って明日借りたいと言えば予約できた。今日も同じノリで明日借りたいと言ったら予約が埋まってますと返された。仕方ないと思って次に近いトヨタレンタカーで尋ねてみたけど、同様に予約が埋まっていますと返された。ネットで探すかなぁと思って、試しにオリックスレンタカーのアカウント作成して、予約検索してみたらちょうど探していたコンパクトサイズで予約できた。ほんの1時間前は予約で埋まっていると店員さんが言っていたのに、、、と思い返しながらいくつかのケースを考察した。

  • 私が質問して帰った後にたまたまキャンセルが出た
  • 店舗予約とネット予約の在庫を別で管理していて、店舗予約在庫はなくなっていたが、ネット予約在庫だけ残っていた
  • 店員さんが在庫を勘違いしていて実は1車だけ残っていた
  • Web の予約システムがバグっていて実は在庫がないのにネットから予約できてしまった
  • ネット予約すると近くの他の支店で余っている車両を再配置するワークフローがあるために予約できた

昨日のメタ認知が暴走するではないけど、メタ認知を働かせるといろんなケースが出てくる。明日お店に行ってちゃんと配車されることを期待する。