開発プロセスを改善したい。どこから相談すればよいか。

Yas Naoi · Pixie Works

「スクラムを実践しているけれど、仕事が進んでいる実感がない」「コーディングエージェントを導入したが、レビューに時間がかかる」。改善したい気持ちはあっても、どこから手を付ければよいか決められないことがあります。

相談を始めるために、完成した改善計画を用意する必要はありません。まず、最近の仕事で何が起きたのかを１つ振り返ってみてください。

「困っている」を、実際に起きたことへ置き換える

たとえば「チケット管理がうまくいかない」には、いくつもの状態が含まれます。

• チケットが大きく、途中で何が終わったのか分からない。
• 実装が終わってから、依頼した側との認識の違いが見つかる。
• 担当者以外は判断の背景を知らず、レビューで同じ説明を繰り返している。

これらは架空の例ですが、必要な対応はそれぞれ違います。最初からツールや会議を増やすと決めず、直近のチケットで、どの場面に困ったのかを確認します。

「誰が悪かったか」ではなく、どの情報や判断が、その時点で足りなかったのかを話し合います。

最初の相談に持ち込む３つの材料

最初から資料を大量に作る必要はありません。次の３つがあると、話を具体的にできます。

1. 最近の仕事を１つ。 何をしようとしていたのか、どう進めたのか。
2. 困った場面。 どこで待ち、手戻り、説明の繰り返しが起きたのか。
3. 変えたい状態。 次の仕事で、何ができるようになればよいのか。

たとえば、「実装後に完了条件を確認し直した。次は、実装前に担当者とレビュー担当者で同じ条件を確認したい」と説明できます。

最初の問い合わせは、機密情報を含まない概要で十分です。チケットや資料の詳細が必要な場合は、共有できる範囲を相談してから扱います。

Jira と Confluence の間で、判断が途切れていないか

Jira に作業があり、Confluence に要件があっても、両者がつながっていなければ、必要な情報を探し直すことになります。

Jira では担当者、優先順位、スプリントの作業を管理します（Delivery）。Confluence には要件や設計上の判断、その理由を残します（Discovery）。チケットから必要なページに進めるか、変更した判断が作業に反映されているかを確認します。

相談の対象は、新しい仕組みを作ることだけではありません。今ある情報の置き場所と更新のタイミングを整理するだけでよい場合もあります。

AI の導入状況より、依頼と確認の仕方を見る

コーディングエージェントがコードを書くようになっても、チームが何を実現したいかを決める必要は残ります。

依頼に目的と作業範囲が含まれているか。完了条件を確認できるか。生成された変更を誰がレビューするか。不明点が出たとき、どこで確認するか。まず、その流れを見ます。

「レビューが大変」という悩みも、変更が大きすぎるのか、依頼が曖昧なのか、確認の担当が決まっていないのかで、取り組み方が変わります。AI-DLC を考えるときも、実際の仕事に沿って課題を整理します。

次のスプリントで試す変更を１つ決める

最初の取り組みとしては、たとえば「次のチケットでは、実装前に Why・What・How を担当者とレビュー担当者で確認する」と決められます。

試した後は、認識の違いに早く気づけたか、完了確認に必要な情報がそろったか、新たな負担が増えたかを振り返ります。うまくいったと決めつけず、続けるか、変えるかをチームで判断します。

小さな変更でも、何を試し、何が分かったかを残せば、次の改善につなげられます。

テーマが固まる前から相談する

Pixie Works では、チケット駆動型開発を軸に、スクラム、Jira・Confluence、コーディングエージェントを使う AI-DLC の支援・研修を扱います。

まず現在の仕事の進め方と困っていることを伺い、取り組む課題、支援範囲、学習目標を一緒に整理します。

お問い合わせには、「最近の仕事」「困った場面」「変えたい状態」を、書ける範囲でお知らせください。支援内容は アジャイルコーチング・研修でもご覧いただけます。

← 記事一覧