1年目から身につけたい! チーム開発 6つの心得

第7章 周りの人と協力しあおう―報告・相談に欠かせない3つの情報

この記事を読むのに必要な時間:およそ 3 分

さて,最後はほかのチームメンバーとの関わり方だね。開発の場面においても,チームで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)
常用している環境での設定や,すでにインストール済みだった別のソフトウェアの影響などを排除するために,できれば,まっさらの環境に必要なソフトウェアをインストールするところから手順をまとめるのが望ましいです。
注2)
画面上での操作の様子を動画として記録したもののことです。
注3)
何か変更を行ったときに,既存の機能が壊れていないかどうかを確認するためのテストです。

報告したら終わり,ではない

問題は,報告したらそれで終わりではありません。報告を受けた人の手元で問題が再現できない場合には,再現条件をさらに詳しく明らかにしないといけません。また,問題の種類によっては,修正が完了したかどうかを報告者の目で確かめなければならないこともあります。

問題の報告とは,クレームを付けることでも,実装者の非を責めることでもなく,報告者自身も交えて「その問題を解決する」という1つのプロジェクトを共同で進めるということです。一緒に問題解決に挑むチームメイトとして,相手がなるべく作業を進めやすいように,協力的な姿勢で臨むようにしましょう。

著者プロフィール

足永拓郎(あしえたくろう)

株式会社クリアコード所属。デスクトップや組み込みソフトウェアの自由を求めて活動中。


沖元謙治(おきもとけんじ)

株式会社クリアコード所属。プロジェクトで利用しているライブラリにバグを見つけたら,アップストリームにパッチを投げることを意識しています。


結城洋志(ゆうきひろし)

株式会社クリアコード所属。Firefox黎明期からアドオン開発を手がけ,業務上もMozilla製品の技術サポートを担当。代表作は「ツリー型タブ」「テキストリンクなど。また,日経Linux誌にて「シス管系女子」を連載中。

コメント

コメントの記入