OpenTelemetryをざっくり学んだ - yigarashiのブログ
OpenTelemetryについての情報を見聞きする頻度がどんどん上がっており、各種サーバー監視サービスやクラウドでも対応が進んでいることから、そろそろ自分の引き出しに入れたいと感じました。概要を自分で説明できるくらいを目指してざっくり学んだログを自分用に残します。 OpenTelemetryとは opentelemetry.io 公式トップページにある以下が全てを物語っているとは思います。メトリック、ログ、トレースはお馴染みのObservability三銃士ですね。 OpenTelemetry is a collection of APIs, SDKs, and tools. Use it to instrument, generate, collect, and export telemetry data (metrics, logs, and traces) to help you
がんばりすぎないふりかえりのススメ - yigarashiのブログ
がんばりすぎてふりかえりを嫌いになった 自分たちのやりかたを検査して改善するふりかえり。巷には様々な思想やフレークワークが出回っています。チームからうまく情報を引き出したり、教訓に昇華したり、SMARTなアクションを設定することも大事です。そういう情報がどんどん襲ってきて、しっかり会を設計してバリューの高いふりかえりをやらなければという気になってきます。 それで工夫して上手くいくなら良いですが、自分にとってはあまり良い道標として機能しませんでした。会を頑張って設計しても、そもそも参加者が喋ってくれなかったり、ファシリテーターと1対1の会話が起こるだけになったりして、手応えを得られないことが多くありました。それでもちゃんとバリューを出さなければと焦って、なんとかアクションをまとめたり、無理やり教訓ということにしてチームのドキュメントに追記したりしていました。そういうぎこちない会を回すのはとに
はじめてのエンジニア1on1メンター - yigarashiのブログ
ピープルマネジメントの文脈でエンジニア同士のメンタリング制度を設置しているIT企業は多いと思います。自分が勤める会社も例に漏れず、1on1によるメンタリング制度があります。エンジニアリングマネージャーを目指す若者の戦略 - yigarashiのブログ でも整理したように、ピープルマネジメントの領域にも取り組んでいきたいと考えていたわけですが、9月ごろからメンティー2人を持つ機会に恵まれました。1on1やコーチングの経験はほとんどなく、同僚のキャリアに関わる責任の重さを思うと、なんらか知識や型を整えて臨むのが適切だろうと考えました。この記事では、はじめてのエンジニア1on1メンターをやっていくために学んだことや実践の様子をまとめてみようと思います。 座学編 スクラムマスターの文脈でコーチングは多少関わりがあるものの、やはり1on1によるメンタリングは初めての経験です。何はともあれ本を1冊読む
エンジニアリングマネージャーを目指す若者の戦略 - yigarashiのブログ
企業でWebアプリケーションエンジニアとして働き始めて2年と4ヶ月ほど経ちました。様々な仕事を経て、自分が向いていることや楽しく感じることが徐々に明らかになり、数年後になりたい像がぼんやりと浮かび上がってきました。そして、その将来像が世間的には「エンジニアリングマネージャー」（以降EM）と呼ばれていることもわかってきました。この記事では、EMについて自分が周囲から受け取った知識を整理するとともに、そこに向けてどんな戦略を取ろうとしているかをまとめてみます。マネージャーというとネガティブなイメージも拭えませんが、EMは年を重ねて吸い込まれるものではなく、積極的に取りに行くに値する面白いポジションであると思います。この記事を読んでEMに魅力を感じる同世代の仲間が増えると嬉しく思います。 EMについての理解 エンジニアリングマネージャーという職務についてのオーバービューは、広木大地さんによるエン
KPTのKがいまいち膨らまないチームに贈るパワフルな質問 - yigarashiのブログ
ふりかえりでKPTのようなポジティブ/ネガティブな話題を出すような手法を使っていると、悪いところの掘り下げはサクサクできる一方で、良いところをうまく膨らませるのが意外と難しいように思います。書いた本人に話してもらって、ファシリテーターが「いいですね」とコメントして終わりとか、「コメントないですか」と聞いて誰も話さなくて終わりとか、そういった場面を見たことがある人は多いんじゃないかと思います。悪いところを解決するのは慣れていても、良いところを伸ばすための道具箱が空っぽという状態ですね。 そんなチームの最初の道具として次の質問を贈ります。 それがうまくいった要因は何かありますか？ これです。なんとかのひとつ覚えで良いので、ちょっとでも話が広がらないなと感じたら、まずはこれを聞いてみると良いです。この質問が優れているのは、出来事や本人の経験から単刀直入にプラクティスを抽出できることです。何か聞き
エンジニア8人チームで"効果的に"タスクをアサインするために検討した8つの軸 - yigarashiのブログ
最近、締め切りのある大きめなプロジェクトでWebアプリケーションエンジニア兼プロジェクトマネージャーとして仕事をしました。一年目なので当然プロジェクト管理の経験はなく、本を読んで知識を得たり、チームメンバーに助けられたりと、だいぶ手探りでの挑戦となりました。その中でもっとも難しかった仕事の一つとして、タスクの効果的なアサインがあります。 エンジニアは最大8人おり、その技術力、ドメイン知識、勤務地などは多岐に渡ります。ウォーターフォール的な開発だったため、タスクは事前に洗い出されており、タスク管理ツール上に無数に登録されていました。適当に人とタスクを辞書順でソートしてアサインするだけなら簡単ですが、現実はそうもいきません。締め切りは厳しく、チームの生産性を少しでも高く維持しなければいけません。メンバーのモチベーションが下がったり、依存の多いタスクが遅れたりといったことはなんとしても避けたいも
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
