Posts for: #Founding

スキルの定量化とお仕事探し

#founding  #career  #medium  #management 

0時に寝て7時に起きた。直近は日曜日はだらだらしてたんだけど、すんなり起きれた。

お仕事探し

offers さんのカジュアル面談 の雰囲気から企業に直接応募するプラットフォームの方が、私の経歴や実績の詳細を確認しやすいので面談に進みやすいのではないかとみている。そこで findy と lapras のプロフィールを作成してみた。これまで oss 活動やブログなどでアウトプットしていた資産がたくさんあるのでレベルはしょぼいにも関わらず、これらのプラットフォーム上ではそこそこよい数値がアルゴリズム的には算出される。プラットフォーム側としては転職やエンゲージメントを高めたいという意図があるから、ゴーストアカウントのようなものも含めて算出すると普通の人は高めの数字が算出されるのではないかと推測する。

findy さんのスキル偏差値によると、想定年収予測は1060-1160万円らしい。この数値は起業する前のサラリーマン時代の年収に近いのでそんなにずれてはいない。lapras さんの公開プロフィール によると、技術力が4.01で約170万人中668位だというのは上位 0.04% に属することになってしまう。んな、あほなという思いはある。とはいえ、自己申告の経歴をいくらでも盛れる職務経歴書よりも、客観的なアルゴリズムで評価できる指標の方が絶対値が適切かは置いておいても、相対評価において他の候補者と比較できるのを好む採用担当者もいるだろう。匿名の一般的な職務経歴書を用いる remogu さんの選考 は書類選考でばんばん落ちまくる。それに比べたら、アルゴリズムで相対的によい数値が出ているプラットフォームの方が面談に進みやすいのではないかという話し。本当にそうかどうかの仮説はこれから検証する。

google の従業員が働いていないという発言の真意

昨日たまたま medium のダイジェストでみかけた記事を読んだらおもしろかったので、なるべく余裕のある日は medium の記事を1つ読むようにしてみようかと思う。言うても deepl を使って斜め読みして大意を掴む程度なので日本語の記事を読むのとそんなに時間が取られるわけではないと思う。今日は次の記事を読んだ。

プログラミングにおける生産性とはどういうものかを説明しつつ、google の ceo がいう生産性が十分ではないという発言の真意は、従業員が業務時間にさぼっているとか怠慢だとかいう意味ではなく、google のビジネス全体がこれまで達成してきたのと同じ業務時間では期待した成果を達成できなくなってきているのではないかと考察している。

At some point, productivity measurement becomes Schrödinger’s cat.

また著者の引用？では生産性の計測とはシュレディンガーの猫のようなものだという話題もおもしろい。どんな会社もある時点での生産性の測定はシュレディンガーの猫のようなものになる。セグメントを分割し過ぎると返ってストレスとなり、余計な混乱を招き、計測そのものが生産性を低下させる。生産性の測定はマクロレベルでやるのが理に適っていて、工場時代のマネジメントをもつ amazon は大量の人員削減をしつつも成し遂げた。google のようなワークカルチャーをもつ会社ならその気になればスマートにできるだろう。一方で google という会社はすでにリベラルな極みにある企業文化をもっているため、生産性を測るような試みは組織全体に大きな感情的ダメージを与えるだろう。その結果として amazon と同じような道を歩むのではないかと。

シュレディンガーの猫がどういう意味かもわからなくてそれも読んでた。

若い会社とのエンゲージメントを図る

#founding  #career 

23時に寝て5時だと思って3時に起きてそのまま家事をやって5時から働いてた。早起きすると暇つぶしのように溜まっているタスクをこなし始めるので早起きは三文の得というのは本当だ。非稼働日だけど、午前中に次のタスクの要件のヒアリングだけやっといて、月曜日の朝一から作業できるように調整しておこうと考えたが、今日は開発リーダーが休みだったので何もしなかった。

カジュアル面談

Offers というサービス でみつけた会社にカジュアル面談を申し込んでいた。エンジニアリングマネージャーを業務委託で募集しているのは珍しかったのでその背景などを聞いてた。面談してくれた方はテックリードと言っていたが、この人も副業で手伝っているらしい。雰囲気的に若い会社のようで正社員はほとんどいなくてチームのメンバーが10人ぐらいのうち正社員が1-2名だという。基本的に外部の寄せ集めメンバーがそれぞれ副業や業務委託で空き時間を使って開発しているといった話らしい。8時間/週といった契約のメンバーもいるとのこと。どんな人を採用するにしてもまず業務委託から始めるというのがその会社の方針らしい。信頼関係という視点からみると、このような経営者にとって都合がよい労使関係を嫌う人もいるのではないかと思う。一方で私は雇う側も働く側もお互いにマッチングしないときの不幸を防ぐには1-3ヶ月ぐらい働いてからお互いに望むときに採用するといったやり方の方がよいと考えている。実際にマッチングしない人の場合は1週間で見切りをつけるとかあるらしい。私自身、初めてお手伝いする会社は最初の3ヶ月とかは1ヶ月契約でも構わないと伝えることがよくある。その後、お互いにマッチングするなら3-6ヶ月の契約期間に延長したいと交渉する。20年働いてきて、過去に試用期間で解雇されたことや1ヶ月で即解約になったことはないので一定の自信もある。

テックリードが若かったので組織もチームもメンバーも若いのだろうという印象を受けた。業務的にはお互いにマッチングしているように私からは思えた。あとは単純にテックリードが話してみた感覚や相性で私のようなベテランを求めているかどうかで次の選考の有無が決まるのではないかと推測する。次があったら正社員の人とも話してみたい。

遊休の日々

#founding  #career 

0時に寝て4時に起きた。5時からドラクエタクトしてた。

運用対応と遊休

今日も本番環境でトラブルがあったらしく、その対応で開発リーダーが忙しくて、お昼にあるチケットの仕様を決める小さい打ち合わせ (15分程度) を経て対応しようと思っていたのに、最終的にそれができたのは19時半になった。当然、実作業もやってない。昼間の3時間を休憩時間として別のお仕事をしていた。9月から新たにフロントエンド開発者が入って、チームの開発者が7人になって開発者が遊休する状態に拍車がかかった。本当はチームを分割すればいいけど、チーム事情でできず混乱している状態。権限委譲もできてないのでチームを任せられる開発者が他にいないのだと思う。人を教育せずに人数だけ採用して開発チームを拡充してきたのが垣間見える。古いプラットフォームの仕様を知っている人が1人しかいないといった状況は大変そう。そういう開発や組織を是としてきた先駆者の責任でもある。そんな組織の開発者が外部でいいことばかりを言っているのをみると、よい開発者が入ってきても騙されたと思って定着しないのではないかと思う。私がみえる範囲でもよい開発者がいないので組織における開発リーダーの重要性を実感する。

次のお仕事探し

たまたま求人検索していて Offers「オファーズ」 - エンジニア・デザイナーのための副業・複業・転職サービス というサービスをみつけた。ちょっと前に求人プラットフォームを開発していたのでいくつかの求人サイトに登録して調査したりしていた。その中でもこのサイトは上位に入る優れた品質だと思う。一番嬉しいのが職務経歴を linkedin からインポートしてくれる。求人プラットフォームでもっとも嫌なことは、それぞれのサイトごとに職務経歴書を作らないといけないところ。プログラマー的に同じ作業を何度も繰り返すことに苦痛を感じる。比較的新しいサイトなのでどういったものか、わかっていないけど、サイトの使い勝手がよかったので縁があれば面談もやってみようと思う。

mvp とその目的

#founding  #scrum 

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

隔週の雑談

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

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

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

むきなおり

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

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

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

会議だらけの1日

#founding  #scrum  #community 

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

隔週の雑談

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

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

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

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

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

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

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

神戸市さんと雑談

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

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

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

エージェント会社と雑談

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

不思議の国のスモールオフィス

#life  #founding 

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名の会議室でどんな会議をやるねん？オフラインの外部勉強会をやるとしたらスペースが広くて快適そうな場所ではあった。あと後ろの方はモニターみえないよね、おそらく。

スクラムのふりかえりは感情に寄り添い過ぎ

#founding  #scrum 

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

内覧前に…

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

大ふりかえり大会

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

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

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

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

ホテル経営の本を読み終えた

#book  #founding 

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

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

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

第10章 不動産屋の悪知恵

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

  • 普通借家
  • 定期借家

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

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

第11章 エピローグ

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

あとがき

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

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

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

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

localstack s3 想像以上に難しかった

#founding  #java 

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

localstack 入門

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

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

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

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時間といったところかな。

ゾンビスクラムを教えてもらった

#founding  #scrum  #book 

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

隔週の雑談

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

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

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

ゾンビスクラム

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

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

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

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

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

法人決算の会計処理を終えた

#founding  #tax  #web3  #event 

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

算定基礎届

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

振替伝票の使い方

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

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

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

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

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

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

はんなりDAO

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

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

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