2021年新卒研修で使った資料です。 “Managing up” をキーワードに、以下の内容について話しました。 1. リーダーとメンバーの関係 2. 自分のリーダーを理解する 3. 効果的な1-on-1のために 4. Engagement Suite他のツールを活用する --…

仕事をしていると、だんだんと抽象度の高いことを任されるようになる。 たとえば、方針も明確な小さな修正タスク => 修正方法がいくつか考えられるタスク => そもそも何をやるかから明確にしないといけないタスク といった感じで次第にふわっとした依頼になってくる。いわゆるグレード制を採用している会社において、"どれだけ抽象度の高い仕事を任せられるか" がグレードの違いの要素のひとつと言ってもいい。 抽象度の高い仕事を安心して任せられる人は何が違うのか自分もよくわからないので、自分のまわりの人がどういう動きをしているかを雑にまとめてみる。 1. なぜやるかを明確にしている わからないときはドキュメントやチャットのやりとりを探し、直接聞いたほうがよい人には自分でコミュニケーションを取っている やる理由がないと判断したら依頼者に話をして、実際にやらないこともある あとで「自分はこう言われただけなので」

春だ。初めてソフトウェアエンジニアとして働き始めた頃、いつも機能のレビューで突っ込まれまくって涙目になっていたのを思い出した。今ならそんなことにはならないので、意識していることを雑にまとめておこうと思う。 今の状況を最初に伝える ざっと考えた仕様や、とりあえず作ってみたプロトタイプを見てもらおうとしただけなのに、めちゃくちゃ細かい部分まで突っ込まれて「あー今そういう感じじゃないのになぁぐぬぬぬ」となったことはないだろうか。これを防ぐには、最初に今の状況を伝えて認識を合わせておくとよい。 「先に今の状況を伝えておくと、まだ完成度は20%くらいです」 「まだ叩き台なのでアラも多いと思うんですがとりあえずざっと作って持ってきました」 みたいな一言があるだけでもだいぶ違う。大事なのは、これを最初の説明で自分から言うことだ。意見をもらい出すと相手も白熱してきてなかなか言うタイミングが難しくなることが

Page Scrolling Vertical Scrolling Horizontal Scrolling Wrapped Scrolling

こんにちは。ぼへみあです。 突然ですが、電気のブレーカーをいきなり落とされるのって、かなり暴力的だと思いませんか？ 安全上、定格電流を超えると危険なので、遮断しなければいけないのは理解できますが、 「電気を使いすぎています」という警告すら一切なく、特定の家電だけが使えなくなるのではなく 突然全電力をカットされるというのは、やりすぎだと思うのです。 昔の家電なら良くても、今の情報家電では、PCやハードディスクの書き込み中に電源を落とされると、ソフトウェア的に死ぬこともあります。 将棋のマスク反則負けでも、一度の警告すらなくすぐに反則負けにされたことが不服だと聞きましたが 電気のブレーカーも、何の警告もなしに電力全カットは、今時のシステムじゃないと思います。 そこで今回は、ブレーカーを落とさないよう、警告してくれる&部分的に家電をOFFにするシステムを作りました。 デモの様子です。 www.y

もう長いこと味噌汁を食べて暮らしている。土井善晴氏の提唱する一汁一菜生活だ。簡単なので仕事に疲れた日でも作れる。味噌はそれだけで美味しいし具から出汁が出る。具の組み合わせによって細かく味が変わるため、飽きることもない。土井善晴氏のいうとおり、持続できるライフスタイルだった。 しかし、いくら味噌汁が楽とはいえ切り物が面倒だった。キャベツは手でちぎれば良いが、玉ねぎや茄子も食べたい。人参やカボチャをちぎるわけにはいかない。どうしても包丁がいる。まな板を出すのも面倒だし、何より刃物を扱うには注意力がいる。疲れた日にやることではない。一汁一菜の唯一の難点が野菜の加工なのだ*1。 こうして行き着いたのがカット野菜だ。ただし、カットされた野菜を買ってくるのではなく、自分でカット野菜を作る。好きな具を選べるのが一汁一菜の醍醐味だからだ。 野菜は余裕のあるときにまとめて切り、タッパーかジップロックに入れて

以下の文章は、コリイ・ドクトロウの「AI is how bosses wage war on “professions”」という記事を翻訳したものである。 Pluralistic 子供の頃、私は「プロフェッショナル」とは何かの対価として報酬を得ている人間のことだと思っていた。その定義自体は完全に正しい（自分の文章に初めて原稿料が支払われたとき、「プロ」になったという実感が湧いたことを今でも覚えている）。だが、「プロフェッショナル」にはもう1つ、はるかに重要な定義がある。 こちらの意味における「プロフェッショナル」とは、雇用主の要求にも国家の要求にも優先する行動規範に縛られた人間のことだ。医師のヒポクラテスの誓いを思い浮かべてほしい。「まず害をなすなかれ」と誓った医師は、患者を害する命令を拒否する義務を（文字通り）負っている。病院の管理者、警察官、裁判官のいずれが医師に患者を害せと命じようと

これは何? RealWorld 業務 Rust に乗っかって普段から考えているなんやかんやを参照可能にしておく. 主に情報の補足と極論の補正 1. 但し業務というコンテキストは外してだいたいいつでも適用できるようにする. legokichi さんの考えには少なからず影響されていることに注意. 皆も自分なりの考えを書こう! (これ とかもどこかにまとめたいわね...) Re: docker でビルドできるようにしとけ docker でビルドできるようにしておくこと自体は大事なんだけど, 最近は Asahi Linux (aarch64) があり docker が絶対とは言えなくなってきた. そんなマイナー環境使う方が悪い? それはそう... (なので x86_64 環境も持っている.) なお今年の ISUCON14 では cross を使った. メンバーが Linux (x86_64), M

RealWorld 業務 Rust 実際に Rust 1.0 の頃から業務で Rust を使ってコードを保守してきてハマった落とし穴についての 知見 恨み言です Rustが素晴らしい言語であるというあたりまえのことにはこの文書では触れません 気が向いたら追加します 開発環境編 ビルドマシンを買ってもらえ ノートパソコンのCPUとメモリでは限界がある CPU 二桁コアのマシンを何人かで共有して使え VSCode の Remote SSH でがんばれ vim でもいいぞ ストレージは可能な限りデカくしろ target はブラックホール 10GB 超はあたりまえ、中には 100GB 超も sccache、 cargo cache 、 cargo sweep などを駆使してがんばれ docker も使うので大容量ストレージだけが正義だ sccache 使用例

組織で物事を進めるのが早い人は、"提案"のコミュニケーションを取っていることが多い気がする。 "指摘"で止まるのではなく課題の解決に向けた"提案"までやる方がいいんだけれど、そもそも提案って一言で言ってもまあ難しいよね。とある1on1で雑談していて、"提案"のスキルを上げていくにあたってはいくつかのレベルに分けて考えてみるといいかもしれないと思ったので、声かけのワード別に自分の考えを雑にまとめてみる。洗練されていないので意見がほしい。 レベル0: 「どうすればいいですか」 何か問題があった時の「どうすればいいですか」という聞き方は提案ではなく指摘で止まっている。 指摘してくれるということは気づいているということだし、それを伝えてくれること自体も素晴らしいことなのだけれど、そこからどうしていくかを決めるのが大変な部分なので次のレベルにも染み出していきたい。 レベル1: 「どれにしましょうか」

権限委譲でよくある失敗として、「権限委譲しきれていない」というのがある。気になってちょいちょい細かく口を出してしまうのだ。自分の経験だと、もともと優秀なプレイヤーだった人に多い気がする。 権限委譲する側でもされる側でも改善はできるが、どちらかといえば権限委譲する側の方がコントロールしやすいので意識するべきことを雑にまとめておきたい。 自分の集中するべきことを明確にする 口を出してしまうのは、口を出す余裕があるから 委譲した分何か別の集中するべきことがあるはずだが、それが明確じゃないか忘れてしまっている 自分が為すべきことを明確にして、優先順位を考えるべき 期待の認識を合わせる 口を出してしまうのは、期待を下回っているように感じてしまうから そもそもどこまでを期待していて何を任せているのか認識を合わせた方がいい デリゲーションポーカーなどで委譲の分野やレベルなどを確認するべき 情報が渡ってい

意思決定できる人は進める手順の型みたいなものを持っているように見える。逆に意思決定が遅かったりできなかったりする人は、進めるときに型のうちの何かが欠けているのかもしれない。 体系化された話は書籍で語られつくされているとは思うが、思考整理のために雑にまとめてみる。 最後は決めるだけだという考えを持つ 目的や満たしたいことを明確にする 最終的な決め方や期日を明確にする 選択肢を広げて考える 今は意思決定しない、という意思決定も選択肢に入れる 意思決定の軸を明確にする 軸をもとに定量/定性データを集める 軸をもとに選択肢を評価する 自分はこうしたいという"推し"を決めてたたき台にする ここまでの話をドキュメントにしている ここまでのプロセスに時間をかけない 意見を聞く人を見定めてフィードバックをもらう 最初に明確にした決め方で意思決定する 意思決定できない場合は決め方と期日と意思決定軸を再定義す

はじめに かつての私は、深夜2時にベッドの中で転職サイトを開いていた。 開いて、求人を眺めて、閉じて、また開く。そういうことを繰り返していた。辞めたいのか、と聞かれると困った。会社の限界が見えたのか。自分の天井が見えたのか。それとも、隣の芝生の青さに目が眩んでいただけなのか。たぶん、全部だった。たぶん、どれでもなかった。 今は、転職を考えていない。 これは「今の会社が最高だから」という話ではない。どんな会社にも良い面と悪い面がある。不満がゼロになることはない。ただ、深夜に転職サイトを開く衝動は、いつの間にか消えた。何が変わったのか。環境が変わったのか、自分が変わったのか。たぶん、両方だ。 「エンジニアは転職で年収が上がる」「成長できる環境に身を置け」——そんな言葉がタイムラインに流れてくる。転職エージェントからのスカウトメールは週に何通も届く。カジュアル面談のお誘い。年収アップの可能性。も

Intro 筆者のように、インターネット上での生活が長く、かつエンジニアとして生きてきた人間には、一般の人には伝わりにくいデジタルの遺品が多く存在する。 仮に自分が死んだ場合に、これらをどのように遺族に処分してもらうかは、なかなか難しい問題だ。筆者はこの「デジタル終活」をどうするかを、長いこと模索してきた。 今回は、「1Password」と法務局が行う「自筆証書遺言保管制度」を用いた方法を思いついたため、検証を試みる。 注意 筆者はエンジニアであり、法律の専門家ではない。 本方式は、法的に有効な遺言の作成については範囲外である。 本方式の目的は、「遺族の負担を減らす」ことである。 ここで「デジタル 遺品」とは以下のようなものを指す。 自分が使ってきたメールアドレスや SNS のアカウント 取得しているドメイン 登録しているサブスク 管理しているコミュニティや OSS etc. 以下のような

There’s a kind of polite fiction at the heart of the software industry. It goes something like this: Estimating how long software projects will take is very hard, but not impossible. A skilled engineering team can, with time and effort, learn how long it will take for them to deliver work, which will in turn allow their organization to make good business plans. This is, of course, false. As every

はじめに 先週、「おい、辞めるな」という記事を書きました。 syu-m-5151.hatenablog.com 思った以上に反響がありました。何人かから連絡をもらいました。辞めないことにしました、考えるきっかけになりました、と。ありがたかったです。嬉しかった、と言っていいです。たぶん。 ただ、何か落ち着きませんでした。辞めないと決めた。それは分かった。で、その次は。辞めないと決めただけで、何かが変わるわけではありません。私がそうだったからです。 辞めないと決めた後も、何も変わりませんでした。評価は上がらない。漠然としたモヤモヤは消えない。夜遅くまでコードを書いた。勉強会に参加した。資格を取った。ブログを書いた。技術力を上げれば認められる。そう信じていました。 評価は上がりませんでした。 振り返ると、私は頑張り方を間違えていたのです。もっと正確に言えば、評価の構造を理解していませんでした。良