さて、最後はほかのチームメンバーとの関わり方だね。開発の場面においても、チームで1つの課題に取り組む以上は、メンバーどうしでうまく連携し合えないといけないよ
僕、まだまだみなさんのお荷物ですよね……
そんなことはないさ。チームの人間関係ってのは、「私作る人、僕食べる人」みたいな一方的なものじゃないんだ。お互いに影響し合って、各自が1人でやる以上のことをできるようにするのが、チームプレイなんだよ
問題を報告しよう
開発したソフトウェアが期待どおりに動かないときに、問題の伝え方が良くないと、解決までに余計な時間や手間がかかってしまいます。
問題の報告で重要なのは、聞き手に過剰な負担をかけないことです。背景やコンテキストを共有していない聞き手が、報告者の状況を想像して報告内容を補わなくてはならない場合、聞き手にとってはたいへんな負担となります。逆に、そのようなことをしなくて済む良い報告は、よりすばやい確実な問題解決につながるので、相手からも喜ばれます。ほかの開発者とより良く協力し合える人になるために、良い「報告のしかた」をぜひとも身につけておきましょう。
良くない報告のしかた
自分よりも「詳しい」人に対して、次のような報告をしたことはありませんか？
- 「全然動きません」
- 「壊れました」
- 「なんか、エラーが出ます」
たいていはこのあとにさらに「ちょっと見てみて」と続くでしょう。しかし、多くの人がこのように「詳しい人」に解決を丸投げすると、その人に負担が集中してしまい、問題の解決が遅れたりその人本来の仕事をこなせなくなったりと、別の新しい問題が出てきてしまいます。
良くない報告というのは、要するに情報が少なすぎる報告です。そうならないよう、自分の側で調べられるところまで調べて、情報を整理してから報告することが大切です。たとえば次のような報告にするだけでも、相手の負担はかなり減るでしょう。
- 「複数の画像を削除しようとするとInternal Server Errorが発生します」
- 「カートに追加できない商品があります」
- 「レコード件数が多くなると、一覧画面の表示が耐えられないくらい遅くなります」
- 「カートに3つ以上商品を追加してからすべて削除するとエラーが発生します」
筆者の経験上、報告の要領がつかめていない人は、どちらかといえば情報を省略してしまいがちです。慣れないうちは、「冗長かな？」と思うくらいがちょうど良いと思って、恥ずかしがらずに可能な限り多くの情報を伝えるようにしましょう。経験を積むと、必要な情報とそうでない情報をある程度判断できるようになります。
報告に欠かせない3つの情報
とはいえやみくもにたくさんの情報を伝えても意味がありません。問題に遭遇したときの報告では、次の3つの情報が重要です。先の「より良い報告の例」も、よく見るとこれらの情報が含まれていることがわかります。
問題の再現条件
再現条件とは、問題が発生する状況のことです。伝えるべきポイントは次の2点です。
- 問題を確実に再現できる環境
- 問題を確実に再現できる手順
環境の情報は、バグを発見した人と開発者がまったく同じ環境を使っているのであれば省略してもよいですが、異なる環境を使用している可能性があるなら、環境を確実にそろえるためになるべく詳しく伝える必要があります。環境を説明する情報としては、たとえば次のような項目があります。
- OSの種類とバージョン
- Webブラウザの種類とバージョン
- ソースコードのリビジョン
- 依存しているソフトウェアのバージョン
再現手順は、問題を確実に発生させられる手順です。なるべく最小の手順のみを伝えることが望ましいですが、長くても問題を確実に再現できる手順であれば大丈夫です。最小の手順を見つけるときは、まずは問題が確実に発生する長い手順[1]を特定したうえで、その後1つずつ手順を省いていき、これ以上は手順を省けないというところにまで絞り込むとよいでしょう。
再現手順の中でコマンドを実行する必要がある場合は、入力ミスなどを防ぐためにも、テキストをコピー＆ペーストしてそのままコマンドとして使えるように伝えるとよいでしょう。また、コマンドの出力も省略せずに伝えるとよりよいです。再現手順を文章で説明するのが難しい場合は、スクリーンショットやスクリーンキャスト[2]を用意するのも効果的です。
特定のファイルやデータを読み込ませたときにだけ問題が再現するという場合には、問題が再現するテストケースとしてそれらも伝えることが望ましいです。著作権が自分にないデータの場合は、データの入手に必要な手順を案内するとよいでしょう。
再現条件に間違いがあったり情報が不十分だったりすると、報告を見た人が環境や手順を補う必要があり、条件がそろわずに問題を再現できないということが起こります。報告の前に必ず、自分の書いた再現手順で問題を再現できることを確認しておきましょう。再現条件の説明の例をリスト1に示しますので、参考にしてみてください。
リスト1 ショッピングサイトのバグ報告の例
環境: iOS 8上のSafari
(1) 以下のユーザでログインする
他のユーザでどうなるかは試していない
ユーザ名: user
パスワード: password
(2) 商品をキーワード検索する
キーワード: ロボット
(3) 表示された商品をなんでもいいので3つ以上カートに追加する
このときカートに追加した商品が2つ以下だと(5) で問題は発生しない
(4) 右上のカートアイコンをクリックして、カートの中身確認画面に移動する
(5) カートから商品をすべて削除するとエラーが発生し、以下のメッセージが表示される
Internal Server Error
再現条件の情報が不十分だと、報告を見た人が問題を再現できないかもしれません。問題を再現できないと解決は極端に難しくなるので、なるべく簡単に実施できて、かつ、確実に問題を再現できるような条件をまとめるように心がけましょう。
実際の結果
実際の結果とは、再現条件を整えた状態で実際に得られる結果のことです。これは事実のみを伝えます。
この情報は、修正担当者が再現手順を実行した結果が報告者の場合と同じかどうかを判断するために必要となります。エラーログやエラーメッセージがある場合には、それらも意訳や省略はせずにありのまま伝えましょう。もし、エラーログやエラーメッセージに何らかの解釈を加えたいのであれば、報告者の意見とわかるようにします。また、省略した部分に重要な情報が含まれていることも多いため、冗長になってしまっても、ありのままのエラーログやエラーメッセージを伝えたほうが修正の助けになりやすいです。
期待される結果
期待される結果とは、再現条件を整えた状態において、本来であればどのような結果が得られていてほしいのかということです。リスト2は、期待される結果の説明の例です。
期待される結果に根拠がある場合には、そのことも伝えましょう。たとえば、別途定まっている仕様と挙動が食い違っている場合は、仕様を参照してあれば、問題の焦点は「仕様が間違っていた」か「挙動が間違っている」かのどちらかだとわかります。また、「このようになっているのが自然だと思う」のような主観的な考えが根拠でもかまいません。
リスト2 期待される結果の例
仕様書ver.1 の3.2.1 の式によると、xxx になる。
仕様書の内容をコピペしてもよい
バグを報告する対象のソフトウェアで自動テストのしくみが使われている場合には、期待される結果を表した自動テストのテストケースを添えるのもよいでしょう。これは、バグが修正されたあとにも回帰テスト[3]のテストケースとして活用できます。
報告したら終わり、ではない
問題は、報告したらそれで終わりではありません。報告を受けた人の手元で問題が再現できない場合には、再現条件をさらに詳しく明らかにしないといけません。また、問題の種類によっては、修正が完了したかどうかを報告者の目で確かめなければならないこともあります。
問題の報告とは、クレームを付けることでも、実装者の非を責めることでもなく、報告者自身も交えて「その問題を解決する」という1つのプロジェクトを共同で進めるということです。一緒に問題解決に挑むチームメイトとして、相手がなるべく作業を進めやすいように、協力的な姿勢で臨むようにしましょう。
協力を求めよう
個々人がバラバラに作業していては実現できないことでも、チームとして協力し合えば実現できる場合があります。チームで開発しているのであれば、チームならではの力を発揮しないともったいないです。
開発を進めていて、実装のしかたがわからなかったり、実装してみても意図どおりに動かなかったりという風に行き詰まることはよくあります。そのような場合に周囲の人にアドバイスを求めると、1人で考えていては気づかなかった視点を得られたり、知らなかったことを教えてもらえたりして、行き詰まりの解消につながることがあります。
とはいえ、「動かないんです」と言って泣きつくだけでは良い結果にはつながりません。良いアドバイスを得るためには、良い相談のしかたで相談する必要があります。
良いアドバイスをもらいやすい相談のしかた
良いアドバイスとは、状況に即した的確な助言のことです。どんなに一般論としてためになる話でも、状況にそぐわないものはアドバイスとは言えません。たとえば、次のようなものは的外れなアドバイスでしょう。
- 全然違う状況の話をされる
- 全然違うゴールに向かうための話をされる
- すでに試して駄目だった案について「これを試してみたら？」と言われる
とはいえ、助言するほうもわざわざ的外れなことを言いたいわけではありません。時間を割いてアドバイスをするからには、有効なアドバイスをしたいと思ってくれていることでしょう。ですから、相談を持ちかけた相手がアドバイスをしやすいような相談のしかたをすることが大切です。
相談するときには、的外れな助言にならないために必要な情報を先に共有して、それから考えるプロセスに移るとよいでしょう。具体的には、先の「的外れなアドバイス」の裏返しとして次の要領で臨むのがおすすめです。
- 今の状態を説明して、現状を共有する
- 目指している状態を説明して、ゴールを共有する
- 相談する前にすでにやったこと、ここまでの経緯を共有する
まず、現状をありのままに伝えます。エラーが出て動かないのであればエラーの内容を、性能が出ずに困っているのであれば現在の性能の測定結果を、説明して共有しましょう。そうして共有できた現状が、そのあとのアドバイスを考えるうえでの出発点になります。
次に、目指しているゴールを伝えます。正常に動くようになったらどういう挙動になるのか、性能が出るようになったらどのような状況になるのか、わかりやすく具体的な目標を共有しましょう。その目標と出発点を結ぶ道筋を一緒に考えるという、プロジェクトのゴールを設定します。
そして、そこまでの間に自分がどんな道筋を通ってきたか、どのルートは大丈夫でどのルートは駄目だったのかを共有します。そうすることで、同じ轍（てつ）を踏まないで済みますし、また、今までのルートで見落としていたポイントがなかったかを再検討できます。
質問と相談は違う
忘れないでおきたいのは、チームメンバーどうしでは「相談」をするということです。一方的に教える側と一方的に教わる側の両者に分かれると、どちらの人も視野が狭まってしまいます。また、未知の問題への取り組みにおいては、相手も答えを知らないことが多いです。
問題の報告と同様に、相談するときも、1つの小さなプロジェクトを一緒に解決に導くために協力し合うチームです。相談を持ちかけた側の自分からも新しいアイデアを出して、積極的に意見をぶつけ合うことで、思ってもみなかった解決策にたどり着けることもあります。また、相談前は頭の中が整理されていなかったのが、相談のために考えを整理したら自然と答えが見えてくることもあります。
あれから僕はずいぶん変わったなあ。それまではスーパーストライカーの個人プレーみたいなものだけしか見えてなかったけど、的確なパス回しのようにチーム内できちんと情報を共有して、チームとして問題に取り組み解決していくことが大事なんだっていうことを、僕はあのとき先輩に教えてもらったんだ。そして今では、僕も人を指導する立場になっている……
ううううう～～～～ん
おや、何を悩んでるんだい？
「もっとちゃんと書きなさい」って言われたんですけど、どうすればいいのかわからなくて……
どれどれ……あぁ、なるほどね。新人さんはそもそも「良いコード」の基準を知らないから、判断に困ってるんだな。じゃあ、これから一緒に見ていこうか
ありがとうございます！！
こうして彼は、先輩から教わったことを次の世代へと語り継いでいくのでした。
