アーカイブ動画

システムトラブルはなぜ、起こるのか

バルテス・モバイルテクノロジー株式会社
開発部 マネージャー　荻野 和俊氏

最初に登壇したバルテス・モバイルテクノロジー（以下、VMT）の開発部マネージャーを務める荻野和俊氏は、「そもそも“品質”とは何か」について語った。

VMTの設立は2012年。モバイル・Webアプリ開発、非機能テスト、リバースエンジニアリングと3つの事業を展開している。所属しているバルテスグループは、ソフトウェアテストをメインとした品質向上支援サービスを提供しており、「品質に対しては強いこだわりを持っているグループ」と、荻野氏は紹介した。

荻野氏はバルテスに入社後、2年間テストエンジニアとして案件に従事。VMTの立ち上げに参画し、開発エンジニアに転身。現在はPMとして管理業務を中心に対応している。

品質について説明する前に、荻野氏は3つのシステムトラブル事例を紹介した。

1つ目の事例は「リリースを優先した結果、不具合に追われる日々」。とにかく早くリリースしたいとオファーがあったため、最短でリリースしたが、緊急対応の問い合わせが来て、日々改修が続いた。どんどんソースコードも複雑化、疲弊したメンバーが離脱していくという事態に陥った。

2つ目は「リリースしたが、業務効率が下がってしまった」という事例。業務システムをWebアプリにリプレイスしたところ、ある業務の処理が30秒から5分かかるようになった。これは荻野氏がテストで案件に関わっていたときの話で、「お手上げ状態で、作り直すしかなかった」という。

3つ目は「リリースしたが、攻撃を受けてサービス停止や経済損失が発生」した事例。開発環境を構築した際、メンバーが開発用の機能をオンにしており、リリース時にコピーして本番環境を作成したところ、外部ユーザーがサイトを改編できる状態になり攻撃を受けた。この事例では一から環境を作り直して移行し、脆弱性診断やWAFを導入したという。

「開発者が考慮すべきことはたくさんあります。どれか一つでも不備があると、システムトラブルにつながってしまうからです」と、荻野氏は語る。

1つ目の事例は不具合を減らすこと、ソースコード品質、ログ出力など保守性を高めることができていなかった。2つ目の事例はパフォーマンス、業務の理解、ユーザビリティへの配慮が足りなかった。3つ目の事例はセキュアコーディング、インフラ設定、ミドルウェア設定がしっかりチェックできていなかったことがトラブルにつながった。

これらの事例のようにリリース後、システムトラブルが発生すると非常に大変なことになる。それは次のグラフを見れば明らかだ。基本設計時に対応するコストが1だとすると、リリース後は100以上のコストがかかるからである。

これらの経験が示すように、「上流工程から品質を作り込むことが大事」と、荻野氏は力強く語る。

品質とは顧客の満足度、品質の向上は顧客満足度の向上

改めて、品質とは何か。テストを十分行えば品質は担保できるのではと思うかもしれないが、テストで品質が上がるわけではない。開発者が作り込まないと品質は上がらない。

では、開発者は品質に対して何を取り組むべきなのか。荻野氏は以下スライドで「品質は要求を満たすことである（クロスビー氏）」「品質は誰かにとっての価値である（ワインバーグ氏）」を紹介し、「品質とは顧客の満足度であると言い換えることができる」と言う。

そして、顧客の満足度、つまり品質を上げるにはどうするべきかについては、こう語っている。

「設計、実装、テストというすべてのフェーズで、常にユーザーの要求は何かを意識して考えることです」（荻野氏）

では、VMTではどんな取り組みをしているのか。立ち上げ当初は開発ノウハウがないため、納期が守れず、親会社が膨大なテストをしてなんとか納めていたという。

この課題に対しては、作成ドキュメントの定義やWBSでの進捗管理を行うことで対処。また納期に納めるも、受け入れでイメージが違うなどの指摘が多発していた課題に対しては、プロトタイプの作成、各フェーズのレビュー強化などを図った。

このような取り組みをしたことで、現在はリリース後に保守問い合わせが少なく、保守費用がもったいないという声が顧客から届くようになった。「これさえやれば大丈夫」という必勝パターンはなく、「お客さまの要求は何かを考えながらやり方を変えていくことが必要」だと語り、セッションをまとめた。

事例から学ぶ技術調査のポイント

バルテス・モバイルテクノロジー株式会社
開発部 リーダー　松尾 勇氏

続いて登壇した開発部リーダーの松尾勇氏は、「要求定義時の技術調査＆製造時のデバッグ」をテーマにセッションを行った。

松尾氏は大学卒業後、1999年にソフトウェア開発会社に入社。組み込み系の開発に従事した後、モバイル開発にシフト。そこで様々なアプリの開発を行った。2019年にVMTに入社し、デスクトップアプリを含む、ネイティブアプリの開発を行っている。

まず松尾氏が取り上げたトピックは、「技術調査のポイント」について。要件定義では、プロダクトの機能要件や非機能要件を定義する。技術調査を実施するのは、定義する内容に不明瞭な部分がある場合だ。

技術調査の成功事例として松尾氏が紹介したのは、体重計のデータを管理するモバイルアプリ（以下、自社アプリ）の開発事例だ。アプリと体重計のデータを連携するという機能要件を持つ。

自社アプリはデータの手入力ができず、体重計で測定したデータをBluetooth経由でアプリに送信して、自動的にデータが登録される仕様となっていた。一方の連携アプリは、データの入力が手入力のみの仕様であった。

まずは連携できるかどうかの判断を行うため、連携アプリの開発者サイトで確認。次に制限事項の洗い出しを行い、最後にリリースまでのリスクの確認を行った。このような技術調査を行ったことで、仕様変更による手戻りもなく、テストでのバグ発生件数がゼロなど、トラブルなくリリースできた。

松尾氏は、失敗事例として「音声入力できるデスクトップアプリの開発」も紹介した。同アプリの機能要件は、音声によるテキスト入力ができることだ。テキストの種類は数字や文章で、文章の長さに上限は設けなかった。プラットフォームから連続音声入力APIが提供されていたため、それを用いたサンプルを作成し、文章の音声入力ができることを確認した。

だが、問題が発生した。顧客からの指摘で連続音声入力APIに30秒以上の音声を入力すると、以降の応答がなくなることが判明したのだ。連続音声入力APIは無音を検知してもヒアリングを継続する機能だ。

しかし原因を調査する有力な情報がなく、手詰まり状態になったという。代替案を模索した結果、単発音声入力APIを発見。この単発音声入力APIを繰り返し実行することで対応したが、このAPIは無音を検知するとヒアリングを終了するという特徴を持つため、音声認識できない短い区間が発生してしまった。

「最低限の品質はクリアできたが、十分な品質ではなかった」と、松尾氏は振り返る。失敗に至った第一の原因は、「文章の長さに上限なしの条件を確認できていなかったこと」。そして第二の原因は、他の案についての検討を行っていなかったことだという。

「技術調査はできるかどうかだけで終わらず、制限事項を明確にすること、対象機能の条件に漏れがないか注意すること。一つの解決策で満足せず、他の方法も探して比較検討することが大事です」（松尾氏）

どのようなポイントでデバッグすれば、テスト工数を下げられるのか

次に松尾氏が取り上げたトピックは、「デバッグ箇所の選定方法」について。実装段階でバグを除去すれば、テスト工数の削減ができる。とはいえ、すべての箇所をデバッグするのは現実的ではない。そこでデバッグ箇所の選び方が重要になるというわけだ。

第一のポイントは、デバッグの単位とタイミングである。「実装直後にデバッグするのが効率的」と、松尾氏は語る。第二のポイントは自信のない箇所を見つけること。自信のない箇所とは、ロジックの挙動を予測できない箇所である。

「例えば、挙動や影響範囲が明確ではないAPIの使用箇所やWeb検索したコードや既存のコードをコピペした部分などは、実際の挙動や影響範囲が想定と異なる可能性があるため、デバッグした方が良いでしょう」（松尾氏）

第三のポイントは、ロジック間の結合部分だ。チームで実装している場合、他の人のロジックと結合する部分が生まれる。

インターフェースの想定が担当者間で異なっていると、バグの原因になる。そのため、担当者の異なるロジック結合部分は、デバッグするのが良い。

そのほか、松尾氏が上げたのはデータベースのアクセス部やファイルを操作するロジック、日次計算などの間違いやすいユーティリティ関数、複数のスレッドで実行処理などである。

「これらの箇所は正確性が求められたり、単純に間違えやすかったり、原因の特定に時間がかかる箇所になっているので、デバッグのプライオリティが上がると思います」（松尾氏）

このように松尾氏は自身で取り組んでいる方法を紹介したが、「今回の内容が性格的に合わない人もいると思う」と言及。「やり方は人それぞれなので、自分に合った開発方法を見つけるため、いろいろな方法を試してほしい」と参加者に語りかけ、セッションを締めた。

顧客の満足度を向上するために必要なこと

バルテス・モバイルテクノロジー株式会社
開発部 リーダー　小澤 亮二氏

最後に登壇したのは、松尾氏と同じく開発部リーダーの小澤亮二氏だ。「顧客要求の深掘り＆組織風土づくり」というタイトルでセッションを行った。

小澤氏は神戸電子専門学校ゲームプログラミング学科卒業後、2013年にサービス＆セキュリティに入社し、データセンターで運用業務を担当。2016年にVMTに入社し、Webシステム、スマホアプリ、ハイブリッドアプリの開発を経験。現在は主にプロジェクトリーダー業務に従事している。

まず小澤氏が取り上げたテーマは「『品質が良い』=『顧客が想定していたもの』ではない」ことについて。品質については荻野氏のセッションでも語られたように、品質が良いとは顧客満足度が高いことを指す。

「依頼して良かったと思ってもらえる。これがベストなプロジェクトのゴールであり、顧客にとって品質が高い成果物です」（小澤氏）

なぜ、顧客が想定していたものを納品しただけでは、品質が良いとは言えないのか。それは、顧客はプロのシステムエンジニアではないからだ。

「素人が考えたものを、玄人が何も考えずに作ることはない」と、小澤氏は言い切る。大工に任せずに素人が作ると、不格好な家ができるのと同様、システムにおいても顧客の要求をそのまま進めてしまうと、かっこ悪いシステムができてしまう。

「顧客に言われた通りのシステムが完成したとしても、最終的には顧客満足度が高いものにはなりません。顧客はプロに依頼することへの付加価値を求めています」（小澤氏）

顧客満足度を上げるために必要なことの1つ目は、システムとしてあるべき内容と市場ニーズとしてあるべき内容の両方を盛り込むことだ。システムとしてあるべき内容とは、「私たちプロから提案すべきこと」と小澤氏は続ける。

一方の市場ニーズとしてあるべき内容とは、顧客の専門分野の内容で、その業界での当たり前や法律、専門用語などが該当する。市場ニーズを把握することで、顧客の思いに寄り添い、システム利用者の立場で考えることができる。さらには、顧客の競合と差別化したシステムの提案が可能となる。

「業界の知識とシステム開発のノウハウを組み合わせて、長く使われるシステムを顧客と一緒に作ることが大切だと思います」（小澤氏）

顧客満足度を上げるために必要なことの2つ目は、要求の目的（背景）を理解することだ。そのために欠かせないのが、顧客へのヒアリングである。

例えばRFPに「アンケート機能の追加」と書かれていたとしても、顧客へのヒアリングによって、「今は電話で利用者から問い合わせを受けており、利用者の声の一部しか収集できていない可能性がある」という顧客の本来の目的を深掘ることができる。

この場合、小澤氏たちが提案するのは、問い合わせ機能の追加ということになる。

「1機能や1要求単位で背景や目的を理解することで、顧客の課題にあった適切な提案ができるようになります」（小澤氏）

プロジェクトを品質良く運営するには

次に取り上げたテーマは、「プロジェクトを品質良く運営するには」だ。「PLだけが顧客の思いを理解していてもプロジェクトはうまくいかない」と小澤氏は言う。

メンバーは作業内容のみしか理解していないことが多く、メンバーとPLで思考に大きな差異がある可能性があるからだ。

例えば、先の例ではつくるものがアンケート機能から、問い合わせ機能に変更となった場合、メンバーは「要求が変わったから、問い合わせ画面を作る」という思考になる。

一方、PLは顧客の課題「今は電話で利用者から問い合わせを受けていて、利用者の声の一部しか収集できていない可能性がある」という課題を把握した上で、問い合わせ画面を作るという思考になる。

このようにPLとメンバーの思考に差異があると、仕様上の疑問が発生したとき、メンバーはPLまたは顧客に確認することになる。

そしてPLは、「背景を理解している分、抱えきれないほどの検討が発生してしまう」と小澤氏は指摘する。PLだけが顧客の思いを分かっていても実現できず、顧客満足度の低下に繋がってしまうのだ。

「大事なのはPLがメンバーを推進するのではなく、PLとメンバーが同じ推進力を持つようにすることです」（小澤氏）

PLとメンバーが同じ推進力を持つには、メンバーも顧客の思いを理解することである。そのために、まずメンバーには必ず要件定義書を見てもらうこと。要件定義書には各要件の背景を記載することも必要だ。次に、朝会の実施やタスクの開始時にミーティングを行うことなども必要となる。

「その画面は誰がどうやって使うのか、なぜその機能が必要なのか、なぜその方針で進めるのか、メンバーには理解してもらうことが大事になります」（小澤氏）

このようなプロジェクトにすることで、顧客が満足する高品質なシステムが提供できると小澤氏は力強く語り、セッションを締めた。

【Q＆A】参加者からの質問に登壇者が回答

最後に設けられたQ&Aコーナーには、多くの質問が寄せられた。抜粋して紹介する。

Q．PLはどんなことに留意し、どんな対策やコントロールをしているのか？

荻野：顧客のニーズ、市場のニーズを理解してメンバーに共有し、顧客と同じ気持ちの人をたくさんつくることを大切にしています。

Q．普段テストを軽視しがちな設計、開発手法。コストを下げるやり方について教えてほしい

松尾：実装時にバグをゼロにするつもりでデバッグをすれば、最終工程のテストは確認するだけなので楽になります。もう一つ、長期スパンでコストを下げるやり方は、きれいなコードを書くことだと思います。

Q．要件定義前の顧客ヒアリングでずれが発生することは多々あるが、手戻りが少ないように要件定義する打ち合わせをする上で、気をつけていることは？

小澤：要件定義は何をつくるかを決めるフェーズではなく、お客さまが困っていることの認識を合わせることが大事です。課題がこれで、だからこれを作るということをお客さまときちんとすり合わせること。またプロトタイプを作れば、画面イメージに加え簡単な動作の確認も出来、認識合わせが進むと思います。

Q．お客様にヒアリングする際に、どういった切り口で深掘りしているか？

荻野：なぜ、その機能が必要なのかを深掘りしていくのですが、お客様の喜びが感じられるところまで聞くことです。それができて何が嬉しいのか、何が喜びなのかというところまで徹底的にヒアリングします。それを引き出せれば、ゴールに近いと思います。

バルテス・モバイルテクノロジー株式会社
https://www.valtes-mt.co.jp/

バルテスグループ採用情報の採用情報
https://recruit.valtes.co.jp/

【VMT】開発エンジニアの求人情報
https://hrmos.co/pages/valtes/jobs/xrecruit06