日本の企業とコミュニティ エンジニアの目線で 2012年07月11日 登録者 つくだひとし
飯泉さんには、実は借りがある。昨年の11月、上海・福旦大学で開催された第5回世界ソフトウェア品質会議(WCSQ)で筆者は飯泉さんの講演を聴く約束を反故にして、別の会場で行われた会議に出席した。間の悪いことに(おめでたいことなのだが)、飯泉さんはWCSQベストスピーカー賞を受賞していたのだった。後で人を介して「不愉快だわ、プンプン」であることが伝わっていた。それもあって今回はそのお詫びの意味もある。しかしそれだけではない。ソフトウェアエンジニアの目を通したとき、日本のソフトウェア開発と品質はどのように見えているのだろうか。興味のあるところではある。
工場配属なら技術士資格
飯泉 よろしくお願いいたします。今日はソフトウェアエンジニアとしてのお話をしたいと考えています。ですがわたくしはいまだにソフトウェアエンジニアとして仕事をしていまして、時間のなかでぴったり終わるのは苦手ですし、途中を端折ってしまうとかいうことがあるかと思います。それとここ数日、ちょっと風邪気味でして、声が1時間もつかどうか自信なかったんですけど、さきほど高田先生に質問させていただいたとき、「あ、これだけ出せれば大丈夫だな」と(笑)。
日立ハイテクノロジーズというのは、以前は日立製作所の計測機事業部といっていたんですけれど、わたくしはそこで計測装置、臨床検査用装置とか半導体検査装置とかですね、それに組込むソフトウェアを開発してきたんですね。日立では研究所に入ったら博士、工場に配属されたら技術士を目指せという不文律のようなものがありまして、それでわたくしは10年ほど前に技術士、情報工学部門を取りました。
外部の勉強会では……、え〜と、これはついさっき気がついて追加したんですけど(笑)、日科技連のSQiP(Software Quality Profession)ですとか日本SPIコンソーシアム(JASPIC)のSEPG(Software Engineering Process Group)、QuaSTomなどに参加していまして、そういう関係からSQuBOK、『ソフトウェア品質知識体系ガイド』(SQuBOK策定部会編、オーム社刊/3,675円)の編集にも加わっています。それと世界ソフトウェア品質会議(SWQC)なんかにも参加して論文を発表したりしています。
そのなかでいろいろ議論して、実際にやってきた品質を作り込む施策をお伝えできれば、と考えています。最初に日立ハイテクノロジーズでのソフトウェア品質向上の取組みのお話をして、レビューのやり方の改善、機能仕様とテスト仕様の同時設計による見逃し防止、オフショア開発における設計書の改善、ドメイン知識の共有の4つの事例をご紹介します。
当社が製造している臨床検査用装置や半導体検査装置は、20年以上にわたるシリーズ製品なんですね。用途が決まっていますから要求要件は大きく変わりません。シリーズ製品ということですので機能を追加したり改善することになります。メカ的な性能向上もありますしユーザーの要求の変化も、ソフトウェアで吸収する傾向が強まっているのは言うまでもありません。
組込まれているソフトウェアというのは臨床検査用装置ですとリアルタイムOSと制御用ソフトウェア、半導体検査装置は汎用OS、それとデータベース、通信機能、GUI、画像処理といったユーザー操作用のソフトウェアです。プログラムの規模にすると100万行前後ですから中規模といっていいかと思います。
皆さんご存知のように、日立の製品というのは洗濯機も冷蔵庫もそうですが、丈夫なんですね。ちょっと叩いたぐらいでは故障しない。その分だけ高い。性能とか機能とかでは他社製品と差別化できない。それでも競争力を保つにはやはり付加価値を付けるしかない。そうなるとますますソフトウェアが重要になってきます。
で、当社でソフトウェア品質向上の取組みが本格化したのは1998年ごろでした。設計書とプログラムについてチームレビューを始めました。次に2000年から2001年にかけて開発プロセスに着目し、品質向上手法を採用しています。それとほぼ同時に国際調達、このころ中国でのオフショア開発が本格化したので、それに対応した品質確保が課題になりました。装置組込みソフトウェア開発における検証品質を目的にしたプロセス改善に取りむようになったのは2002年から2003年です。
そのあと対象ドメインの知識を共有することで品質を高めようという取組みをやりまして、昨年11月、中国の上海で開かれた第5回世界ソフトウェア品質会議でその成果を発表しました。振り返るとこの10年とちょっとの間、最初にレビューをやってプロセスに注目して、知識の共有ということなので、やることはやっているんだな、というのが感想です。
QCDに戦略性を持たせること
ソフトウェアの品質を考えるうえでポイントになるのは、品質(Q:Quolity)、コスト(C:Cost)、納期(D:Delivery)のうち何がいちばん重要か、何をいちばん優先するかだと思います。開発者から見ると納入先の方針がありますし、自社の方針もあります。システムがトラブルを起したとき、誰にどのような影響が出るか、ということも考えなければなりません。誰に、というとき納入先、自社だけでなく、納入先の顧客、臨床検査用装置の場合だと患者さんの生命にかかわることもあるわけです。
いちばん重要なのは何か、わたくしは経験がないので勉強会や研究会などでいろんな人に訊ねると、大規模な業務系システムだと大抵の方が「納期」だというんですね。でも「品質もコストも大事だよね」というので、ここでは〔D→Q、C〕ということにしました。ミッションクリティカル、例えばちょっとでも不安があったらロケットの発射を中止するNASAのシステムのような場合は何といっても「品質」です。アウトソーシング、オフショア開発ではどうかというと、今はちょっと事情が変わっているかもしれませんけれど、「コスト」が最優先でした。
それぞれ優先することが違うんですが、わたくしは高品質がいちばんだ、と考えています。それはワッツ・ハンフリーさん、CMMの生みの親であり2010年の10月に亡くなられましたが、ハンフリーさんが言われた「高品質の仕事は時間と費用を節約する」という言葉のとおり、高品質を追求することが結果として納期とコストを抑制するというのが弊社の基本姿勢です。品質の上に納期やコストが乗っかっている。
わたくしや日立ハイテクノロジーズがそのように考えているのは、決して根拠がないことではありません。実はそれは日本の企業に共通していることでして、この図=上=、皆さん、見たことがありますか? 見たことがあるという人が意外に少ないんですけれど、2005年に日科技連から出版されたロジャー・プレイスマンという人の本にある図です。「品質中心の文化」がいちばん下にあって、日本のソフトウェア開発はまさにこれだ、って思っていて、やはりこれがベースにないとプロセスにも手法にも入っていけない。
ソフトウェア品質技法には品質分析・評価、テスト、レビュー、要求分析、品質計画、メトリクスといった切り口がありますし、設計技術にはアーキテクチャ、アスペクト指向分析・設計、オブジェクト指向分析・設計、モデル駆動開発、形式手法といったアプローチがあります。こういうのを組み合わせて活用すればうまく行きますよ、それがソフトウェア工学ですよ、と言うんですが、しかしそれを聞いただけではうまく行きません。そのためにはやはり戦略、別の言い方をすると「ベストプラクティスの“知”」を見極めることが重要です。
1.必要なのか――誰にとって(Who)/なぜ(Why)/何が(What)
2.適しているのか――組織文化/タイミング(What)
です。ちょっと偉そうに言うんですが、これを見極めないで、世の中の流行や宣伝文句に惑わされちゃいけませんよ、と。
NGパターンを示しますと、何か改善活動をしなきゃいけないということで組織を作ってしまう、何をとらえるべきかを探らないまま見える化することを偏重する、あるべき姿論に固執する、何をやっても現場は変わらない・変えられないという変な現場重視。
それとあえて言うんですが、ポジティブ思考。良いといわれているんだからどんどん取り入れようというのは、一見すると前向きなんですが、どこをどう改善しなければいけないかを知らないで取り入れるのは、薬と同じでかえって危険なこともあるんです。いまこの問題でちょっと悩んでいるものですから、思わずリキが入ってしまいました(笑)
もう一つ、ワインバーグという人が組織文化のパターンを「無意識」から「適合」まで6段階に分けています。CMMができる前のものですけれど、レベル0の「無意識」というのはプロセスを実行していることに気づいてもいない状態ですから、ここに重たい工学的手法を持ってきても活かすことはできません。レベル1の「可変:やりたいことは何でもやる」、レベル2の「慣習:パニックのとき以外は慣習に従う」でも同じです。レベル3の「舵取り:結果によって慣習を選別する」の段階になると工学的手法が機能するようになります。先ほどの高田先生のお話に通じるものがあるかと思います。
レビュー報告書をテンプレートで
で、これからお見せするプレゼンテーション資料というのは、2009年に情報処理学会の組込みチュートリアルで紹介したスライドで、それを今回そのまま使うんですが……、それに出席してらした方、いらっしゃいませんよね?(笑)
レビューの方法っていろいろありますよね。2000年のちょっと前、CMMが出たころ、QuaSTomで「ピアレビューって、いまわたしたちがやっているレビューとどう違うの?」という議論が盛り上がりました。そのときある方が「こんなのがあるよ」と教えてくれたのがこの図です。
2000年当時は「レビューにはどんな手法があるの?」という段階でした。でも現在はこのように整理されちゃうと、選り取り見取りです。テスト段階や納入先で何か問題が発生すると、設計段階でレビューの手法が間違っていたんじゃないか、ピアレビューをやるべきだったとかインスペクションのほうがよかったとか、そういう話になることが多いんですけれど、それって筋違いじゃないかと思ったものですから、2001年にソフトウェア設計者の問題意識を調査しました。そうしたら「上流工程の設計が不十分」が34%、「ドキュメント不足」が33%、「詳細設計の不足」が13%、「質の評価不足」が8%というような結果でした。
当時もそれなりにレビューはやっていましたし、開発プロセスも確立されていました。でも「上流工程の設計が不十分」とか「ドキュメント不足」という指摘が3分の1を占めました。それって何故だろうと考えて、内部レビューについて計画の立て方やメンバー、手順がどんなふうに行われているのかを調べました。そうしたら実際は手探りの状態で、レビューがプレゼンテーションの場とか仕様決めの場だったり関係者の理解を深める場になっていていることが分かりました。レビューをやっているつもりになっているだけだったんですね。関係者の理解を深める場というのはアリなんですけど、何となくやっているんじゃダメで、目的をはっきりさせないといけません。
それでレビューの意味を教育しなければならないと考えました。他の事業所のやり方を勉強したりレビューの進め方や報告書のフォーマットを規定しました。フォーマットを決めるということはレビューの範囲、回数、レビュー方法、実施工程、参加者構成などが“見える化”されるわけです。何のためにレビューをやるのか、という意識が共有されるので自信を持ってレビューをやるようになったり、チェックリストを活用するようになりました。あれから10年以上経って、弊社ではドキュメントが不足なんていうことはあり得ません。これでもかッ、ていうほどドキュメントを書かされますし、「上流工程やらされ過ぎ」なんて言っている人がいるくらいです(笑)。
テストファーストの考え方
2つ目の事例「機能設計とテスト仕様の同時設計による見逃し防止」ですが、『プロセス改善ナビゲーションガイド』(情報処理推進機構ソフトウェア・エンジニアリング・センター編、オーム社刊、2008年)に詳しく書いてありますので、サラッと流していきます。これは2003年に取り組んだ施策です。
なぜそういうことに取り組んだかというと、テスト工程がいつまでも終了しないので、システム開発が遅延するということが起こったからでした。開発に遅延が発生するとわたしたちはヒアリングをして原因を調べます。そうすると人手が足りないとか誰が作ったか分からないとかいう話が出てきます。でもそれは本質的な問題ではないんですね。
テスト工程に問題があると分かったのは、プロジェクトごと、工程ごとにリソースや期間、不具合数といったメトリクスを取っていたんですね。特に不具合に関するメトリクスを取っていたのが役に立ちました。テスト工程で手戻りが発生していて、それでいつまで経ってもテストが終わらない。
弊社ではQA(Quality Assurance)チームが不具合検出をやるのは2回まで、という“しきい値”を定めていまして、それを「入検」と呼んでいるんですけど、ところがそれを出っ張っちゃうプロジェクトがあるわけです。現場から「AQにテストされているんじゃないの?」という警戒の声とか、「QAはテスト項目の設定が上手いだけなんだよ」という変な声がありました。その立場だったらわたくしも同じことを言ったかもしれません(笑)。QAはいじわるをしているつもりはないんですけれど、現場の技術者は一生懸命やっている。それを無碍にすることはできません。
それで設計者に反省文を欠かせるようにしました。「品質計画書」っていういいネーミングなんですが、それを提出してもらうようにしました。不良発生防止策と実施工程を宣言してもらうんです。そうすると2回目のとき、同じことは書けません(笑)。わたしたちQAが「もっと工夫した計画書を出しなさい」と突き返すこともあって、そこで手戻りが発生したりして、設計者は「こんなこと、いつまでもやってられないや」とヘソを曲げるようなことがありました。最後は「テスト、頑張りま〜す」みたいになっちゃうんですね。
テストを頑張ればいい、っていう話じゃないだろうと考えて、設計者を対象にどの工程を改善したらテスト遅延が解消すると思うか、と聞いたんですね。するとグラフのように「結合テスト」という回答が約半数、47%でした。もっと細かくインタビューをしたら、「仕様に記述があるのにテスト項目がない」「仕様の記述が不備なためにテスト項目が抜けている」「仕様変更の影響範囲を把握しきれないためにテスト項目が不十分」といったことが分かってきました。
で、これはどうやら要因が4つあるみたいだぞ、ということに気がつきました。1つは開発リソースです。アウトソーシング、オフショア開発で仕様の誤訳や誤解。2つ目はVモデルの開発プロセスでしばしば起こる問題です。機能設計とテスト設計が分離されていたり分断されているために一貫性が欠けることが起こります。3つ目は機能仕様書とテスト仕様書が別々に作られていて、レビューでカバーしきれないんですね。4つ目はソフトウェア機能が複雑になってテスト項目がすごく増えているということです。規模が大きくなっていますから、テスト工程に入ったとき、機能仕様書にどんなことを書いたか、細かなところまで覚えていなませんよね。
1つ目と4つ目はいっぺんに解決できませんが、機能設計とテスト設計が分離された開発プロセスを見直せばかなりの部分が改善するんじゃないか。システム方式設計→ソフトウェア方式設計→詳細設計→コーディング→単体・組合せテスト→結合テスト→総合テストという従来の開発プロセスに、当時話題になっていた「テストファースト」の考え方を取り入れて、方式設計、詳細設計の段階でテスト設計を行うやり方です。そうすると機能仕様とテスト項目が同期するので、テスト項目の抜けがなくなるんです。それでMS−Wordのコメント機能を利用して、機能仕様を書くときテスト仕様を併記するツールを開発しました。
部長は「それで行こう」と言ってくれたんですが、現場の設計者には「それは自分たちの仕事じゃない」とか「いまやらなくてもいいでしょう」とか「第三者検証でいいじゃないか」とか、いろいろ言い分がありました。でも設計者だからこそ書けるテスト仕様があるよね、絶対条件じゃなくて必要条件だと考えてよ、と説得して、それを実施したら設計者がその効果を実感しましてQAへの持ち越し不良が減少しました。ほんの一例ですが「仕様に記述があったけれどテスト項目がない」は11件から0件になっています。
翻訳の誤解とコストを減らした
サラッと行く予定だったんですけど、ちょっと熱が入ってしまいました(笑)ので、先を急ぎます。さっきも触れましたけれど、これは決してすり合わせをしたわけじゃないのに高田先生も「日本の企業は外注・オフショア開発が苦手」とお話になっていて、さっき聞きながら「さすがッ」と思っていました(笑)。
最近はちょっと減っていると思いますが、オフショア開発ではうまく仕様が伝わりません。日本語を英語に翻訳するとき、例えば「登録」を翻訳すると「レジスター」ですけど、画面上に保存するのかデータベースの更新なのかセーブなのか、解釈が異なります。それとブリッジSEの能力に依存しますし、アウトソーシングですから進捗や完成度が見えません。そのほかに行間が読めない、ホウレンソウ(報告・連絡・相談)が身についていない、サンプルをほしがる、品質に対する意識が違う、だから困るという話もしばしば聞きます。そういう問題は弊社はもうクリアしちゃったんですけど、参考になるかもしれませんのでお話します。
オフショア開発がうまく行かなかったり失敗すると、多くの人は「相手が悪い」と考えます。でもそれは間違いで、こっちも悪いところがあるし、お互いに協力し合えば解決することも少なくありません。技術力とかインフラが整っていないとかいうのは相手の問題かもしれないけれど、それを選んだのは自分たちですし、特に仕様書の問題とか伝達の方法というのはこっちが改めなければならないことです。 実際にあったケースでは、GUIの開発でデータの初期値が誤っているとか表示される文字列が途中で切れている、データの値域チェックが実装されていないので範囲外の値を入れることもできてしまう、テスト仕様書にデータが記載されていないので何をどこまでテストしたのか分からない。
もっと卑近な、というか初歩的なケースでは、ちょっと笑っちゃうかもしれませんが、コンボボックスの文字フォントが違ったり文字列の高さが簿妙にそろっていなかったこともありました。オフショア先の人はあとで直せばいいと考えているんだけれど、こっちは最初からキチッとしていてほしい。これはイカン、と。
これをオフショア特有のよくあることなんだ、相手が悪いんだ、で済ませてしまうとそれきりなんです。でも受入れの検収にものすごい負荷がかかって、オフショアのメリット、2000年代の前半でしたから優先したのはコストです、そのメリットが出ないことになります。例えばコンボボックスが500あったとすると、QAが一つひとつ全部チェックしていたのでは時間がかかって仕方がない。発注する側、調達する側の問題なんだ、と考えて、どうすれば要求どおりのものを作ってもらえるか工夫しなければ事態は改善しません。
品質を作り込むには信頼関係が欠かせません。思いやりとか、ね。書き手・読み手のスキルに依存しない、かつ翻訳が容易なドキュメントですとか、必要十分なテスト項目を抽出しておくですとか、品質確認の根拠となり得るテスト仕様書とか、それはオフショア開発に限ったことではありません。実は社内でも国内でも同じなんですね。できあがったあとブツブツ言うくらいなら、最初からちゃんと仕様を固めておいたほうがいい。
で結局どうしたかというと、必要かつ必須の仕様項目を確実に記述するドキュメントテンプレートを作りました。基本は画面機能、フィールド仕様、データ接続仕様の3つ、それとテストデータについては粒度をそろえること、使用したデータが何なのか記載するようにしました。わたくしたちが無意識に相手に求める“当たり前”を、意識して相手に伝えること、それが目的です。それで実施したら、これも一つの例ですけど、ある製品のサブ機能、18のサブ機能画面でボタンとかコンボボックスとかのコントロールが3,400個という規模で、コントロール単体内の不具合はわずか10件でした。
不具合率が大幅に減少した、つまり品質が向上したわけですけれど、意外だったのは翻訳コストが削減できたということです。用語が限定されるので長い文章が減る。そうすると設計者が、自分が使っている用語を気にし始めるんですね。「あれ、さっきこういうふうに書いたけどそれでいいのかな?」とか、「オフショア先の人はどう理解するだろうか」とかです。認識、意識の違いを設計者が理解することができた効果はたいへん大きかったと思っています。
暗黙知の伝達を組織的に
最後は「ドメイン知識の共有による組織的開発の強化」です。これは去年、上海で行われた世界ソフトウェア品質会議で発表したんですけど、以前は少数精鋭のチームで設計から開発、テストまでやっていたんですけど、現在は大勢でプロジェクトを編成します。そうすると工程ごとにチームができますし、未経験領域の問題に対応できない。自分がかかわった領域は分かるんだけれど、それ以外は分からない。全体を知っておく必要があります。
でも共有すべきドメイン知識は何なのか、どの範囲まで共有すればいいのかとなると、よく分からない。というのはドメイン知識は技術者一人ひとりの中に蓄積されていて表に出すのが難しいし、しかも体系だっているわけでもありません。興味の持ちようによってウエイトが変わります。これからますます必要になってくるのは団塊世代の技術者が第一線から退いていくということです。退職する人がいろいろ書き残していってくれますが、それが設計に役立てられていないことが多いんですね。ナレッジマネージメントのツールはいろいろ提供されていますけれど、使いこなせていないのが実情です。
なぜか、と考えると、一つは知識の抽出と表現の手法が欠けている、もう一つはその知識を社内の公式のものとして認める、つまり公認することなんですね。それで2010年の5月から、最終的に「ドメインモデル図」を描くことを目的に、知識の抽出から始めました。適用したのは生化学・面英気自動分析装置のシリーズ製品の開発に携わる5つのチームです。最初にドメイン知識を抽出する意義を部長から説明してもらって、既存のドキュメントに記載されている知識を書き出し、並行して質問票で個人が蓄積している知識を引き出すというやり方です。それを個々のレポートしてまとめるんですが、その場合、レポートの長さを30ページまでと規定しました。ダラダラした文章だと何がポイントなのか分からなくなりますから。
2010年の5月から作業を開始して、9月までに表のような成果がありました。それをもとに「ドメインモデル図」を描きますと全体像が分かるだけじゃなくて、全体はどういうくくりで構成されていて、自分たちはどこのパートを担当していて隣接するのはどういう機能なのか、どこに影響するかが見えてきます。これをもとに知識抽出チームのリーダーが技術者に講義をし、技術者が独学できるようにしました。あくまでも机上のシミュレーションですが、ドメイン知識に起因する欠陥18件のうち、16件までが未然に防止できたというのが結論です。発見された欠陥39件の41%に相当します。
ちょっと、というか10分以上オーバーですが、「咀嚼して見極める」「現場に合う施策」が品質向上の決め手ということを申し上げてわたくしの話を終わります。(拍手)