「バグをなくす」のはエンジニアの仕事？
こんにちは。PIVOT R&Dで、プロジェクト管理や業務要件定義を担当している栗林です。開発・育児・学業の3足のワラジを履いている最中です。頭の切り替えスキルが高くなってきました。
前回に続き、「人間らしさ」に注目したプロジェクトの在り方について考えてみたいと思います。
今回は、プロジェクトであまり発生してほしくない、「バグ」について考えてみます。
前回の記事はこちら。
バグが起きるのは誰のせい？
バグは、開発プロジェクトにとっては厄介者です。本番稼働後であれば、バグ発生＝呼び出し＆緊急対応につながるので、PMやエンジニアにとってはあまり見たくもないワードですね。
しかし、開発にバグはつきものです。というか、人が作ったものである以上、プログラムだろうとなかろうと、不具合というのは必ず含まれているはずです。
バグを発見したら、チケットなどで報告し、エンジニアに直してもらう、というのが一般的な流れだと思います。このとき、プロジェクトにはどんな空気が流れているでしょうか？
リリース前の結合テストまでであれば、どんなバグもそんなに致命傷はありません。でも、リリース直前だったり、本番稼働後の障害であれば、緊迫度はぐっと上がると思います。致命的な障害につながっていれば、報告書も書かないといけません。
バグ発生の原因分析は必須ですが、そのとき、「誰のせい？」ということを無意識に考えてしまっていないでしょうか？
実際、プログラミング・設計など、直接バグが混入した工程の担当者に意識が向いてしまいがちだと思います。
無意識にでもそう考えてしまうと、バグの対策として「その人がミスしないようにする」ための案になりやすいです。
でも、バグが起きた原因は「人」ではなく、「プロジェクト」にある、と考えるべきだと思います。
バグはたいてい、プロジェクトの中から生まれる
そう痛感する理由は、多くの場合、バグのもとの原因をたどると、認識齟齬や誤解、コミュニケーション不足に収束するからです。
・ドキュメントに書かれていなかったので勘違いした（作成者は、書かなくても伝わると思っていた）
・ドキュメントに書かれていたけど、違う意味でとらえていた
・うっかり忘れてしまった（今まで当然の前提として扱われていたが、引き継ぎや期間を挟んで忘れた）
・うっかりミスしてしまった（開発フローのボトルネックになっており、いろんな作業を並行していた）
どれも、表面的には人のミスのように思えますが、真因をさぐってみると、意識の違い・解釈の違いなどは、片方の責任ではないし、人間として避けられないものです。聞いた話や時間がたってしまった話は忘れやすいということも、たくさん同時に作業をしていたら精度が落ちるということも、人間にとっては当然の結果といえます。
ここまで考えが至ると、はじめて、「じゃあ、そうならないようにするためには全員でどうしようか」という具体案が出せるんじゃないかと思います。
品質向上は、メンバー全員で！
バグを、プロジェクト全体で防止することれができれば、品質は確実に上がっていって、みんなが幸せになれるはず！と思っています。
バグの要因分析手法はいろいろあると思いますが、まずは意識を変えることが大事ではないかな？と思っています。PMや非エンジニアの人も、要因をたどると、自分も無関係な話ではなかった！というケースがあるはず。それに気づくことで、バグがメンバー全員の「自分事」になっていくと思います。
前回の記事でも触れていますが、つまるところ「プロジェクトを実施するのは、結局『人間』なんだよなあ」ということ。
人間であるが故の不完全さを受け入れた先に、創造的な工夫が生まれるんじゃないかと思います。私たちが念頭に置く使い勝手も、使ってくれる「人」に向けられているもの。
まずは作り手である私たち自身が、お互いの目線を合わせて関係性をつくることが大切です。
この記事が気に入ったらサポートをしてみませんか？