社内ドキュメントはなぜ更新されないのか？情報の鮮度を最小限の運用負荷で維持する「イミュータブルドキュメントモデル」のススメ - KAKEHASHI Tech Blog
はじめに こんにちは。カケハシの各プロダクトを支えるプラットフォームシステムの開発チームでテックリードを担当しているkosui(@kosui_me)です。 プロダクト開発の世界では、明瞭な社内向けドキュメントを書くための方法が数多く提案されてきました。読者の中には、製品要求を明瞭にするためにPRD (Product Requirements Document、製品要求仕様書) を書き、プロジェクトの背景から全体の設計やその代案について明瞭にするためにDesign Docsを書き、アーキテクチャに関する意思決定の記録を明瞭にするためにADR(Architecture Decision Record) を書いてきた方も数多くいらっしゃると思います。 しかし、どんな素晴らしいドキュメントも、何故か更新されなくなります。新メンバーへのオンボーディングのためにインフラ構成図を検索したあなたが見つけた
1on1で質問をする側になって「工夫したこと」と「気づいたこと」 - Qiita
プロジェクトでの進捗確認ミーティングもありますが、進捗を聞くだけに終始してしまいます。「働くこと」にもう少し視野を広げて、いろいろ聞いてみることがあります。1on1です。進捗確認MTGとは別の事柄を聞けます。以前は、1on1で質問される側でしたが、最近は1on1で質問をする側になったので、気づきをメモしておきます。 1on1の目的 1on1の目的は、（私の場合は）「心理的サポートをすること」です。別の言い方をすると、「働くことを通じて自己実現ができそうか/できているかを念頭に置き、会話を通して、精神面や志向についてプラスを大きく、マイナスを小さくするように働きかけること」です。 その上で、①働き方仕事内容の確認、②不安心配事の検知・助言、③成長・改善の意識付けという3つの観点から、プラス面、マイナス面を把握し、プラスを大きくマイナスを小さく働きかけます。 また、1on1をするときの基本的な
理想のリーダー像を言語化してみました。 - Qiita
チームで仕事をすると、リーダーが必ずいます。経験や実力のある人が担うことが多いように思います。今回は、いろんな書籍や記事などをもとにして、どんなリーダーが理想的か考えてみました。 リーダーについて思うこと ①【前提】チームはリーダーで決まる リーダーって、チーム内のミーティングで発言回数が一番多く、影響力が大きい存在です。だからこそ、チームメンバーに良くも悪くも影響を与えるものです。例えば、リーダーのコミュニケーションの取り方は、メンバーの相談しやすさを左右します。 また、スケジュール管理/進捗管理もリーダーが行うので、タスクの品質やスピード感もリーダーの個性や能力が反映されます。例えば、どんな観点でどれだけ細かくチェックするのかはリーダーの考え方で変わります。結果として、（要件は最低限守れたとして）成果物の品質が高いか、低いかの分岐点になるような気がします。 故に、チームはリーダーで決ま
エンジニアの"有害な振る舞い"への対処法 - Qiita
本記事の続編として、自分が有害な振る舞いをしないようにする改善の取り組みを扱った記事も書いてます。 エンジニアや上司が"有害な振る舞い"を改善する方法 ※「難しい人」は概念として用い説明するのに便利な言葉でしたが、誤解を生じたり、本記事のポリシーに沿わない使用（難しい人というラベリングを特定個人に適用する使い方）が容易にされてしまいそうだと分かりました。そのような誤用を防ぐことを最優先とするため、代わりに「有害な振る舞い」という表現を使用し、人ではなく振る舞いに着目するタイトル及び文章に変更致しました。 はじめに 以下の記事を読んだ際に「難しい人」という表現が何となく面白い響きで印象に残ったので、これを機に自分の考えを今までの経験をもとに書きたいと思います。 “難しい人”が1人入ると、チームの生産性は30〜40％低下する 対抗せずに、場の「安心感」を作るための3つの条件 - ログミーBiz
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
