Kindleで本を買う 読みながら、あとから読み返してもわかるように気になった箇所を黄色でハイライトする。 Glaspを使って、Kindleのハイライトとメモをコピーする Heptabaseの新規カードを作成して、コピーしたものを貼り付ける(読書カードと呼ぶ) ハイライトした箇所の章の名前を書き足していく かなりめんどくさいので、自動化したいが難しいっぽいので諦めてるがいらないような気もしてきた。Kindleアプリ上だと出てるんだけどなぁ。 読書カードにあるハイライトとメモを読み返して、自分の中で大事だなと思うところを改めて赤色でハイライトする。 Heptabaseのホワイトボードを作成して、読書カードを追加する 読書カードを右ペインに表示しながら、読書カードのハイライトとメモから大事だと思う箇所をドラッグアンドドロップで切り出してカードとして作成する。 カードを作成したら、ハイライトした

言葉の定義 モバファクの 1on1 の目的 1on1 で自分が大事にしていること 1on1 はメンティーの時間である 1on1 はメンターの時間でもある 1on1 初回 今使っている 1on1 のフォーマット 体調 半期目標の進捗振り返り ネクストアクションの振り返り うまくいかなかったこと・もっとよくなりそうなところ・うまくいったこと・その他に話したいこと ネクストアクション 1on1 の中でのやりとり お休みの取り方がわからない 最近見積もりの精度が高くなっている 朝会の議事録をとるようにしたい 最近チームの動きがぎこちないと感じている 1on1 定期的な振り返り まとめ こんにちは。駅メモエンジニアの id:dorapon2000 です。 今回は自分自身がメンター側として実施している 1on1 について、どのように実施しているのかご紹介しようと思います。 1on1 のやり方はメンター

これは、複数の他社の人から聞いた話をくっつけたり混ぜたり脚色した話になる。つまるところフィクションだ。 あるIT企業ではチームごとに始業時にスタンドアップミーティングを行っている。スクラムで言うところのデイリースクラムである。よくあるやつだ。 ある日、5〜6人くらいの小規模チームに新しいメンバーが加入した。新卒ではないけれど第二新卒くらいの若さのメンバーであった。将来的にはリードする役職（テックリードだったり、デザインリードだったりそういうやつ）につきたいという、意欲のあるメンバーだ。仮にメンバーを山田としよう。 入社後しばらくした山田からマネージャーに相談があった。 「毎朝、スタンドアップミーティングをしているが、時間の無駄にしか感じない。それぞれが進捗を共有するが、自分には関係ないタスクの話を聞いても意味がないので早くタスク消化に入りたい。」 マネージャーはスタンドアップミーティングの

たまにSNSで論争になるので、意見を言っておこう。 日進月歩のIT業界でお勉強するべきかって話。 そりゃ、しないと置いて行かれるでしょうね。特にソフトウェア周りって、気を抜いているとどんどんバージョンアップして、操作方法も変わる。基本的なことさえ押さえていれば、あとは便利になっていくだけだから新しく勉強することなんてないよね勢がいるのもわかるが、それでも時間的に限界はある。7.0と8.0は大きな違いが感じられなくても、7.0と15.0はもう全然別のソフトウェアになっている。 どんなソフトウェアも、情報処理技術者試験で出てくるような基本から成り立っている。その上に応用としての技術があるので、基本をしっかり身に付けていれば、ある程度の技術の変化にはついていける。それは間違いない。 問題は、この基本の部分をどの程度習熟しているか。それこそ年齢が若い時に、仕事「以外」の時間も使って学ぶことをお勧め

今や毎日耳にするChatGPTだけれど、そもそもどんな風に話題になってきたのかをこのGWを利用して振り返りたいって人もいるはず。そんな人のためにChatGPT関連ニュースをまとめておきましたので、ぜひご利用ください！ 良い振り返りで、良い人生を。 このタイトルだけでもChatGPTに食わせて、話題の流れをまとめてもらうのが一番かも？ 週刊東洋経済　2023/4/22号（ChatGPT 仕事術革命） 作者:週刊東洋経済編集部東洋経済新報社Amazon 2020/06/01 あまりに高精度のテキストを作り出してしまうため「危険すぎる」と問題視された文章生成言語モデルの最新版「GPT-3」が公開 - GIGAZINE 2020/07/21 GPT-3の衝撃 - ディープラーニングブログ 2020/07/22 「GPT-3」は思ってたより「やばい」ものだった。話し言葉でプログラミングまでこなすAI

最近zatsuを書いてなかったので、「理想のOKRとは何か」をハンターハンターを例にして書く。必要な前提知識は8巻にある。 高いObjectiveの設定とは何か クロロ「全部だ」「地下競売のお宝 丸ごとかっさらう」 8巻 P152~153 これが高いObjectiveの設定である。 戦略発表前にはメンバーは「どこ狙うと思う？あたしは古書全般だと思う。団長本好きだし」「違うね。きとゲームね」などと色々な予想をしていたが、それをはるかに超えた目標を掲げている。そう 「全部盗む」である。 OKR シリコンバレー式で大胆な目標を達成する方法では、『Objectiveは達成確率が60〜70%程度になるくらいの高い目標を設定せよ』とあるが、このクロロのセリフはまさにそれだと言っていい。 合意のプロセスとは何か OKRの運用において一番大事なのは、所属するメンバーとそのObjectiveについて話して納

クックパッド株式会社で採用の立ち上げから上場以降まで携わる。その後、海外事業や子会社の新規事業を経験。北海道に移住し、2019年に無添加おやつの開発を行うコロッケ株式会社を創業。併行して2022年2月に10X入社。青森県出身、2児の母。ビールが好き。 半年前に生じていた、エンジニア採用「2つの課題」 ──10Xのエンジニア採用における変化について、改めて教えてください。 石川：まず、半年前の10Xのエンジニア採用の状況について話をすると、当時は採用に関するアクションが継続できていませんでした。そのため応募数も月ごとに波があり、また内定承諾率も低く、選考の途中で辞退になってしまうこともよくありました。 当時のエンジニアリング本部は緊急のプロダクトの開発対応に追われている部分が多く、同時並行で採用も進めなければいけなかった。事業計画上、人員を拡大していく必要はあることは全員わかっており、テコ入

観測しようとすると、その観測が影響を与えてしまう感じで、おもしろい 自分の頭の中 この機能をチームで開発するのに、だいたい2ヶ月くらいかなぁと自分が頭の中で思っているとする。もし僕らの知ってる範囲ですべてが収まれば1ヶ月くらいで終わるかもなぁと思いつつ、まぁ、知らない範囲のことがあるだろうし2ヶ月くらいに思っておくのがいっか という感じ。6割ぐらいの自信 チームの中 チームメイトに「この機能いつ出せるかな？」って聞かれることはあんまりないと思うけど、もし聞かれたら「んー、2ヶ月くらいじゃない？もしかしたら、もうちょっと早くできるかもだけどね」ってそのまま頭の中を伝えると思う 聞かれることがあんまりないというのは、そもそも、チームでラフに見積もるから。Tシャツサイズとかストーリーポイントとかを使って「Mサイズだから2ヶ月くらいだね」って話をするだけで済む。「2ヶ月くらいだね」って言ったものは

自分は元々とにかく技術志向のエンジニアであり研究者であった。とにかくコードを書いたり論文を書いたりすることが生き甲斐であった。 そんな自分が数年前に色々考えた結果、マネージャーや経営者の道を志すようになったのだが、その際によく聞かれることがある。「技術を中心にやれなくなる不安や葛藤はなかったんですか？」と。 その答えとしては「その不安や葛藤はない」である。なぜかというと、マネージャーや経営者に強烈な専門性を感じているからだ。勉強すればするほど、あれ、これはエンジニアや研究者の時にやっていた学び方とほとんど変わらないのではないか、と思えているからである。 おそらく僕自身も、かつてはマネージャーや経営者に専門性を見出せておらず、エンジニアからそうなることは考えてもいなかった。むしろ、技術者としての諦めのような風に捉えていたかもしれない。しかし、自分がそこに身を置くにつれて、全くもって雰囲気で適

フラーで働く社員には、使うアイテムに強いこだわりを持っている人が多くいます。 今回はその中でもエンジニアのキーボード事情を調査して記事にしました。調査と書き手は9月に入社したiOSエンジニアの多田さんです。 実はこの記事、多田さんからの持ち込みで公開に至りました！ 入社初日から左右分離型の自作キーボードを使っていることが社内Slackで話題を呼び、同じくキーボードにこだわりを持つエンジニア社員に取材を重ねた多田さん。エンジニアの目線でフラー社員のキーボード事情をレポートしてもらいました。 なお、掲載の順番は取材をした時系列になっています。 iOSエンジニアの多田さん。9月にフラーへ中途入社。はじめにはじめまして、iOSエンジニアの多田です。 執筆時点ではオンボーディング期間中で、部署関係なく色々な人と話してまわっています。 多種多様なスキル・バックグラウンドを持っている人がたくさんいるため

はじめに ※この記事はEngineering Manager Advent Calendar の22日目の記事になります。前日はmtx2sさんの技術的負債に対するマネジメントの記事でした。個人的には「負債上限」「負債ベースライン」の考え方良かったです。 こんにちは。モノタロウでエンジニア組織のマネージャーをしております普川(@taipuka0)です。 自分は前職から通算10年以上してエンジニアリングマネージャーを続けた後、現在モノタロウでは8人のEMのみなさんと日々ソフトウェア・エンジニアリングの現場でマネージャーとして課題解決に向き合っています。これまで色々な壁にあたり、試行錯誤を繰り返して来ました。EMの難しさを痛感したことも多々ありました。 なぜEMが難しいのか？その一つとして、エンジニアからEMにジョブチェンジした際のギャップというのがあると思います。同じチーム、現場にいたとしても

人気シリーズ『図解 人材マネジメント入門』や『図解 組織開発入門』の著者であり、企業の人材マネジメントを支援する株式会社壺中天の坪谷邦生氏が、MBO（目標管理）をテーマとした新刊の発行にあたり、各界のエキスパートと対談を行います。第1回は、ドラッカー学会共同代表理事の佐藤等氏と共に、ドラッカーのマネジメント哲学をひもときながら、目標管理に関する誤解について話し合いました。 MBOには「根本的な誤解」がある 坪谷邦生氏（以下、坪谷）：まず最初に、前段をお話しさせていただくと、今『図解 目標管理入門 マネジメントの原理原則を使いこなしたい人のための「理論と実践」100のツボ』という本を書き始めています。私はいろんな会社の目標管理も含めた人事制度を作り、その支援をさせていただくことが多いんですね。 そもそもMBO（Management by Objectives and self-control

仕様書を浸透させるために何が必要か？ 品質の作り込みをしていきたい・仕様を把握するコストが高いので仕様書を書くことを会社全体で浸透させたいと思っていて、そのために書く・読むの負担軽減が重要だと考えて以下をやることにした。 仕様書の項目を減らす 仕様書フォーマットの統一 仕様書の命名規則を決める 統一されたフォーマットに沿ったテンプレートの作成 管理方法の明示化・単純化 仕様書作成・更新・廃止プロセスの明示化 仕様書の具体例の作成 仕様書を書くときに迷いそうなときに参照するガイドの作成または作成の依頼 実は一回シンプルなフォーマットを決めたのだが、自分の進め方が悪くそれが全く浸透しなかった。その反省を踏まえて上記を考えた。 仕様書の話は、このあたりの話に関係する。 仕様書は必要か？ - パルカワ2 チームが品質を作り込むために必要なこととは - パルカワ2 ちなみに仕様書は、Notionで記

・Slackにおけるtimes文化とは ・一度仕事中のチャット雑談の全てを断ったがまたtimesを立てた話 ・守りたい節度とこれからSlackにおけるtimes文化とは「times」とは、社内チャット等で自分のチャンネルを持ち、短いスパンで発言する社内Twitterのような文化形態である。 私がまだ学生でインターンやアルバイトという形でIT企業に関わって居た頃、彗星の如く現れた以下のブログがきっかけで、Slackを導入していたITベンチャー企業で流行りはじめたと記憶している。 分報、times、timelineなど、様々な呼び方を各社がしているが、要は社内チャットにおけるTwitterである（ここでは最も一般的だと思われるtimesに統一する）。 timesは、カルチャー性とSlackの各機能とが相まって、爆発的に流行った。近年ではTwitterのフォロワー内でも「times文化がない会社

みなさんこんにちは。@ryuzeeです。 言いたいことはタイトルに書いたとおりなのですが、2022年8月26日に、新刊『エンジニアリングマネージャーのしごと チームが必要とするマネージャーになる方法』が発売になります。 エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法著者／訳者：James Stanier、 吉羽 龍太郎、 永瀬 美穂、 原田 騎郎、 竹葉 美沙出版社：オライリージャパン発売日：2022-08-26単行本（ソフトカバー）：376ページISBN-13：9784873119946ASIN：4873119944 原著はDr. James Stanier氏の『Become an Effective Software Engineering Manager: How to Be the Leader Your Development Team Need

2022-08-08 リーダーの作法 ささいなことをていねいにを読み終えた。 著者は Netscape でマネージャー、Apple でディレクター、Slack でエグゼクティブを経験した Michael Lopp さんで、過去にBeing Geek や Managing Humans を書かれている。 翻訳の質も非常に高く、楽しく読めた。1 そんなにマネジメント関係を読んでいるわけではないが、HITH OUTPUT MANAGEMENT や、エンジニアのためのマネジメントキャリアパス ―テックリードから CTO までマネジメントスキル向上ガイド 同じくらい良い書籍で、学びや共感を多く感じた。 自分はマネジメントのポジションについたことはないが、仕事をしていくなかでマネジメント関係のソフトスキルや複数人でどうやってうまくリーダシップを発揮して、大きい問題を解決するかに興味があるので、良い書籍

『はじめての設計をやり抜くための本 第2版 概念モデリングからアプリケーション、データベース、アーキテクチャ設計、アジャイル開発まで』は初版から14年ぶりの改訂となり、手法やツールを最新にアップデート。アジャイルやマイクロサービスなど現代のシステムに不可欠な要素を追加しています。 システム設計は、プログラミングの仕事をこなせるようになったエンジニアが次のステップとして挑むにふさわしい領域です。本書ではそんなエンジニアの皆さんをサポートし、下記のような設計にまつわる課題を解決できる内容になっています。 アプリケーション設計をどうするのか データベース設計をどうするのか 画面・帳票設計をどうするのか 外部システムとの接続方式をどうするのか アーキテクチャ設計をどうするのか スキルアップはもちろん、開発リーダーを目指す方にもおすすめの本書。設計ができるエンジニアになるための最初の1冊です。 目次

プロダクト開発人材の副業転職プラットフォーム Offers を運営する株式会社 overflow VPoE の あほむ でございます。 今回は Offers エンジニアリングチーム[1]においてリーダーやマネージャーといった職務をどのように捉えているかについて紹介させてください。なにかのご縁があって弊社にご興味をもってくださった方のご参考になれば幸いです！ エンジニアリング組織のリーダー、マネージャーの扱い 所属する組織の中で「リーダーシップを発揮してほしい」とか「リーダー経験がないとこれ以上評価できない」とかのコミュニケーションをとった/とられたことがある方も少なくないのではないでしょうか。 こういったコミュニケーションの背景には 「組織としてリーダーシップを発揮できる人材を欲している」 という意図や 「評価上の分かりやすい材料を欲している」 などの事情があると考えられます。 そんなこと

Stockmark ( https://stockmark.co.jp ) 社内勉強会の資料公開です。