自分一人がエンジニアとしてシステムの開発に携わっている頃はそれほどサービスの質というものをあまり意識したことがなかったのですけど、ある程度チームを管理する立場になってくると下から上がってくるその質というものに敏感にならざるを得ないことは日常よくあることです。
しかし、そのサービスの質をどうやって向上させればいいのかというのはなかなか難しいもので日々頭を悩ます問題でもあります。
サービスの質を意識する
もちろんサービスの品質を上げる手段というものは世の中たくさんソリューションが出ていたりもします。
単体テストのツールからSeleniumのようなブラウザを使ったテスト自動化ツールであったり、Redmineのようなバグトラッキングシステムで情報を管理したりと多角面からサービスの質を向上させる取り組みというものを取り入れたとしても、当のエンジニアたちがそれをうまく活用し、効率的に不具合を見つけて改善することを開発のサイクルの中で実施していかないと質の向上には結びつきません。
しかし、エンジニアは納期などの制約からテストをおざなりにしているケースはよくある話で、テストそのものに時間を割かれることを嫌う人もいたりします。
それがリリース後に不具合として発見され、バグの修正だけでなく面倒な報告書の作成や上司やお客さんへの謝罪など、テストをすること以上の時間が割かれることになるとしても。
品質への意識が薄いと言ってしまうことは簡単ですが、なかなかエンジニア自身が率先してテストをするというのは本人たちの意識が高くないと無理ですし、多くは開発工程の制約としてテストをする際のルールを厳格化し、それを順守しているように整備されているのだと思います。
結局のところ、テスト自体も開発工程の一作業としてでしか認知されず、形骸化した作業の中ではサービスの品質はそれほど上がることなく、リリース後に多くの不具合が発見されたりもします。
システムは多くのモジュール化されたプログラムの寄せ集めであり、その1つ1つが正しく動いたとしても結合した際に不具合が出たり、また動作はするもののそれが仕様通りではないというケースもあったりして、不具合を発見することは実際に人が見て触れて判断を下さないといけない場合も多くあります。
これは、単に動作が想定通りかどうかというものではなく、実際に動くものを目にしたときにより良いものに作り替えるための判断も含まれているわけです。
テスト自体が一作業として成り下がってしまうと、テストがパスしているから問題ないとスルーされ、受け入れや実際にユーザーが使い始めた際に不具合だけでなく仕様バグとしての指摘を受けたりします。
それが許される環境ならそれでブラッシュアップしていけばいいでしょうけど、それはそれでエンジニアとしても「不具合があれば誰かが報告してくれる」という受け身の癖がついてしまったりして問題です。
これは、開発者とテスターを分けるような体制で構築を進めた際もよく起きたりして、とてもテストする品質でもないのにそれがテスト工程に持ち込まれたりしてひと悶着あったりもします。
品質を上げる意味と意義
最初に自分一人がエンジニアとしてシステム開発に携わっていたころはこのサービスの質について意識しなかったというのは、もちろん経験が少なかったということもあるのですが、もう一方の視点として自分がその質を担保するしかない状況にあったことや、自分が作ったものだからある程度そのシステムに愛着があったからというのもあります。
なので、実際には無意識にそれを意識せざるを得ない状況だったのだと思います。
まぁ、その質とやらは置いとくとして。
これはある意味環境に恵まれていたのだと思いますが、自分たちで何かを生み出しそれを進展させることができたからそれに伴う品質というものも意識することができたというもので、現状のエンジニアを取り巻く環境というのは「新人エンジニアの教育を悩ませる7つの環境と課題」に書いたように、何かを一から生み出すということはやりづらい状況であったりもします。
もちろん、日々何か新しいサービスを生み出し、開発の案件を受託して仕事をしているのだと思いますが、それは自分が考えたものではなく誰かが作ったものを保守したり、自分とは遠く離れた場所で出来上がった設計仕様に基づいて構築をする話であったりして、それに対して愛着なんてものもなく、また多くの関係者がいる中でその責任の所在というものも曖昧になったりもします。
自分が担当している領域はある程度明確にはなっているので、その範囲で問題が起きないよう、怒られない程度に品質を担保していこうとする意識は働くと思いますが、積極的に品質を高めていく取り組みというのはなかなか行われません。
ひどく整備された開発のタスクや役割の中ではその品質を高めるための取り組みというのは、担当チームや組織が用意されていたりもして、開発チームでは余計なことはするなとばりに、自分の領域の仕事を全うすることに注力をさせられたりもします。
結局のところ品質を高めるためのツールや手法というものは世の中にたくさんあるわけですが、それをエンジニアたちが積極的に採用し品質を高める行動を自発的に促していくという意識を持ってもらうことに課題があったりします。
自分たちが作っているものが何なのか、実際にお客さんや利用者と対話しそれを実感してもらうことも大事なのかもしれませんが、規模が大きくなってきたりすると末端のエンジニアまで同行させることが難しかったり、ヘルプデスクのような現場の声を聴ける業務を担当してもらうことも本業が忙殺される中ではなかなか難しかったりもすることです。
しかし、やはりそのような意識の変革をもたらすためにはエンジニア自身が担当としての役割だけでなく、何に貢献をしているのかその意味をきちんと理解してもらう必要があるのではないかと思ったりします。
繰り返しにはなりますが、如何にエンジニアがテストツールなどを積極的に採用をしたとしてもそれを継続的に利用し、日々サービスの品質を向上しようとする取り組みを維持しなければ結局のところ目立った成果がでなかったり、テストがなおざりにされている頃に戻ってしまうわけです。