マスタカネット

最近は小さなチームのリーダーとしてチーム運営をしており、GitHub Projects を何年かぶりに使っています。 GitHub Projects は以前からありましたが、2022/07/27 に完全リニューアルし、GA (Generally Available) となりました。 Planning next to your code - GitHub Projects is now generally available | The GitHub Blog 最近の使い方 こんな前提です。 現在は自分含めた 3 人のチーム コア開発っぽいリポジトリと、案件ベースのリポジトリ合わせて 10 個くらいある 1 つの機能をチームで開発することはなく、それぞれが別々の開発をしている 出来るだけレビューを通した PR をマージするように、合意はしている そんな GitHub Projects を再現したものがこちらです。Issue/PR が少ないのはご愛嬌。😅 @masutaka’s trial project 各 view の使い方 Board いわゆるカンバンとして使います。 -status:Idea というフィルターのとおり、Idea カラム（後述）は非表示にしています。 Inbox や Backlog などのカラムには、短いながらも的確な Description を書いたつもりです。例えば In Progress の「１人１つまで」だとか。 Schedule 期間を決めた主要 Issue や、期日が決まった Issue のスケジュールは、ここで確認できます。...

先週の 1 on 1 で上司から「増田さんには合わないと思いますが(^^;」という但し書きの上で紹介されたので、逆にやる気を出して読んでみた。 確かに反論したい箇所は多々あるものの、その主張の根本を辿るとそうでもない気はした。むしろ合うかもしれない。 想定読者を読み誤っていた 全体的にリーダー（マネジメント）視点で書かれているので、プレイヤー視点で読むと、誤解が多く非常に良くなかった。← 最後まで誤解してた人 P11 この本は、そんな識学のメソッドを元に、「若手リーダー」に向けてマネジメントのノウハウを伝えるものです。 初めて部下やスタッフを持つような人、いわゆる「中間管理職」を想定しています。 最初ここを流して読んでしまったけど、この前提を忘れて読み進めたので最後までヘイトが溜まってしまった。 特に「プロセス（過程）は評価しない」には嫌悪感さえ覚えた。プレイヤーがプロセスを軽視して良いわけがない。業務の属人性が高まるし、再現性の低いものばかりできる。そんなものはプロフェッショナルの仕事ではない…と。 P173 そこでのひとつの結論は、「 プロセス（過程） は評価しない」ということ ここでさらにヘイトが溜まったけど、、（続く）ｗ P214 そこで重要なのが、第４章の「プロセスに口を出さない」ということでした ここで、逆説的にはプレイヤー視点ではプロセスが大事と言っていることに気がついた。💡 ※ これ、解釈が間違っていたら前提が覆るね (^^; P220 プレーヤーだった頃の自分を、部下たちがはるかに超えていく瞬間 。 ぜひ、それを体感していただきたいと思います。 はい、完全なマネージャー向けの本ですね。失礼しました…。 [2023-03-26-1] にも書いたけど、今は自分含めた４人チームのリーダーを任されたところで、且つ自分以外は業務委託の方々なので、想定読者ど真ん中ではなさそうだった。 エンジニア組織に合うのだろうか？ これは最後まで疑問だった。営業組織向けの本かと思っていたら、、、 P189 デザイナーやエンジニアの世界では、部下に対して、「上司が納得したらＯＫ」という設定をすることもあるでしょう。 ここでズッコケてしまった。うーん、大企業ならあるのか…？ まだ私に前職までの、スタートアップでのウェブプロダクト開発の空気感が残っているので、賛同し兼ねてしまう。これからあるのかあ…。🌀 肝心の感想 事実に対して淡々とフィードバックする。プロセスは見ない、結果だけにフォーカスする。 上司（≠プレイングマネージャー）と部下という関係なら、とても良いし、理想的とさえ思った。 本の中では 1 on 1 を否定していたけど、まさに [2023-03-26-1] の『ヤフーの１ｏｎ１ 』と同じことをしている。作者の方はダメな 1 on 1 しか見たことがないのかも。 まとめ そういうわけで、マネージャー向けには良い本だと思う。ボリューム少ないのも良かった。２時間ちょっとで読めた（重要）。 自分用読書メモ いいリーダーの言葉は、 「時間差」 で遅れて効いてきます。 これはそうかもね。最近小さく実感したところ（自画自賛）。 識学では、組織の成長スピードを考えたとき、「ピラミッド構造が最適であり、最速である」と考えます。 まだ自分の中で結論が出てないけど、条件付きで Yes かもしれない。 [2021-03-13-1] でも思ったんだけど、スタートアップのような能力密度の高い組織では成り立たない可能性があるから。 大阪市のような普通の人が多そうな組織で成り立つのだと思う。大企業もそうだと思う。 「この仕事はＡさんに任せた。契約に結びつけてください」 「来週の火曜の 15 時までに資料をまとめておいてください」...

数年ぶりに 1 on 1（をやるほう）をやることになったので、『ヤフーの１ｏｎ１ 』という本を読んでみた。 なぜこの本を選んだのかと言うと、前職で 1 on 1 をしてくれていた @meihong の記事 👇 で紹介されていたから。 🔗 コミュ障が1on1をやり始めたので参考になりそうなことを書いておく ※ この記事は自分の中でちょっとしたバイブルになっていて、必要な時に読み返しています。 もうひとつの『HIGH OUTPUT MANAGEMENT』は大事に積みました。(ｱｶﾝ 😅 感想 第１章がマンガでの事例で始まるので、読み始めが楽。ボリュームも大きくなく、流し読み程度だけど１時間 x ２日で読み終わった。 全体的なキーワードは「アクティブリスニング」と「信頼関係」だと理解した。 「アクティブリスニング」は「傾聴」と訳されることが多いが、日本語だと真剣に黙って聞くというイメージが強いため、ヤフーでは「傾聴」ではなく「アクティブリスニング」を使っているそう。 うなずいたり、相槌を打ったり、相手が発したキーワードを繰り返したりするため「傾聴」とは異なる。そうすることで、相手の頭のなかの今まで動いていなかった一部分を動かすことができるとのこと。出来る気はしていない…。 ありがちな失敗として、上司がアドバイスしようと思うがあまり、「どういうふうに進めたいの？」「誰かに相談した？それは誰？」などと自分の理解のために質問をしてしまうこと。それでは部下から上司の依存が強くなってしまうだけ。まあそうだよね。 「信頼関係」は一朝一夕で出来るものではないので、会社からの支援と、上司の日々の行動が重要だと思った。 個人的には「いつも気にしているよ」というメッセージもしくはシグナルを投げかけるようにしている。 具体的には、Slack の活動は見えるものは全部読んで、絵文字リアクションを適宜付けている。GitHub の活動も全部読んで、こちらも適宜絵文字リアクションを付けている。それらを朝会などで必要に応じて伝えている。どれも上司（リーダー）だからやっている訳ではなく、今までもやってきたことを意識づけしただけ。 現実にはそのメッセージも限界はある気はするので、まだまだ悩み中。🌀 まとめ ここまで書いたけど、今回私が始めた 1 on 1 は「上司と部下」ではなく、自分含めた４人チームのリーダーとメンバーなので、そのままでは使えない。例えば中長期にキャリアのことを話して欲しいなど。 とは言え、知識の整理や、心の拠り所にはなったので、実践や他のインプットも含めてやっていきます。 自分用読書メモ 1 on 1 では、考えを深めるツールとして「言い換え」をよく使う。 へー ヤフーでは、「アサインよりチョイス」と言っています。 めちゃめちゃええやないか。。。私もアサインという言葉は好きではない。 日本語での会話は、主語を省略することが多いので、カギとなるセンテンスでは、あえて主語を明確にすることによって、それが部下の本音なのかどうかを確認しています。 細かいけど重要なテクニック 傾聴するとは、真剣に聞くことではないと思っています。むしろ、話の中身はまったく頭に入れず「へえ」「そうなんだ」と返事をしていれば、話している側は勝手に内省を深めていくこともある。 面白い。 しかし、あまり間隔が空きすぎるのは望ましくありません。最低でも３週間に１度は行うようにします。 ですよね。私の場合だと 1 on 1 の相手とも話して、一旦２週間に１度にしました。 Q10. １ ｏｎ １で知りえた部下のプライベートな話は、どの程度周囲と共有してもいいのでしょうか？ A. 共有してはいけません。 ですよね。😅 私は第一回の 1 on 1 の時に、前提のひとつとしてお伝えしました。

前職フィードフォースで働いていた時から、チームを移動した後に見えた光景に「ああ…」という気持ちになることがあり、結果的にやっていることがあります。 フィードフォースの時もこんな記事を書きましたが、esa の社内記事に置いてきてしまったので、アップデートを加えつつまとめます。 この記事に触発される人には言わずもがなですが、どれも最初の現状把握のあとに行動することが重要です。現状把握なしの行動は、逆にチームのスピードを下げる可能性が高くなりますから…。 (1) ノイズを減らす まずはとにかくノイズを減らし、重要でない情報を目に入れないようにします。無意識のうちに集中が削がれるからです。 不要な記事はアーカイブもしくは削除 例えば、古くなったり要らなくなった社内記事はアーカイブもしくは削除します。 削除の判断は難しいことが多いので、アーカイブできるサービスを使うことが重要です。そういう意味ではアーカイブすると検索スコアが下がる esa.io は秀逸でした。検索対象から外さないのが素晴らしかったです。 Slack channel をまとめる Slack channel をまとめるのも良いでしょう。例えばめったに来ない通知用の channel をアーカイブし、チーム用の channel にマージするなど。 メールのノイズも減らす 個人ではメールのノイズも減らします。不要なメルマガは停止したり、停止できないメールは Gmail のフィルター等で目に入れないようにしたり。gmailctl [2022-02-13-1] のようなツールで、フィルターをコード管理すると意外と楽しくできたりはします。インボックスゼロを保つことが重要です。 (2) リンクを添えることを日常とする 社内記事や、Slack や GitHub でのコミュニケーションの際は、リンクを添えることを日常として下さい。 読み手に情報源を推測させない 例えば Slack で何か書いた時に、読み手に情報源を推測させないようにします。書き手はリンクを添えて、読み手に情報源を見に行く選択肢を作ります。書く回数は 1 回ですが、読まれる回数は多くのケースで 1 回よりも多いです。 これが根付くと、情報をいもづる式に辿ることが出来るため、情報取得の難易度が下がります。出来てない場合は、辿れず諦めるケースも多いかと思います。「誰かに聞けば分かる」みたいな、属人性が根付いてしまう危険性もあります。 古くなった文書を敢えて削除しない 少し発展的な使い方としては、古くなった文書や Google スプレッドシートは削除せず、新しい文書へのリンクを張り、誘導するのもとても良いです。古くなった文書をそのまま放置するのが、一番良くありません。 導線を作るのも良い なにか形が見えてきたら導線を作るのも良いでしょう。先月入社した会社では、一ヶ月かけてようやくこんな導線を作ることが出来ました。逆に言えばなかったので、最初の現状把握がとても大変でした。 チームのホームとなる Slack channel（新規作成） ↓ channel bookmark チームのホームとなる社内記事（新規作成） ↓ チームの GitHub リポジトリまとめ社内記事（新規作成） ↓ 各 GitHub リポジトリ の About に LookML プロジェクトの URL を追記 ↓ 各 LookML プロジェクト (3) 情報はできるだけ一ヶ所にする 現状把握が進み、文書をリンクで繋いだり、導線を作ったりしたら、いろいろ見えてくるものが出来てきます。例えば重複した文書を１つにまとめたり、似た情報の距離を近くしたり。...

訳者である岩瀬さんのツイートをたまたま拝見し、ちょうど先月入社した会社の部署で大きな課題だと感じていたところだったので、購入して斜め読みした。 loading... 本書の対象者は、ドキュメントを書くエンジニアやテクニカルライターではあるけど、ユーザー向けドキュメントのようにある程度の規模が想定されているように思う。 私が感じた課題はもっと原始的で、GitHub リポジトリに README.md がなく、どのような README.md を書けば良いか伝える方法を模索していたので、本書がど真ん中だったわけではなかった。 ※ 今は、既存ドキュメントへのリンクを張るくらいで良いので、まずは README.md を作るようにチームメンバーなどに伝えている。でもその先が難しい…。 ただ、最後の付録Bに出てきた「README チェックリスト」はチームメンバーへの説明のヒントになるかもしれない。良さそう。 ちなみに自分がドキュメントを作る時はこんな流れ。これでは伝わらない。😅 概要や書きたいことをとりあえず書いてみて、あれこれ並べる やっているうちに見出しが見えてくるので、文書構造を作っていく 文書自体はできるだけリストではなく、パラグラフ記法 [2021-11-29-1] を使います 詳細化したり、逆にバッサリ削除して、完成に近づけていく 読み手目線で書くだけではあるのだけど、それが難しいのだよね。書いたその日じゃなくて、次の日の少し冷静になった頭でもう一度読むなどの細かいテクニックはあるのだけど。 ドキュメントライティングに課題を感じている人は、何かのヒントになるかもしれないので読むと良いかも。

[2023-01-31-1] に書いたとおり、先月は前職の最終出社月でまるまる有給消化していたので 、平日に WORKAHOLIC というオフィスチェアのコンシェルジュサービスを体験してきました。 時間があったのもそうですが、去年の 6 月から急に背中のおかしなハリや首の痛みが耐え難くなったからです。おまけに微熱も続き、結果的に整骨院で直ったのですが、それはまた別のお話で。 loading... 予約〜来店 WORKAHOLIC のコンシェルジュサービスは完全予約制かつ有料制です。 2021-09-01 からそうなった ようです。電話もしくはウェブのフォームから予約します。2 時間 3,300 円。椅子は買わなくても問題ありません。 結構人気があるようで土日は予約が埋まりがちです。前述の通り有給消化期間だったので、平日の 1/10（火）13:00-15:00 で予約しました。 店舗の場所は秋葉原の隣駅、浅草橋から約 4 分です。着くと物静かなコンシェルジュの方が迎えてくれ、高さ調節が出来る机が、あらかじめ伝えておいた自宅の机と同じ高さに準備されていました。 そこで正しい椅子のセッティング方法を聞いたり、店舗に数ある椅子を試座して質問などしていました。ほとんどの時間を試座に使ったと思います。 購入〜到着 先入観を避けるために敢えて値段を見ずに試座を重ね、その場で購入したのがこちら。227,480 円です。た、高けぇ…。😱 ※ オカムラのページはこちら 最終的に 10 万円程度のバロンとの二択になりました。バロンも悪くはないのですが、座り心地が硬く、仕事以外のリラックスする時に座ることを考えてコンテッサセコンダにしました。もっと安い選択肢があっただろうことは認めます。 以前の椅子は 2 万円程度だったので、10 倍以上です。まさか自分がこんなに高い椅子を買うとは思ってもいませんでした。😅 そんな椅子が到着したのは 2/4（土）です。聞いていた 2 月下旬よりずっと早かったです。 3 週間使った感想 以前の椅子、同じオカムラのビラージュ が結構ひどかった事情がありました。 座面を調節できず、お尻を背面につけると膝が伸びてしまう。逆に膝裏を座面に合わせるとお尻の置き場所が安定しない 座面の素材がツルツルしている上、なぜか真ん中が盛り上がっていて滑りやすいので、無意識に力んでいた可能性がある テレビで YouTube を見る時などリラックスする時に、背面を倒した状態て固定できない。ヘッドレストもないので、頭の置き場所に困る どうして 6 年以上も使っていたのか。😇 一方のコンテッサセコンダはもちろん全部解決できています。 座面を調節して、お尻を背面に付けられるようになった。安定感が全然違う 背面を倒した状態でもちろん固定できるし、ヘッドレストがあるので頭の置き場所もある とは言え、PC 作業中は背中をベッタリ椅子に付けずに、自立するようにしています。 あまりに楽な姿勢だと腸腰筋などのインナーマッスルを使う機会が減り、肩甲骨周辺や首の痛みが再発する恐れがあるからです。整骨院でのトレーニングで（多分）インナーマッスルをうまく使えるようになり、以前よりはマシになったので、できるだけ維持したい気持ちがあります。 もっと言うと、整骨院の先生的には座りやすい椅子はかなりオススメしていませんでした。そういうわけで買ったことはあまり話していません。😅 まとめ WORKAHOLIC でコンシェルジュサービスを受けて、ハイエンドオフィスチェアを購入しました。 総じて満足していますが、我ながら椅子に 20 万円もかけるのはいかがなものかと思います。😅 コンシェルジュサービスを受けつつ、あれだけの椅子を試座できる機会はあまりないでしょうし、椅子を買わない選択肢はもちろんあるので、興味ある方は体験してみると良いと思いました。

本日 2023 年 1 月 31 日をもって、株式会社フィードフォース を退職しました。退職は人生 3 回目で [2014-03-09-1] に書いたラングリッチ以来です。 入社が 2014 年 3 月 1 日なので、8 年 11 ヶ月在籍していたことになります。新卒で入社したメタテクノの 11 年に続く長さです。 こんなに長く在籍するとは思ってもおらず、配属されたチームで目の前の課題に向き合っていたら、結果的にこれだけの期間在籍することとなりました。 いろいろ足りないところはあったと思いますが、フィードフォースならびに仕事で関わった皆様、これまでありがとうございました。楽しかったです。これからは一株主として応援しますし、将来また仕事で関わることもあるかもしれません。 これまでのロールを振り返る About 新卒で入社したメタテクノでは、2000 年 4 月から 2011 年 初めまで、組み込みソフトウェアエンジニアとしての経験を積みました。 次の会社ラングリッチからフィードフォース中盤の 2011 年半ばから 2020 年 3 月までは、Web のバックエンドやインフラまわりのエンジニアとしての経験を積みました。 フィードフォースの後半 2020 年 4 月から 2023 年 1 月までは、LookML 開発を中心としてデータエンジニアとしての経験を積み、これは次の会社でも続く予定です。 こうして振り返ると 10 年周期で、ソフトウェアエンジニアとしてのロールが変わっていることが分かります。 全く計画的ではなく、内発的か外発的かの違いはあれど「なんとなく面白そう」が動機です。経験を積んだり信頼を貯めたりして、どうにか「きっかけ」を掴んできたのだと思います。 共通するのが本業と並行して、チームや会社を便利にすること。 メタテクノでは UNIX ネットワークの管理者に立候補し、自発的にサーバーの保守やアップデート、便利ツールのインストールなどをした。チーム向けに自動テスト環境を作ったこともあった ラングリッチでは Redmine や Jenkins を導入し、アップデートにも追随した フィードフォースでは GitHub や CircleCI、Qiita:Team などを導入し、その後の運用にも責任を持った データエンジニアもその側面があると思うので、何かが繋がった気がしました。...

[2022-03-06-1] にも書いたとおり、佐々木俊尚さんの Voicy をなんとなく毎日聞いています。Web3 関係の本を出したということで、なんとなく買って読んでみました。それについての読書メモ。 「現在のウェブ３は、単なる権力奪取ゲームにすぎないと断言してもいいと考えている」には完全に同意。歴史好きの私としては、似たようなことが形を変えて螺旋状に続くと考えているので、ユートピアは来ないと思っています。 他もだいたい同意なんですが、自分の認識不足のこととしては「Zoom が平板な画面を並べているだけの二次元のオンラインミーティング」で「平面で全員が並んでいる」ということ。深く考えていなかったけど、現実のミーティングを再現しきれてなかったですね。 メタバースが究極的に進化すると、現実世界のミーティングや飲み会との差が少なくなるのかなと思いました。どの程度少なくなるのかは、とても興味があります。帰省とか楽になると良いな。 現時点では胡散臭く進化も不十分な Web3 やメタバースだけど、距離に関係する課題を解決できると良いですね。 ちなみに、人と人のあいだの距離は４つに分類できるそう。 密接距離 ↑ 近い 個体距離 メタバース 社会距離 例: Zoom 公衆距離 ↓ 遠い 他も Web3 のトークンエコノミーとは贈与経済ではないか？という話も興味深かったです。貨幣経済が「等価」という概念を生んでしまったことで、人間関係を持続させる手立てをひとつ失ってしまった。「貸し借り」を意識しづらくなる。なるほどね。

[2014-09-08-1] に引き続き、また健康診断で便に潜血が見つかったので検査を受けてきました。 実は 3 年くらい前にも引っかかっていたのですが、また誤検知な気がするのと、なにより準備と検査が大変なことを知ってしまったのでスルーしてました。あかん。🙄 💡 今回は閲覧注意な内容ではないと思います。 前回との差分 前回 今回 病院 河北総合病院 荒川外科肛門医院 洗浄剤 ムーベン モビプレップ® 麻酔の方法 注射 点滴 病院を変えたのは、世田谷区から荒川区に引っ越していたからです。歩いて 10 分ちょっとなのでだいぶ近くなりました。 洗浄剤はモビプレップでした。ほんのり梅干しの味がするので、自分は少し苦手でしたね。ムーベンはつい最近の 2022-10-11 に販売中止になってたのですね1。レモン味で飲みやすかったのに…。 麻酔は後述します。 準備から検査まで 前日の昼と夜は配給食でした。昼がクラッカーと野菜のクリーム煮、夜が鳥雑炊と大根のそぼろ煮です。amazon.co.jp で発見。 当日はなんと 6:00 過ぎに起きました。11:30 受付の関係で、6:30 から洗浄剤を飲むよう指示があったからです。前回は 8:00 起床、14:20 受付でした。内容はアレだし、前回とだいたい同じなので省略します。 受付後、検査の前に点滴を打たれます。まだ麻酔ではないとのこと。 前回の検査は医師と看護師で 2 人くらいだったのに対して、今回は看護師が多め。 検査が始まり、点滴が麻酔2に切り替わりました。なぜか喉の奥がカ〜ッとしてきて、1 分も立たないうちに検査が終わりました。え？と思ったら実は麻酔で意識が飛んでいて、実際は 15~20 分くらい経っていたようです。 まだはっきりしない意識の中、ポリープがあったので切除したみたいなことを看護師から伝えられました。その後数分で意識は復活。痛みや違和感などはありません。 着替えた後で、大腸内部やポリープの写真を院長から見せられつつ、1cm のポリープを切除したこと、これから 2 泊 3 日の緊急入院だと告げられました。 え、緊急入院！？😳 突然の入院 入院なんて人生初です。年末にビッグイベント到来や！😭 とは言え、命に危険が迫っている訳ではなく、以下の偶発症に対応するためのようです。 ① 出血：0.007%（ポリープ切除による出血：1~2%） ② 穿孔：0.02%（約 5000 人に 1 人） ③ ショック：0.0009% 「2 泊 3 日ならなんとかなるっしょ！」と思うことにしました。...

Python は今まで雰囲気で読んでいて、データまわりだとちょいちょい出てくるので購入した。購入したと言っても ￥250 と破格な上、kindle unlimited だと無料。 63 ページと短いので 1 時間もかからずに読めた。 プログラミング経験者がなる早でつまみ食いするには良いかも。さすがにもう変数の説明から読むのはしんどいからね。デコレータや引数や戻り値の型指定など、書かれていないことはあるけど、必要あれば起点に深堀りすればよい。 こういうさくっと読める本好き。