~ソフトウェア品質の向上とそこに関わるすべての方へ~ Software Quality Profession

2.人材育成

ソフトウェア開発における知の整理・体系化と伝承
―JSQCソフトウェア部会「遺言」プロジェクト―

(社)日本品質管理学会ソフトウェア部会前部会長
兼子 毅

2.フレームワーク(トップダウン型知)と実践(ボトムアップ型知)

欧米型の「知」の多くは、「フレームワーク」の形をとる。全体像がひと目でわかり、構造も明確である。一方日本型の「知」の多くは「実践」の形をとる。一つ一つは極めて具体的だが、全体の位置づけ、構造などは不明確で、したがって、短い期間に他者に伝達することが極めて困難である。家元制度、一子相伝、免許皆伝など、長い期間一緒にいる中で伝えられていく「極意」のようなもの、これが日本型の「知」である。なぜ日本人は「枠組み」を考えるのが不得手なのか。これは本稿の主題から離れるので、あえて触れない。筆者個人的には、麦を主食とせず米を主食としたこと、あたりが関係しているのではないか、と考えているのだが、それはまた別の機会にでもお話したい。

さて、ここ20年ほど、日本における品質管理やマネジメントの分野でも、様々な欧米型フレームワークが導入されてきている。それは自分たちの活動を再構成し、整理する上では極めて有益ではあるが、それらのフレームワークが持つ本質的な陥穽に気付いていないため正しく用いられていないことが多いように思われる。フレームワークが持つ本質的な陥穽とはなにか? いろいろな業務や業種で使える枠組みとするために、途中のレベルから下の活動を「抽象化」している、ということである。特定の業務や業種で当該フレームワークを有効に用いるためには、まさにこの抽象化された活動を具体的に記述し、かつ実践することが極めて重要である。しかしながら、ISO9000シリーズの第三者認証の仕組みなどの影響もあり、この「具体化すべき部分」を放置したままフレームワークを適用するという極めて憂慮すべき状況があちらこちらで見られる。

分かりやすさも、欧米型フレームワークの特徴であろう。日本における師弟関係では、きっとこんな会話がなされている。「珍念(弟子の名前です)、まずはこれができるようになりなさい」「できました」「まだまだダメだ。次はこれに挑戦しなさい」というようなやりとりが延々と続き、ある時、お師匠様に呼ばれて「免許皆伝」を告げられる。いつ終わりが見えるのか、わからないまま走り続けなければならない。欧米型だと、もっとスマートだ。「この仕事には、ポイントが3つあります。一番目はこれ、二番目はそれ、そして三番目はあれです。ひとつずつマスターしていきましょう」というような感じだろう。極めて分かりやすい。

誰かが、あなたの仕事のために、専用の枠組みを考えてくれたのなら、それは素晴らしいことだ。考え抜かれていて、必要なことが全て収まっているのだろう。でも待って欲しい。貴方と全く同じ仕事をしている人は、世界に何人いるのだろうか?その人達のための専用枠組みを、誰かが作ってくれるのだろうか? 欧米型フレームワークは、せいぜいが「モノづくりをするのであれば、まずはこのような形」とか「ソフトウェアを開発するなら、一般的にはこんなことが必要ですね」というレベルである。本当に役に立つ「知」は、もっと現場に近いところにある。

少なくとも日本人は、フレームワークを考えることが苦手だと思う。むしろ、整理されていない「実践」を多数積み重ね、「底力」を発揮する、というタイプだ。競争優位をいかに維持し高めていくかという戦略を考えたとき、多くの人が「自分の長所、優位な点を伸ばすべき」という。そこでJSQCソフトウェア部会では、あえてトップダウンの構造を作らず、ボトムアップによる体系化を志向した。

3.構造・分類と視点

博物学の分類とは異なり、実務における分類には必ず目的が必要である。例えば、乗り物であるか否かという観点であれば、「馬、牛、ロバ」と「ヤギ」に分類できるが、食べ物であるか否かという観点であれば、少なくとも日本では「馬、牛、ヤギ」と「ロバ」に分類できるだろう。このように、構造や分類は、その視点によって複数存在し、どれが正しいかを議論することはあまり意味が無い。むしろ、ある特定の視点から見たときに、最も良い分類は何か、目的に合致した分類は何か、が議論の対象となる。

JSQCソフトウェア部会では、約60の形式知を集め、記述し、それらの体系化をはかろうとした。要求分析から、運用・保守に至る大まかな開発フェーズ、これである程度の分類ができるよね、ということは皆合意した。これを「時間軸」と呼んだ。もう一つ、どのような「軸」があるのだろう、と、かなり長い時間かけて議論し、いろいろと試してみた。結局、ひとつの視点に絞り込めなかった。そこで、我々が作成した『形式知集』は『複数』の目次を持っている。目次は、形式知を分類し、並べ替えた項目を示したものであるから、正しく「軸」を意味している。使う状況、読み手のレベルによって異なる目次を参照することになるのだろうな、という想いからである。

日本品質管理学会 http://www.jsqc.org/

Vol.11 2010年 8月号 目次へ1. 品質へ3. SQuBOK®へ

ソフトウェア品質のホンネ
SQuBOKソフトウェア品質体系ガイド
セミナー
SQiPセミナー
SQiPセミナー開催レポート
研究会
ソフトウェア品質管理研究会
シンポジウム
ソフトウェア品質シンポジウム
資格試験
ソフトウェア品質技術者資格試験
JSTQB 認定テスト技術者資格
国際会議
世界ソフトウェア品質会議
ASQN
ニュース
SQiPニュース
webマガジン「QualityOne
コミュニティ
ソフトウェア品質確証部長の会(東京)
ソフトウェア品質保証責任者の会(大阪)
SQiPコミュニティ
SQuBOKユーザーの会
SQiP SIG
SQiPアーカイブ(研究成果や実践事例集
SQiPライブラリ
ソフトウェア品質管理の宝箱
調査・研究
ソフトウェア品質実態調査
調査・研究
ソフトウェア品質実態調査