1. ソフトウェア開発では何をしているのか

あなたの学校で、文化祭の出し物を紹介するWebサイトを作ることになったとします。サイトを完成させるには、プログラムを書くだけでなく、次のような活動が必要です。

1. 来場者や実行委員が何に困っているかを知る
2. どんな状態になれば困りごとが解決するかを考える
3. 今回作るものと、今は作らないものを決める
4. 画面や仕組みを設計し、実際に作る
5. 正しく動くか、使いやすいかを確かめる
6. 使った人の反応を聞き、次の改善を考える

たとえば「出し物を検索できる機能を作る」という依頼があったとしても、すぐに検索欄を作り始めるとは限りません。「名前から探したいのか」「場所から探したいのか」「スマートフォンで使うのか」を確認しなければ、本当に必要な機能は分からないからです。

つまり、開発とは単に指示されたものを作る作業ではありません。

コードが正しく動いていても、誰の役にも立たなければ、開発の目的を達成したとは言えません。反対に、最初は簡単な仕組みでも、困っている人の助けになれば、価値のある第一歩になります。

2. 誰のために、何のために作るのか

何かを作る前に、次の二つを考えることが重要です。

• 誰のために作るのか――そのソフトウェアを使う人は誰か
• 何のために作るのか――その人の何を良くしたいのか

文化祭サイトなら、使う人は一人ではありません。

同じ「文化祭サイト」でも、誰のどの問題を優先するかによって、必要な機能は変わります。来場者の「探しにくい」を解決したいなら検索や絞り込みが重要です。実行委員の「変更を伝えにくい」を解決したいなら、お知らせの見つけやすさが重要です。

3. なぜ複数人で開発するのか

小さなプログラムなら、一人で作れることもあります。それでも、多くのソフトウェアは複数人で開発されます。一つのサービスを届けるまでには、さまざまな見方や技能が必要だからです。

• 利用する人の話を聞き、解決したい問題を整理する
• 情報を分かりやすく見せる画面を考える
• プログラムとして動く仕組みを作る
• 想定したとおりに動くかを確かめる
• 何を先に作るか、チームで判断する

ここで大切なのは、仕事を人数分に切り分けることだけではありません。自分一人では気づけないことを、別の人の視点から見つけられる点にも意味があります。

たとえば、検索機能を作った人は、機能が動いたことで安心するかもしれません。しかし、別の人に使ってもらうと、「検索ボタンがどこにあるか分からない」「漢字を間違えると見つからない」といった問題が見つかることがあります。

4. 開発ではなぜ予定どおりにいかないのか

開発を始める前に計画を立てることは大切です。しかし、最初に立てた計画が最後までそのまま使えるとは限りません。開発には、やってみるまで分からないことが含まれているからです。

文化祭サイトでは、たとえば次のことが起こります。

• 来場者に話を聞くと、予想とは違う情報が求められていた
• スマートフォンで試すと、画面が読みにくかった
• 出し物の数が予想より増え、一覧だけでは探しにくくなった
• 校内ルールが変わり、掲載できる情報が変わった
• 作り始めてから、想定より難しい技術上の問題が見つかった

これは、計画を立てた人が怠けていたから起きるとは限りません。未来の利用者の反応や、まだ作っていないものの使い心地を、最初から完全に知ることはできないからです。

5. 作ってみないと分からないことがある

紙に描いた画面や、言葉で説明された機能だけでは、実際の使い心地まで確かめられません。動くものがあると、利用する人は具体的な反応を返しやすくなります。

たとえば、開発前に「ジャンルで出し物を絞り込めたら便利ですか」と尋ねれば、多くの人が「便利そう」と答えるでしょう。しかし、実際の画面を使ってもらうと、次のような事実が分かるかもしれません。

• ジャンルの名前が分かりにくい
• 絞り込みを解除する方法が見つからない
• 実際には開催場所から探す人の方が多い
• 通信が遅い場所では表示に時間がかかる

このような発見は失敗ではありません。より役に立つものへ近づくための情報です。大切なのは、すべてを作り終えてから初めて見せるのではなく、確かめられる小さな形を早めに用意することです。

1. アジャイルを一言で説明すると

アジャイル（agile）という英単語には、「素早い」「機敏な」という意味があります。しかし、アジャイル開発を「とにかく急いで作ること」と捉えると、本質を見失います。

アジャイル開発を、この教材では次のように考えます。

ポイントは、最初の計画を守り抜くことよりも、その時点で分かったことを使って、より良い結果を目指すことです。

文化祭サイトで考えてみましょう。最初は「出し物を名前で検索できれば便利だろう」と予想したとします。実際に試してもらったところ、多くの来場者が「今いる場所の近くで何が行われているか知りたい」と話しました。

このとき、最初の予定だけを理由に名前検索を作り込み続けるのではなく、場所から探せる機能を先に検討します。目指すのは、予定表どおりに機能を完成させることではなく、来場者が見たい出し物を見つけられるようにすることだからです。

2. 「最初に全部決める」方法との違い

ものを作るとき、始める前に必要なものを詳しく調べ、設計し、計画どおり順番に作る方法があります。何を作ればよいかがよく分かっていて、途中の変化が少ない仕事では、この進め方が有効です。

一方、ソフトウェアには、利用する人が実物に触れて初めて希望を具体的に話せることや、作る途中で新しい問題が見つかることがあります。その場合、最初にすべてを正確に決めるのは困難です。

これは、どちらか一方がいつでも正しいという比較ではありません。状況に合わせて進め方を選ぶことが大切です。また、アジャイルでも計画や設計は行います。違うのは、先のことをすべて確定させようとせず、分かったことに応じて計画を更新する点です。

3. 小さく作って、確かめて、改善する

アジャイル開発では、完成まで何か月もかかる大きなまとまりを、確かめられる小さなまとまりに分けます。そして、一つ作るたびに「期待した価値があるか」「次に直すべきことは何か」を確認します。

文化祭サイトの検索機能なら、次のように段階を分けられます。

1. まず、出し物の名前を入力すると候補が表示されるようにする
2. 数人に使ってもらい、操作や検索結果を確かめる
3. 分かった問題を直し、必要なら場所での絞り込みを加える
4. もう一度使ってもらい、前より探しやすくなったか確かめる

小さく作るのは、機能を適当に減らすことではありません。一度に確かめたいことを絞るためです。小さな単位でも、途中で壊れたままにせず、その範囲ではきちんと使える状態を目指します。

このサイクルは、一度で終わりません。何度も回すことで、最初には見えていなかった正解へ少しずつ近づいていきます。

4. ここでいう「学び」とは

「学び」と聞くと、教科書を読んで知識を覚えたり、一人で新しい技術を身につけたりすることを想像するかもしれません。もちろん、それらも学びです。しかし、アジャイル開発で大切にする学びは、それだけではありません。

この教材では、開発における学びを次のように考えます。

• 利用者について新しく分かったこと
• 自分たちの予想と現実の違い
• 作ったものが目的に近づいたかどうか
• 次の判断を変える根拠

たとえば、文化祭サイトを使う様子から「来場者は出し物の名前より、現在地に近い場所から探すことが多い」と分かったとします。これは単なる感想ではありません。「場所から探せる機能を先に検討する」という次の判断を変える根拠になります。

反対に、情報を集めても、それを見ただけで終われば開発は変わりません。分かったことの意味を考え、これまでの予想を見直し、次の行動に生かすところまでが重要です。

学びは、「最初の考えが間違っていた」と誰かを責めるためのものではありません。開発を始めた時点では知らなかった事実をチームで共有し、より良い判断をするためのものです。

5. フィードバックから次を決める

作ったものに対して返ってくる反応や情報を、フィードバックと呼びます。利用者からの感想だけでなく、操作する様子、起きたエラー、利用状況の記録、チームからの指摘などもフィードバックです。

フィードバックを受け取ったら、言われたことをすべてそのまま追加するわけではありません。まず、何が起きているのか、その背景にどんな困りごとがあるのかを考えます。そのうえで、目的に照らして次に取り組むことを選びます。

6. アジャイルにする目的

アジャイルな進め方を採用する目的は、短い期間でたくさんの機能を完成させることではありません。利用する人にとって価値のあるものを、不確かさの中でも作れるようにすることです。

そのために、小さなサイクルを繰り返します。

• 重要なものから届け、早い段階で役立ててもらう
• 間違った予想に長い時間を使う前に気づく
• 利用者や周囲の変化に合わせて方向を調整する
• チームが経験から学び、作り方そのものも改善する

「計画した10機能をすべて作ったが、ほとんど使われなかった」状態より、「本当に必要な3機能を使いやすく届け、困りごとを解決した」状態の方が、開発の目的に近いと言えます。

7. 速く作ることだけが目的ではない

アジャイルという言葉の印象から、「短い締め切りで休まず作る方法」「計画や記録を省いて速くする方法」と誤解されることがあります。しかし、無理な速さで作り続ければ、ミスが増え、直す時間がかかり、チームは疲れてしまいます。

アジャイルで大切なのは、単純な作業速度よりも、次のような学びの速さです。

• 役に立たない案に早く気づく
• 分からないことを早く見つける
• 小さな問題のうちに共有する
• 利用者の反応を早く次の判断へ反映する

また、変更しやすい状態を保つには、読みやすく作る、動作を確かめる、チームで情報を共有するといった丁寧な仕事が必要です。速さを理由に品質を後回しにすると、やがて変更が難しくなり、学んだことを生かせなくなります。

アジャイルなチームが目指すのは、いつでも全力で走ることではありません。無理なく続けられるペースで、小さな価値を届け、確かめながら進むことです。

1. 「作ること」ではなく「役に立つこと」を考える

開発をしていると、機能を完成させること自体が目標になりがちです。しかし、利用者が必要としているのは機能の数ではなく、その機能によって困りごとが解決されることです。

文化祭サイトに地図、人気順、コメント、写真投稿の四つを追加しても、来場者が開催時刻を見つけられなければ、重要な問題は残ったままです。「何を作ったか」だけでなく、「誰にどんな良い変化が起きたか」を確かめます。

2. いきなり完璧を目指さず、小さく完成させる

最初からあらゆる利用者、端末、状況に対応しようとすると、完成まで長くなり、途中で確かめる機会を失います。そこで、まず一つの目的を満たす小さな範囲を決め、その範囲ではきちんと使える状態にします。

たとえば「出し物を探す」という目的に対して、最初は名前と場所を一覧表示し、名前で検索できるところまで完成させます。見た目だけで動かない画面や、途中で必ずエラーになる状態は「小さな完成」ではありません。

小さく完成していれば、実際に使って確かめられます。問題があっても影響範囲が小さく、次の改善へ進みやすくなります。

3. 大きな仕事を小さく分ける

「文化祭サイトを作る」のような大きな仕事は、そのままでは何から始めるか、どこまで進んだかが分かりません。利用者に届く価値を意識して、小さなまとまりへ分けます。

「画面を作る」「プログラムを書く」のように作業の種類だけで分けると、最後まで組み合わせなければ価値を確かめられません。できるだけ、一つ終わるごとに利用者の立場で動きを確かめられる分け方を考えます。

4. 大切なものから取り組む

時間や人数には限りがあるため、思いついたものをすべて同時には作れません。そこで、次の観点から優先するものを選びます。

• 多くの利用者にとって重要か
• 困りごとを大きく改善できるか
• 分からない点が多く、早く確かめる必要があるか
• 他の仕事を始めるために必要か
• 安全や公開日に関わる問題か

簡単なものから着手すると進んだ気分にはなりますが、重要な問題が最後まで残ることがあります。反対に、重要でも大きすぎる仕事は、確かめられる範囲まで小さくしてから始めます。

5. 変化を前提にする

利用者の希望、学校のルール、使える時間、技術上の条件は変わります。変化をすべて防ぐことはできません。だからこそ、変化が起きても直せるように準備します。

• 決まったことと未決定のことを区別する
• なぜその判断をしたか共有する
• 一度に作りすぎず、途中で確認する
• 変更による影響を確かめる

変化を受け入れることは、誰かの思いつきに毎回従うことではありません。目的、影響、必要な時間を確認し、今取り入れる価値があるかを判断します。

6. 小さく試して、早く学ぶ

正解が分からないときは、長い議論だけで決めようとせず、小さな試し方を考えます。試作品を数人に触ってもらう、紙に描いた画面で操作をたどってもらう、二つの案を比べてもらう、といった方法があります。

試す目的は、案が正しいと証明することではありません。予想のどこが合っていて、どこが違うかを知ることです。試す前に「何を知りたいか」を決めておくと、得られた反応を判断に使いやすくなります。

7. チームで情報を共有する

一人だけが重要な情報を知っていても、チームの判断には生かせません。利用者から聞いたこと、作業中に気づいたこと、うまくいかなかったことを共有します。

情報共有には、相手が次の行動を判断できる具体性が必要です。「検索がだめでした」ではなく、「スマートフォンでは検索結果が画面の下に隠れ、3人中2人が気づかなかった」と伝えれば、問題の状況が分かります。

共有は報告のためだけではありません。認識の違いを早く見つけ、助けを得て、チーム全体でより良い判断をするために行います。

8. 毎回少しずつ改善する

改善する対象は、作っているサイトだけではありません。チームの進め方も振り返ります。

• 質問するのが遅くなったなら、次はいつ相談するか決める
• 確認漏れがあったなら、確認項目を一つ追加する
• 話し合いが長すぎたなら、目的と終了時刻を最初に共有する

一度にすべてを直そうとすると続きません。次のサイクルで実行できる小さな改善を一つ選び、効果を確かめます。改善案も、試して学ぶ対象です。

1. 何を解決したいのか考える

サイクルは、作る機能を選ぶところではなく、解決したい問題を理解するところから始まります。

文化祭サイトでは、「来場者が見たい出し物へ時間どおりにたどり着けない」という声が集まったとします。誰が、どの場面で、なぜ困っているのかを調べます。原因は検索機能の不足かもしれませんし、校内図の分かりにくさや、時刻変更の伝わりにくさかもしれません。

問題を急いで機能へ置き換えず、まず「良くしたい状態」を言葉にします。

来場者が、見たい出し物の場所と開始時刻を迷わず確認できる。

この状態が、サイクル中の判断をそろえる目印になります。

2. 今回作るものを決める

解決方法の候補を出し、今のサイクルで何を作るか選びます。すべての問題を一度に解決しようとはしません。

今回は、来場者への聞き取りから「教室名だけでは場所が分からない」ことが大きな原因だと分かり、各出し物に校内図上の位置を表示することにしたとします。

選ぶときは、次を確認します。

• 目的にどれくらい近づけそうか
• 今回の期間で、使える状態まで完成できるか
• 何を確かめたいのか
• 今回は扱わないものは何か

「今回は地図上の位置を表示する。経路案内はまだ作らない」と範囲を明確にすれば、チームの認識がそろいます。

3. 仕事を小さくする

選んだものを、そのまま「地図機能を作る」という大きな仕事にせず、確認できる単位へ分けます。

1. 出し物ごとに校舎・階・教室の情報をそろえる
2. 詳細画面に場所を文字で表示する
3. 階ごとの簡単な図に位置を示す
4. スマートフォンで読み取れるか確認する

分けることで、必要な情報や難しい点が見えてきます。仕事の順番も考えやすくなり、途中の状態をチームで確認できます。

ただし、細かくすること自体が目的ではありません。一つずつ終えたときに、全体の完成へ近づき、何かを確かめられる分け方にします。

4. 作る

決めた範囲を、実際に使える形へしていきます。作っている途中にも疑問や新しい事実が見つかります。

たとえば、教室名の書き方が出し物ごとに違う、階によって図の向きが違う、といった問題です。小さな判断であっても目的へ影響しそうなら、チームに共有します。

作る段階でも、長い間一人で抱え込まず、途中のものを見せます。早めに認識の違いを見つければ、完成後に大きく作り直す危険を減らせます。

5. 確かめる

「表示されたから完成」とは限りません。まず、決めた条件どおり動くかを確認します。次に、利用者が目的を達成できるかを確かめます。

作った本人は仕組みを知っているため、迷いに気づきにくいことがあります。別の人にも使ってもらい、説明なしでどう操作するかを観察します。

6. フィードバックを受ける

動くものを見せると、具体的な反応を得られます。「便利ですか」と聞くだけでなく、実際に目的地を探してもらい、どこで止まるかを見ます。

「現在地が分からない」「階段の位置が必要」「図より教室番号の方が探しやすい」といった反応があったとします。すべてをすぐ変更するのではなく、誰がどの場面で困ったのかを確かめます。

良かった点も集めます。何が役立ったかが分かれば、残すべき部分と改善すべき部分を区別できます。

7. 次に何をするか決める

最後に、得た学びを次の判断へつなげます。現在地を示すことが多くの人に必要だと分かったなら、次のサイクルで優先します。一方、階段の表示は別の案で十分かもしれません。

この段階では、次の三つを整理します。

• 目的へどれくらい近づいたか
• 新しく分かったことは何か
• 次に最も大切なことは何か

サイクルの終わりは、開発全体の終わりとは限りません。学んだことを持って、次のサイクルの「何を解決したいか」へ戻ります。

1. Scrumとは何か

Scrumは、複雑な問題に取り組みながら価値を生み出すための、軽量な枠組みです。短い期間で成果を作り、結果と進め方を確かめ、次の計画を調整します。

Scrumには、チームの責任、定期的に行う活動、仕事や成果を見えるようにするものが定められています。ただし、何を作れば正解かをScrumが教えてくれるわけではありません。チームが経験から学び、判断するためのリズムを作ります。

文化祭サイトなら、数週間ごとに使える改善を完成させ、来場者や実行委員と確認し、次に必要なことを選ぶ進め方が考えられます。

2. アジャイルとScrumは同じではない

アジャイルは、変化や不確かさのある開発で価値へ近づく考え方です。Scrumは、その考え方を実践するためによく使われる枠組みの一つです。

Scrumを使わずにアジャイルに開発するチームもあります。反対に、Scrumの用語や予定だけをまねても、フィードバックを無視し、計画を更新しなければ、アジャイルな開発にはなりません。

3. スプリント

スプリントは、価値のある使える成果を作る、1か月以内の固定された長さの期間です。一つのスプリントが終わると、間を空けずに次のスプリントが始まります。

スプリントには、計画、毎日の確認、成果のレビュー、進め方の振り返りが含まれます。文化祭サイトなら、2週間のスプリントで「出し物の場所を探せる状態」を目標にする、といった使い方ができます。

短く区切ると、遠い未来まで一度に予測する必要がなくなり、結果を確かめる機会が定期的に訪れます。うまくいかない案に使う時間や危険も、小さくできます。

4. プロダクトバックログ

プロダクトバックログは、プロダクトを良くするために必要だと分かっていることを、順序をつけて並べた一覧です。機能だけでなく、不具合の修正、調査、使いやすさの改善なども入ります。

文化祭サイトなら、次のような項目が考えられます。

• 教室変更を目立つように表示する
• 出し物を場所で絞り込めるようにする
• 古い端末で表示が遅い問題を調べる
• 校内図を読みやすくする

バックログは最初に完成させて固定する仕様書ではありません。フィードバックや環境の変化から新しいことが分かれば、追加、削除、並べ替え、具体化を続けます。

5. スプリントバックログ

スプリントバックログは、スプリントゴール、その達成のために選んだプロダクトバックログの項目、実現するための計画を合わせたものです。

スプリントを始めるとき、チームは「なぜ価値があるか」「今回何ができそうか」「どう進めるか」を話し合います。実際に作る開発者が、状況を見ながら計画を更新します。

予定外の問題が見つかったときも、スプリントゴールを守りながら計画を調整します。最初に書いた作業一覧を変えないことより、ゴールを達成することが重要です。

6. デイリースクラム

デイリースクラムは、開発者がスプリントゴールへの進み方を確かめ、次の一日の計画を調整する、15分の活動です。

上司へ作業を報告する会議ではありません。チーム自身が、ゴールへ近づいているか、協力や計画変更が必要かを判断します。

たとえば次のことを共有します。

• 地図表示は完成したが、教室データに不足がある
• 別の人の確認がないと今日の作業を進められない
• 想定より表示が遅く、先に原因を調べたい

詳しい相談が必要なら、関係する人がデイリースクラムの後で続けます。短い時間で重要な変化を見つけ、問題を何日も放置しないことに意味があります。

7. スプリントレビュー

スプリントレビューでは、スプリントで生まれた成果と、その間に起きた環境の変化を関係者と一緒に確かめ、次に何をするか話し合います。

完成したものを一方的に発表して承認をもらうだけの場ではありません。実際の成果を見ながら、「目的に近づいたか」「利用者や学校の状況は変わったか」「次に何が価値を持つか」を考える作業の場です。

レビューで得た情報によって、プロダクトバックログの内容や順序を更新します。

8. レトロスペクティブ

スプリントレトロスペクティブでは、成果物ではなく、チームの進め方を振り返ります。人、やり取り、作業の流れ、使った方法などを見て、品質と効果を高める改善を考えます。

たとえば「教室データの不足に気づくのが遅かった」という問題に対して、誰かを責めるのではなく、「次はスプリントの最初に必要なデータを確認する」という改善を選びます。

改善案は、実行できる具体的なものにします。選んだ改善は、次のスプリントの仕事へ加えることもあります。

9. Scrumを使う理由

Scrumの活動は、会議を増やすためにあるのではありません。一定のリズムで次の機会を作るためにあります。

Scrumは、現在の状態や問題を見えやすくします。見つかった問題を隠さず、確かめ、必要な変更を行うことで初めて役立ちます。

1. チーム全体で成果を出す

文化祭サイトでは、企画を考える人、画面を設計する人、プログラムを書く人、内容を確認する人がいるかもしれません。しかし、利用者にとっては、誰が担当したかより、サイト全体が役に立つかが重要です。

チームは、個人の作業を集めるだけでなく、一つの目的に向かって協力します。

• 必要な情報を共有する
• 困っている人を助ける
• 担当の境界にある問題を放置しない
• 成果全体を一緒に確かめる

2. 開発を担当する人

Scrumでは、各スプリントで使える成果を作ることに責任を持つ人たちを開発者と呼びます。ここでいう開発者は、プログラムを書く人だけに限りません。成果に必要なら、設計、文章、テスト、調査などさまざまな技能を持つ人が含まれます。

開発者は、次のことに責任を持ちます。

• スプリントの計画を作る
• 完成の基準を守り、品質を作り込む
• スプリントゴールへ向けて毎日計画を調整する
• 専門家として互いに責任を持って行動する

誰かが細かな作業をすべて割り当てるのを待つのではなく、ゴールを達成する方法をチームで考えます。

3. プロダクトオーナー

プロダクトオーナーは、チームが生み出すプロダクトの価値を最大にすることに責任を持ちます。利用者、関係者、チームから情報を集め、何を目指し、何を優先するかを明確にします。

主な責任は次のとおりです。

• プロダクトゴールを示し、共有する
• プロダクトバックログの項目を分かりやすくする
• 項目の順序を決める
• バックログが見え、理解される状態にする

プロダクトオーナーは、すべての答えを一人で考える人でも、開発者へ命令する人でもありません。多くの意見を聞きながら、価値についての最終的な判断を担います。

文化祭サイトなら、来場者と実行委員の要望が競合したとき、サイトの目的や状況をもとに優先順位を明確にします。

4. スクラムマスター

スクラムマスターは、Scrumがチームや組織で正しく理解され、役立つようにすることに責任を持ちます。

会議の司会だけをする人ではありません。チームが自分たちで成果を出せるよう支援し、進行を妨げる問題の解決を助け、効果の高い活動が行われるよう働きかけます。

たとえば、レビューが完成報告だけになっているなら、関係者と成果を確かめて次を考える場になるよう支援します。質問しづらい雰囲気があるなら、問題を安全に共有できる方法をチームと考えます。

スクラムマスターも開発者の上司ではありません。チームの判断を代わりに行うのではなく、チームがより良く判断できる環境を作ります。

5. デザインなどを担当する人

実際の開発には、画面や体験を設計する人、文章を書く人、利用者を調査する人、データを分析する人なども参加します。

これらはScrum Teamの外に必ず分離する職種という意味ではありません。使える成果を作るために日々一緒に働くなら、その技能を持つ開発者としてチームに参加できます。

大切なのは、専門分野ごとに仕事を順番に受け渡すだけにしないことです。たとえば、画面を考える人と実装する人が早い段階から一緒に試せば、見た目と技術の問題を完成前に見つけられます。

6. 役割が違っても目的は同じ

役割によって注目する対象は異なります。

意見が違うことはあります。開発者は技術上の危険を、プロダクトオーナーは利用者への価値を強く見るかもしれません。違いを隠さず、共通の目的と事実をもとに話し合うことで、より良い判断ができます。

7. 「役割」と「上下関係」は違う

責任を持つ範囲が違うことは、人としての上下や偉さを表しません。プロダクトオーナーが優先順位に責任を持っていても、開発方法を一方的に命令するわけではありません。開発者も、技術だけを理由に利用者の価値を無視することはできません。

責任の所在が明確なら、判断が必要なときに誰と話すべきかが分かります。一方で、担当外だからと問題を放置せず、必要な人へつなぎます。

1. タスクとは何か

チームでは、取り組む仕事を小さな単位にしてタスクと呼ぶことがあります。タスクには、機能の追加、不具合の修正、調査、文章の改善、確認作業などがあります。

タスクは、書いてある文章をそのまま実行する命令ではありません。チームが目的へ近づくために、必要な仕事を見えるようにしたものです。短い説明の背景には、利用者の困りごとや他の仕事との関係があります。

2. なぜこのタスクをやるのか確認する

「検索結果がないとき、メッセージを表示する」というタスクを考えます。目的を知らなければ、指定された文章を表示して終わりにするでしょう。

背景を聞くと、「結果が空白になるため、利用者が読み込み中だと思って待ち続けている」と分かりました。すると、必要なのは文章だけでなく、検索が終わったことや条件を変えて再検索できることを伝える表示だと理解できます。

目的が分かると、細かな判断に迷ったときの基準になります。まず「この仕事で、何を良くしたいのですか」と確認します。

3. 誰のための変更なのか考える

同じ画面でも、利用する人によって必要なものは変わります。初めて文化祭へ来る人には分かりやすい案内が必要です。情報を登録する実行委員には、間違いを見つけやすい表示が必要かもしれません。

次の点を具体的にします。

• 主に使うのは誰か
• どのような場面で使うか
• 今は何に困っているか
• 変更後に何ができればよいか

「みんなのため」のままでは判断しにくいため、今回最も助けたい人と場面を明確にします。

4. 「何を作れば完了なのか」を確認する

依頼した人と作る人で、「できた」の意味が違うことがあります。そこで、完成したと判断できる具体的な状態を確認します。

検索結果の例なら、次のような条件が考えられます。

• 一件も見つからないときだけ案内が表示される
• 検索前や読み込み中には表示されない
• 入力した言葉が間違っていないか確認できる
• スマートフォンでも文章が読める

完成の条件があれば、作業中に自分で確かめられ、レビューする人とも認識を合わせられます。

5. 分からないことを見つける

説明を読んで「だいたい分かった」と感じても、一度自分の言葉で説明してみます。

• なぜ必要か説明できるか
• 利用者と利用場面を説明できるか
• 変更する場所が分かるか
• 完成をどう確かめるか分かるか
• 他の仕事への影響が分かるか

説明できない部分が、確認すべき不明点です。分からないことがあるのは問題ではありません。分からないまま作り始め、思い込みで埋めることが問題を大きくします。

6. 作業をさらに小さく分ける

タスクが一日で終わりそうに見えても、必要な行動へ分けると進めやすくなります。

1. 現在の検索結果の動きを確認する
2. 表示する条件と文章を確認する
3. 案内を表示する
4. 結果がある場合とない場合を確かめる
5. 別の人に見てもらう

分けた結果、分からない作業や想定より大きな範囲が見つかることもあります。その時点で早く相談できます。

7. 完了したと言える条件を確認する

チームには、一つのタスクの条件に加えて、成果全体に共通する「完了」の基準があることがあります。たとえば、表示確認が終わっている、別の人のレビューを受けている、既存の動きを壊していない、といった基準です。

作った本人が「コードを書き終えた」と感じても、確認や共有が残っていれば、チームとしては完了していません。始める前に完了の基準を知っておけば、最後になって必要な作業に気づくのを防げます。

1. 最初から全部分かる必要はない

開発を始める前に、必要な知識をすべて覚えることはできません。作業を進めたからこそ、新しい疑問が見つかることもあります。

分からないと感じることは、自分に能力がない証拠ではありません。「今の情報だけでは判断できない」と気づいた状態です。その気づきを、調査や質問の出発点にします。

知ったふりをすると、誤った理解のまま作業が進み、後で大きな手戻りになります。安心して「分かりません」と言えることは、チームの品質にも関わります。

2. 分からないことを放置しない

疑問を抱えたまま、分かる部分だけを長く進めると、前提が違っていたときに作り直しが増えます。また、他の人がその作業を待っているかもしれません。

まず、分からないことを言葉にします。

「何が分かっていて、どこから分からないか」を切り分けるだけで、自分で答えを見つけられる場合もあります。

3. まず何を調べればよいか

すぐ確認できる事実は、自分で調べます。ただし、闇雲に検索するのではなく、知りたいことに合う場所を選びます。

1. タスクの説明や、完了条件を読み直す
2. 現在の画面や動きを実際に確かめる
3. チームですでに決めたことや、過去の似た例を確認する
4. 一つだけ小さく試し、予想と結果を比べる

「利用者へ何を表示するか」のようなチームの判断は、一般的な検索だけでは決まりません。誰に聞くべき問題なのかも見分けます。

4. どこまで調べたら質問するか

何時間も一人で調べ続ける必要はありません。特に、次の場合は早く相談します。

• 目的や完了条件が分からず、選択によって成果が変わる
• 他の人の作業を止めている
• 安全、公開、データの消失など大きな影響があり得る
• 試せることを試しても、新しい情報が増えない
• 決めた時間を超えて進展がない

チームで「15分調べて進まなければ相談する」のような目安を決めてもよいでしょう。時間だけでなく、間違えたときの影響も考えます。

5. 良い質問には何が入っているか

良い質問とは、難しい言葉を使う質問ではありません。相手が状況を理解し、一緒に次の行動を考えられる質問です。

次の四つを含めると伝わりやすくなります。

たとえば次のように質問できます。

検索結果が0件のときの案内を作っています。タスクと現在の画面を確認し、二つの表示案を考えましたが、再検索を促すか一覧へ戻すかの目的が判断できません。今回はどちらの利用場面を優先するか確認したいです。

試したことを長く並べるだけでなく、最後に相手へ何を求めているかを明確にします。

6. 自分の理解を確認する

回答を聞いたとき、「分かりました」で終わらせず、自分の言葉で確認します。

つまり今回は、入力間違いに気づいて再検索できることを優先し、入力欄の近くに案内を出す、という理解で合っていますか。

相手の言葉をそのまま繰り返すのではなく、自分が次に行うことまで説明します。認識が違えば、その場で修正できます。

重要な判断は、後からチームも確認できるように共有します。同じ質問を何度も繰り返さず、別の人も判断の理由を理解できます。

7. 質問することも開発の一部

質問は、作業を止める行為ではありません。不明点を明らかにし、間違った方向へ進むのを防ぐ開発活動です。

一方で、質問を受ける側にも責任があります。質問した人を責めず、前提や判断理由を伝えます。同じ疑問が何度も起きるなら、個人の問題にせず、説明やタスクの書き方を改善します。

1. 今何をしているか伝える

進み具合を伝えるときは、「作業中です」だけでなく、ゴールとの関係が分かるようにします。

• 何を完了したか
• 次に何をするか
• 予定との違いはあるか
• 助けが必要なことはあるか

場所の文字表示は確認まで終わりました。今日は地図上の位置表示を作ります。教室データが3件不足しているため、実行委員への確認が必要です。

このように伝えると、他の人は待つべきか、助けるべきか、計画を変えるべきかを判断できます。

2. 困ったことを早く共有する

問題は、確実な原因と解決策が分かってから報告するものではありません。影響が広がりそうなら、調査中でも共有します。

次の順で伝えると状況が分かりやすくなります。

1. 何が起きているか
2. どこに影響しそうか
3. 何が分かっていて、何が不明か
4. 今何をしているか
5. どんな助けが必要か

早い共有は、できないことの告白ではありません。チームが選べる対応を増やす行動です。

3. 予定より時間がかかりそうなとき

遅れは、期限を過ぎてから伝えるのではなく、予定との差が見えた時点で共有します。「何とか間に合わせます」と抱え込むと、範囲を小さくする、別の人が助ける、順番を変えるといった選択ができなくなります。

伝える内容は、次のように具体的にします。

今日完成予定でしたが、地図データの形式が階ごとに違い、変換に追加で半日ほど必要そうです。文字での場所表示は完成しています。位置表示の範囲を一階だけにするか、別の人と変換を分担するか相談したいです。

見積もりは予言ではないため、外れることがあります。差から学び、次の計画を更新することが重要です。

4. 他の人に影響しそうなとき

自分の変更が、他の画面、データ、担当者の作業へ影響することがあります。影響が確定していなくても、可能性があれば関係する人へ早めに知らせます。

• 何を変える予定か
• どの部分に影響する可能性があるか
• いつ変更するか
• 相手に確認してほしいことは何か

相手の作業が終わった後に知らせるより、始める前に短く相談する方が、作業の衝突を小さくできます。

5. 意見が違うとき

意見の違いは、どちらかが悪いことを意味しません。見ている利用者、持っている情報、心配している危険が違う可能性があります。

人ではなく、目的と案について話します。

共通の目的を確認し、各案の良い点、心配な点、確かめられる方法を出します。決めきれないなら、小さく試して情報を増やします。

6. レビューで指摘を受けたとき

レビューの指摘は、自分自身への評価ではなく、成果を良くするための情報です。まず内容と理由を理解します。

• 分からない場合は、具体的な例を尋ねる
• 自分の判断理由や前提があれば説明する
• 同意した場合は、どう直すか確認する
• 意見が違う場合は、目的と事実をもとに話す

すべての指摘へ黙って従う必要はありませんが、すぐ防御するのでもなく、相手が何を心配しているかを確かめます。

7. レビューするときに気をつけること

レビューする側は、相手が次の行動を取れるように伝えます。「だめ」「分かりにくい」だけでは改善方法を判断できません。

結果が0件のときも一覧と同じ余白なので、案内を見落としやすいと思います。案内を見出しの直下に移すか、区切りを付ける案はどうでしょうか。

事実、心配する影響、改善案を分けて伝えます。必ず直す必要がある問題なのか、検討してほしい提案なのかも明確にします。

良い点も具体的に伝えると、残すべき判断を共有できます。「スマートフォンでもボタンが押しやすくなっています」のように、何が良いかを示します。

1. 何を作るのか読む

ユウが受け取ったタスクには、こう書かれていました。

文化祭サイトに、出し物を検索する機能を追加する。

ユウは、すぐに画面を作り始めませんでした。「検索」という言葉だけでは、対象、利用場面、完了条件が分からないからです。まず、タスクに書かれた背景と関連する情報を読み、現在のサイトも操作しました。

2. なぜ必要なのか確認する

企画を担当する人へ尋ねると、来場者への試用で「一覧が長く、見たい出し物を見つける前に諦めた」という問題が見つかったと分かりました。

目的は検索欄を置くことではなく、来場者が興味のある出し物を短時間で見つけられることです。ユウは、この目的をタスクへ書き加えてチームと共有しました。

3. 分からない点を見つける

ユウは、自分の理解を説明しようとして、次の不明点に気づきました。

• 名前だけを検索するのか、紹介文も対象にするのか
• 一部だけ入力しても見つかるのか
• 結果がないとき、何を表示するのか
• どのくらい早く見つけられたら改善と言えるのか

分からないことを一覧にし、現在の情報から確認できるものと、チームの判断が必要なものに分けました。

4. 質問する

ユウは、目的、確認した内容、判断できない点をまとめて質問しました。

一覧から出し物を見つけにくい問題を解決する仕事だと理解しています。試用時の記録では、名前の一部を覚えている人が多くいました。最初は名前の一部で検索する範囲にしてよいですか。また、結果がない場合は別の言葉を試せる案内を出したいです。

チームは記録を一緒に確認し、その範囲で試すことに同意しました。将来は場所やジャンルも検討しますが、今回は含めません。

5. 完了条件を確認する

ユウとチームは、今回の完了条件を具体的にしました。

• 名前の一部を入力すると、該当する出し物だけが表示される
• 文字を入力していないときは、すべて表示される
• 該当するものがないときは、再検索を促す案内が表示される
• スマートフォンで入力と結果を確認できる
• 別の人の確認を受け、既存の一覧表示が壊れていない

これで、何を作り、何を確かめれば完了かがそろいました。

6. 仕事を小さく分ける

ユウは作業を次の順に分けました。

1. 現在の一覧がどう表示されるか確認する
2. 検索欄を表示する
3. 入力に合う出し物を選んで表示する
4. 入力なしと結果なしの場合を扱う
5. 複数の端末サイズで確かめる
6. チームに確認してもらう

分けた内容を見た別のメンバーが、「出し物の名前にはひらがなとカタカナの違いがある」と教えてくれました。今回は入力どおりの検索で始め、その違いが問題になるか試用で確かめることにしました。

7. 作業を始める

ユウは、最初の小さな部分から作り、動きを一つずつ確かめました。途中で、入力のたびに一覧の位置が大きく動く問題に気づきました。

一人で最後まで進めず、途中の画面をチームへ見せました。画面設計を担当するメンバーと相談し、検索結果の件数を同じ場所へ表示すると、変化が分かりやすいという案を試しました。

8. 作ったものを確認する

完成条件に沿って、ユウ自身が動きを確認しました。よく使う言葉だけでなく、次のような場合も試しました。

• 一文字だけ入力する
• 結果が複数ある
• 結果が一件だけある
• 一件もない
• 入力した文字をすべて消す

正しく動くことに加えて、初めて使う人が検索結果に気づけるかも確認しました。

9. チームに確認してもらう

別のメンバーが、目的と完了条件を見ながら確認しました。すると、検索自体は動きますが、結果が0件の案内が画面の下にあり、スマートフォンでは見えないことが分かりました。

レビューでは「案内を上へ移動してください」だけでなく、「利用者が結果なしに気づかず待つ問題を防ぎたい」と理由も共有されました。ユウは指摘の目的を理解できました。

10. 指摘を受けて修正する

ユウは案内を検索欄の近くへ移し、入力した言葉も表示しました。また、結果がない場合にだけ案内されることをもう一度確認しました。

修正後、指摘した人に見てもらい、心配していた問題が解決したことを確認しました。別の場所を直した影響で一覧表示が壊れていないかも確かめました。

11. 完成させる

完了条件をチームで見直し、すべて満たしていることを確認しました。作った内容、確認したこと、残っている不確かさも共有しました。

残っている不確かさは、「ひらがなとカタカナの違いで見つからない人がいるか」です。今回は想像だけで機能を増やさず、実際の利用から学ぶことにしました。

12. 実際に使ってもらう

5人の生徒に、「見たい出し物を探してください」とだけ伝えて使ってもらいました。4人はすぐ見つけましたが、1人は「おばけやしき」と入力し、カタカナで登録された「オバケ屋敷」を見つけられませんでした。

また、2人が名前ではなく「体育館」と入力しました。検索結果が0件になった後、場所では検索できないと気づきました。

感想だけでなく、どんな言葉を入力し、どこで迷ったかを観察したことで、次の判断に使える情報を得られました。

13. フィードバックから次を考える

チームは試用結果を整理しました。

• 名前検索は、多くの人が出し物を早く見つける助けになった
• 表記の違いで見つからない場合がある
• 場所から探したい利用者もいる

すぐ両方を追加するのではなく、文化祭本番までの時間と影響する人数を考えました。次は、表記の違いを吸収する小さな改善を優先し、場所検索は必要な情報と画面を調べることにしました。

1. バグを出してしまった

公開した検索機能で、一部の出し物が表示されないバグが見つかったとします。まず、責任を隠すことや、原因が分かるまで黙って直すことは避けます。

1. 何が起き、誰に影響しているか共有する
2. 影響が広がるなら、一時的に機能を止めるなどの対応を相談する
3. 起きる条件を確認する
4. 修正し、問題と周辺の動きを確かめる
5. 原因と再発を減らす改善を共有する

「誰が間違えたか」だけを探しても、次のバグは防げません。確認方法、情報不足、作業の急ぎ方など、問題が通り抜けた仕組みも見ます。

2. 予定より遅れてしまった

遅れに気づいたら、残り時間と未完了の仕事を具体的にします。すべてを無理に終わらせるのではなく、目的を守れる選択肢をチームで考えます。

• 範囲を小さくして、重要な部分を完成させる
• 優先度の低い仕事を後へ移す
• 別の人と協力する
• 公開時期を変える必要があるか相談する

終わった後には、見積もりだけを反省するのではなく、どの時点で予想との差が見えたか、もっと早く共有できる合図がなかったかを振り返ります。

3. やり方が分からなくなった

何を試しても進まなくなったときは、同じ方法を繰り返す前に立ち止まります。「検索機能が動かない」ではなく、期待、実際の結果、試したことを整理します。

その情報を持って相談すれば、別の人が原因に気づくかもしれません。問題を二人で一緒に見る、もっと小さな例で確かめる、別の方法を選ぶ、といった選択もできます。

分からない状態が長引いたことを責めるより、次から相談する目安や、必要な知識を共有する方法を決めます。

4. 間違ったものを作ってしまった

完成後に「求めていたものと違う」と分かった場合、まず目的と現在の成果の差を確認します。作ったものを守ることや、すべて捨てることを急いで決めません。

• 利用者の問題をどう理解していたか
• どの判断で認識が分かれたか
• 今の成果で利用できる部分はあるか
• 最小の修正で目的へ近づけるか

費やした時間が長いほど手放しにくくなりますが、過去の作業量ではなく、これから価値を届けるための判断をします。

5. 要求の意味を勘違いしていた

「場所を表示する」を文字で表示する意味だと思っていた一方、依頼した人は地図を想像していた、ということがあります。言葉だけでは、同じ理解にならない場合があります。

勘違いが分かったら、まず正しい目的と必要な範囲をそろえます。その後、次から早く認識を確認する方法を考えます。

• 自分の言葉で理解を説明する
• 完了条件を具体例にする
• 早い段階で途中のものを見せる
• 分からない言葉をそのままにしない

確認を増やしすぎるのではなく、間違えたときの影響が大きい部分を早めに確かめます。

6. 他の人の作業とぶつかってしまった

同じ画面を二人が別々に変更し、一方の変更をそのまま合わせられないことがあります。まず両方の変更の目的を確認し、必要な内容を失わない組み合わせ方を相談します。

急いで片方を捨てたり、相手の変更を無断で直したりしません。判断が難しければ、画面全体の目的を知る人も交えて決めます。

次からは、作業を始める前に影響範囲を共有する、大きな変更を小さくする、途中で変更を合わせる、といった方法で衝突を小さくします。

7. 問題を早く共有することが重要な理由

早く共有するほど、チームが選べる対応は多くなります。公開の三日前なら範囲を変えられても、公開直前では選択肢が限られます。

問題が起きたこと自体を評価する雰囲気では、共有が遅れます。「知らせてくれて助かった」と受け止め、状況と次の行動へ集中することが、チーム全体の安全につながります。

8. 失敗から次のやり方を改善する

問題を直しただけでは、同じ条件で再び起こるかもしれません。落ち着いた後で振り返ります。

1. 期待していたことと、実際に起きたことを分ける
2. 途中で見えていた合図を探す
3. うまく対応できた点も確認する
4. 次に試す小さな改善を一つ選ぶ
5. 改善が役立ったか、次のサイクルで確かめる

ここで第2章の「学び」が再び重要になります。失敗の情報を集めるだけでなく、その意味を考え、次の判断や進め方を変えられる状態にします。

1. 最初から全部分かる必要はない

経験のある人でも、初めて扱うプロダクトや利用者については知りません。最初から正しい答えを持つことより、観察し、質問し、試しながら理解を増やす姿勢が重要です。

分からないことを隠すために一人で決めず、今の理解を言葉にします。理解が不完全でも共有すれば、チームは不足している情報を一緒に見つけられます。

2. 分からないことを放置しない

「後で分かるだろう」と曖昧な点を残すと、思い込みが作業へ入り込みます。目的、利用者、完了条件に関わる疑問ほど早く確認します。

すぐ答えが出ない場合も、「何が未決定か」「誰がいつ判断するか」を見えるようにします。未決定であることをチームが知っていれば、その前提で安全に進められます。

3. 自分だけで抱え込まない

難しい仕事を一人で最後まで解決することが、いつでも最も良い貢献とは限りません。長く止まれば、チーム全体の成果にも影響します。

早めに途中のものを見せる、別の人と一緒に考える、仕事を分け直すといった方法を使います。助けを求めるだけでなく、他の人の困りごとにも気づき、できる助けを申し出ます。

4. 「何を作るか」だけでなく「なぜ作るか」を考える

タスクの文章は、目的を実現する一つの案です。目的が分かれば、細かな判断を自分で行え、より小さく価値を届ける案も提案できます。

作業を始める前、迷ったとき、完成を確認するときに、「これは誰の何を良くするのか」へ戻ります。目的は、チームが違う専門性を持っていても判断をそろえる共通の基準です。

5. 自分の担当だけでなくチーム全体を見る

自分の作業が終わっても、チームのゴールが達成できなければ成果は届きません。待っている仕事、困っている人、確認が不足している部分がないかを見ます。

ただし、無断で他人の仕事を変えることではありません。必要な助けを尋ね、優先することをチームでそろえます。個人の忙しさではなく、価値が流れて完成することへ注目します。

6. フィードバックを怖がらない

途中の成果を見せると、問題を指摘されることがあります。しかし、完成後や公開後に初めて分かるより、変更できるうちに知る方が安全です。

指摘を自分の評価と結びつけず、相手がどんな目的や危険を見ているかを聞きます。レビューする側も、相手を責めず、事実と改善の目的を具体的に伝えます。

7. 変化を嫌がらず、理由を考える

せっかく立てた計画が変わると、無駄に感じることがあります。まず、何が新しく分かり、なぜ変更が必要なのかを確認します。

目的へ近づく変更なら、すでに使った時間だけを理由に拒みません。一方、理由や価値が不明な変更には質問します。変化をすべて受け入れるのでも拒むのでもなく、得た情報をもとに判断します。

8. 毎回少しずつ改善する

一度の振り返りで理想のチームにはなりません。次に試せる小さな行動を選びます。

• 質問が遅れたので、朝の確認で不明点を共有する
• レビューが大きくなったので、次は途中で一度見せる
• 目的を忘れたので、タスクの最初に利用者の状態を書く

実行したら、役立ったかを次の振り返りで確かめます。うまくいかなければ、別の方法へ変えます。チームの働き方にも、作る・確かめる・学ぶ・次を決めるサイクルを使います。

1. 今、何を作っているのか

プロダクト全体と、現在取り組んでいる小さな範囲を確認します。

文化祭サイト全体の中で、今は出し物を名前から検索できる機能を作っている。

説明が大きすぎる場合は、短い期間で完成させる範囲まで小さくします。逆に、自分の細かな作業しか分からない場合は、それがどの機能につながるかを確認します。

2. なぜ、それを作っているのか

作業の背景にある問題と、良くしたい状態を確認します。

一覧が長く、来場者が見たい出し物を見つける前に諦めているため、短時間で見つけられるようにする。

「タスクに書いてあるから」しか答えられないなら、判断に必要な目的が不足しています。作業を依頼した人や目的を知る人へ尋ねます。

3. 誰のために作っているのか

主に利用する人と、利用する場面を具体的にします。

文化祭へ初めて来て、スマートフォンで出し物を探す来場者のため。

「全員」と答えたくなったら、今回最も助けたい人を考えます。対象が明確になると、文章、画面、優先順位を判断しやすくなります。

4. 自分は何を担当しているのか

自分が責任を持つ範囲と、他の人と協力する部分を確認します。

検索結果を表示する部分を担当し、案内文は文章担当者と、試用は企画担当者と確認する。

担当を明確にするのは、境界の外を無視するためではありません。誰と情報を共有し、どこまでそろえば成果になるかを知るためです。

5. 完了とはどんな状態なのか

作業終了ではなく、利用者の立場で確認できる具体的な条件をそろえます。

名前の一部で検索でき、結果がない場合も次の行動が分かり、スマートフォンで確認されている。

完成の基準が曖昧なら、作り始める前に例を出して相談します。確認やレビューも完了に含めます。

6. 分からないことは何か

自分の理解を説明し、言葉にできない部分を見つけます。

表記が違う名前を同じものとして検索するか、今回は決まっていない。

分からないことがないと思ったときほど、目的、利用者、完了条件を自分の言葉で説明します。不明点は、調べるものと相談するものに分けます。

7. 困っていることは何か

作業を妨げている問題、予定との差、他の人への影響を確認します。

必要な出し物データがそろわず、明日の確認作業に影響しそう。

原因や解決策が確定していなくても、影響が広がりそうなら共有します。「困っていない」と答えるために、問題を小さく見せないようにします。

8. 困ったら誰に相談するのか

問題の種類に応じて、最初に話す相手を知っておきます。

• 目的や優先順位なら、それに責任を持つ人
• 作り方や品質なら、一緒に成果を作る人
• チームの進め方なら、その改善を支援する人

相手が分からない場合は、チームへ「誰と確認すればよいですか」と尋ねます。相談先を探すことに長い時間を使わない仕組みも必要です。

9. 次に何をするのか

次の行動を、始められる大きさで一つ明確にします。

まず現在の一覧表示を操作し、検索後も残す必要がある情報を確認する。

「検索機能を完成させる」のように大きければ、さらに小さくします。次の行動が目的へどうつながるかも確認します。

毎日のチェックリスト

• 今、何を作っているか説明できる
• なぜ作るのか説明できる
• 誰のために作るか説明できる
• 自分の担当と協力する相手が分かる
• 完了の状態を具体的に説明できる
• 分からないことを言葉にできる
• 困りごとと影響を把握している
• 困ったときの相談先が分かる
• 次の小さな行動が決まっている

すべてに完璧な答えを書くことが目的ではありません。答えられない項目を早く見つけ、確認、質問、共有という次の行動へ移すためのチェックリストです。

仕事を見えるようにするツール

第5章のプロダクトバックログや、第7章のタスクを扱うときは、仕事の一覧を共有するツールがよく使われます。

• 課題管理: 一つの仕事について、目的、完了条件、担当、話し合いを残す
• ボード: 未着手、作業中、確認中、完了など、仕事の現在地を見えるようにする
• バックログ管理: 必要な仕事を並べ、優先順位や今後の候補を共有する

よく見る名前には、GitHub Issues、GitLab Issues、Jira、Trelloなどがあります。どれを使う場合も、項目をたくさん登録することではなく、大切な仕事と困りごとをチームが判断できる状態にすることが目的です。

変更の履歴を扱うツール

第10章のように複数人で成果を作るときは、ファイルの変更履歴を扱うバージョン管理がよく使われます。

• いつ、何を、なぜ変更したかを残す
• 複数人の変更を安全に組み合わせる
• 問題が起きたとき、以前との違いを調べる
• 試している変更を、公開中のものと分ける

代表的なものがGitです。GitHubやGitLabなどは、Gitの履歴をチームで共有し、課題やレビューと結びつけるサービスです。

変更をレビューするツール

第9章のレビューでは、変更前後の違いを表示し、行ごとに質問や提案を残せる仕組みがよく使われます。GitHubではPull Request、GitLabではMerge Requestなどと呼ばれます。

目的は、変更を承認する印を集めることだけではありません。

• 目的に合った変更か確認する
• 不具合や分かりにくさを早く見つける
• 判断理由や知識をチームで共有する
• 別の変更へ与える影響を確認する

レビューの道具があっても、相手を責める表現を避け、事実と目的を伝える姿勢は変わりません。

会話と情報共有のツール

第8章の質問や第9章の早い共有には、チャット、オンライン会議、共有文書などが使われます。Slack、Microsoft Teams、Discordなどはチャットの例です。

急いで助けが必要な相談には会話が向き、後から判断理由を確認したい内容には共有文書が向くことがあります。重要な決定が会話だけで消えないよう、必要な部分をチームが確認できる場所へ残します。

ツールを増やしすぎると情報が分散します。「どの情報をどこへ残すか」をチームで決めておくことが重要です。

画面や体験を試すツール

第3章の「小さく試す」場面では、紙に描いた画面、ホワイトボード、デザイン作成ツールなどが使われます。Figmaなどは、画面案を共有し、実装前に操作の流れを試すために使われることがあります。

見た目を完成させることが目的ではありません。「利用者が次の操作を見つけられるか」のような、知りたいことへ答えられる最小限の試作品を作ります。

動作を継続して確かめるツール

第10章の確認や第11章の再発防止では、決めた操作を自動で確かめるテストや、変更のたびに確認を実行する仕組みが使われます。

• 以前できていたことが壊れていないか確かめる
• 同じ確認を繰り返し実行する
• 問題を変更後の早い段階で知らせる

自動化できる確認が増えても、利用者にとって役立つかを人が確かめる必要は残ります。正しく動くことと、価値があることは別の観点です。

ツールを選ぶときの考え方

有名なツールをすべて導入する必要はありません。次の順で考えます。

1. チームのどんな問題を解決したいか
2. 今の方法では何に困っているか
3. 新しいツールで本当に改善できるか
4. 全員が無理なく使い続けられるか
5. 導入後、役立ったかをどう確かめるか