仕事・チーム開発

2026/9/18

リモートで新人から質問が来ない｜「いつでも聞いて」より途中の成果を見る

環境構築を頼んだ新人から、一日連絡がなかった。終業前に聞くと、午前中から認証エラーで止まっていた。「困ったら聞いて」と伝えたはずなのに、どうして黙っていたのだろう。この記事は、リモートで新人の受け入れやOJTを担当する人に向けたものです。本人が質問できるようになるまで待つのではなく、質問が来なくても行き詰まりを発見できる仕事の渡し方を作ります。最初の仕事では、完了報告だけを待たない。途中で見せる成果、止まったら連絡する条件、受け手の返信時点を決めます。「分からないことはない？」より「どこまで動いたか見 ...

仕事・チーム開発

2026/9/18

仕様確認メールの書き方｜食い違う資料から、相手が答えられる一通を作る

設計書ではユーザーIDが必須になっている。しかし前回のレビューでは任意と決まったはず。このまま実装すると、外部連携側と条件が合わないかもしれない。確認メールを書こうとして、経緯を全部説明したら長文になった。この記事は、そんな仕様の食い違いを、設計担当や顧客へ確認するエンジニア向けです。相手に答えてほしい問いを一文目に置く。その後へ、食い違っている根拠、実装への影響、判断が必要な時点を付けます。短くする対象は挨拶の重複であり、判断材料ではありません。「確認をお願いします」だけでは、回答が決まらない次 ...

仕事・チーム開発

2026/10/15

仕事を引き受けすぎたときの相談方法｜「全部急ぎ」に優先順位をつけてもらう

明日リリースする機能のテストが残っている。そこへ別の上司から「この調査も明日まで」と頼まれ、反射的に引き受けてしまった。今さら断りづらい。でも、両方を終える見通しはない。この記事は、複数の依頼を抱え、期限を自分では変更できない開発担当者に向けたものです。必要なのは、もっと速く働く方法より先に、同時に守れない約束を、決める権限のある人へ戻すことです。結論：仕事量ではなく、衝突している二つの約束を見せる。「Aを先にするならBはいつになるか」を示し、優先順位・期限・担当のどれを変えるか決めてもらいます。着手 ...

仕事・チーム開発

2026/9/30

「自分でやった方が早い」を抜け出す仕事の任せ方｜手順だけ渡しても仕事は減らない

支援メンバーが来た。手順も説明した。それなのに質問が来るたびに自分が調べ直し、最後は「ここからは自分でやる」と引き取っている。これでは、人数が増えても自分の仕事は減りません。この記事は、実務を抱えながら後継者を育てているリーダーに向けたものです。対象は、週次報告や問い合わせ対応のように繰り返し発生する仕事。「人に任せるのは大切」という話ではなく、次の一件をどう渡すかまで決めます。先に結論手順書を渡すだけで終わらず、実際の仕事で「何を見て、なぜそう判断したか」を見せる。その後、途中で確認できる範囲から本 ...

仕事・チーム開発

2026/9/8

開発が遅れたら増員すればいい？『人月の神話』から考える判断材料

開発が遅れると、「あと一人いれば」と考えたくなります。人手が有効な場面はありますが、人数の分だけ残り日数が減るとは限りません。先に結論何が止まっているかを先に分ける。作業量の不足と、仕様・環境・判断待ちでは必要な支援が違う。渡して受け取れる仕事があるかを見る。引き継ぎ、受入条件、レビュー担当、残り期限まで確認する。増員・範囲・期限を同じ前提で比べる。増員は必ず遅れを悪化させるものでも、解消するものでもない。『人月の神話』を入口に、小さなチームの架空ケースで考えます。出版社・書誌の紹介情報に基づく ...

仕事・チーム開発

2026/9/8

開発が納期に間に合わないときの報告｜残作業と相談を伝える例文

約束した日に終わらないかもしれない。でも原因も完成日も、まだはっきりしない。そんな段階でも、いまの状態と必要な相談は先に共有できます。先に結論完了・残作業・期限への影響を伝える。完全な原因分析や回復時刻が出るまで待たない。現状と、決めてほしいことを分ける。期限・範囲・支援のどこを調整したいか示す。次に状況を返す時点を決める。完成の約束とは区別し、未確認でも続報する。題材は、問い合わせ管理へ必須・1〜100文字の件名を追加する架空の改修です。以下の期限や時刻も説明用で、実際の予定や成果の報告ではあ ...

仕事・チーム開発

2026/9/8

開発の工数見積もりのやり方｜実装以外の作業を含めた分解例

「半日くらい」と答えたのに、調査やテスト、レビュー修正が残って終わらない。見積もりでは、時間を当てる前に、見積もる作業を見えるようにします。先に結論実装以外も分けて見積もる。調査・テスト・レビュー対応・引き渡しまで、担当する終わりを揃える。作業時間と待ち時間を区別する。合計時間だけで完成日を約束しない。数字には前提と更新条件を添える。不明点は調査し、分かった時点で見積もり直す。問い合わせ管理に、必須・1〜100文字の件名を追加する架空の改修を使います。以下の時間は説明用の仮置きで、実測値や業界標 ...

仕事・チーム開発

2026/9/8

エンジニアの質問の仕方｜何が分からないか分からないときの相談例

「何が分からないの？」と聞かれても、そこを説明できない。質問文を書く手まで止まったら、まず見えている状況から相談できます。先に結論目的・止まった操作・見える結果を送る。原因や仮説がなくても、相談は始められる。調べた分だけ、操作と結果を足す。観察したことと、まだ確かめていない考えを分ける。困りごとの影響で、相談する時点を決める。期限や安全に関わる場合は、調べ終わるまで待たない。架空の問い合わせ管理を題材に、整理できていないときと、少し調べた後の相談文を紹介します。「件名は必須・1〜100文字」は説 ...

仕事・チーム開発

2026/11/4

「だと思っていて構文」の使い方｜技術会議で結論・根拠・相談を伝える

会議で「こうしたほうがよいと思っていて」と聞いたとき、あとに続く理由や、何を決める話かが見えず、返答を待つことがあります。この表現を使うなら、提案の確かさ、確認した根拠、参加者に相談することを分けて話すと、相手はどこに答えればよいか判断できます。そもそもこの言葉は何？「だと思っていて」は、自分の見立てを伝え、その理由へ話をつなげる表現です。技術会議で使うと、提案として聞いてほしいのか、すでに決まった方針を伝えているのかが、言葉だけでは分からない場合があります。「暫定案です」「いま確認できたのはここま ...

仕事・チーム開発

2026/11/4

製品比較して報告書を書くときの注意点

製品の比較資料では、機能を多く並べるほど判断しやすくなるとは限りません。比較の依頼を受けたら、先に決めたいことと、そのために揃える試用条件を書き出します。この記事に書いてあること比較表を作る前に、誰が何を決める資料かを書きます。たとえば「来期のCIツールを選ぶ。開発チームの承認者が、必須条件を満たす候補の中から試験導入先を決める」という粒度です。最初の一枚に置くのは、暫定結論、判断を変える条件、決めてほしいことです。機能一覧と個人の感想は、その判断に必要な箇所から出します。 iPad miniの使用 ...

« Prev 1 2 3 Next »