ゴールドマン・サックスが実践する「品質向上」の取り組みと役立つツール：ソフトウェア品質向上の“変”2015秋（後編）（2/2 ページ）

2015年10月23日に開催された＠IT主催セミナーより、後編ではゴールドマン・サックス・ジャパン・ホールディングスの伊藤博志氏による特別講演の他、品質向上に役立つ考え方やツールを紹介した各講演を紹介する。

[谷崎朋子，＠IT]

テスト自動化を組織に根付かせるための三つのポイント

　「テストを自動化すると、夜間や土日を利用してテストを実行、自動検査スクリプトを再利用でき、エビデンスの取得も任せられるなどから、最終的にはコスト削減につながるのではないかと、多くの企業は期待する。しかし、実際はメンテナンスや検索スクリプトの作成作業、専任者の不在、トレーサビリティのなさで、むしろコストはかさんでしまうこともある」――セッション「テスト自動化サービスプロバイダがこっそり教える成功の秘訣」に登壇した日本ノーベルの東大輔氏はテスト自動化で陥りやすい失敗を挙げ、テスト自動化を成功させるには組織に根付かせることを考えるべきと指摘した。

日本ノーベル 検証システムビジネスグループ グループマネージャ、東大輔氏

　東氏は、テスト自動化に成功しているユーザーには三つの共通点があると述べる。

　一つは、ツールを理解した専任者がいることだ。「ツールの特徴やメリットを理解し、自動化プロセスの定義や検査スクリプトの記述などができる専任者を育成し、配置することは重要」と東氏は言う。「片手間で中途半端な知識のまま自動化しても失敗に終わる」（東氏）

　二つ目は、ゴールが明確であることだ。「目的が不明瞭では、スクリプト作成が目的になってしまったり、流用や再利用もできなくなったり、効果の測定もままならなくなる」。自動化したいテスト対象や範囲を明確化し、ROIを算出して、ステークホルダーに承認を得られるよう提案書やテスト計画書をまとめるべきと東氏は言う。

　三つ目は、自動化プロセスを定義することだ。東氏はプロセスフローとして、自動化可能性の分析、スケジュールやテスト戦略、試験環境構築、スクリプトの作成と実行、ドキュメントの作成、スクリプトのメンテナンスを挙げた。「ソフトウエア開発に近いプロセスを確立できたら大成功だ」（東氏）

　以上の三つのポイントを実現し、組織にテスト自動化を根付かせるには、長期的に継続して品質向上を推進する専門家や検証パートナーが重要になる。「日本ノーベルでは、テスト自動化を定着させたい企業を全面支援する」（東氏）

ゴールドマン・サックスが実践するソフトウエア品質向上の取り組み

　最後の特別講演「ゴールドマン・サックスにおけるソフトウェア品質向上の取り組み」に登壇したのは、ゴールドマン・サックス・ジャパン・ホールディングスの伊藤博志氏だ。

ゴールドマン・サックス・ジャパン・ホールディングス テクノロジー部 ヴァイス・プレジデント 伊藤博志氏

　同社はグローバルで3万以上の社員を擁し、うち8000人以上、なんと「25％近くがエンジニアだ」と伊藤氏は明かす。エンジニアは世界15カ国44のオフィスに在籍し、株取引や債券取引、各ビジネスドメインに特化したアプリケーション開発を行うアプリ開発チーム、エンタープライズプラットフォームとクライアントプラットフォームを開発するチーム、インフラチーム、テクノロジ全般に関わるリスクマネジメント担当チームに分かれて、日々業務に邁進している。

　独自開発を進める上で、伊藤氏は一般的に大規模な開発組織が直面し得る課題として、「開発内容が別チームと重複してしまうリスク」「マニュアル作業によるヒューマンエラーが発生するリスク」「テストや自動化の状況の可視化」「問題発生時の迅速な対応」「説明責任」「トレーサビリティ」「人員が異動する際に、異なる開発ライフサイクルやツールの違いに戸惑い生産性が低下するリスク」などを挙げた。

　こうした課題に対して、同社は技術と人材の両面からソフトウエアの品質管理に取り組んでいる。

　技術面では、まず再利用性の向上を図る例として、同社で開発されたプラットフォームの一部が紹介された。具体的には、金融商品のモデル化やリスク計算に特化した自社開発言語／プラットフォームの「SecDB」、フロントエンドプラットフォームの「Goldman Sachs Web UI Tool Kit」、そして自社内開発のモデリング言語を含むバックエンドプラットフォームの三つが例として挙げられた。また、「マニュアル作業を減らして生産性の向上と品質管理の強化を図ること」「数値化やグラフ化を通じてボトルネックの理解と改善を目指すこと」「透明性を得ることでマネジメント層への理解の確保と監査への対応」などを目的として開発された統一プラットフォームを全プロダクトで採用し、ソフトウエア開発ライフサイクル（SDLC）を効率化している。

　コードの品質は、定量的に計測できるものはOSSの静的解析ツールなどで対応し、定性的な領域でもコードの品質を向上させるために、設計レビューやコードレビュー、ペアプログラミングなどの各種取り組みを行っている。「例えばコードレビューは、バージョン管理システムにコミットする前に独自のレビューシステム内で行うようにしている。また、コードの変更があった場合はコミット前にCI上でまずビルドし、テストに合格してからコミットする仕組みを活用している」（伊藤氏）

　この他、テストが十分実施されているかどうかは、独自のテスト成熟度モデルを使って評価しているという。

　人材面では、社内SNSやチャットシステムなどのコラボレーションチャネルの作成、コミット数やレビュー数をポイントランキングしてモチベーションを刺激するゲーミフィケーションの導入、社内ハッカソンの開催、1990年代より毎年エンジニアを新卒採用し育成しているなど、継続的な社員育成を図っていると述べた。

　「管理するだけでは品質は向上しない。長期的に組織が成長できる環境を作り、学ぶ文化を浸透させることが大切だ」（伊藤氏）

---

　今回は非常に多数のコンテンツを用意したこともあり、「スピードと品質の両立」をさまざまな観点で考えさせられるセミナーとなった。特に重要なのは、ソフトウエアがビジネスを支えるものである以上、その「品質」も「ソフトウエアとしての品質」だけに閉じるものではないことだろう。実際、「何のために、どのような品質を担保すべきか」「その品質を担保するためには、どのようなツール機能が有効か」といったロジックは各講演に共通していた。

　「スピードと品質」というとツール機能に目を奪われがちなものだが、「現場のため」ではなく「ビジネスのため」という最終目的を見据えてこそ、正しい取り組み、本当に必要なツール機能を判断しやすくなるのではないだろうか。