Posts for: #Management

個人の人生と会社の経営

1時に寝て6時半に起きた。久しぶりに起きずに長時間眠れた気がする。1-2ヶ月に1回あるかどうかぐらいの感覚。

リファクタリング

ここ最近、私がバックエンドのリファクタリングを集中的にやっている。私からみたらバックエンドの設計にはいくつか改善の余地がある。動いているという視点では及第点ではあるし、メンバーは限られた時間の中で十分にうまく開発していると考えている。それでも、遊撃として余裕があるときにリファクタリングをしている。これから運用レベルの QA テストに入っていく。その前にがーっとリファクタリングしておくとテストで振る舞いを検証できるし、テストで別の不具合をみつけたときも保守コストが下がるように設計を洗練させておくことには一考の価値がある。実際にコードを書き始めると時間をどんどん取られて、マネジメントの業務から離れていってしまう。マネージャーがコードに集中し過ぎるのも問題だというのも理解できるようになってきた。本来はあまり深入りしない程度にメンバーに要点を伝えて改善したもらうのが正しいとは思う。いろいろプロジェクトの都合があるので必ずしも思い描いたようにはいかない。バランスをとってうまくやりたい。

余暇と経営と個人

1月以降は実家の法事のために私の余暇の半分程度の時間を取られている。先週末に49日を終えたので次の法事は初盆まで余裕がある。とはいえ、弁護士さんと実家と相続のやり取りがあってまだ何割か時間を取られている。この余暇の時間に、これまでは自社の業務や事務手続きをしている。その余暇が少なくなると、最終的には他のところにも皺寄せがいく。余暇に余裕がないと自分の会社を経営するのはなかなかしんどいところもあるかもしれない。

来季は実家の一部を自社のオフィスにしようと考えている。よくよく考えれば、神戸のオフィスでフルリモートワークをするのも、淡路島のオフィスでフルリモートワークをするのも、お客さんからみたら全く違いがない。いままでそうしてこなかったのは、神戸のオフィスでは業務に集中できるよう、私にとって最適な環境を構築し続けているからと言える。最も大きな違いは椅子だと思う。よい椅子でデスクワークしていると、あまり粗末な椅子でデスクワークしたくないというネガティブなモチベーションになってしまう。

メインオフィスと同じとはいかなくても準ずる程度のオフィス環境を実家に構築できれば実家に帰って1-2週間程度のフルリモートワークをしてもよいと考えている。その延長上で実家との行き来を出張扱いにして経費を使えるようにし、経営的にはそうすることで節税にもつながる。私個人の視点からも、親の介護という、私の人生設計上避けられない問題に対する解決策となる。個人の人生の問題と会社の経営を両立させることは、自分の会社であれば、十分に両立できると自信をもって言える。この話しも田舎から上京してその後のキャリアを考える上でのモデルケースの1つとして、いつかブログの記事として書きたい。

マーケティングと炎上

0時に寝て6時半に起きた。夜にコードを書こうと思いながらネットで遊びながら寝てしまった。今日は echo 移行のコードを書いていてレビューしてもらったりしていた。11月入ってから業務中に数時間コードを書いたのは初めてかもしれない。

あるサービスの社長とマーケティングと承認欲求と

昨日たまたまタイムラインであるサービスを退会したというツィートをみかけて、なんかあったんやろかと調べたら note の記事が原因だとすぐにわかった。私が読んですぐ思ったことは次の曖昧な姿勢でこれはまた物議を醸しそうだと思えた。

  • 事実はどうだったのかの結論が曖昧
  • 事件はなかったと明確に書いているのに相手と示談したという矛盾
  • 自社の当該社員に落ち度があったという矛盾

被害の有無について私はまったく知らないし関心もないが、虚偽なら虚偽と書けばいい。内容からなんらかの被害はあったようにも受け取れるため、被害者への配慮がまったくないことに懸念を感じた。いかなる背景や理由があろうと、被害を被った人がいる場合にその内容について書く文章はただ事実と謝罪のみである。過去の謝罪会見などで言い訳して余計に非難を浴びる事例はたくさんある。当事者としてできることは謝罪することしかない。これがまず鉄則。当該記事にはその姿勢がまったくみられなかったために炎上に至ったのではないかと思う。

リスク管理の専門家とも相談していてなぜこんなことが起きるのか。sns 慣れからの承認欲求もいくらかあると思うが、社長として「世間の耳目を集めるネタ」を入手したと思ってしまったのではないか。コンテンツを作るにはネタが必要でそうそう毎日おもしろいネタなどない。今回の事件は滅多に起きる事件ではなく、マーケティング的におもしろいネタになるとそのサービスの社長は考えたのではないかと推測する。リスク管理の裏側を語っていて、その在り方にクレームをつけている人たちもいる。私からみたら会社なんてそんなもんという内容でしかない。しかし、それを公けにすることで被害者が傷つかないかというのをまず第一に考えるべきである。もしこの被害者のインシデントが虚偽であればまったく問題ない。しかし、そうではないにも関わらず、会社のリスク管理の詳細を被害者が読んでどう思うかという配慮がまったくなかった。私からみて嬉々として詳細を書いてしまい、会社の危機に陥っているようにみえる。

おそらく社長個人の人柄や性格は悪くないのだと思う。自分の会社や身内を守ることのみに頭がいっぱいになってしまった結果、被害者への配慮という視点が抜け落ちてしまったのではないかと思える。私自身、そう在れるかどうかはともかく、経営者として客観的な視野をもって日々の業務の判断を下すように努めている。自社の損得ではなく論理的に考えて落とし所はここだろうという、私なりの論理最適解を顧客に提案するようにしている。このインシデントは社長が自分たちの会社のことしか考えなかったから発生したもので経営者の姿勢を問う事例の1つであると私は考えている。この状況からその会社がどういった顛末になるのか、今後の動向もみていきたい。

課題の洗い出し

20時に寝て0時に起きて、3時に起きて6時に起きた。春先のような、なぜかたくさん眠れる状態になった。

ソースコードを読むマネージャー

アリエルをやめてから複数の組織で働いてきたけれど、以降ソースコードを読むマネージャーを1人もみたことがない。アリエルなんか cto が日々の開発のソースコードを読んでいたぐらいなのに。もしかしたらテックリードというマネジメントはしないが、開発のリーダー役のポジションができたせいかもしれない。そしてエンジニアリングマネージャーがソースコードを読んでいるのも見たことがない。いま私はプロダクト開発のマネージャーとしてお手伝いしているわけだけど、毎日変わるソースコードを読みながら、私が懸念に思ったコードについて issue 登録したり、技術的な課題であれば改善提案したりしている。もし開発リソースが足りそうになければ、私も開発に参戦しようと虎視眈々と狙っているのもある。

まだ初期開発フェーズなので粗いところが多々あるから読みがいがある (提案しやすい) というのもあるかもしれない。ソースコードも読めない (読まない) マネージャーが開発の進捗を正しく検査できると私は考えていない。その姿勢でプロジェクトマネジメントがどのように進捗して、どのような結果になるのか、これから私が実践して自分なりの考えをまとめたい。

まずは定例会議から言語化する

23時ぐらいに寝て2回ぐらい起きて7時に起きた。やっぱり家だとうまく眠れない。

mermaid の er 図

メンバーが mermaid の Entity Relationship Diagrams でデータモデルの図を書いてくれてレビューしてた。見た目もすっきりしていて、テキストも書きやすい方だと思うので印象はよかった。gitlab でもリポジトリや wiki で mermaid で書いた図を表示できた。

定例会議の進め方

マネージャーっぽいお仕事の1つとして定例会議を週に1回行う。スクラムにあるデイリースクラムのような、毎日メンバー全員を集める会議するのが私は好みではない。そんなことしなくても定例会議が週1で 1on1 が週1回ならば5日のうち2回は話すし、あと個別の打ち合わせも1-2回やれば十分に話す機会を得られると考えている。定例会議の進め方というドキュメントを一通り書いてみた。私が忘れたときに見返したり、実際にやってみてよかったこと・わるかったことを振り返りながら改善するための、基準として設けた。基準があるから改善できる。最初の1-2ヶ月ぐらいはうまく成果がでなくて悩むことも想定しつつ、過去に書いたドキュメントがそういうときの拠り所になる場合もある。

オフラインのもくもく会

19時ぐらいに一口寝ようと思って寝たら0時過ぎまで寝てしまって、それから4時過ぎまで作業して寝て7時に起きた。出張の慣れない環境で生活が不規則になってきた。

ドラム式洗濯機

泊まっているホテルの部屋に備え付けられていたので洗濯・乾燥した。館内設備として有償のコインランドリーがあるのは普通だと思うけど、部屋に洗濯機があって無料で使えるのは長期出張客を対象とした差別化の1つだと思う。乾燥もしてくれるならうちの洗濯機もドラム式に変えようかなと使いながら思った。

もくもく会

出張もくもく会 を開催した。8人が参加してくれた。知り合いが5人でそうじゃない人が3人も来てくれた。初めて行った場所のコワーキングスペースの会議室だから設備をわかっていなかった。8人で作業するにはちょっと窮屈な部屋と外の工事と換気扇がややうるさかった。もくもく会をやる上で我慢できないほどではないが、あまり参加者の満足度は高くなかったかもしれない。私は3つの作業を目標として作業してた。

  • 日記を書く
  • 課題管理勉強会の資料作り
  • go 言語の勉強

上の2つはできたが、それで疲れて go 言語の勉強はしなかった。17時から成果発表。なんだかんだで全員発表してくれたと思う。物理的にモニターやプロジェクターに接続しなくても zoom に参加してマイク/スピーカーをオフにして画面共有すればよいと教えてもらった。これはテレビ会議が当たり前になったいまのプラクティスとしてよいなと思えた。

後の飲み会

もくもく会が終わってから5人で飲みにいった。参加者が知り合いを1人呼んで6人になった。2時間半制で18時から始めて20時半で終わった。眠かったのと翌日も飲みに行く予定があったので私はそこで帰ってホテルで2時間ほど寝てた。昔は当たり前だった勉強会後の飲み会というのも久しぶりの感覚で楽しかった。

知り合いだけならうちの会社の経費で落とそうかと考えていたものの、その考えがまとまらないうちに割り勘になってしまって、自身の優柔不断さを悔いた。会社の経費を使う理由は売上につながるかどうかというのが原則になる。知人であれば、日常的にお世話になっているからという大義名分が私の中で成り立つものの、そうじゃない状況になってしまったことで私の中で論理的に説明がつかなくなって接待として経費で落とすという決断ができなかった。個人ではなく経営者として判断するときは理論武装してないと固まってしまうことに気付いた。

イベントはしご

1時に寝て4時に起きて6時に起きた。

jackson の tips

jackson で調べているとググったときに stackoverflow に書いてある内容が、機能的には正しいけれど、deprecated になっているアノテーションが多々ある。そのときに新しいやり方はどう設定していいか分からないということがある。今日たまたま実装した処理に2つアノテーションが出てきたので備忘録として書いておく。

@JsonNaming(PropertyNamingStrategies.SnakeCaseStrategy.class)
  • デシリアライズするときに my_field のようなスネークケースのフィールド名を myField のメンバーにマッピングする
@JsonIgnoreProperties(ignoreUnknown = true)
  • デシリアライズするときに json に存在してクラスに存在しないフィールドを無視する
  • データ構造の移行時にエラーを出さないとか、不要なフィールドがあるときに設定するとよい

上司道 リーダーはレジリエンスを高める自己肯定感を学ぼう

以前 SECI モデルのワークショップ に参加して、同じチームにおられた方が 上司道 という勉強会コミュニティを運営しているのでお誘いを受けた。せっかくの縁だと思ったのでコミュニティに参加した。その勉強会で 日本セルフエスティーム普及協会 の工藤氏による自己肯定感の紹介イベントがあったので試しに参加してみた。

軽く私の自己肯定感をチェックしてみると普通。低くも高くもない。私はどこかのタイミングで他人と比較するのをやめた。それは自己肯定感を高めるためにはよい慣習らしい。そのおかげで私は自己肯定感が低くはないようにみえる。自己肯定感には社会的と絶対的の2つの構成概念がある。

  • 社会的自己肯定感
  • 絶対的自己肯定感

重要なのは絶対的の方になるらしいが、多くの人は社会的の方が割合として大きいらしい。社会的に頼っていると、キャリア戦略に失敗したり、会社でリストラされたりすると自尊心が傷つきやすくなる。私もこのタイプだと思う。近い将来リストラされることを想定して自分の会社を作ったという背景もある。自分の会社があると、自分で自分をリストラしない限りは集団に帰属しているという社会的欲求を満たせる。それが社会的自己肯定感と関係があるように思える。いまの私の環境は自尊心が傷つきやすい状況ではないため、あまりセミナーの内容には関心をもてなかった。それよりも参加者が共有していた自尊心を脅かされる状況の経験談にひどいものが多くて、それらと比べると私の環境は恵まれていて世の中に感謝する気持ちになった。

後藤達也さんのオンラインミーティング

たまたま21時半からコアメンバー向けの zoom ミーティングを行うという投稿をみかけたので参加してみた。2時間ぐらいやってたのかな?軽く聞いて帰ろうと思っていたものの、なんだかんだで最後まで参加していた。

軽く計算すると note のメンバーシップだけで約774万円/月の売上になる。すごい。

(500 * 9577) + (3016 * 980) = 7,744,180

こんな儲かっているサブスクリプションの新規募集を停止する背景として、これ以上コアメンバーが増えてもコミュニティとしての運営が難しくなるからやりたくないのだという。例えば、すでに3000人いるが、この人数でオフ会を開催することはできない。月々の料金を高くしてメンバー数を減らすというのが経済学的な解であることは理解しているが、後藤さん1人で提供しているようなサービスに月980円を超える料金をとることに抵抗感があるから値段をあげたくないと話されていた。とても謙虚な人だと思う。コミュニティ運営を難しくせず料金もあげないという戦略からコアメンバーをこれ以上増やさないという判断をしたそうだ。

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

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

お仕事探し

offers さんのカジュアル面談 の雰囲気から企業に直接応募するプラットフォームの方が、私の経歴や実績の詳細を確認しやすいので面談に進みやすいのではないかとみている。そこで findylapras のプロフィールを作成してみた。これまで 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 と同じような道を歩むのではないかと。

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