SQuBOKによる無知の知の体験

SQuBOKv2読破会アドベントカレンダー4日目のブログエントリーです。

www.adventar.org

SQuBOKの入手動機と読破会への参加動機

SQuBOKというのはこれです。ソフトウェア品質体系ガイド。

ソフトウェア品質知識体系ガイド -SQuBOK Guide-(第2版)

いかにも堅そうな名前の本を手にした理由は 「一応専門家のはしくれだし*1持っておくか」くらいのもので、読もうとは思っていませんでした。 ぱらぱらとめくってみると、文体は淡々としており、図はあまり無く、かみ砕いた説明も無く、 色気の無い本だなという印象でした。読破会*2の主催者は「宝箱のような本」と言っていますが、 一体こんな色気の無い本のどこが宝箱なのかと思っていました。 読んだ今では、BOKにごてごてとした読者への配慮を求めるものではないということがわかったのですが、 読む前はBOKと名のつく書籍を手にするのは初めてだったこともあり、そのような印象を持っていました。

また、ソフトウェア開発に関するBOKとしてはIEEE発のSWEBOKが筆頭に挙がると思います。 SWEBOKがあるのにSQuBOKが作られたことは疑問でした。そして、SQuBOKは日本発のBOKというのも疑問でした。 SQuBOK V2の"はじめに"には次のことが書かれています。

日本のソフトウェア品質への取り組みは、製造業を中心として発展した品質のマネジメントに学ぶところから始まった。 それは一定の成果を得たものの、その技術や知識は各企業の現場それぞれで暗黙知の状態だった。 SQuBOKガイド第1版の策定動機の一つは, 日本で培われたソフトウェア品質に関する暗黙知を形式知化することにより…

こんなことを書くと何人に石を投げられるかわかりませんが… 日本で培われたソフトウェア品質に関する暗黙知に参考になるものがあるのかと。 製造業を中心として発展した品質のマネジメントが一定の成果を出したのかと。 NTT, NEC, 富士通, 日立, 東芝, 松下などの日本企業よりも、 Microsoft, Apple, Google, Amazon, Facebook などの米企業の方がソフトウェア工学において先を行っているのではないかと。

そう、思っていました。 だから、日本からSQuBOKが生まれたのは不思議でした。 いや、読んだ今でもその疑問は解けていないところもあるのですが、読む前は実に不思議でした。

そこで読破会の誘いを受けて、参加することにしました。 私に知識があるのか無いのかを確かめるために、 本当に宝箱のような本なのかを確かめるために、 日本発のソフトウェア品質の知見が参考になるのかを確かめるために。

あと、読破会の主催者がV1の策定メンバーであったことや、 8人という少人数であることも参加を後押しする理由でした。

無知の知テーブル

読破会の進め方は毎月集まって30ページずつ程度を読み進めながら議論をするというものです。 2015年の1月から始めて今月で終わる予定なので全部読んだわけではありませんが、 大体読んだとみなして、ここでSQuBOK全体の中で私が知っていたことと知らなかったことをまとめてみました。 結果、知らないことが多かったことを認識できました。なので、これを無知の知テーブルと呼ぶことにします。

• ● : 半分以上知っていた
• △ : 一部は知っていた
• × : 全くと言って良いほど知らなかった

項目	●△×	コメント
1.1 品質の概念	×	なじみがあったのはISO25010と狩野モデルくらい。デミング賞のデミングってここで出てくるのかー
1.2 品質マネジメントの概念	×	日本における品質マネジメントの歴史があるんだなーと
1.3 ソフトウェア品質マネジメントの特徴	×	理解はともかく冒頭の文が熱い！
2.1 ソフトウェア品質マネジメントシステムの構築と運用	×	日本企業、昔から努力してたんですね。QCサークル,品質会計,Qfinityとか色々初見。
2.2 ライフサイクルプロセスのマネジメント	×	プロセスモデルだけならまだしもライフサイクルと言われると難しい
2.3 ソフトウェアプロセス改善のマネジメント	×	名前しか知らないものがほとんど。三階層SEPGやばい
2.4 検査のマネジメント	△	1ページだけで、まぁそうだよねという内容。
2.5 監査のマネジメント	×	経験がないので全く知りませんでした。
2.6 教育・育成のマネジメント	×	知っていたのはETSSだけ
2.7 法的権利・法的責任のマネジメント	×	PL法なんてあったなーとか
2.8 意思決定のマネジメント	×	IPD, 今でもやってるんでしょうか
2.9 調達のマネジメント	△	外注するなという話が欲しいところだけどBOKには書かれないかなぁ
2.10 リスクマネジメント	×	ISO/IECの規格があるんですね
2.11 構成管理	●	仕事でやってるのでここはまぁまぁ
2.12 プロジェクトマネジメント	×	PMBOKの名前くらいしか
2.13 品質計画のマネジメント	△	トピックがベンチマーキングだけなのはいいんでしょうか？
2.14 要求分析のマネジメント	●	深そうな項目名だけど難しいことは書いていない
2.15 設計のマネジメント	●	まぁやりますよねという内容
2.16 実装のマネジメント	●	まぁやりますよねという内容
2.17 レビューのマネジメント	●	大事
2.18 テストのマネジメント	△	やけに手厚い
2.19 品質分析・評価のマネジメント	△	どうマネージするのかは理解が浅い
2.20 リリース可否判定	△	合格基準って意外とわからない
2.21 運用のマネジメント	×	経験がないのでさっぱり。理解できないところも多い。
2.22 保守のマネジメント	×	経験がないのでさっぱり。理解できないところも多い。
3.1 メトリクス	●	だいたいは
3.2 モデル化の技法	△	PAD, DSLは初見。
3.3 形式手法	△	経験はありませんが、ツール名・効果・労力に関して話に聞くことがあります。
3.4 品質計画の技法	×	そういうのもあるのか
3.5 要求分析の技法	△	清水吉男さんの本を読んだくらい
3.6 設計の技法	△	デザインパターンやTDDなど馴染みのものもありますが、ほかにもあるんですね。
3.7 実装の技法	●	契約による設計が初見
3.8 レビューの技法	△	3.8.1については名前は知らないけど実はやってるというケースが多いのではないかと
3.9 テストの技法	△	SQuBOKの中で一番ボリュームがあるのではないか。"3.9.9テスト技法の選択と組み合わせ"は熱い！
3.10 品質分析・評価の技法	△	知っているのは2割くらい
3.11 運用の技法	×	仮想化よくわかりません
3.12 保守の技法	△	コードクローン分析は保守の技法なのか？
3.13 使用性の技法	△	黒須先生の本を読もうかなと
3.14 セーフティの技法	×	安全とは一体うごごご
3.15 セキュリティの技法	△	テスト, これ以外に無いのかなと

SQuBOKを読んで良かったこと

どの知識領域をどれだけ知っているかを認識でき、どこを伸ばしてゆくかを考える機会ができました。 BOKでありポインタ集なので知識そのものが増えるわけではないのですが、知識を増やすためのキーをたくさん得ることができました。 キーというのは、用語・人名・書籍名・規格名のことで、SQuBOKを読む前はこれらのキーを全く知らなかったことを考えると、それだけでも収穫だと思います。

ソフトウェア品質マネジメントの歴史の中に日本の大企業や日本人が多く登場することも初めて知りました。 実は20年前の方がプロセス改善やマネジメントの面では力を入れていたのではないかとも考えさせられました。

また、少人数で集まって読むというスタイルは、SQuBOKを全て読むために欠かせないことでした。 一人では最初から最後まで考えながら読むということは、BOKに対してはできなかったと思います。 今でもSQuBOKを開くと読破会の情景や議論したことを思い出します。 この知識領域は誰が詳しかったなとか、あのトピックは意見が分かれたなとか。

主催者の言うように宝箱のような本なのかは読んだ今でもわからないのですが、 私の職務に関わる広大な知識領域において、有志の協力を得て無知の知を体験できたことは、とても貴重であることは間違いありません。

おわりに

あっさりとしたエントリにしようと思っていたのに結構書いてしまった！ SQuBOKV2読破会アドベントカレンダーはまだまだ続きます。 次は @Kazu_cocoa さんです。よろしくー

*1:私はQAではなくSEPGやSoftware Engineering Consultantの立ち位置です

*2:詳細は1日目のエントリーを参照