1on1 で伝えたので外にも書いておく。 プロダクトやチーム、メンバーのフェーズ まず現状分析。 自プロダクトは PPM で言う花形、金のなる木、問題児、負け犬のいずれに当たるのか 勢い MAX でめっちゃ盛り上げるのか、地味に役割を達成するのか。自チーム全集中なのか他チームのフォローに回るのかみたいな方針が変わる 自チームは エラスティックリーダーシップ で言うサバイバルモード、学習モード、自己組織化モードのいずれに当たるのか チームを改善しなければいけないのか、プロダクトだけを見ていて良いのか。チームで改善できるのか、リーダーや外部の強い意志が必要なのか 各メンバーは、期待される役割において SL理論 で言うとどのフェーズなのか 指示的行動が必要だとマイクロマネジメントすることになり、マネージャ/メンター的な人/行動を増やす必要がある 役割を網羅しているか こういう軸で考えていることが

フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発

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

Kyash Advent Calendar 2023 23日目の記事です。 Kyashに入社して6年が経ちました。 Androidアプリのエンジニアとして入社し、Androidを書いたりiOSを書いたりGoを書いたり、CSチームで問合せ対応をしたり、MobileチームのEMをやったりQAとしてテストの自動化をやったりして、今は開発組織全体のマネジメントをしています。あと4年前には子も産まれました。色々ありましたね。 最近他社のマネージャーに時間の使い方の話を聞いた時にとても面白かったので、自分の6年間のGoogleカレンダーのスケジュールの変遷を書いてみます。 2017/12 1週間 Android開発に集中する 真っ白ですね！Android開発に集中って感じでした 3週間くらいはこんな感じで、その間に送金時の39アニメーションとアプリロックの指紋認証機能を作ってリリースしました 2018

大変多く読んでいただいた「プログラミングというより物事が出来る思考法」というポストや、世界一流エンジニアの思考法の書籍で紹介した内容がある。 私の職場でも、ものすごく出来る人が「実践」しているところを何回も目撃しているので「実践編」として皆さんにシェアしようと思って今回のポストを書いてみた。 タイトルにもある通り、私はエンジニアだが、ビジネス書である書籍と書かれた多くの思考法と同じく、あまりエンジニアリングというものに関係ない要素であると感じている。 上記のポストや書籍でシェアした内容を端的に言うと「理解には時間がかかるがかける価値が十分あり、それによって自分が物事をコントロールしている感覚を身につけることが出来る」という自分の小さな発見だ。私がこのことを最初に発見したのは、新卒の出来る人々との出来事がきっかけだが、今回その小さな自分なりの発見を後押しするような出来事がいくつかあった。それ

You possess a rudimentary understanding of computer science fundamentals: data structures, methodologies, and strategies. You have practical knowledge in the specific programming language(s) and framework(s) used by your team. You are capable of diagnosing problems, planning and applying fixes. You are motivated to learn new technologies and techniques and demonstrate an ability to turn these lear

太一のコードの読み方メモ 全体として太一が感覚的に実践している事を論理的に説明しようと試みている為、 説明の粒度が適切でなかったり一貫性が無いように見える部分があるかもしれない。 普段やっているけども書ききれていない事も多分きっとある。 コードを読むとは何か コードを嗜む コードを学ぶ 武器を手に入れる これは武器を手に入れるコードリーディングの話 武器とは何か プロジェクトで戦う為の道具となる知識 プロジェクト内における技能を示す為の道具となる知識 プロジェクトのやり方を自ら決められる様になる為の道具となる知識 権限と責任がバランスよく割当てられた時モチベーションは最大化する 何と戦うのか プロジェクトリスク プロジェクトをより良い状態にする為の基礎的な根拠となるのがコードである コードが全てではないが適切に動作するコードが無ければプロジェクトは終わらない これはつまり理想を体現する為の

何か相談事があるときに真っ先に話をしに行く相手のことを go-to person と呼ぶ。要するに「頼りになる人」のことである。本記事ではミドルレベルのソフトウェアエンジニアが go-to person として頼りにされるためにはどう振る舞えばよいか私見を紹介する。職種や立場が違えば目指すべき go-to person のあり方もまた違ったものになることはご留意ください。 Go-to person の役割 Go-to person は相談者が抱える課題を分解・整理するのを手伝い、自身の知識や経験に基づいた適切なアドバイスを提供する。相談者は go-to person と話すことで暗中模索する時間を節約し、最終的な判断に自信を持つことができる。シニアソフトウェアエンジニアやテックリードになる要件として、何らかの分野で go-to person として認知されていることを求めている場合も多いだ

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

自立したエンジニアとは 仕事で、自立とか自走とかいうキーワードが飛び交っていた。冷静に考えるとどういう意味なのかあまり言語化できていなかった。 自立しているエンジニアってなんだろう、ということを考えているうちにこの文書が生まれたのでここに公開する。なお、以下では「エンジニア」と「ソフトウェアエンジニア」を特に区別せずに使う。 なんでも自分でできると思っていた 本題に入る前に、少し昔話をしたい[1]。 僕は仕事でコードを書くようになった。2017年くらいのことになる。 学生時代にある程度プログラミングをやっていた僕ではあったが、仕事はコードを書けるだけではできないことがたくさんあることがわかった。 作って欲しいと言われたものを作ることはできた。とにかく仕事を前に進めるためのことを色々とやっていた。 でもセキュリティのこととかよくわからなかった。他にも、Linuxサーバーの操作はできて設定ファ

「仕事で成果を出す人」と聞いて、どのような特徴を思いうかべますか。 才流はコンサルティング会社であり、ビジョンとして「メソッドカンパニー」を掲げています。顧客へ価値を届けるにあたって、営業やマーケティング、新規事業などの専門知識はもちろん、ベースとして強固な「仕事力」が欠かせないと考えています。 本記事では、社内で実際に活用している仕事の進め方マニュアルの中身をテーマ別に厳選し、チェックリスト形式で紹介します。 ※本記事が多くの方々に読まれていることもあり、このたび内容を最新版にアップデートしました。 ビジネスパーソンの心得1. ビジネスの原理原則を理解するビジネスで価値を提供するためには原理原則が存在するビジネスの原理原則とは、相手＞自分であり、顧客＞外部パートナー＞自分であること具体的に表すと「顧客や社会、チームメンバーに価値を提供する→顧客や社会からお金がもらえる→自分たちの給与が出

リーダーシップというと、カリスマ的な魅力をそなえた人物が輝かしいビジョンを指し示し、大衆を率いていく……というドラマチックな光景を思い描いてしまうものだが、実地で求められるリーダーシップとはそういうもの（だけ）ではない。というか、そうであってほしい。 ここでは英雄的資質を持って生まれなかった多くの人間が、どうやってリーダーシップを獲得していけるのか、を考えていく。 定義 リーダーシップを定義するために語られていることを、いくつかの本から引用してみる。 リーダーシップとは、集団に目標達成を促すよう影響を与える能力である（スティーブン P. ロビンス『組織行動のマネジメント』） リーダーシップとは、理由の如何にかかわりなく、［何かしらの目標をめざして］他人や集団の行動に影響を与える試みそのもののことである。（ハーシィ・ポール他『入門から応用へ 行動科学の展開』） 「絵を描いてめざす方向を示し、

最近テックリードのロールを手放し、働き方がEMに近づいた。折に触れてEMになりたいと言ってきたが、だからと言って最初からうまくできるわけもなく、ここ1ヶ月くらいは悶々としながら過ごしている。特に今回困ったのは、自分の現在地がぼんやりしていて漠然と据わりが悪い感触に苛まれている点だ。もう少し課題や方向性を精緻にして、自信を持って前進できる環境をつくりたい。その一環としてマイスキルマップを作ってみたので紹介する。 マイスキルマップへ至る思考 自分が大事にしている心構えのひとつに「練習していないことはできない」というのがある。十を知るには十を聞き、繰り返し実践することでしか一人前にはなれないという、ごくごく当たり前のことだ。この心構えでひとつひとつ丁寧にやっていくのが、ここ5、6年の自分の強みだと思っている。 しかしこの心構えを維持するのは簡単ではない。何かができるようになると、自分の能力のイメ

2023年03月31日追記：この記事を基に、@sadnessOjisanさんより、コードレベルにより踏み込んだ、かつ、グリーンスレッドベースの新しいWebサーバアーキテクチャも含めて整理された記事 Webサーバーアーキテクチャ進化論2023 | blog.ojisan.io が公開されました。 主に新卒のWebエンジニア向けに、古典的なWebサーバアーキテクチャを学ぶ道のりと代表的な実装モデルの概要を紹介します。 この辺りの話題がWeb界隈で流行っていたのは数年以上前というイメージですが、Webサービスは相変わらずWebサーバの上で動いているので、流行り廃り関係なく学ぶべき内容だと思っています。 また、HTTP/2がいよいよRFC化し、既にh2oやtrusterdなどのHTTP/2のサーバ実装があり、今後Webサーバアーキテクチャを再訪することが増えるような気がしています。 ところが、We

はじめに 最近プログラマーとしてのキャリアに一区切りつけようと思っており、これまでのプログラミングの勉強の集大成となるブログを書きたくなったので書く。初めてプログラミングをして、フロントエンド開発をして、サーバーから値が返ってきたときは「どういう仕組みで値が返ってきたんだ？」と疑問に思っていた。ずっと理解したくて理解できていなかった。だからずっと勉強していた。そして最近になってようやく自分の言葉で説明できるようになった気がしたのでブログを書きたい。 2015 年版が自分の原点であり、この記事を書くモチベーションになった このような記事は実は過去に存在している。 FYI: https://blog.yuuk.io/entry/2015-webserver-architecture その記事はサーバーがどういう仕組みで動いていて、どのように進化し、2015 年に至るかを解説してくれた記事だ。自

悪いコードを憎んで人を憎まず！ プルリク送付前に心がけたいコードレビューのコミュニケーション術 コードレビューを円滑に進め、より学びを促進するために重要な「コードレビュー時のコミュニケーション」について、現役エンジニア・池田 惇さんの経験とともに考えてみます。 アプリエンジニアの池田 惇（いけだ・じゅん／@jun_ikd）です。 コードレビューとは、エンジニアにとって毎日発生する作業であり、「コードを書く」という行為と等しく重要なタスクの1つです。同時に、ただ漠然と「粗探し」をするだけがレビューの目的ではありません。特に若手のエンジニアにとっては、先達のエンジニアのコードにじっくりと触れ、学びを得て、さらにチームに自分の持つ知識・技術を還元する、大事な機会でもあるのです。 今回はコードレビューを円滑に進め、より学びを促進するために重要な「コードレビュー時のコミュニケーション」について、私自

「最高の電源タップ」と呼ばれるものがある。 しかし中身も含めて最高であるかは分からない。 なのでバラすことにした。 電源タップの選び方 家の電源タップ全部抜く 全部バラす サンワサプライ TAP-SP2110-1 (2018年9月購入) エレコム T-K6A-2625BK (2018年4月購入) ヤザワ Y02YBKS662WH (2011年製) 星光商事 型番不明 (2011年製) 代わりに買ったもの 終わりに 実家へのメモ 記事を書くのに使った工具 38in1特殊ドライバーセット アックスナイン 電源タップに言及した記事 電源タップの選び方 一週間ほど前、「最高の電源タップ」がバズっていた。 電源タップに拘り始めて18年、数百のタップを買い続けた結果出た最高の電源タップはこれです pic.twitter.com/lIbigmYH4A— まつもとりー / Ryosuke Matsumot

はじめに アーキテクチャ・デザイン全般 ソフトウェアアーキテクチャの基礎 Clean Architecture　達人に学ぶソフトウェアの構造と設計 Design It! ソフトウェアシステムアーキテクチャ構築の原理 データ指向アプリケーションデザイン マイクロサービス マイクロサービスアーキテクチャ マイクロサービスパターン 実践的システムデザインのためのコード解説 ソフトウェアアーキテクチャ・ハードパーツ ドメイン駆動設計 エリック・エヴァンスのドメイン駆動設計 ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本 現場で役立つシステム設計の原則 要件定義 はじめよう！プロセス設計 ～要件定義のその前に はじめよう！ 要件定義 ～ビギナーからベテランまで はじめよう！システム設計 ～要件定義のその後に Web, Web API Webを支える技術 プロになるためのWeb技術

ドキュメントでは、「モノや人の関係を明確に表わす」「複雑な流れをわかりやすく説明する」といった場面がたくさん出てきます。概念図は、言葉だけでピンとこない複雑な関係も、わかりやすく伝えることができます。 本セッションでは、テクニカルライター向けに概念図を描くテクニックをご紹介します。

2023 年度の僕のエラーハンドリング について書きたい。 昨日Safe Data Fetching in Modern JavaScriptを読んでいて、fetch に限った話ではないが一家言ある内容だったので書きたくなった。 おそらくやりすぎだとか非効率と言われる点はあると思うので、みんなの一家言も教えて欲しい。 対象は Typescript での サーバー開発想定だが、TS であればクライアント開発にもほとんどに当てはまる話だと思う。 例外のスローではなく Result 型を使う Result は失敗するかもしれないという文脈を与えてくれる型 エラーハンドリングの戦略として例外を投げるのではなく、Result 型を返すやり方がある。 Result 型というのは export type Result<T, E> = Ok<T> | Err<E>; export interface Ok