システムアップデート直後に問題発覚。その時の開発員の心境とは?

2015/11/01

マインド 日記

t f B! P L
iOSがメジャーアップデートされた直後に、すぐにバグ修正版として、マイナーバージョンがアップデートされる事が何度か続いていて、ユーザーからは、 「またか」 と落胆されている光景をよく見かける事がありますが、大手のアップルの検証作業をもってしても、バグって防げないものか? と、ユーザー達は疑問に思う事もあるかもしれません。 実際にアップルの開発事情は、全く知らないので、身の回りで起こっている事で分析してみたいと思います。

開発作業は孤独との戦い

プログラミングもコーディングも何を行うにしてもITソフトウェアは、基本的に一台のパソコンで行える作業は1人で行います。 もちろん、企画もディレクションも作業自体は1人です。 チームという概念で行える事はその後の結合やら、何かしらの確認、コーディングしたソフトウェアのソースレビューなどですが、 バグが発生するのは、一番下流の工程のコーディングという事になります。 当たり前ですよね、プログラミングで実体化するわけですから、この工程にミスがあれば次以降の工程でエラーは発生するはずです。 もちろん、プログラムの設計が間違っているという事もありますが、プログラムという工程では、設計のミスも補える要素がある事も理解しましょう。

ミスの見つけ方

多くの場合、デバッグや、テスト、検証、などの工程で、不具合を検知して、その場で修正をするという流れになるはずです。 チームプレイの場合は、単体テストのあと、結合テスト、ユーザーテスト、などと、幾つかの工程で探しきれなかった不具合をチェックして、トコトンバグ修正を行います。 でも、開発員であれば誰しもが経験した事があると思いますが、致命的な不具合は本番でのみ発見されるのです。 非常に奇妙ですよね。 優秀なエンジニアがたくさん集まり、専門分野の人達でチェックを行うのに、本番まで見つからないバグがあります。 これは、ユーザビリティチェックが、ペルソナチェックとして、ユーザーの取るであろう行動を想定して捜査するが、得てしてユーザーは、想像しない事をする為、想定外の捜査となってしまうんですね。 ここで言えるのは、ペルソナチェックはあまり意味が無く、想定事象のチェックをしないといけないのかもしれません。 もちろん、システムによっては、想定事象が天文学的数値になる可能性もある為、より、絞り込んだチェックになっているのが現状なのです。

ほとんどの不具合は凡ミス

システムエラーが発生して、原因を調査してみると、syntax errorではないが、warningレベルのエラーがあったり、エラーではないが、ある条件の時を想定できていなかったり、 こうした、うっかりなミスが致命的になっている事も少なくないでしょう。 パレードの法則でいうと、
「発生した不具合の80%の内、クリティカルな不具合は20%である。」

バグ撲滅は可能なのか?

多くの会社が不具合改善を品質向上として、チェック部門を立ち上げあり、品管部署を作る方向になりますが、 先に言った通り、不具合の発生元は、コーディング段階でほとんどの発生しています。 コーダーのスキルアップがまず第一だと思われますが、残念な対策としては、すべての工程に、チェック項目が加算されていき、仕事の効率自体も下げてしまいます。 コーダーも、こうしたチェックをクリアするような作業になり、時間との兼ね合いで、作業量の落ち込みからくおりては下がり、網羅されていないチェックもれから、バグが発生し、さらなる工程チェック項目が膨れ上がるという、無駄だサイクルにはまっていきます。 とにかく、コーダーの質を上げる事がだいいちだと理解しましょう。

それでもバグは無くならない

完璧なモノを作る事は大事な指標であり、ユーザーの望んでいる姿ですが、本来それをクオリティと言うのはあまりにもお寒いと思いませんか? 質というのは、不具合がない状態では無く、システム利用者が、便利に使えるシステム、機能だと考えましょう。 普通に使える普通の機能で不具合が少ないモノと、高機能で便利だが不具合があるモノとでは、ユーザーはどちらを選ぶでしょうか? 確実に言えるのは、不具合を全面に出しているサービスなどはなく、機能面で勝っている方が支持されるはずです。 発覚した不具合が修正されれば良いだけなので、ユーザーとしては、高機能を欲する事は、新しいiphone発売で行列ができる事を考えると、間違いないと言い切れます。 ただし、開発側で考えなければならないのは、ユーザーはバグが無くて当たり前と思っているという事です。 不具合を出した後で、あーだこーだ言い訳しても、ユーザーは納得するはずがないですからね。 とにかく開発員のできる事は、魅力的なシステムにするという事と、不具合がでない仕組みを作るという事です。 チームや会社にすでにあるルールに従ってましたという言い訳は何処にも通用しない事を、理解しましょう。 ただ、それでも不具合というものは、無くならないと思いますけどね。

人気の投稿

このブログを検索

ごあいさつ

このWebサイトは、独自思考で我が道を行くユゲタの少し尖った思考のTechブログです。 毎日興味がどんどん切り替わるので、テーマはマルチになっています。 もしかしたらアイデアに困っている人の助けになるかもしれません。

ブログ アーカイブ