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

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。先日の勉強会で聞いた mvp の考え方 について気になったので相談してみた。はらさんと相談していて mvp とは一般論としてこうだと語ることはできないということが理解できた。大事なのは mvp でやりたい目的であって、その目的によって mvp が何になるかは変わってくる。

• コンシューマー向け (toC) と業務向けの (toB) でアプリケーションは全く異なる
  • toC 向けはニーズや要件がまったくわからない
  • toB 向けはニーズや要件が明確にわかっている
• mvp が何になるかは目的によって異なる
  • toC 向けはニーズや要件を把握するのが目的になる場合がある
    • PMF (Product Market Fit) という概念もある
  • toB 向けはニーズや要件に合致するものかどうかを確認するのが目的になる

あと フリーランス協会 という団体があるのを教えていただいた。フリーランスは会社員と比較して守られていない箇所がたくさんある。例えば、取引先とトラブルになって損害賠償が発生するとかがある。うちの会社に限って言えば、役員は基本的に労災保険の適用外になる。この仕組みを見直そうといった取り組みや制度があるという記事もみかけたりはする。そういった保険やら福利厚生やらいろんなものをパッケージングして比較的安い金額で提供してくれるらしい。はらさんによると、なぜ○○協会といった団体がたくさん作られるかというと、団体では受けられるが、個人では受けられないサービスがあるからだという説明をされていた。

むきなおり

チームで改善のための会議があった。会議のホストがいなくて、誰も何も準備をせずに会議が始まり、課題は何なのかを会議中に相談して決めるみたいな、これまでもそうだったようにだらだらした会議の始まり方をした。私はすぐにいなくなる人間なのであまり今後の方針についてはコメントしないようにしている。議論の行方だけを聞いていた。ストーリーポイントとベロシティの運用が混乱をもたらし始めていて、PO がベロシティは納期の対する進捗度合いを把握するために計測していると発言していて取り返しがつかなくなっているように感じた。いつまでに何ができかるかの期日を出さないといけないという使命感からストーリーポイントをスケジュールと同視ことから抜け出せていない。周りの知人と話したり、私自身の解釈としてもストーリーポイントとベロシティで把握できるのはチームの成熟度や成長の度合いだけになる。1年前よりもベロシティが増えているのであればチームは成長したと言える。言わばたったこれだけのことしか分からないし、成長の度合いに関すること以外に使うべきではない。

ストーリーポイントの誤解と誤用は、特にプロセスがチームから部署、企業へとスケールして行くときに、時間をかけて増幅されていきます。これらの誤解と誤用を正すのは、時間と労力を要します。

ストーリーポイントを使うのをやめよう で書かれているように、ストーリーポイントという抽象化された数値が独り歩きして、自分たちの都合のよい指標になると考え始めている。この記事によると、これが周りに広がっていくにしたがって混乱が増幅していくように書かれている。いま正にそういう雰囲気をみていて実感した。

0時に寝て6時に起きた。夜中に暑さと気分の悪さで起きるのが常態化してきた。今日は珍しく4つの会議が重なって喋りつくして後半バテた。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。前隔週を1回飛ばしたので話題がたくさんあった。

• スクラムの話題
• もてなしだけではもう食えない -ホテル経営学の本質と実践-
• 起業プラザひょうごさんの内覧

もう1年近くスクラムをやっているのでスクラムの弱点や欠点なども少しずつみえてきた。しかし、はらさんと話していると、はらさんが実践してきたスクラムと私がやっているスクラムにはいくつか違いがある。同じスクラムというガイドに沿っていても、実際は組織やプロジェクトの内容によって大きな乖離が生じるというのも事実のように思える。プロジェクトのサービスインに伴い、大きなふりかえりやストーリーポイント運用の見直しを経てわかったことを雑談しながら理解を深めた。主には次の3つにまとめられる。

• スクラムマスターの限界
• スクラムと心理的安全性
• ストーリーポイントという信仰

PO でも開発者でもないスクラムマスターはプロジェクトが経過する時間とともに貢献度が減っていく。ヒト・モノ・カネ・情報というプロジェクトのリソースのうち、もっとも変動するのは間違いなくヒトである。プロジェクトの初期とマイルストーンの区切りにおいてヒトだけが経験を経て大きく成長する。成長しないヒトがいるとすれば、それはそのヒトがさぼっているか、プロジェクトにマッチングしていないと言える。普通のプロジェクトマネジメントにおいて成長しないメンバーなど存在しない。大きなふりかえりによって、驚いたことにスクラムマスターだけがそうじゃなかった。安西先生の言葉を借りるとこうだった。

まるで成長していない ………

PO も開発者も日々の業務からドメイン知識を深めていき、大きく成長しているのに「ただ観ていただけ」のスクラムマスターは全くメンバーの話しについてこれていない。それが上辺だけの浅いふりかえりで終わり、総括はおろか、今後の改善の施策もまとめられないという結果になった。ファシリテーションをスクラムマスターが担っているからそうなってしまう。また過度に感情に配慮したふりかえりをするとネガティブな事実や結果を直視しようとしない。関係する誰かが責任を感じたり嫌な思いをさせる可能性はあるが、それらを認めないと次の改善の施策をたてられない。これは日本の会社ではよく起こることに思える。うちのチームは仲が良いだけのぬるま湯チームになっていてゾンビスクラムにも近付きつつある。

もう1つ、スクラムをやらなくてもよい背景の1つとして、チケット駆動開発と業務のワークフロー最適化の話題をつぶやいてみた。

チケット駆動開発の優れているところの1つとして、課題管理システムを中核にして業務のワークフローを明確化できるところにある。業務の始まりから終わりまではどんな会社でも何らかのワークフローがあって、その手順をメンバーが理解することで業務というものが成立する。

— Tetsuya Morimoto (@t2y) August 5, 2022

神戸市さんと雑談

Kobe x Engineer’s Lab という取り組みを担当されている職員さんとその運営会社の担当者と面談した。前から三宮.devのすみよしさんから話しを聞いていたので、そのつてで面談の依頼がきたと思っていたら、全然違う知人からの紹介だったので驚いた。ざっくばらんにエンジニア不足の社会問題の解決のために「神戸市として」どんな施策があるか、コミュニティはどう運営すればいいか、これまでに彼らがやってきたことの成果などを聞きながら雑談していた。エンジニア不足という社会問題と地域性は相性が悪い。私から意見したことはこれらかな。

• コミュニティはコントロールできない
• (個人や有志の) コミュニティとお金は相性が悪い

前者について、私自身、プログラマーのコミュニティと深く関わってきたことから、彼らがこの1-2年やってきたことの課題感はいくつか類推できる。コミュニティを中核に、自分たちの意図した目的を達成するのは相当に難しい。コミュニティに人を集めるにはコンテンツが必要になる。コンテンツのないコミュニティに人が集まることはない。多くのケースでコンテンツは主催が提供する。主催がコンテンツを作れなければ人を集められない。そして、コミュニティに人を集めるのも大変な労力だが、集まったとしても多様な集団の行動やモチベーションなどを、他人がコントロールして導くのは難しい。個人や有志のコミュニティは、主催が負担のないレベルで長く続けているうちになにか起きるかもしれないといったふわっとした願望で取り組むのがよい。コンテンツを提供し続ける主催の熱意は不可欠だが、必要以上にがんばり過ぎると燃え尽きてしまってやはり続かない。コンテンツと持続性の2つが優れたコミュニティを運営する上で最初にぶつかる課題かなと私は思う。

エージェント会社と雑談

次のお仕事探しに新しいフリーランス向けのキャリアエージェントの会社と面談してみた。11月開始だと9月中旬ぐらいに出てくる案件になり、いまから探していても時期があわないといった話だった。職務経歴書をまだ提出していなかったせいか、なんとなくマッチングしていない雰囲気がした。そのキャリアエージェントの会社が扱っている案件と法人としての私の働き方があっていないのかもしれない。手応えがなかったので別のキャリアエージェントの会社とも話しつつ次のお仕事を開拓していくことに決めた。

23時に寝て7時に起きた。今週は不規則な生活をしたのでバテた。

ストレッチ

今日の開脚幅は開始前156cmで、ストレッチ後160cmだった。先週よりちょっと数値が悪くなった。自覚症状はなかったけど、ストレッチをしてみると右腰の張りがそこそこあることに気付いた。自覚症状のない疲労に気付けるのがストレッチのよいところの1つでもある。

スモールオフィスの内覧

たまたま 起業プラザひょうご さんのスモールオフィスに空きがあるのをみつけたので内覧に行ってきた。電話したらとくに予約は取らなくてよいのでいつでも来てくださいと言われたのでアポなしで17時頃に行くことにした。現地のビルに行ってみたが、ビルが工事していて入れる状態ではない。なんかおかしいと思って調べたら地図には全然違う場所が示されていた。後で知ったことだが、2020年8月に移転していた 。前に起業プラザひょうごさんに2-3回行ったことがあったけど、それは移転前だった。その後、移転したことを全く知らなかった。

このコワーキングスペース兼レンタルオフィスが三井住友銀行神戸本部ビルという旧居留地の真ん中に18F建ていう、この付近ではトップレベルの高層ビルと言える。そんなビルの2Fという「ん？」という場所にある。おそらくビルの名前から三井住友銀行の自社ビルだろう。1Fには銀行の窓口があり、窓口の前を横切る形でエスカレーターを上がると起業プラザひょうごさんのコワーキングスペースがあった。入り口には警備員さんが立っていて入ろうとすると「会員証をみせて」と止められた。内覧にきた旨を伝えると通してくれた。銀行のビルなので休日でも警備員さんが控えている。

2Fにエスカレーターで上がり、受付で内覧にきたことを伝えるとそのまま (おそらくアルバイトの) 若いお兄さんがあちこち案内してくれた。興味本位で「素朴な疑問なんだけど、どういう経緯で銀行の自社ビルの2Fの空きスペースみたいな場所を間借りできたんですか？」と聞いみたら、さすがにそれは分かりませんと返ってきたw

普通のオフィス (5.6㎡) と広いオフィス (8.4㎡) の2つに空きがある。

空きスペースをパーティションで区切っただけの簡易的なオフィスではあるけど、家賃は税込でそれぞれ 23,595 円と 33,275 円になる。登記さえできれば、オフィスの体裁は私にとってそこまで重要ではない。物理的なセキュリティの懸念として壁の上によじ登ることができるのはあるけれど、扉には鍵がかかる。床面積から比較するとレンタルオフィスとしては周りの平均よりも半額から1/4ぐらいの破格の価格設定と言える。一通り話しを聞いてみて引越し先として検討できるかどうかを確認していた。私にとっての一番の課題はこのビルに入れる時間帯が制限されていること。私は平日は7時台にはオフィスにいるし、夜も遅かったら3時ぐらいまで作業をするときもある。外的要因で時間の制約を課せられるのが私にとってはストレスとなる。22時をまわることは月に数回程度しかないからまだ譲歩できても朝9時というのは始業が遅過ぎる。

• 平日: 9:00 - 22:00
• 土日祝: 10:00 - 20:00

顧問のはらさんとも相談して懸念がなければ、審査を受けるだけ受けてみてもよいかもしれない。但し、三井住友銀行の拠点ビルとも言えるところにあるコワーキングスペースなのでうちみたいなマイクロ法人は審査が通らない可能性も高いと思われる。過去に三井住友銀行で法人口座開設の申請を出してお断りされた実績もあるのでそれを思い出してた。

外部の人を招いて無償の勉強会を開催してよいかどうかを確認したところ、会議室の予約さえとれれば開催してよいとのこと。さらに会議室の利用料は無料とのこと。会議室は定員6名が2部屋、10名が1部屋、20名は1部屋の合計で4部屋ある。定員20名の会議室と聞くと「はぁ？」って感じでそこもみせてもらった。広い部屋のスペースを贅沢に浪費した構成だった。「こんな広い部屋の会議室って普段使うんですかね？」と質問したら使っているところをみたことないと返ってきて笑ってしまった。定員20名の会議室でどんな会議をやるねん？オフラインの外部勉強会をやるとしたらスペースが広くて快適そうな場所ではあった。あと後ろの方はモニターみえないよね、おそらく。

2時に寝て7時に起きた。前日はリファクタリングで0時過ぎぐらいまでコードを書いてた気がする。

内覧前に…

窓付きオフィスの空き をみつけて内覧依頼をしていた。昨日入居者が退去したということで日程調整して今日の13時から内覧を申し込みしていた。朝起きて楽しみにしていたら、午前中に電話が掛かってきて昨日たまたま申し込みがあって成約してしまったとのこと。もちろん内覧前に成約があることは承知しているのでそれ自体は仕方ないことだと理解している。タイミングがよすぎて陰謀論のように妄想していた。本当はもっと事前に決まっていたのに連絡するのを忘れてたとか、私の場合は同じ施設間の移動になるので利益だけを考えると外部からのご新規さんを優先されたとか、いくつかパターンは考えられる。妄想遊びはともかく、最低でも1ヶ月前には空き情報がサイトに掲載されるので十分な時間があるので他のお客さんが申し込む可能性は高い。私はそれも含めて縁があるかどうかを試していたところはあった。これは縁がなかったということで受け入れた。契約はできないけど、今後のために内覧だけさせてほしいとお願いして行ってきた。普通に内覧してよい部屋だった。空いていれば内覧後にすぐ申し込みをしていたので1日の差で希望が叶わなかった。とはいえ、すでに内覧したので次に空きが出ているのをみつけたら内覧せずに申し込みできる状態になったとも言える。もしかしたら、昨日申し込みした人も私と同じように事前に内覧はしていたが、なんらかの理由で申し込みできなくて今回は縁があったのではないかとも考えられる。いずれにしても、また次の縁があるときを待つ。

大ふりかえり大会

サービスインが落ち着いたのでお手伝いしている開発プロジェクトの大きなふりかえりイベントがあった。スクラムのスプリントが1週間単位なのでふりかえり自体は毎週やっている。ホストがスクラムマスターで、どんな風に数ヶ月分の大きなふりかえりをするのか興味があったんだけど、とくに目新しいことはなく、総論として期待はずれだった。毎週のふりかえりイベントの延長でしかなく、区切りとしての総括もなければ、次の開発に向けての改善や展望もほとんどなかったと思う。スクラムマスターは業務を理解していないのでまともにファシリテーションできなかったとも言える。みんながんばった、サービスインできてよかった、これからもがんばっていこうのレベル。

スクラムマスターがこのプロジェクトに参加したのは昨年の10月で、私が11月からお手伝いしているのでほぼ同期だということもわかった。その開発プロジェクト自体はその1年前ぐらいからやっていたのかな？現時点で2年ぐらい経っているのだと推測する。私がイニシアティブをとったところで評判のよかった項目はこれら。コメントを求められたので、開発者が開発しやすい環境を作った方が開発のサイクルが早くなって結果的にプロダクトの品質が上がるという当たり前のことを話した。

• 課題管理を backlog/github issues に分かれていた運用を backlog に一元化した
• backlog-github-integration-action の導入
• ビルド／デプロイのワークフロー改善

1つがっかりしたのが、ストーリーポイントを用いたバーンダウンチャートの実績 のふりかえり。ネガティブな結果が出ているのに、そのバーンダウンチャートがあったから間に合わないということがわかって納期を延期できたみたいなことを話していて呆れてしまった。導入当初、納期が守れなくて五月雨式に延期してしまう課題への対応として導入したはずだった。導入時に私は2回スクラムマスターにストーリーポイントで納期を見積もるのは誤った運用だと指摘した。しかし、スクラムマスターが他プロジェクトでうまくいっているからと強引に導入した経緯がある。そして納期をまったく守ってもいないのにその事実を真剣に総括しようとしない姿勢が不誠実だった。また翌日ストーリーポイント見直し大会をするという話しがあったからこの場は丸くおさめた。

スクラムマスターはポジティブな内容とネガティブな内容を交互にふりかえるようにファシリテーションしていた。あとネガティブ内容の厳しい指摘は意図的に避けているようにもみえた。おそらく担当者の心情を慮ったのだろう。人を責めるわけではなく、ネガティブな事実や結果と向き合って、組織として仕組みで次の改善につなげるというのは、私が言うほど簡単ではないのかもしれない。私は sier 時代にお客さんからも社内からも怒られるのが日常だったからいまの若い人たちよりはネガティブな事実に対する耐性が高くてギャップに映るだけかもしれない。

0時に寝て7時に起きた。

もてなしだけではもう食えない

読み終えた。あとで総評を書く。

第10章 不動産屋の悪知恵

2000年に改正された借地借家法38条の「定期借家」の条項から賃貸契約には2種類あるらしい。

• 普通借家
• 定期借家

普通借家は契約期間更新の概念があり、借り主が契約更新を拒否するには「正当な事由」が必要になる。一般的な賃貸マンションなどの契約も多くのケースでこちらの契約になる。ここでいう正当な事由とは、建物が老朽化して立て直す必要があるとか、貸し主がそこに住むといったものらしい。一方で定期借家は契約期間が終了すれば、一旦契約は終了してから新たに再契約するといった段取りになる。この定期賃貸借契約の条件を満たすには、契約期間更新の定めがないことを説明した書面を交付する必要がある。その書面がない場合はすべて普通借家とみなされるという。その是非を巡って争った最高裁の判例があるらしくググるとすぐに出てくる。当事者同士で双方の合意があったとしても説明書面がない場合は無効とするような判例となっている。これを逆手に取れば、普通借家として契約更新を主張できるというストーリー展開になっている。

• ■Q&A不動産の豆知識（定期建物賃貸借）－弁護士伊藤

あとは PDCA サイクルのうち、日本の会社で一番弱いところはどこ？という話題が出てくる。Check だろう？という主人公の答えに、アドバイザーは Plan じゃないかと返す。Plan が曖昧だから Check できないという背景になっているのではないかと。一理あるかもしれない。日本人は気質として誰か1人が責任を担うのを嫌う文化があるように思う。個人の責任にしたくない・されたくないという空気から Check を曖昧にしたがる傾向があると私は考えている。

第11章 エピローグ

タイトルのままの章でホテル経営についてのアドバイスがあるわけではなく、ストーリ仕立てで展開してきた物語の結末や登場人物たちのその後のキャリアや展望などを紹介している。総じてハッピーエンドと言えるし、総じて人生の中のスナップショットとしてこんなもんとも言える。区切りがきてなんらかの結果が出たとしても、さらに人生は続くので日常が少し変わっていくだけといった展開になっていた。

あとがき

著名なホテルの総支配人と著者との対談がある。読んでいて関心をもてたところは Job Description (職務分掌記述書) の重要性が説かれている。適正な評価、公平な人事、採用にも必要とされる。この考え方はメンバーシップ雇用を長く続けてきた日本の会社の年功序列とは大きな違いがあるため、制度設計の見直しは時間がかかるのだろうと思える。過去のしがらみがない新興企業が新たに制度設計して台頭していくのがよいのだろう。

また外資系という言葉に抵抗感のあるスタッフに対して「トヨタやファーストリテイリングは外資系ですか？日系ですか？」と尋ねるという話題も出てくる。そうすると、外資系や日系というグルーピングに意味がないことに気付く。その違いを対談の中ではグローバルかノングローバルかの違いでしかないと説明されている。ビジネスの規模や競合をグローバルの視野で考える必要があるかどうかによって変わってくるという。

勝てる能力があってもその素地となる基礎体力がないと発揮できない。野球でも基礎体力があるから速い球を投げられる。

これもホテル経営に限った話しではないなと思えた。私自身、昨今の開発チームをみていて感じることでもある。クラウドでアプリケーション開発が簡単になったがために基礎がなく、スキルが低い開発者もメンバーの一員として働けるようになった。もちろん最初は誰もがそうだけど、適切な指導や教育を受けないとそのまま経験年数だけが経ってしまう。さらにそんな人が偶然リーダーになってしまうと 許される無知の範囲は開発経験年数に反比例する という現象が起きる。一定の水準を超えていない開発者がなにを作ってもうまくいかないのではないかと私は感じるようになってきた。私はそういったプロダクトを「ただ動くだけ」と呼んでいる。その後の拡張や保守に必要以上にコストがかかり、それが原因で将来の開発計画に支障をきたすこともある。そして、多くのケースでその状況を作った人はその後いないことが多い。

1時に寝て5時半に起きて7時に起きた。夏バテなのか朝起きれなくなってきた。

localstack 入門

s3 とやり取りするアプリケーションの保守を手伝うことになった。いま開発環境向けに minio を使っていて、そのためだけにトリッキーな DI を実装している。そのコードがトリッキーなだけに知らない人がコードをコピペしてトラブルを起こす火種になってた。minio 使う必要性はまったくなく localstack を使えば解決できるのを、誰もその保守してなくて、仕方ないからこの機に私がやることにした。すぐにできるやろと思ったら意外にはまって2-3時間デバッグに時間を取られたので書いておく。

簡潔に言うと、(おそらく歴史的経緯で) minio は基本的に path style で s3 api を扱う。virtual hosted style でリクエストするとアクセスできなくてどうやって解決するのかが分からなかった。ググって出てきたどこかの開発者の言っている通りで path style は deprecated していて、aws も削除するとまで宣言していて、いつなくなるかもわからないのに未だにそれがデフォルトというのはどうなの？っていうお気持ちを表明している。

Beware accessing @_localstack using an AWS S3 client configured with virtual hosted style access: GET my-bucket.localhost:4566/prefix/my-object.txt wrongly 404 errors, but a path-style GET localhost:4566 /my-bucket/prefix/my-object.txt succeeds!

— James Shaw (@hertzsprrrung) October 27, 2020

私も同意見で issue をよくよく調べてみると次のエンドポイントに対しては virtual hosted style でアクセスできた。localhost に対しては path style で動いていて、virutual hosted style は localhost.localstack.cloud という、よくわからんドメインを使わないといけない。ドキュメントには書いてなくてググって辿り着く issue のコメントをみてたら気付いた。

• Support for s3 bucket subdomains #2631

mybuket.localhost.localstack.cloud 

aws-sdk-java v1 のコード例だと次のようになる。バケット名は実際にリクエストするときのパラメーターから s3 client がセットしてくれるのでこんな感じ。

var endpoint = new AwsClientBuilder.EndpointConfiguration("localhost.localstack.cloud:4566", "ap-northeast-1");
var client = AmazonS3ClientBuilder.standard()
        .withEndpointConfiguration(endpoint)
        .build();
return client;

こんな初期設定でつまづくと、このライブラリを使うのをやめようかという気持ちになる。ちゃんとドキュメントに書いておいてほしい。

窓付きオフィスの空きをみつけた

エリンサーブさんの内覧 に行ってきてから縁があればという感じでオフィス引っ越しは待ち状態になっていた。いま契約しているところの別オフィスで 神戸旧居留地 のサイトを、たまたま今日みたら窓付きの部屋が空き予定だと書いてあった。

7F-07 7月末空き予定 ￥69,300 ￥6,600 2名 6.22㎡ 完全個室/窓付き/棚付き

家賃はいまより 31,900 円増える。年間にすると 382,800 円のコスト増になる。高くはないけど、いまの環境でもう少し続けたら？と言われたらそれでもいっかと思えるぐらいのコスト感。優先度は高くないが、縁があるなら見逃す手もないといったスタンスで臨む。ひとまず明日、電話してまだ空いているなら内覧できるかを聞いてみるところから始める。内覧してよさそうな場所だったら引っ越しを検討する。7月末って急な話だけど、小さいオフィスなので本気出せば レントラ便 で2時間もあれば引っ越しできるはず。荷造りの準備に1時間、搬送に1時間といったところかな。

2時に寝て7時に起きた。今週はバテた。金曜日は非稼働日だけど、バタバタしているから普通に働いていた。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。今週はお手伝い先がサービスインでバタバタしていて議題の準備がほとんどできなかった。少し前に参加したアトラシアンさんのウェブセミナーのスライド資料が公開されたのでそれを眺めながら雑談していた。

jira の有料プランのサービスに jsm chat という halp の技術を活かした新機能が追加されたらしい。既存プランの延長上で使えるらしい。質疑応答のときに halp とは別プロダクトだと明確に回答していたので halp が今後どうなっていくのかの将来にはかなり懸念がある。チャットと課題管理システムの双方向連携という、slack や teams といったチャットサービスがよく使われるようになった昨今のビジネス事情にあわせたサービスと言えるだろう。

私も以前からその領域に課題意識をもっていたし、ベンチャーでは workstreams.ai も同様のサービスを提供している。満を持してというのか、(私にとっての) 課題管理システムのベースラインとなる jira にその機能が入ったことで競合製品も同様に機能拡張を提供していく気がする。1-2年後にはチャットと課題管理システムが双方向連携しているのが当たり前の開発スタイルになるのかもしれない。非開発者にとってはチケットを扱うよりも敷居が下がるのでそれは適切な世の中の変化だと私は考えている。

ゾンビスクラム

jsm chat と課題管理の話しをしているうちにスクラムの話題になった。Zombie Scrum Survival Guide という書籍があって形骸化したスクラムの特徴をまとめているらしい。ある記事で2021年から翻訳していると書いてあったので翻訳版が出版されたら読んでみようと思う。

• 「ゾンビスクラムサバイバルガイド」読んだ飼育係の日記
• ゾンビスクラムの4つの症状
• ゾンビスクラムを解決するための10の成功要因

ブログ記事の所感を読んだ感じだと、私がいま関わっているスクラムにも一部通じるところがあるなと思って関心がある。

うちのチームは1週間スプリントをもう1年近く続けているのだけど、これは検査が早い段階でできるというメリットがあるものの、開発のメリハリがないなぁとずっと思ってた。それはただ与えられたタスクを無理なくこなすだけというルーチンになってしまっているのと、昨今の労務管理を徹底する働き方改革？のせいか、残業・休出を一切やらない開発スタイルが開発者の自律性や意欲を削いでしまっているのではないかとも思う。もちろん「余白」があれば、業務時間内に好きなことをやったらよいと思うけれど、うちの場合は半分ぐらいのスプリントゴールが未達で、スプリントに達成できないタスクを盛り込むからスプリントゴール未達の状態で他のことをやるのが憚られる空気がある。もっとも好き勝手やっている私がそれを感じるのだから、若い開発者には相応のプレッシャーになっていると思う。結果として、指示されたタスク (プランニングで決めたこと) 以外のことはやらない雰囲気になってしまっている。試しに直近3ヶ月のスプリントバックログアイテムの種別のみで開発者のチケット登録した数をカウントすると次のようになった。

• 私: 66件
• 開発リーダー: 17件
• 開発者1: 14件
• 開発者2: 12件
• 開発者3: 1件
• 開発者4: 6件

これは課題管理システムに慣れていて、業務をタスク分解しながら作業していくというワークフローに私が最も習熟しているから、適度な粒度のチケットをいくつも作りながら作業をやっているという背景もある。しかし、いまやらなくてもいずれ必要なタスクも、業務をやりながら気付いたときに私は随時登録している。憚られる空気を感じている私が週4日労働で控えめにやっても3ヶ月でもこれだけの数が開く。要はゾンビスクラムだと開発者の自律性は期待できないという話し。

0時に寝て6時に起きた。夜あまり眠れない。

算定基礎届

e-gov電子申請 を使って初めて電子申請してみた。昨年もやろうと挑戦したけど、macos からだと不具合があってエラーになるから断念してた。今年は windows マシンがあるので windows アプリケーションをインストールして問題なく申請できた。うちは社員1人なので csv 取り込みを使わず、手入力で申請した。申請した書類は pdf 出力できるし、申請後に送信したデータは xml で控えとして保持できる。本当に紙でやっていたものを文書データと数値データに置き換えたようなアプリケーションになっている。紙の書類と比べて、アプリケーションがよいところは申請の進捗状況がわかるところ。算定基礎届で問題が発生することは過去にないけど、審査開始、審査終了、手続終了のステータスをアプリケーションから確認できる。それはそれで申請者にとって状況の追跡ができて安心感になる。

振替伝票の使い方

前期は赤字決算だったので中間申告で支払った税金が還付される。中間申告というのは、前年度の納税金額から翌年の税金の半分を納めるという仕組み。前年度の法人税額が20万円を超えると中間申告が必要となる。前年度と同じ法人税が今年度もあるという前提で半分納めるけれど、その納めた金額よりも確定申告のタイミングで実際の納税金額が少ない場合は還付金という形で返ってくる。今回は赤字決算となったものの、それも初めてだったので税務署からの還付金をどう会計処理するのかも初めての機会でよくわからなくて調べながら作業した。

会計システムとして普通に行う処理ではないので freee のドキュメントも断片的にしか説明されていない。基本的な操作の考え方を理解した上で自分がやりたい会計処理に変更しないといけない。

• 取引を預り金や仮払金で決済するには、どうすればいいですか？
• 還付を受ける場合の処理

まず中間申告のタイミングで振込した納付金額は「仮払金」として登録される。本来は確定申告のタイミングで確定した納付額に対して「仮払金」を相殺するような会計処理を行う必要がある。freee では取引データの決済欄に「+更新」というボタンがあってそこから仮払金から引き落とすようなデータ登録が可能となる。今回は赤字決算ですでに支払った「仮払金」が還付金として戻ってくるときの会計処理をしなければいけない。その手続きのために使うのが「振替伝票」になる。例として金額を10万円とすると次のような振替伝票を作成する。

• 借方
  • 勘定科目: 未収入金
  • 税区分: 対象外
  • 金額: 10万円
• 貸方
  • 勘定科目: 仮払金
  • 税区分: 対象外
  • 金額: 10万円

「仮払金」を相殺するための勘定科目は「未収入金」になる。この「未収入金」を還付金の取引 (税務署から銀行口座に振り込まれた金額) で消し込むことで会計システム上の辻褄があう。一般的に還付金の勘定科目は「雑収入」として扱うらしい。還付金は消費税がかからない取引であるので不課税取引となる。ややこしいのは還付金が振り込まれる際に還付加算金というお金も一緒に振り込みされる場合がある。還付加算金というのは、納め過ぎた税金に対する金利のようなものになる。試しに計算してみると金利が 0.46% になった。ある銀行の定期が 0.002% だったので税務署に税金を納め過ぎるとめちゃくちゃ金利のよい貯金みたいな扱いになる。話しを元に戻すと、還付加算金は課税対象になるので「雑収入」の課税売上として会計処理する。

うちの会社では、振替伝票は決算のタイミングでしか使わない。振替伝票の使い方を忘れていてたまに使うときに右往左往する。

はんなりDAO

はんなりDAOをはじめてみます に参加した。イベントで話した内容は notion で公開されている。

• hannali-dao

まだ全然、計画段階で段取りの計画も目処もたっていない。dao が良いものかどうか、私はまだよくわかっていないが、実際に自分で試してみることには肯定的である。そして組織の取り組みは実際に複数人いないとあまり実用的ではないことからコミュニティのような、一定以上の信頼のある実際の人間が関わってくれるならそれはそれで実証実験の場としてはおもしろい取り組みになるかもしれない。初回だったので dao とは何かとか、dao や web3 を取り巻く世の中の状況はどうかとか、はんなり dao の目的をどうするかとか、計画段階の雑談が主だった。最初はそんなもんかもしれない。私もスマートコントラクトとか、何が嬉しいのかよくわかってないので dao を運営する中で実際に実装してみる機会があれば、それはそれで学びの機会としてよいかもしれないと考えている。

aragon という dao を作るためのプラットフォームがあって、これを使うと dao そのものはすぐに準備できるらしい。あとは組織運営のルールやスマートコントラクトを実装していくだけみたいな話し。ethereum で動かすと手数料がかかる。しばらくは testnet であーでもないこーでもないみたいなやり取りをしながら dao の運営を学んでいこうみたいな話しをしていた。

1時に寝て7時に起きた。

源泉所得税の納付

ちょうど給料日を過ぎたので所得税徴収高計算書 (納期特例分) の申請を行った。これまでも e-tax で電子申請して振り込みしていたのだけれど、e-tax ソフト (web版) でブラウザから申請していた。今回は windows マシンにインストールされている e-tax ソフトから申請してみることにした。e-tax ソフトは起動時に「追加インストール」という機能があって、申請に必要なモジュールのみをダウンロードしてインストールできるようになっている。20年前で言うところの saas はこうだった。「源泉所得税関係」というモジュールをインストールしないと、所得税徴収高計算書の申請ができない (e-tax ソフトに帳票がインストールされない) 。モジュールを追加インストールすれば、「源泉所得税」という税目から「所得税徴収高計算書 (納期特例分) 」という帳票を選択して、あとは数字を記入して送信するだけ。この申請に電子署名は不要。

法人税の修正申告と欠損金の繰り戻し還付の訂正依頼

国税局の職員さんからの指摘 で提出した書類が誤っていることに気付いた。いくつか訂正箇所を書いておく。

• 欠損金額とは
  • 正: 税引き後の欠損金額 = 別表1の1の数字をそのまま使えばよい
  • 誤: 税引き前の所得 (税務上は負の所得を欠損金と呼ぶ) を使っていた
• 法人税と地方法人税の計算は別
  • 欠損金の繰り戻し還付の申請は法人税のみの還付金を算出
  • ↑で求めた還付金に対して(令和元年以降は)10.3%を地方法人税の還付金とする
    • この手続きは不要で別表一に算出した数字を記載すればよい

まずこの申請書の誤りを修正して訂正依頼とする。

さらにこの欠損金の繰り戻し還付の申請の数字を別表1に記載しなければならない。それらが漏れているのと還付申請のためには別表七も提出しないといけない。あと細かい数字の記入漏れの指摘もあった。法人税の確定申告に対して次の5つの書類を修正申告として提出する。

• 別表一
• 別表一 次葉
• 別表四
• 別表五 (一)
• 別表七 (一)

税務署の職員さんが訂正する数字を書いてくれていたので、それをみながら e-tax ソフトで数字を修正して紙に印刷してそれを再提出する。おかげで赤字のときの別表書類の書き方もわかった。大半は欠損金の繰り返し還付に関する数字の記入漏れなので今後も赤字の年度があったときにこの内容を踏襲しながら申告すればよい。また1つ行政手続きのノウハウを得ることができた。税務署の職員さんに感謝。

企業サイトの更新

企業サイトを作成してから3年近く経つのでそろそろ初期の頃に書いた内容が現状とあわなくなってきた。あちこち現状とあっていない内容を更新した。本当はデザインを刷新したいと思っている。デザイン刷新のためのチケットを作ったのが2021年7月28日 20:04なのでもうすぐ1年経とうとしている。どんどん時間が過ぎるな。今日のところは、主には 企業情報 の構成を作り直した。それと同時に過去に働いていた会社での業務外発表を除去した。今後は自社の発表のみを掲載する。これには会社としてマーケティング活動をやっていくという意気込みと過去との決別の意味合いもある。トップページに news を5件表示しているところがビルドするタイミングによってそうならないときがあって、実行タイミングによってページングがされたりされなかったりする現象に悩まされている。ワークアラウンドとしては、何回かビルドをやり直せばページングされるときもあるのでそれを待つみたいな、どうしようもないやり方でこの場は凌いでいる。

0時に寝て6時に起きた。だいぶ復調してきて朝起きれるようになってきた。

歯科検診

3ヶ月ごとの定期検診。前回 は2年ぶりにレントゲンをとったので新しい歯のレントゲン写真をみせていただいた。とくに変わりなく、親知らずにゴミが溜まるスポットがあるから、親知らずを抜いた方がいいのはいいけど、下側の親知らずを抜くのは大変だから痛くなってからでもよいかも？みたいな話しをした。いま3ヶ月ごとに定期検診して親知らずのゴミスポットの掃除をしてもらっているからそれでもしかしたら大丈夫なのかもしれない。あと1箇所だけ銀の詰めものと歯が精密に一致していないところがあって、その隙間にゴミが溜まりやすいとのこと。急がなくてもよいけど、いずれ付け直した方がよいらしい。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。今日の議題は次の3つ。

• お手伝い先の契約更新についての話題
• カフーツさんとワーケーションの話題
• jjug ccc 2022 spring ふりかえり

先日の記事 でも「余白」という概念が個人的にはまったのであちこちで余白談義をしている。デザインで言うところの余白とは何かをはらさんに聞いてみたところ、次のようなものだという。

• 空白というコンテンツである
• 他に使ってはいけない領域である

開発における余裕とかゆとりのことを余白と言ってしまうと、デザインの文脈とは一致しないという話しになった。ワーケーションの文脈では予定調和じゃない時間を指すといとうさんは仰っていた。何かをやるための計画を立てた時間ではない。何もしなくてもよいし、思いつきで何かをしてもよい。先日の記事で、課題管理の文脈でメタ課題の抽出や他人のチケットにコメントしたりするのも余白の1つではないかと私が書いたのはその行動が必須というわけではない。誰かから指示されてやっているわけでもないという行動が、ワーケーションにおける予定調和じゃない行動と共通点があるのではないかと考えたから。

私が開発における余白を余裕やゆとりのように解釈して発言したので余っているものというニュアンスになってしまったけど、その時間は余っているものではなく、明示的に明けておくべき時間のように捉えたらデザインの文脈で言う余白にも近い概念になるかもしれない。開発だと想定外の追加作業や要件漏れなどのために確保しておく時間をバッファと呼んだりもする。例えば、開発の作業時間を1日8時間、1週間(5日間)で40時間と見積もるから余白がなくなってしまうであって、仮に1週間の余白を3時間と先に確保してしまって、37時間を開発の作業時間としてしまえば余白がなくなるということない。その余白時間に業務に関係ない勉強会をやってもいいし、自分の調べたいことに費やしてもいいかもしれない。私が金曜日を非稼働日として業務委託の作業をやらずに雑談していることにも通じる。

その後、余白談義からスクラムの課題や展望の話しなどにも発散して盛り上がった。スクラムには余白がないから。まだまだ私自身、余白の言語化に曖昧なところがあるので今後も意識しながら概念や価値を言語化していくように努めたい。

3時に寝て6時前に起きた。起きて作業しようと思って階下に降りた (寝室は2階) ものの、なんかバテてて、畳の部屋で寝転がっていた。涼しくて気持ちよかった。2度寝もしてたかもしれない。起きてからは帰りの高速道路のサービスエリアを調べたり、丹波篠山市か、六甲山天覧台に寄り道するならどういうルートになるかシミュレーションしたりした。

朝風呂とモーニング

昨日と同じように7時を過ぎてから朝風呂に出掛けていく。今日は「地蔵湯」に入った。子ども向けの浅いお風呂と大きなお風呂があった。座椅子でやや腰に負担がかかっていたのでジャグジーで腰の療養をした。昨日3時まで雑談して疲れていたせいか、2泊を終えてバーンアウトしてしまったのか、3日目の旅程の考えがうまくまとまらなくて、お風呂に入りながらぼーっとしていた。喫茶店の 萠阿 (のあ) さんでモーニングを食べた。

事前に作成しておいた旅のしおりでは、チェックアウトは11時にして、13時に城崎温泉を出発する旅程になっていた。意図としては観光したい人向けに余裕をもったスケジュールにしていたつもりだった。しかし、周りも疲れているようにみえて、11時に城崎温泉を出てもいいかなという空気にはなっていた。とはいえ、11時から帰り始めると2時間半で神戸に着いてしまう。はらさんの帰りの飛行機の時間が19時だったのであまり早くても持て余してしまう。車で行ける付近の場所を観光してもいいかなと思いつつも具体的なアイディアが出てこない。疲れると想定外の状況に対していくつかの仮説を並行してシミュレーションできなくなっていた感じ。お昼ご飯どうする？という話題に、城崎温泉で食べるか、よそで食べるかもまとまらない。誰かが出石そばを食べに行こうと言い始めて「あっ、よさそう」と思えた。近くのパーキングエリアで出石そばを食べたらいいんじゃない？という案もあったが、出石の城下街へ行こうと押し切った。はまらないパズルのピースがはまった。学生の頃にツーリングで出石に行ったことがあったので私はどんな場所かを知っていて、お昼ご飯も食べられて少し観光もできてちょうどいいと思えた。

チェックアウト

11時に管理人さんが来られ、チェックアウトの手続きはすぐに済み、みんなで記念写真を撮って帰り始める。管理人さんは城崎温泉のことを質問すると、あれやこれやと教えてくれていた。すみよしさんが「出石そばのお薦めのお店知っています？」と管理人さんに尋ねた。私がそれは流石に知らんやろと横で聞いていたら「ちょっと待ってください」と即答で2店舗を教えてくれた。この管理人さんは何でも知っているんやなと感心して笑ってしまった。管理人さんは本当に親切でよい人だった。

このときの集合写真はきのいえのインスタグラムで公開されている。

• お宿で勉強会！

出石そばと城下町散策

11時に城崎温泉を出て出石の城下町へ向かう。40分ほどで着く。きのいえの管理人さんに教えてもらった 官兵衛 さんに訪問。お昼前で少し早かったせいか、ちょうど待たずに入れた。うちらがお店を出たときは2組ほど並んでいた。出石そばのシステムがわからなくて、注文するときに店員さんに尋ねると、大人男性ならだいたい10-15皿だという。ひとまず10皿を頼んで足りなかったらまた注文すればいいとのこと。まずはそばだけ食べて、その後に薬味を使って、卵は後半の方がよいと教えてくれた。私は、最初の2皿をそばだけを食べて、次にわさび、その後に葱や大根おろしを試し、とろろも入れ、8皿目ぐらいに卵をつかってみた。ちょっとした味のバリエーションにもなっていておもしろかった。私は10皿で満足した。

余談だが、まったく値段を知らずに入ったので、お会計のときにこれはいくらなんだろう？思いながら勘定をした。1人あたり薬味150円と皿そばが170円 * 10皿で合計すると1,850円 (税込) だった。おいしかったし、皿そばという名物を食べるという雰囲気も味わえてよかったのでまったく不満はない。純粋にそばだけだからそんなに高くないのかな？という先入観から想像以上だったので少し驚いた感じ。はらさんが「外国人を連れてきたらすごく喜ぶと思いますよ。」と2回ぐらい言ってた気がするので、これは大事なことなんだと思って、外国人を連れてきたらいいと私の記憶に残った。

その後、せっかく出石に来たから城跡も行ってみることにした。城跡には行ったことがなかった。城跡だから原っぱみたいな場所をみるだけかな？と考えていたら、石垣がしっかり残っていて3段目ぐらいまで登って街並みを展望できた。さらにもっと山を登っていけるようで、頂上までいくとそれなりの山登りハイキングができる場所になっているみたい。

私はまったく出石城のことを知らなくて、もともとのお殿様ではないが、なんやらかんやらで 仙石秀久 が城主になったらしい。センゴク の漫画の主人公。城跡に上る鳥居の裏に作者の宮下英樹さんの名前もあった。仙石秀久：鈴鳴り武者、またの名を蕎麦の伝道師…、あんたはいったい何者だ!? の記事によると、出石そばも仙石秀久が信州から出石へ転封したときに一緒に付いてきた信濃のそば職人が発祥になっているらしい。はーん。

西紀サービスエリア

ワーケーション1日目の反省点 にも書いたが、車の移動で行きはどこで休憩するかを決めていなかった。そうすると、どのタイミングでどこのサービスエリアに入っていいかがわからなくなってしまった。帰りは下調べして、休憩によさそうな設備があって中間の適切な位置として、舞鶴若狭自動車道の西紀サービスエリアがよさそうと調べていた。そして最初からナビの目的地をサービスエリアにしてしまうことで走り過ぎや休憩までのペースなども走りながら考える必要がない。当たり前のことなんだけど、自分で運転してみて初日はうまく段取りできなかったのでこれも大事な事前準備だと気付いた。

小さなふりかえりと神戸空港

神戸に戻ってきてから雨がぱらぱらし始めた。天候も何とかもってちょうどよかった。1時間ほどドトールさんで休憩しながら軽いふりかえりみたいになった。

• 朝と夜に温泉入るのは疲れる
  • 7つの外湯があり、パスポートを購入していても連続でお風呂に入る人はいなかった
• 開発合宿は2泊3日が限界
  • 非日常の慣れない生活は楽しさととも緊張もあるので疲労も大きい
• 実際にやってみることから得られる経験や体験はとても大きい
  • 城崎温泉がどういう場所か、その文化や歴史の一端を垣間見えた
  • 主催としてやらなければならない段取りや準備の経験を大きく積めた
    • 今回の経験をベースにして今後も課題管理システムに積み重なっていく
• 今後の開発合宿イベントの展望
  • オープン版は三ノ宮.devでやりそうなのでそこに便乗する
  • うちの会社の関係者や知人に声をかけてクローズドなイベントを1回/年でやる
    • (当面は) bizpy ではやらないかなぁ

その後、解散してはらさんを神戸空港まで送っていった。空港の場所は知っていたけど、実際に行ったことなかったので車で空港への行き方がわかってよかった。これで飛行機で神戸に来る人がいても送迎ができる。18時半にレンタカーを返却した。今回は日産 NOTE e-Power というハイブリッド車を初めて運転した。今回の旅程で約350km走って消費したガソリンは約15リットルだった。燃費は23.3/リットルだった。レンタカーを返して家に着いたらやり終えたなって感じで気分がよかった。

ストレッチ

いつもは土曜日の10時に通っているストレッチを、ワーケーションがあったので日曜日の19時半に変更してもらっていた。温泉に入った後に多少はストレッチをしたものの、運転疲れで体が硬くなってしまっていた。今日の開脚幅は開始前155cmで、ストレッチ後160cmだった。ワーケーションへ行ってきて疲れた後にストレッチを受けられるのは、疲弊した箇所がわかってとてもよかった。外湯に入るために普段より歩いたのものあって腰とふくらはぎの張りが強かった。その上で座椅子や車の運転なども相乗効果があって疲れが溜まっていた感じ。トレーナーさんと旅のふりかえりを雑談しながらストレッチを受けていて、週末どこかへ行ってきた後にストレッチを受けるのはすごくいいと思ってしまった。この場合、私の中ではストレッチがマッサージに置き換わってしまっている。