私は１９８２年に今の会社に入社し、当時のソフトウエア工場「検査部」に配属され、いわゆる受託開発ソフトウエアの「検査」をやっていました。設計部署が開発／テストしたソフトウエアを検査員が改めて独自に設定した検査項目に沿って検査し、その結果で出荷の合否判定をする、というのが仕事です。

その後、会社の方針により「検査部」から「品質保証部」と組織が改名され、仕事の重点も「検査」から上流での品質評価へ移っていくとともに評価対象もプロダクトそのものからプロセスへと変化しました。現在ではＰＭＯとも密に連携し、プロジェクトのリスク分析の段階から関与するようになりましたし、対象もソフトウエアだけでなく、システム運用などを含む「ＩＴサービス」まで拡がっており品質保証活動における「検査」のしめる比重は少なくなってきています。しかし我々の根底にあるものは「検査マンとして悪いものは絶対社外に出さない」という検査マインドであることは今も変わりはありません。

このように、品質保証技術者に必要な技術・スキルは時代とともに縦方向（下流から上流へ）、横方向（ソフトウエアからシステム、さらにサービスへ）と拡がってきました。

仕事の主流が検査であった時代は、テスト技術が主要なスキルであったものが、対象が上流に移ってくると例えば、構造そのものの良し悪しも評価できなければならない、ソフトウエアエンジニアリングに関する造詣も深くなければならないし、リスク分析手法についても理解してなければならないなど、大変な時代になったものです。

もっとも、それらの領域はそれだけでもひとつの本が書けるほど奥が深く、またその領域のエキスパートもいるわけで、それはそういったエキスパートの人たちにお願いすることにしてもいいわけです。それでは品質保証技術者に求められるもの、他に譲れないものは何かというと、

• 品質評価技術
• 問題発掘能力

ではないでしょうか。

テストにせよ、レビューにせよ、監査にせよ何らかの検証活動から得られた情報から現在の、また将来予測される問題を推定すること、これがすべての品質活動をドライブする起点になります。この品質評価技術は品質保証技術者にとって不可欠のものと言えます。

さらに重要なのがその評価結果から実際に有効な品質改善アクションを起こす実行力であり、またステークホルダに行動を起こさせるコミュニケーション能力かと思います。

どんなに的確に品質評価を行い問題を分析できても、それらが実際の改善に結びつかなければ企業に働く品質保証技術者としては何の意味もありません。品質保証技術者はステークホルダーの理解を得て、彼らに改善に向けての行動を起こしてもらうように働きかけなくてはいけません。

テクニカルスキル以外の

• 行動力
• コミュニケーション力
• 交渉力

といった、いわゆる　ヒューマンスキルとかビジネススキルとかいった技術や能力が大切だと思います。

それでは、そのようなものはどのようにして獲得していけるのかというと、そういったスキルは教えて身に着くものではありません。たくさん仕事をして実践を通して多くの経験を積むこと、ステークホルダーと一緒になって汗をかくこと、失敗の苦さを知ってそれを乗り越えようと苦労した経験があること・・・が必要です。

本来、人は自ら成長しようとするものだと思いますから、育成とは即ち成長の機会や場を提供するということだと考えます。ここでは、私の職場で取り組んでいることをいくつか紹介したいと思います。

私の所属するカンパニーでは、カンパニーの組織としての品質保証本部があり、その下に金融とか公共とかビジネスドメイン対応の品質保証部があります。

2009年から本部内の各組織のコミュニケーションの活性化と共通的な課題への対応のために組織横断でのプロセス改革活動を始めました。その活動の大きな柱の一つに「QAスキル向上WG」があり、人財育成と組織活性化をテーマに活動を推進しています。（ここで「人財」と表記していますが、コンピタンスの源泉は人であり、人こそが財産、ということで私の職場では「人財」と表記するようにしています）

WGメンバーは、若手から管理職まで幅広い層から構成し、大きなテーマはトップダウンで与えるけれども具体的な課題の抽出や解決策については現場主義でボトムアップで検討するようにしています（このような活動それ自体も、育成の場となっていると言えます）。

図1は、このQAスキル向上WGの活動ロードマップです。
先に述べたように、テクニカルスキルだけでなくマインドやビジネススキルに重点をおいたものとしています。

ビジネススキルの獲得のために、またテクニカルスキルについてもより深み厚みを持たせるためには「経験」が必要ですし、失敗の経験から得られる教訓には教科書からは得がたい知見や洞察が含まれています。このような経験を共有し、擬似体験することで経験値を上げていくことが重要と考えます。

失敗事例の分析と再発防止策を報告する「落穂拾い」や品質改善事例を紹介する「テクニカルフォーラム」はそのような場となっています。

さらに自らの考えをまとめ、表現し、ステークホルダに理解してもらう実践的な訓練の場としてSQiPなど「社外発表」の奨励や合宿形式での「VALUE-UP研修」などを開催しています。

また、従来あまり積極的ではなかった特許活動ですが、品質管理ツールなどを題材に特許活動を進めることにより、より広くＩＴ技術への知見を広げる機会になるかと考えています。

「QAスキル向上WG」では、品質保証技術者に求められる望ましい行動規範を「QA10か条」にまとめ、毎年、この10か条に照らした技術者自身の行動についてのアンケート調査を実施しています。図2は2011年度のアンケート結果です。

「専門能力と知識」に関する行動の改善が必要と自己評価する技術者が半数を超えています。初めに述べたように品質保証技術者に必要な知識の領域は非常に拡がってきているため、専門領域に対する不安が現れているものと思われます。これに対応するために品質保証技術者に対してもＩＴＳＳを活用したスキル評価を試行し、強化すべき専門領域について技術者自身と上長が共通認識を持つように努めてもらうとともに、品質評価技法など品質保証技術者にとって重要なスキルを強化するために、社内共通の教育カリキュラムに加えて品質保証部門で独自のカリキュラムを開発しています。

技術者の育成とは「成長の場を提供する」ことだと思います。教科書を読んで得られる知識は、各自が自己啓発で努力すべきことです。ただしスキルは実践を通して磨かれていくものでそのためには経験を積むことが必要です。職場で組織として考慮すべきは、ケーススタディやワークショップ、業務の成果報告会など若い技術者が経験を共有する場をなるべく多く持つようにすることではないでしょうか。また、スキルだけでなく、時代とともに変化していく中にあって、検査マンとしての品質に対する執念、マインドを継承していくことを忘れないようにしたいと思います。

これまでの２年間SQiP研究会の分科会（注）で研究員と向き合って、問題の分析や課題の掘り出し、解決方法を考えるといった活動をやってきました。その活動のなかで、彼らは大きく変化し成長していくのを目の前で見てきました。 今回は、SQiP研究会分科会における活動の意義や、その活動のなかで研究員がどのように変化し、成長して行くかということを紹介します。

• 注：ソフトウェア品質管理研究会（URL: http://juse.or.jp/sqip/workshop/index.html）のメイン活動で、希望の研究テーマごとに分かれて指導講師と共に該当テーマについて深く検討、討論する。２０１１年度は６つの分科会と３つのコースがあり、筆者は第6分科会 派生開発の主査を務めている。

2009年にSQiP研究会の分科会に「派生開発」という部会が新設されたのを機に、当時の主査の足立氏から私に手伝って欲しいということで声がかかりました。その頃、私は「派生開発」という呼称で「XDDP(eXtreme Derivative Development Process)」という方法を中心にプロセスの改善活動をしていました。これがSQiP分科会との関わりの始まりです。但し、SQiP研究会の分科会活動についてよく知らなかったので、最初は「アドバイザー」という立場を用意してもらいました。

SQiP研究会には「分科会」と「演習コース」の２つがあり、分科会は終了時に「論文」を書くことになっています。私としては派生開発の場面における問題に対して技術的なアドバイスはできると考えていましたが、分科会の進め方や論文の指導はやったことがなく、１年目は主査、副主査の皆さんの指導を横で見させてもらいました。そうしてお手伝いしているなかで、私自身が若い頃に情報処理学会の論文を真似て、論文らしいものを書きながら問題を解決してきたことを思い出したのです。「30年前の自分自身の行動がこんなところに繫がってくるんだ」というのがそのときの感想でした。

派生開発の領域で生じている問題を解決するためのヒントになればということで、「派生開発」の分科会では最初に４〜６時間を使って「XDDP」の説明をしています。

あるとき、課題抽出を経てその対応方法を検討するなかでXDDPの「部分導入」が検討されました。XDDPを導入する際に、それまで私自身は「変更要求仕様書」「TM(Traceability Matrix)」「変更設計書」の「３点セット」の「一括導入」を勧めてきました。部分導入となると、現状の成果物とうまく繋がらなければなりません。

それまでの私のコンサルティングのなかでは部分導入で成功した事例がなかったので、思いとどまらせるべきかどうか一瞬とまどいました。この時の主査である足立氏も、チームが部分導入を検討していることに対して不安な様子で私の顔を見ました。足立氏も私の本を読んでいて一括導入が頭にあったようです。

チームは今、私の目の前で部分導入の方法を検討しています。思いとどまらせるのであれば「今」止めなければなりません。 彼らがボードの前に集まって議論している様子を見ながら、

• これまで私自身がコンサルティングの場で見てきた組織は、「統制」とはほど遠い状態であり、なかには無法地帯に近い組織もありました。そのような状況では「部分導入」してもまともに繋ぐもの（プロセスや成果物）がなく、一括導入しか選択肢がない。
• それに対して、分科会の彼らが所属する現場は、たしかに派生開発に対して不適切なプロセスに起因する問題（バグなど）は出しているものの、作業そのものは標準プロセスの下でしっかり統制がとれている。そういう状況であれば部分導入も可能かもしれない。

と考えるに至りました。

彼らはXDDPに対する先入観もなく、自分たちの所属する現場へのXDDPの導入障壁を低くするために部分導入を検討したわけですが、逆に、私のほうがそれまでの経験から先入観を持っていたことに気付かされました。

たしかに、コンサルティングの場で目にするのは、どこも同じように混乱した状況でした。でも、現実に派生開発の問題の解決に取り組もうという組織は、すべてがそのような混乱した状態とは限らないわけです。

SQiP研究会の分科会の活動は、月に１回程度の定例会があり、そこでは顔を合わせての議論ができますが、普段はML（メーリングリスト）を介しての議論になります。論文作成の詰めの段階になるとチームで１日に５０通前後の添付ファイルを伴ったメールが飛び交います。これをレールから外れていないかチェックするだけでも大変です。ただし、MLでの議論に慣れていない人は，最初は戸惑うようです。

直接、顔を合わせての議論は、慣れていることもあってやりやすいようです。自分の考えの表現の仕方によって論点が外れる兆しが見えたときは、その場で表現し直すことができます。何よりも、メンバーの意見を聞きながら考えを整理し修正することもできます。

MLではこうはいきません。お互いの表情は見えませんので、文章での表現がキツくなったり、正面から反論されたりするとカチンときたり、落ち込んだりするかもしれません。でも、ここで冷静に対応することを覚えます。また、Aさんのメールに対してBさんとCさんがそれぞれの意見を同時に返信することも起きます。そのような場合は調整には余分な時間が必要になります。

でもMLだからできることもあります。それまで発信された意見はすべて文字の形で手元に残っていますので、メールを読み直して真意を汲み取ったり、メールをさかのぼって相手の考えの流れを確認したりすることもできます。何よりも、相手の文章をしっかり読み込んで、その上で自分の意見をきちんと文章にしてから発信することができます。

このようにMLを使っての議論には一長一短ありますが、これをうまく使いこなすことは、これからの研究活動には重要な手段になりますので、SQiP分科会の活動を通じて、これに慣れていくことは役に立つはずです。

「分科会」は、最終成果物として「論文」の形にまとめることになっています。ところが、ほとんどの人は会社に入ってから論文というものを書いていないと思います。研究職に就いていないかぎり、業務のなかで論文を書く機会はないでしょう。

初めてSQiP研究会に参加する人のなかには、ここに来ると自分の回りの問題の解決方法（解答）がもらえると思っている人はいますが、最初は困惑することでしょう。自分で身の回りにある問題を集めてきて、それを何らかのキーワードで分析し、そこから取り組む課題を抽出して解決策を考える・・・。という作業に取り掛かるなかで、分科会の活動の意味がわかってくるようです。

SQiP研究会分科会の活動のなかで手に入れるのは、「論文的思考」を使って問題を解決する方法です。もちろん、現実の問題を解決する方法は手に入るのですが、取り組みのテーマはメンバーの「共通項」になるため、それぞれの人にとって解決したいことの一部分にならざるをえません。

それでも、問題を解決するための思考や取り組み方は手に入ります。これらは汎用の技術であり、これを手に入れておけば、いつでも応用できるものです。これこそがソフトウエア技術者として生きていくための重要な汎用技術なのです。現実に、このような技術を身につける機会は、SQiP研究会の分科会以外にはほとんどないでしょう。

（論文を書くことの効果については「Quality One 8月号」で述べましたので，ここでは省略します．）

日常の業務をこなしながら、SQiP研究会分科会の課題に取り組むのは容易ではありません。自分１人での研究活動であれば、とっくに挫折してもおかしくない状況であっても、SQiP研究会の分科会活動としてそれぞれの分担を決めて研究活動を進めるというなかでは、勝手に「や〜めた」というわけにはいきません。これが歯止めになって活動を支えるのです。

ここで重要なのは「１日の時間の使い方」です。カール・ヒルティの「幸福論」（岩波文庫）の最初に「仕事の上手な仕方」という節があり、その冒頭に次の文章が書かれています。

原著は1890年代に書かれたものですが、内容的には今でもほとんどそのまま通用します。つまり、時間の使い方や仕事の上手な仕方というものは時代を超えたテーマだということです。そしてヒルティはこれを征することが「幸福」に繫がるというのです。

私は、この「技術」は一種類ではないと考えています。たとえば、先に触れた「論文的思考」で問題を解決する技術もこれに含めてよいでしょう。ヒルティは、この本の少し先に「時間のつくり方」という節を設けていて、そこには時間を作り出す汎用の方法が書かれています。もちろん今でも使えます。智的活動（知的活動）をする人にとって共通しているのは、これらの技術は時代を越えて有効な技術だということです。

ところで時間は余りませんね。あれば全部使ってしまいます。家計のやりくりと似ていて、天引きという手段を使わない限り簡単には貯金は溜まらないのと同じように、時間も先に取ってしまわないと余ってくれません。

現実の問題として，多くの人は次々に発生する問題の対応に追われています．それは必要な知識や技術の習得が不足した状態で業務に就いているためです．そうした状況で発生する問題に対処しながら、同様の問題を発生させないための方法（技術）を手に入れなければ、人生のすべてがバグ潰しで終わってしまいます。

このようななかでSQiP研究会の分科会の活動をするには、たとえば１時間か２時間、最初に分科会の活動に使ってしまうことです。そうすれば現状の業務には残りの時間で対処する方法を考えざるをえません、このとき「今でも時間が足りないのに」という思いとの戦いが生じます。もしここで後退すれば、混乱している業務への新たな対応方法は手に入りません。でも、ここで踏ん張れば、それまでとは違った対応方法を引き出すことができるでしょう。

ここで問われているのは、その状況にあって新たな工夫を生み出せる可能性を持つ自分を信じることができるかどうかです。 SQiP研究会の分科会活動では、もしかするとこうした選択を迫られることになります。人生のなかで「自分を信じるかどうか」という選択に遭遇することは何度もあるものではありません。（まさに人生のドラマがそこに展開するのです）

SQiP研究会の分科会では、こうした場面を乗り切って、ほとんどの人は「時間の使い方を変える」ことに成功しているのです。それは彼にとっては単に時間の使い方が変わったというだけではないはずです。

私はアミエルの次の詩が大好きです。

　心が変われば　態度が変わる
　態度が変われば　習慣が変わる
　習慣が変われば　人格が変わる
　人格が変われば　人生が変わる

分科会の活動のなかで、課題の整理から問題の解決方法、さらには論文の作成にわたって、分科会のメンバーは休日も関係なく毎日夜遅くまでメールで意見をぶつけ合います。そこでは、お互いの性格や考え方を意識しながら自分の意見をぶつけていきますが、それでも意見の違いが表面化することがあります。

実際、自分の考えに対して「いや，私はむしろこう考える」と真正面からボールが返って来ることがあります。日本人は職場で意見をぶつけ合うといった経験が少なく、多くの人はこの場面で戸惑うようです。

職場のなかであれば、単に「考えが合わない人」として対応すれば済むのですが、一つのテーマで研究活動をするメンバーとなればそうはいきません。自分の考えの方が優れていると思う時は、相手を説得する方法を考えたり、メールを読み返して妥協できるところを探がしたりします。

「論文」という形にすることが課せられている状況では、ここを避けて通ることはできません。そうして彼らは一回りも二回りも成長するのです。そうして、みんなでゴールテープを切ったとき、彼らは「チーム」から「クルー」に変わるのです。SQiP研究会の分科会活動が終了しても、このクルーのメンバーはこの先も交流が続くはずです。なかには個人的に協同で研究活動を続けることも考えられます。

SQiPは「Software Quality Profession」の略ですが、この「Profession」はただの「専門家」という意味ではありません。聖職者、医者、法律家の３種類の専門家を指します。つまりそれぞれの領域での高い専門技術の他に、強固な倫理観を求められているのです。そこにソフトウエアの（品質）技術者も参加できるように、というのがSQiPの理念です。

でも、知識や技術が不十分では、倫理観や職業観を維持するのは容易ではありません。このことは、過去においていろいろな領域での専門家が犯した過ちからもわかることです。

私が40年前にこの世界に戻ってくるときに、日々の行動指針として「大学」から引用した「格物　致知　誠意　正心」は、SQiPが目指す「Profession」と通じるところがあると思っています。
そして、この分科会の活動のなかで、彼らはその階段を登ることになるのです。
（「格物　致知　誠意　正心」については８月号をご覧ください）

今回は、私にとって「論文を書くこと」あるいは「論文的思考」が、どれほど役に立ったかということについてお話しします。この論文的思考によって今の私が存在しているといっても過言ではありません。その有効性、そして重要性を分かっていただくために、まずは私の最初のつまずきと、そこで出会った「論語」と「大学」の文章からお話しします。

私の最初の3年間は、多くが失敗の状態でした。顧客の要求を捉えきれず、でき上がったものはあちこちで顧客の求めるものとは違うという状態でした。「新しい時代」に憧れてこの世界に入ったものの、現実の厳しさに挫け、「自分はこの仕事に向いていない」と啖呵を切って、一度はこの世界から離れました。

弁解がましくなりますが、当時は数人の仲間が集まって仕事を融通しあっていました。オフコンのようなものは一人でも対応できますが、コンピュータのメモリーが大きくなると、稼働日までに必要なシステムを開発するには何人かで手分けすることになります。仲間の中では「失敗」の状態は程度の差であって、私だけが失敗していたのではありません。それでも私の場合は、最初の「憧れ」が強すぎたのでしょうか。私としては「失敗」の状態を解決できないまま仕事を続けることができませんでした。私の「ソフトウェアの世界での第1歩」はこうして惨憺たるものでした。

1年間まったく別の世界にいて、そこから戻るきっかけになったのは、半年程経った時に「論語」を読んで下記の記述を見つけたことでした。

もともと漢文は好きな領域でしたし、私たちの世代は「論語」は人生に迷ったときに読む本という認識を持っている人が多かったと思います（もちろん「儒教」というレッテルを貼って嫌う人も少なくないですが）。論語の中にこれを見つけたことで、自分は本当に「力足らざる者」なのか、を確かめるためにソフトウェアの世界に戻ることにしたのです。

そう、私は道半ばで倒れたわけではありません。まだ生きているのです。あのとき「自分にはこの仕事は向いていない」と啖呵を切って抜けただけだったのです。私の中に3年前の「憧れ」は消えていなかったのでしょう。

戻るにあたって日々の行動のガイドラインとしたのは「大学」の以下の節です。

一般には「天下を平らげるにはまず自分の国を治め・・・」と後ろから解釈するのですが、ここでは簡単に前からの解釈を紹介しておきます。

物のあるべき姿をただし、知るべきことを極める。そうすれば誠意を貫けるし、心も正しく維持でき、自分の身を修めることができる。そこまでくれば、家がととのうし、国を治め、さらに天下を平らかにすることができる。
（ちなみに、斉家から平天下までが同時に達成するという解釈もあります）

私は、この最初の「格物 致知」を自分の置かれている状況に合わせて以下のように読み替えました。

「格物」すなわちソフトウェアの世界の有るべき姿を知って、「致知」すなわち、それに必要な知識や技術をすべて手に入れる。そうすれば、「誠意　正心」すなわち行動は誠に背かないし、お客さんに心正しく対応できる（ようになる）、と。

一度撤退した者としては、「大学」のこの1節を信じるしかない状態でした。当然ですが保証はありません。そのためにも、とにかく「格物　致知」ということで、すべての時間をそこに投入しました。

今の若い人たちの中には「大学」という本があることすら知らないかもしれませんね。でもここで出会った「格物　致知　誠意　正心」は、この後の私の人生に決定的な役割を果たすことになります。人生とはそういうものかも知れません。

復帰後、「格物　致知」ということで、手に入る文献は片っ端から入手して、毎晩仕事が終わってからアパートの部屋で夜中の2時頃まで自習しました。この状態が約３年続きます。しかしながら組織に属していないため新しい技術などで単行本になる前のものが入手できません。雑誌といっても、内容的にしっかりしたものは「bit」という雑誌ぐらいでしたので、それだけでは不足しているという不安を埋めることができません。

また、大手の企業には組織の中に先輩たちが残した知識や技術がありますし、直接話しを聞くこともできます。でもフリーで活動している者にはそうした知識や技術を手に入れることができません。時々、客先で目にしたものをお願いして借りて帰るぐらいです。今日のようなインターネットのない状況では、このハンディはとてつもなく大きなものでしたし、私自身「このままではマズイ」と「危機」を感じていました。「格物 致知」にならないのです。

この不利な状態をどうカバーするかということで、あるとき情報処理学会の論文誌を見つけ、読み始めたのです。当時は情報処理学会の会員ではなかったので、近くの書店にお願いしてオーム社から取り寄せてもらいました。その他、客先によっては電気通信学会の論文誌が置いてありました。この雑誌にもソフトウェアに関する論文が書かれていることがあり、それを見つけて借りて帰りました。これが私と論文との最初の接点です。

当時、私の回りの人でそこまでやっている人はいなかったのですが、私自身、一度躓いてこの世界から撤退しており、二度は失敗できないという状況にあったことと、復帰する際に「格物 致知」を腹に決めていたことによって、「致知」の一つの実現手段として、論文を読むというところに繫がったのでしょう。論文を手に入れて読むということには何の迷いもありませんでした。

当時、手に入る単行本は片っ端から入手して読んでいましたので、それで十分と考えることもできたかもしれませんが、復帰前に「大学」を読んでいたことで、それだけでは「致知」にならないと考えたのです。実際、まだ「そこ」に知るべき「場（領域）」があるのですから。もし事前に「大学」を読んでいなかったら、この時点で論文を読むことはなかったでしょうし、そうなると今の私はなかったと思います。

いや、自転車操業でボロボロになっていたかもしれません。実際、フリーで仕事を続けるのは決して楽なことではありません。そんな中で、「営業しない」という方針を貫くことができ、しかも一度も仕事が途切れなかったのは、やはり「格物 致知」の効果であり、そこから発した「論文を読む」という行動のお陰だったと言えるでしょう。

こうして論文を読んで、その構成に沿って理解した範囲で要約をまとめていました。そうして論文を読んで要約をまとめていると、論文の構成が

「abstract — まえがき — 現状分析 — 課題抽出・・・」

と共通していることに気がついたのです。

■ 現状分析

• まず、現状を分析して問題を整理します。この時、データが収集されます。
• 集めたデータを原因などの特徴で分類して選択しやすいように整えます。

■ 課題抽出

• 整理された問題から、解決の優先度が高いものや効果の大きいものを選択します。
• 選択された問題を、取り組みやすいように「課題」として形を整えます。
• このとき、問題に繫がったと思われる原因の分析が行われます。

■ 対策の選定

• 推定されている原因に有効がありそうな技術を探したり、既存の技術を組み合わせたりします。
• この時、関連した課題を扱っている論文や文献を調べることになります。
  関連しているものがあればそこでの対応方法が参考になります。
• 今回の課題に適したものがなければ、それまで経験してきた中から新しい対応策を考えることになります。

■ 対策の選択と実施

• そうした対応策の中から良さそうな方法を選んで、実際に取り組むためにプロセスなどの環境の整備を行い、その上で実際に取り組みます。

■ 検証と考察

• 取り組んだ結果を検証し、当初の課題がどこまで解消したか検証します。
• 結果のデータ計測は、事前の現状分析のときにやった方法と基本的に同じです。
• 解決しなかった課題や、部分的に解決しなかった事象を確認して、継続取り組みとします。
• この時、今回の取り組みをベースに、さらに工夫して対応することになります。

さらに、この論文の構成が、まるで物事が解決していく階段のようで、読み手の私にとって心地良さ、リズムのようなもの感じたものです。同時に、この構成が問題を解決する思考のステップであり実践のステップになっていることに気付いたのです。

（このステップは、いわゆる「QCストーリー」とほぼ同じですが、当時の私にはそのような知識は持ち合わせていません。直感的にこのステップが問題を解決する、と感じたのです）

この種の論文は、基本的にそこにある問題を解消する、あるいは軽減するための取り組みが行われ、その経緯が記述されています。そこから、自分の回りにある問題もこれで対応すれば良いのではないか、と考えるようになりました。

当時、私の回りにあった問題としては、

• 顧客要望を掴みきれていない
• 見積もりの精度が悪い
• 開発途中の仕様変更が多い
• バグが思った以上に出ている

といったものでした。

実際問題として、ソフトウェアの開発現場にはいろいろな問題が溢れています。これらの問題の解決が遅れれば遅れる程、問題が新たな問題の原因になったり、問題が絡んだりして複雑になり、解決の糸口が見えにくくなります。

これとは別に、新しい設計技術などが提案され、文献の形になって出てきます。ソフトウェア開発に関する技術には、モジュールの分割尺度のように、ほとんど知っているだけの状態でも役に立つものもありますが、設計手法のように「習熟」が必要な技術も少なくありません。そして「習熟」が必要な手法は簡単に習得できるものではありません。

そこで考えたのは、このような身の回りにある問題の解決や新しい文献に書かれている技術の習得にこの論文の構成が使えるのではないかということです。

最初は、不足しがちな知識や技術を補充するために「論文を読む」ことを始めたのですが、ここにきて自分の問題を解決するために「論文を書く」、あるいは新しい技術をしっかり習得するために「論文を書く」という段階に進むことになります。

論文を書くといっても学術論文を書くわけではありません。自分の回りにある問題を課題として捉え、それを一つずつ解決していくために論文を書くわけで、いわゆる「経験論文」のようなものです。「ようなもの」というのは、私自身はこうして書いた論文は正式にはどこにも提出していませんので、第３者の査読を受けていません。もしかすると「論文」と言えるものになっていないのかも知れません。真っ赤に訂正されて送り返されたかもしれません。

それでも、私の回りにあったバグは大幅に減少します。また見積もりの精度が上がったことなどの効果からスケジュールの遅延も直ぐに解消します。仕様の書き方が安定することで、途中で発生する仕様変更などの問題も片っ端から片付いていきます。

こうして、レビュー技法や、見積もり技法、スケジューリングなどの他、リスク管理や構造化手法もこの方法で入手してきました、また「一人レビュー」やクリーンルーム手法（のマネごと）に取り組んだときも、そして最後のプロジェクトの一つ（このとき2つのプロジェクトを並行）で取り入れた「Review lessによる開発」のときも、論文の形にしながら考えた方法を検討し、取り組み方をシミュレーションしながら実施してきました。

私の場合、問題を整理して課題として抽出する際に「原因」を仮定します。「問題」は症状として見えていますが、それが起きるのは何が原因だろうか、と考えるのです。何かができていない、何かを間違えているからこの問題が発生しているのではないかというように「因」と「果」で捉えます。こうすることで、取り組みの方法を選択する時点で、この「因」に対して効果がありそうな方法を選択しますので、結果は70～80％改善するのです。

この「因」と「果」で捉える方法は、後にリスク管理でも活用する方法を考えました。リスク管理では、この考え方の他に「USDM(Universal Specification Describing Manner の略。 仕様がモレない表現方法として筆者が開発したものです)」の表記法を応用して対応する方法を、やはり論文の形で実施し、効果を確認できています。

こうして課題に取り組みながら論文の形に整理することで、そこで取り組んだ方法が確実に身につきます。また論文の「形」に残していることで、その上に「未解決事項」への取り組みの工夫がやりやすくなります。さらに、数年後にこの方法が使えるという時に、引っ張り出すこともできます。

こうして結果的に20～30歳代の間に30数本の論文（らしきもの）を書いてきました。もちろん、40代にも数本書いています。その効果は、

• バグの発生率は「0.1／KLOC以下」（単体テストを含む）
• 22年間納期遅れなし、仕様トラブルなし
• 組み込みシステムの時代は週35時間しかメインの顧客に投入していない
• 健康に何の問題もなし

という結果に現れていると思っています。

1996年から提供を開始した「硬派のホームページ」（URL: http://homepage3.nifty.com/koha_hp/）は、当時「文字の青木ヶ原」と呼ばれていました。そこに掲載したコンテンツのネタは、こうして書き溜めた論文（らしきもの）や、いろいろな場面で書き溜めた「対策メモ」が元になっており、それを文章に作り直したものです。

そして今、SQiP研究会でこうしてお手伝いするというところにも繫がっているのです。

【お知らせ】
次回のQuality One（#16）では、続編としてSQiPでの研究会の活動の意味や、そこで論文を書くことの効果について書く予定ですので、ご期待ください。

なぜ「勉強会」を開催するのが「学ぶ」事に繋がるのか？疑問に思われる方も多いと思います。

ふつう、学んだ後に催すものではないのか。

実は「勉強会」でいちばん「勉強」になるのは講師です。まず、多くの人の前で自分の考えや、その場にいる全員の貴重な時間を使って達成したいことを明確にしなければなりません。次に、講義の途中でなぜこれを教えているのか、どうしてこういう教え方になるのか、を論理的に説明できなければならず、最後に、受講者の素朴な、思いがけない質問に回答できるだけの一段上位の理解と考察を、前もって準備しておく必要があります。これだけの要件を、明確に示された日時までに満たすための「学び」は特に効率面において他のどんな方法にも勝るのではないかと私は考えます。

　一点、この「学び」に失敗すると参加してくれた方に多大な迷惑を掛けてしまう点において非常にリスキーな方法ではあります。しかし、成功すれば自分自身の学びと参加者への知識の伝達という大きなリターンを達成できます。ただ、経験的に、期限とゴールと参加してくださる方々が具体的にイメージできる状況で「学び」に失敗する事などそうそう有りません。一見ハイリスク・ハイリターンのように読めますが、リスクの方はほぼ100％自分でコントロールできる種のものです。今回は通り一遍のリスクをコントロールできると確信できたのでさらに、私がこういうセミナーが欲しい！と常々考えていた形式にトライしてみました。要件は以下のとおり。

(1) ワークショップ形式であること/参加者が具体的な成果物を持ち帰れること
(2) 講師と参加者が一緒にリアルタイムで成果物を作り上げていくこと
(3) 参加にあたって条件となる開発技術経験のハードルは極限まで下げること

開発入門講座ですので、成果物は実際に動作するアプリケーションになります。最初に講義、次にライブコーディングでそれを実演、参加者がそれに倣う、という形式で、通常想定される数倍のチェックポイントを設けることで講師も含めた参加者全員が同期をとりながら一歩一歩進めるような形を目指しました。実際にはこの参加者全員が同期を取る、というのはとても困難である事が容易に想像できましたので、講師の他に躓いた参加者をフォローして頂く補助の講師に数名ご参加頂きました(宮田さん、津田さん、渡辺さん、加藤さん、東さん、早川さんに感謝です。また、前述の参加者からの思いがけない質問に私が対応できないときも、左記の方々に助け舟を出していただきました)。ワークショップ形式では必ずつまずく方がランダムに発生しますので、ここのフォローアップをどう設計するかが非常に重要なポイントとなります。全員止めてその間に雑学や細かい部分の解説で場を繋ぐ、とりあえず先に進んで次のチェックポイントまでに補助の講師にお任せで追いついてもらう、などの手法があります。

社内外を問わず、私が講師として何か技術やノウハウを伝えるときに特に気を付けている点として、

(1) その技術やノウハウで何が/誰が、なぜ嬉しいのか？を論理的に伝える
(2) 今何をやっているのか、全体の中のどんな位置にいるのかを本当にしつこく、くどく伝える
(3) 世の中の8割の人が同意してくれるレベルで簡略化する。2割の嘘はいとわない

があります。特に (2) は有識者や他の講師の方からすれば本当にくどいので、同席されると眉をひそめられるかも知れませんが、私自身がおよそ有史以来最も鈍い「勉強会」参加者であった経緯からして、こと「わかりやすさ」というパラメータを重視するにはこの方法が最適と信じています。当日はこの講義スタイルでトレードオフになる「スピード」を考慮のうえ、7時間というかなり余裕を持ったタイムテーブルを組みました。結果としては何とかギリギリある問題を解決できる最低限のアプリケーションまでは全員たどり着く事が出来ましたが、想定していたゴールの60%の位置で時間切れとなってしまいました。残り40%がとても楽しい部分だっただけに本当に悔やまれます。次回で必ず挽回したいと思います。ゴールインできていないので明らかな失敗なのですが、散会後に数名の参加者の方から「わかりやすさ」について評価頂けたのは嬉しかったです。

「勉強会」を主催するとき、テーマ以外に何が必要でしょう。ひとつは催しそのものを引っ張る役の人。これは講師であったり、発表者をアテンドする司会であったりその形態は様々です。今回のように、主催者が講師を兼ねる例も少なくありません。ひとつは催しの告知方法。これに関してはここ1、2年でウェブ上の告知、スケジュール管理ツールが充分に実用レベル、かつ気楽に使えるようになってきましたので、現在ではほとんど問題にならないかも知れません。Twitter も自分と興味を共有している人と繋がっているという点で、とても強力な告知ツールでもあります。

テーマも決まり、講師の段取りもついていざ告知、という段になって立ちふさがる最後にして最大の壁が、会場です。最低でも10人程度が集まれて、プロジェクターは必須、マイクや可能であれば参加者が自由に使える無線LAN環境も欲しい。となると、都内の貸し会議室では2時間で数万円という額になってしまいます。企業に所属する方であれば次に考えるのが自社設備の利用ですが、これも会社によって実現性に大きな差があり、空間はあってもその入退室管理、ネットワークの分断など主にセキュリティ上の事由により却下されてしまう場合が多々あります。例外として、既にある一定以上の知名度のある方が主催する場合、主に外資系の企業が会場を提供してくれる例もありますが、そういった方は「勉強会のつくりかた」という段階ではないでしょうから、私たちの参考にはならないでしょう。

現状、この問題に対する解決策は 2+1 つあります。

(1) 「勉強会」に理解のある企業に勤める知り合いに会場確保を依頼する
(2) 地域の施設や大学、特定技術の推進団体に相談する
(3) オンラインでやってしまう

ひとつめの方法を採るにあたっては、ニフティ株式会社様による「＠nifty エンジニアサポート」が現状最高のサービス形態であると言えます。主催者が自社(ニフティ)社員である必要がなく、設備面でも一切の抜かりなく、前述のものに加え動画配信用の機材まで完備しています。正直、これを最初に見たときには「やられた！」と思いました。IT企業における最大の資産が人であるなら、自主的に「勉強会」を催したり、そこに足を運んだりする層の技術者に自社の名前を知ってもらう、よい印象を持ってもらえることを思えば、入退室管理やネットワークの分断に掛かるたかだかの投資など、年間を通して人材獲得に掛けているコストと比べても無視できるレベルではないでしょうか。さらに、夜間や土日、祝日の会議室はいわば「遊んでいる土地」であり、管理費用や土地代だけを無為に浪費しているとも言えます。これを有効活用しない手はなく、むしろここまで思い至ればやらないほうが不思議です。大きな会議室をお持ちの企業の特に人事や広報のみなさまには、是非一度ご検討を頂ければと思います。

ふたつめは催しものを安価にあげるのに古典的かつスタンダードな方法です。地域の公民館や区民ホールなど、専業のサービスに比べると費用面で大きなアドバンテージがあります。しかし、手続きの煩雑さや詳細な制約事項(使えるコンセントの口の数など)が、特に機器を多く用いるIT系の勉強会には不向きな面も否めません。もし伝手があれば、大学や推進団体に所属する方に相談して、場所を提供してもらうほうが設備面や制約事項の面で有利でしょう。また、いささか裏技的ですが、”同じような催し物を開催した事のある人に聞いてみる”という手もあります。案外、こちらのほうが先方ものってくれてスムーズに話が進むかもしれません。

最後の方法を +1 とした理由は、まだ前述のふたつの方法ほど確立された手法ではないから、です。そもそも場所を必要とせず、設備や参加者全員が各個に準備、そしてブロードバンド環境さえあれば誰でもいつでも主催、参加できるこの方法が確立できれば、今後の「勉強会」手法の主流になり得る可能性を秘めているのですが、この手法は致命的な欠点もはらんでいます。それは参加者同士の交流が薄れてしまうことです。「勉強会」は受講やディスカッション、ワークショップを経て自分の技術力を向上させられる事が本義ですが、散会後の歓談の時間や、懇親会での交流によって新たな人的ネットワークが形成される点も見逃せないメリットです。この点を上手く解決できるようなインフラまたはやり方の模索をはじめています。

以上、Android開発入門や社内/社外勉強会のほんの少しの主催/講師経験と、数多の参加者経験を踏まえて、私なりの「勉強会のつくりかた」をご案内いたしました。いまさら私に言われるまでもなく、凄まじい速さで変化する環境に対応するため、IT技術者は常に学び続ける事を強いられる職業です。いえ、どんな職業でも学び続ける事は必要なのでしょうが、ことIT技術者においてはその必要性が顕著でわかり易いように感じます。しかし、本来学びとは発見であるなら、発見をし続けることができる職業であるとも言えるでしょう。せっかく、こんなに面白い職業に就いているのですから、ふとした疑問や発見を独り占めせずにみんなで共有することで、その喜びを何倍にも広げてみてはいかがでしょうか。

何か問題にぶつかったとき、何をしますか？　先輩や上司に聞く？　インターネットで調べる？　それもいいですが、私は、こんなときこそぜひ専門書を読んで調査してほしいと思います。自分の抱える問題が、有史始まって以来、初めて発生した問題だなんてことはほとんどあり得ません。間違いなく先人に同じ問題を抱えて、解決した人がいるのです。それを利用しない手はありません。

私が自己育成で最も効果があるのは何かと問われたら、本を読んで自分の頭で考えることを挙げます。読むだけでなく、自分の頭で考えて消化し、自分の意見として説明できるようになることが重要です。私はソフトウェアを専門に勉強したわけではないので、会社に入ってソフトウェアの仕事についたとき、本を読んで勉強するしかありませんでした。私が入社したころは、まだ日本語のソフトウェア工学の専門書は少なかったので、専門書を読むようになって数年もすると、たいてい見たことがある本ばかりになりました。ソフトウェアの本はこれくらいしかないのかとわかって驚いたことを覚えています。今は、ソフトウェアの本がずいぶん増えて、むしろ良い本を選別する能力の方が重要かもしれません。いずれにしても、本を読んで自分の頭で考えることくらい、自分の成長に役立つことはないと思います。なにより、知らないことを知るのはとてもわくわくすることだし、なるほどと納得することはとても楽しいですから。そして、それを単に読んで楽しむだけでなく、自分の頭で考えて、自分のものにすることがとても重要です。心から納得すると表現すればいいでしょうか、自分の頭で考えるというのはそういう感覚です。

こんな当たり前のことをわざわざ書くのは、ソフトウェア領域でこのアプローチをしている人がそんなに多くないと思うからです。たいていの場合、人海戦術や腕力で切り抜けようとしていると思います。「がんばります！」と体力で勝負する方法ですね。なぜでしょうか？　専門書を調査して問題を解決するという経験がないのかもしれません。いつも徹夜してがんばり通してなんとかしてきたから、それが当たり前になっているのでしょうか。これは、業界として危惧すべき事項だと思います。私達がそんなことをしているから、ソフトウェア技術者は５Kとか１０Kとか言われてしまうのです。

先日、JaSST東京の基調講演で、リー・コープランド氏が、「最近読んだ専門書を教えてくださいと聞いて、専門書は読んでいませんと答える外科医に、手術してもらいたいと思いますか？」という表現で、本を読むことの重要性を話しておられました。確かにそうです。専門書を読まないエンジニアといっしょにソフトウェア開発の仕事をしたいとは思いません。みなさん、本を読みましょう！

ＮＥＣには、その昔、ＳＷＱＣと呼ぶソフトウェア開発の小集団活動がありました。SWQCでは成果の論文発表が義務付けられていて、それが形骸化の一因となり、いったん活動を休止した経緯があります（現在は、コミュニティという形式で残っています）。それでも、私はＳＷＱＣ活動で学んだことは多かったと思います。

その理由は、論文を書いて発表することが義務付けられていたので、仕事の区切りがつくたびに、自然と自分の考えを文章にまとめ、人前で発表する経験ができたからです。文章にして自分の考えをまとめると、取り組んでいたときには正しいと思っていても、論理的な矛盾や不足があることに気がつくことができます。文献調査の必要性を実感したのもこのころです。自分一人で考える工夫には限度があって、先人の経験を取り込んでそれに自分の工夫を重ねる方がより良い成果が得られるのだと実感しました。また、人前で発表することによって、論理的に説明するだけでなく、わかってもらえるように話すことの難しさも学びました。

私が論文を書くことを勧めるのは、自分のこのような経験に基づきます。でも、実際に書いている人は少ないですね。時間がないのはわかりますが、時間の有無は関係ありません。要はやる気です。ただし、文章にまとめることが未経験だと、何をどうしたらいいのか、最初のきっかけがつかみにくいかもしれません。そういうときは、論文募集している団体の論文執筆サポートを利用しましょう。ちなみにSQiPソフトウェア品質シンポジウムにも論文執筆サポートがあります。ぜひ利用してみてください。

実際に書いてみれば、書くことの難しさと重要性に気がつくと思います。ちなみにパワーポイントでは同じ効果は得られません。きれいな図でごまかされて、できたような気がするだけです。口数の多い人は、プレゼンでごまかしてしまうかもしれません。プレゼンの能力と、文章で論理的に記述する能力は異なります。自分で説明してまわれる範囲は限られるのですから、読んでわかるように書くことができなければ、広く自分の意見を理解してもらえません。読んで理解できるように文章を書くことが出来ない人は、技術者とは言えないと私は思っています。

QiPにソフトウェア品質管理研究会というのがあります。入社したてのころ、私はこのSQiP研究会へ1年参加させてもらいました。SQiP研究会では、1年に7～8回の終日かけた研究会が開催され、ソフトウェア品質に関連するテーマについてグループに分かれて研究し、最後にはグループで論文にまとめて発表します。さまざまな会社の方が参加するだけでなく、その領域の有識者がグループを指導してくれます。私にとって、社外に出るという経験はこのSQiP研究会が初めてでした。たしか、メトリクスをテーマに選んだ記憶があります。そのときの指導役は忘れもしない、保田先生（日立製作所（当時）、つくば国際大学（現））と堀内さん（日立製作所（当時））でした。SQiP研究会には合宿もあるのですが、当時は箱根の小涌園が合宿会場でした。その小涌園での議論の光景は、今でも目に焼きついています。保田先生と堀内さんには、今でもお付き合いしていただいています。1年かけた研究はとても良い経験になりました。なにより、社外の方と話ができたことが良かったと思います。自分の困っていることや考えていることが他社の人に理解してもらえるのか、他社も同じようなことを悩んだり検討したりしているのか、自社にない新しい試みをしている会社があるのか…等々、多くの刺激を受けました。なにより、社外の人に社内の用語は通じないというあたりまえのことを、実感したことが忘れられません。自分の仕事さえうまく説明できなかったときのことは、今も恥ずかしさとともに思い出します。相手にわかるように説明できる能力というのは、実はとても高度な能力なのだと思います。社外での交流は、その練習の場にもなります。当時は、ソフトウェア関係のシンポジウムもほとんどなく、他社の方と交流できるような機会はとても少なかったので、私にとってSQiP研究会は貴重な経験でした。手前みそになりますが、自分自身の体験から、SQiP研究会はとてもお勧めの教育コースの一つです。

業務が忙しくて、なかなか社外に出る機会は少ないかもしれませんが、会社を休んでも社外の集まりに参加し、社外との交流を持つことは、間違いなく自分を磨く貴重な場になります。ソフトウェア関係のシンポジウムなどは、何年か続けて通うといいと思います。各専門領域の主要なプレーヤーがわかるようになるはずです。主要な人物はそれほど多くないことがわかると思います。また、そういう集まりに参加する人達とも顔見知りになると思います。そういう人たちとの関係が重要なのです。困った時に助けてくれる良き友になると思います。私自身は、社外のお友達にどれだけ助けられたかわかりません。会社と会社はどこでつながっているかわからないし、お互いお客様であり同時にお客でもあるわけで、ビジネスの場面で顔を合わせることもしばしばあります。そんなとき、事前に必要な情報を入手できるかどうかは、実質的にはともかく、精神的には大違いです。特にトラブル対応のときは背景も含めた情報量がものを言います。私は、社外のネットワークが業務で直接役立つようになるまでに、20年くらいかかりました。役立てようと思って顔見知りになったわけではないですが、最近ひしひしと社外ネットワークの重要性を感じています。20年我慢（！）してお友達で良かったと（おそらくお互いに）思うこのごろです。

社内でも社外でも、人的ネットワークを作るには、宴会が一番です。最近は、社内のイベントでも、学会やシンポジウムなどのイベントでも、併設してお酒が出る交流会が開かれることがしばしばあると思います。それにはぜひ参加すべきです。そこには、ネットワークを作りたいと思っている人がたくさん参加します。皆、交流を求めて参加するのですから、人的ネットワークを作るのに最適です。

私は、まわりの人に必ず社外の宴会には参加するように言っているのですが、なかなか参加してくれません。なぜでしょうか。業務が忙しいから？　イベントの日は残業がないのだからそんな日くらい早く帰りたい？　おもしろくなさそう？…。理由はいろいろあると思いますが、ここは騙されたと思って、設定されている宴会には必ず参加してみてください。 お酒の席でしか聞けない話が必ず出てきます。私は、自分の人的ネットワークは、ほとんど宴会の席で作ったと思います。なんというか、お酒の席は、本音が出ますよね。きっとそれがいいのだと思います。私もきっとずいぶん好き勝手なことを言ったと思いますが、それで信頼関係を作ったことも多いと思いますよ。

また、お酒の席で重要なことが決まったりします。人事とかね。私は、自分の転機になる大きい仕事が宴会の席で決まった経験があります。どうも、指示する側も、宴会の席でもないと私が引き受けなさそうだと考えたようなのですが、私も、宴会の席でなければ、エイヤで引き受けることはなかったと思います。それは、2年もかかる大きなプロジェクトでした。その時のことを思い出すたびに、言う側も受ける側も勢いが重要なときがあるなあと思います。こんなふうに、宴会は様々な変化を生む場なのです。

私が人前で話すときに事前に自己チェックする点は、言いたいことを一言で言えるかどうかです。その講演で伝えたいことを一言で説明できるか、各スライドで言いたいことを一言で説明できるかを確認します。一言で説明できないときは、自分の中でその内容を整理できていません。たとえば、スライドで何行にも渡って説明しているようなときは、ほとんどＮＧです。ああでもない、こうでもないという自分の頭の中でぐるぐる回っている混乱状態が、そのまま書かれているだけです。文章を書く場合でも同じです。各章での主張を一言で説明できないときは、結局何を言いたいのかわからない文章になってしまいます。

私が他の人のスライドや文章をレビューするときも、そういう観点でまずチェックします。ですから、スライドの場合は一目見ればすぐに混乱しているかどうかわかりますね。タイトルが一言で表現されているか、中身がぱっと見れば目に飛び込むように表現されているかということです（これは決して、デザインとか色調の問題ではありません）。文章もしかりです。技術系の文章はそれほど難しくなくて、書くべき条件が揃っていれば、たいてい主張はわかります。

皆さんにお勧めしたいのは、常に自分が言いたいことを一言で言えるかを確認することです。それができれば、言いたいことが伝わらないということはなくなるはずです。自分の頭の中が混乱しているのか、整理された状態にあるのかも自覚できると思います。整理された状態であれば、議論の焦点は、お互いの主張を認められるかどうかに絞られるので、議論の時間は最小限で済みます。議論が長時間に及ぶのは、当事者が言いたいことをわかっていない場合が多いのです、お互いに何を言いたいのかを知るまでに時間がかかってしまいます。言いたいことを知るために、根掘り葉掘り聞くので時間がかかり、結局わかってみると、時間をかけて聞くほどの価値はなかったりするのです。自分が整理された状態にあれば、反論されても素直に受け止められるはずです。主張の違いが明確にわかるので、冷静に対処できるようになります。逆に相手のほうが混乱していると気がつくこともあるでしょう。実に生産的な時間を過ごすことができるようになります。

私が自己育成として重要と思うことをまとめました。参考になれば幸いです。私たちは、出来上がってしまったら、もう店じまいするしかありません。まだ若いのに、一丁上がり状態になっている人を見かけます。一丁上がり状態というのは、自分はあるレベルに達したと勝手に思いこんでいる状態と表現すればいいでしょうか。勝手に偉い先生の立場になってしまい、回りの指導ばかりしている人です。評論家のような発言は並べ立てるものの、自分では何一つ実行できません。とても残念ですし、回りにとっては迷惑です。これは本人の意識の問題です。もっと知りたい、もっと自分の好奇心を満足させたいと思う限り、私たちは成長するものだと信じています。いつまでもそういう自分でありたいと、心から願う次第です。

以上

WACATEは参加者と実行委員、講師、サポーターの皆様、たくさんの良き先輩方達の手厚い協力と支援で成り立っています。皆様のご協力・ご支援に感謝の気持ちでいっぱいです。本当にありがとうございます。

2.1	運営の工夫 WACATEは参加者だけでなく、実行委員、講師役など関係する全員が、それぞれの立場で学ぶ「場」とするために様々な工夫をしています。 【参加者(若手)】 WACATEは”大規模勉強会”です。セミナーではありません。 参加費は2万円以上、開催は土日です。そして参加者には前もって参考書籍を読んでいただくなどの予習を求めています。これには、以下の効果があります。 覚悟を決めてもらう 参加した効果を高める こういったものは「自己を啓発する」という行為そのものです。 WACATEは”参加者である若手が主体的に勉強をする「場」”なのです。 また、ワークショップ当日はそれぞれ地域、経験、考え方等が異なる参加者を５名程度のチームとして、同じ題材・目標を共有してワークショップのゴールを目指して取り組んでもらいます。 異なる意見や考え方を調整して課題を進める過程で、チームワークや新しい考え方、ノウハウを学びつつ、新しい”人的ネットワーク”を形成するきっかけを獲得します。 当日、参加者(若手)は以下のものなどを持ち帰ることができます。 意識の高いベテランの皆さんからの貴重なアドバイスや豊富な知識 講師陣からの情報 同世代の人間の中での自分の立ち位置 図1.立ちあがって議論をする参加者の皆さん 【参加者(ベテラン)】 ベテランの参加者も毎回10名ほどいらっしゃいます。ワークショップではベテランの皆さんもベテランとしての立場で学びます。そこでは異なる経験を持った若手技術者達とのディスカッションによって自らの経験を言葉として表現し、伝える必要があります。そうすることで自らのノウハウを再定義、再整理をでき、それは理解を深めることに繋がります。また、若手技術者に任せ、ミスリードをしないようにアドバイスをすることで、勢いのある技術者を動かすことを学びます。 ベテランは以下のものを持ち帰ることができます。 教育/指導のためのヒント 若手が悩んでいること/悩みやすいこと 世の中の若手はどのようなものか 自分に足りないものは何か 図2.参加者(ベテランと若手)による積極的な議論の様子 【実行委員】 実行委員は”若手が主体的になるための教育や運営”について考え、実運用を行う過程で、テーマ・題材の内容を深く理解するとともに、「主体的に勉強をできる仕組み」を学んでいます。 本コラムのテーマは「人材育成」ですが、実はWACATE実行委員会は積極的に人材育成を行っているわけではなく、人材が自ら育つ「場」を企画し、提供しているにすぎません。 休日返上で打ち合わせやコンテンツ作成にあたり、ときに素晴らしい先輩方から貴重なアドバイスを得ながら「場」を作り上げる――それはとても貴重な経験であり、とても有用な勉強になります。一流の先輩方との交流、対話は素晴らしい経験です。 実行委員は以下のものを持ち帰ることができます。 看板を背負い、責任を持って仕事にあたる経験 2万円以上という大金に見合ったコンテンツを作り上げる経験 すばらしい先輩方との交流や貴重なアドバイス 自らのモチベーションアップのきっかけ
2.2	WACATEの目指す場所 図3.ミニ地球儀 WACATEの特徴として、ポジションペーパーセッションがあります。 参加者が自ら記載したポジションペーパーを使って意気込みや悩み、現在の考えなどを交えながら自己紹介をするセッションです。ポジションペーパーは冊子にして参加者に配布され、参加者全員に見える形となります。 そして参加者は「最も素晴らしいポジションペーパー」に投票を行い、最も投票数が多いポジションペーパーを記載した参加者には「ベストポジションペーパー賞」が贈られます。「ベストポジションペーパー賞」の受賞者には「賞状」及び「地球儀」が贈呈されます。 この「地球儀」は、実行委員たちが選んだ「WACATEの行く先」を示しています。 「若手技術者がWACATEを経て世界へ羽ばたいて欲しい。」 そんな起点となる場所になれたら素敵だな、と運営側は望んでいるのです。 ほんの少しの勇気を持って敷居を跨いだその先には、きっと世界が待っています。

3.1	参加者からみたWACATEの特徴 参加者視点として、特に目立つWACATEの特徴にコミュニケーションの活発さが挙げられます。 例えばWACATEではセッションの多くがグループワーク形式となっているほか、分科会という、参加者・運営者・講師が入り混じって好きなように語り合うセッションが毎回用意されています。またセッション外では、ビール片手に話す機会、温泉につかりながら話す機会等が定番として確保されます。そして年2回のワークショップ外でも、WACATE-SNSや、ミニイベント(Short Short)といった学習・交流の手段が公式として提供されています。 一方、これら豊富なコミュニケーションの場の上に、参加者も合宿勉強会に参加するぐらいモチベーションの高い方々が集まってくるので、WACATEではセッション内外でテスト談義や技術者交流がかなり活発に行われるようになってきます。
3.2	WACATEの魅力 この活発なコミュニケーションは、ワークショップという枠を超えた「学習の場の広がり」や「学びの深まり」という、WACATEならではの魅力につながっていると感じます。 まずワークショップでは、チームメンバー間で議論を深めたり、エキスパートによるインタラクティブなアドバイス・支援を受けたりできる環境のおかげで、良い相乗効果か実現され、学習効果がより深まるようになっています。 また、ワークショップ後は、WACATEのイベントやSNSをハブにして、様々な勉強・交流の機会が派生し、ワークショップを超えた学習の場が次々に拡大しています。最近ではWACATEのワークショップに付随して、前夜祭、後夜祭、予習会、復習会といった関連イベントが開催され、WACATE参加メンバーが中心となった勉強会や読書会も結成されています。
3.3	WACATEが築いた「場」と「流れ」 こうした学習の場の広がり、学びの深まりがある点で、WACATEで得られる学習効果は、他では得がたい高さを持っていると実感しています。 私自身、参加者・講師の方とのコミュニケーションや指導で形成された「場」を通して、テストへの理解は当然ながら、貴重な気づきやテスト観(例えば体系的な知識や、座学では中々得られない実践上のノウハウ等）を得ることができました。またソフトウェアテストについての勉強仲間や継続的な学習機会も得ることができ、自分の知識・視野の穴を補完しつつ、継続的に勉強を進める良い流れに身をおけるようになっています。 さらにWACATEでは場の広がりの中で大小様々な場や機会が生まれているため、「（WACATEが構築した）場に依存する者」から「場を構成する者」となり、そして「場を支える者」にもなるというステップアップの流れが形成されていると感じています。私自身、WACATEが生み出している流れに乗っかる形で活動の幅を広げ、今では実行委員としてWACATEに参加するまでになりました。

振り返ってみると、元々狭い領域での業務改善に興味を持って参加したWACATEでしたが、WACATEを通して得ているものは、その当初の目的以上の広さ・深さをもつものでした。これからもそうした魅力的な場を構成する一員として、WACATEに関わっていきたいと考えています。

運営側の思い、参加者側の思い。それらはふとしたところに現れます。

• 「ディスカッションのときに腕組みをやめて他人の意見を傾聴しているとき」
• 「ディスカッションのときに自分の意見を曲げて他人の意見を受け入れたとき」
• 「ディナーセッションのときに隣の人と酒を飲みながらテストの話をするとき」
• 「分科会で真面目に、けれども笑顔で語り合っているとき」
• 「集合写真で笑顔のままポージングをするとき」
• 「終了後も宴会や勉強会で交流をするとき」

これらは全て、運営側の思いと参加者側の思いが交錯するときに見せるキラキラした瞬間です。成長をした瞬間であり、成長をしているシグナルでもあります。
インターネット上に参加者からのレポートも沢山上がっています。
是非、ご覧ください。きっと彼らが「自分で自分を育成している様子」を感じることができるはずです。

またそうした思いの交わりは、WACATEという大規模勉強会の枠を超えて拡大しています。
最近ではWACATE参加者が中心となって、ワークショップ形式を取る勉強会が続々と実施されるようになりました。そこではまた運営者、参加者(ベテランと若手)が協力しながら、WACATEさながらに学びの場が今もなお整備されています。

WACATEは主体的に学ぶ心構えを持つ人達が様々な立場でコミュニケーション豊かな場に集まり、係わり合いを通してさらに加速しています。その楽しさは、他ではなかなか味わえないものです。

さて、数ページに渡ってWACATEについてご説明させていただきましたが、いかがでしたでしょうか。なんとなくWACATEについて興味をもって頂けたなら幸いです。
「WACATE2010 冬 ～温故知新～」を2010年12月18日（土）～19日（日）の日程で、神奈川県は三浦海岸、マホロバ・マインズで開催します。興味のある方はぜひWACATE-Webサイト(http://wacate.jp/)をご覧ください。最初に記載したとおり過去のWACATEのダイジェスト動画などもありますので、WACATEの雰囲気などについてもイメージが湧きやすいかと存じます。
また、WACATEは今後も継続して開催していく予定でおりますので、ご都合が合いそうな際には、是非ご参加いただければ幸いです。そこには心地よい疲れと、笑顔と、たくさんの同志が待っています。皆さんもそれぞれの立場で、何かを感じ、気付き、もぎ取ってみませんか？
それでは、皆様とWACATEの会場でお会いできることを楽しみにしております。最後までお付き合い頂き、誠にありがとうございました。

図4. 終了時恒例のWACATEポーズ。皆さん笑顔でそれぞれの「次」を目指します。

日本のソフトウェア産業における主たる生産物は、大きく分けると二種類あるといえるだろう。一番目は、特定の企業の、特定の業務を自動化、省力化、効率化するために開発される受注型業務システムである。これらは、紙媒体の帳票が物理的に部署間を移動しながら、様々な情報が付与されたり、承認されたり、モノが動いたりしながら進められている実際の業務を、完全に、あるいは大部分コンピュータのソフトウェアに置き換えるものである。もう一つは、様々な機械の中にあり、メカニズムやエレクトロニクスの制御を行ったり、簡単なユーザ・インタフェースを提供したりする組込みシステムである。一昔前の自動車では、アクセルペダルを踏み込むと「物理的に」キャブレターの燃料噴射量が変化していたが、いまどきの車では、アクセルペダルは単にボリューム操作のための特別なインタフェースに過ぎず、その踏み込み量を数値化した上で、燃料噴射量を制御している。

多くの開発プロジェクトでは、単純に既存の業務をソフトウェアに置き換える、あるいは物理的なメカニズムをCPUとセンサーからなる制御システムに置き換える、というだけではない。一定の投資を行うからには、単純に省力化、効率化、自動化するだけではなく、何らかの付加価値を与えることが多い。つまり、従来の業務では存在しなかった、あるいは、やりたくても現実的とは言えなかった、何らかの機能や業務が付け加えられていることがほとんどである。

このような開発においては、いくつかの独立した能力が開発者（と発注者）に要求される。

• １） 発注者が自動化・システム化を望んでいる業務・対象の理解と記述
• ２） 発注者が実現を望んでいる「夢」の理解と記述
• ３） 記述された業務や「夢」を実現するシステムの設計
• ４） それらのシステムを実現するためのコストなどの見積もり
• ５） 限定された期間とコストの中で、どこまで業務や「夢」を実現させるか、発注者との交渉
• ６） 合意されたゴールを、定められた期間とコストで実現するための技術とマネジメント

従来ソフトウェア工学、あるいはソフトウェア科学として研究対象となってきているものは、上記の３）、４）、及び６）である。１）や２）も対象となっているが、実世界の本質的非論理性が、その解決を難しくしている。５）は実際のプロジェクト・マネジメントでは極めて重要なポイントだが、ソフトウェア工学などの文脈でまともに議論されていない。

「実世界の本質的非論理性」について、簡単に触れておこう。例えば、獲得した要求仕様の矛盾を示すことは数学的・論理的に可能である。しかしながら、獲得した要求仕様が、現在の顧客業務を正確に反映しているかどうかを数学的・論理的に立証することは、そもそも不可能である。よく使う例なのだが、ある金融機関で「お得意様を優遇します」と言っている。お得意様は誰か？　何を、どの程度優遇するのか？　これらを聞きとって紙に書き留めたとしても、本当にそのように実際の業務が行われているのかを「論理的に」確かめる手段はない。支店長決裁で「お得意様」認定された顧客もいるだろう。いままでの取引履歴から、一定条件を満足しているにもかかわらず「お得意様」認定されていない顧客もいるだろう。全て「明文化」したルールに基づいて業務を運用しているところは、実はあまり多くない。全てが「明文化」されているわけでもなく、実際の運用ではルールと相反する決定がなされることもあり得る。

それでも発注者は、ありのままの業務を、そのまま自動化したい（もちろん、システム化するにあたって「業務改善」を行う場合もある）のである。特にエンタープライズ系のシステムの場合、どこまでもこのような「実世界の本質的非論理性」がついてまわる。発注者が自らの業務に対して最適化しようとすればするほど、このような問題はあちらこちらで出てきてしまう。しかも、このような「人が『恣意的に』決めたルール」は、極めて簡単に「変わる」。ビジネスの都合、競争相手との差別化、様々な要因が、これらのルールを簡単に過去のものにしてしまう。お金を取れるかどうかは別にして、これらに付き合っていかなければならない。

一方、組込み型システムの開発の場合、相手はもう少し「モノ」寄りであることが多い。このような開発の場合、実時間という制約が問題となることが多い。例えば、自動車エンジンの燃料噴射制御では、おおよそ0.1秒ごとに燃料噴射量を計算しなければならない。しかも一気筒あたり、である。限られたハードウェア性能のもとで、高機能化によって設置された様々な種類のセンサーからの情報を集めて、である。

ソフトウェア開発には、このように、いくつかの「難しさ」がある。現実に、日々進められているソフトウェア開発を的確に行うためには、様々な「知」が必要である。いろいろな教科書もあるが、ほんとうに困ったとき、いざという時に役に立つ「知」は体系化されていない。したがって、教育や伝承も極めて困難である。JSQCソフトウェア部会では、それらの「知」を集め、体系化を試みるプロジェクトを２年ほど前から始めた。その活動の中で私が得た「気付き」をお話したい。

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

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

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

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

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

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

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

議論の結果『メイン目次』とされたものの表題のみを示す。

（１）	物事の真実・原因をつかむ方法を考えたい （ア）現地現物 （イ）原因分析 （ウ）レビュー
（２）	対象をモデル化して問題解決の方法を考えたい （ア）システム化対象のモデリング （イ）開発プロセスのモデリング （ウ）組織設計のモデリング （エ）モデル化と推定
（３）	人に動いてもらう方法を考えたい （ア）コミュニケーション （イ）育成 （ウ）仕組み

現在のソフトウェア開発に置いて重要な「知」は、以下のような三種類に大別できる、というメッセージだと受け取って欲しい。

１）問題解決（日本的品質管理の考え方・実践）
２）モデリング
３）人

開発対象が硬いか柔らかいかにかかわらず、日本的品質管理における問題解決の考え方や実践は、極めて重要だ。どうもソフトウェアの開発をされている方達は優秀なひとが多いようで、話を聴いて、頭の中で思考実験をして、簡単で有効性がはっきりしたものだけを「やってみたいな」と思う、そういう方が多い気がする。地道にデータを集めるなどというようなことは、どうも苦手ではないだろうか。そのくせ、どこかの雑誌の特集などで「次世代のなんとか」というような特集を見ると、すぐに飛びつく。ちょっと試してみて、直ぐに効果が出ないと、さっさと諦めて次を探す。

もう一度「事実に基づく」という言葉を考えなおしてみて欲しい。これは、「事実」と「感想」が常に分離できる、ということだ。そして、「感想」を裏打ちする「事実」を集めるのではなく、「事実」を説明する「仮説」を懸命に探し出す、という態度だ。一般的に優秀な技術者や管理者は、ある「事実」を見つけると、その「事実」の原因となる問題を、過去の経験などから即座に引っ張り出し、その「原因仮説」を補強する「事実」だけを集めて眺める、という極めて厄介な癖を持っている。これはおそらく、人間そのものが本質的に脳の中に持っている思考パターンだ。それがいつでも自在に使えるからこそ、あまり世の中が変わらないという前提では、問題解決能力が高い優秀な人、と周囲から思われる。このような人は、未知の問題に出会ったときに、いきなり破綻する。しかし、その時には結構偉くなっていることが多いので、その発言には権威があり、組織全体がその破綻にお付き合いすることになってしまう。もう一度「事実に基づく問題解決」を学び直して欲しい。

モデリングに関しては、様々なソフトウェア工学の教科書を、まずは勉強して欲しい。我々が集めた「知」は、その上手な使い方、である。

最後は「人」である。最初の方で述べた「実世界の本質的非論理性」に対処するためには、「人」のコミュニケーションの質向上しか方策がないように思える。コミュニケーションにおける「記号（＝文字や言葉）のやりとり」と「情報・知識のやりとり」を、もう一度考え直し、研究する必要がある。「あれ、よろしく」という一言で、相手が全てを理解し、こちらが期待することをすべてやってくれる、というのはいったい何故なのか。どうすれば、そのような関係になれるのか。逆に、そのような関係にないことを「お互いが理解する」ためにはどうすればよいか。どのようなコミュニケーションの作法が必要とされるのか。

ある人から尋ねられた。「一緒に飲みに行く」ことが有効だということは皮膚感覚的に分かるし、いろいろな人も言っている。では「一緒に飲みに行かない」ときでも、同じような効果を上げるためにはどうすればよいのか、と。私たちは、二つの方向から問題を解かなければならないのだろう。「仕事の文脈で、どうすれば『仲良く』なれるのか」という方法論、そしてもうひとつは「『仲良し』でなくても良好なコミュニケーションを維持する」方法論である。特にオフショア開発の問題などを考える上では、真面目に後者を考える必要がある。

近年の開発では、業務が細分化され、それぞれ専門性が高まってきているが、同時に「これは自分のこととは関係ない」と、他者の経験を「学ぶ」姿勢が希薄になってきている。これは想像力が欠如しただけなのかもしれないが、忙しい現代の開発者に対し、自分にとっての問題であると興味をもたせることが極めて重要である。また、体系化されていない「知」をどのように「教える」のかは極めて難しい問題で、「経験しなければ分からない」というだけでは物事の解決にはならない。

一般的な教育の理論では、新しい事柄を教えるときに、生徒側の情報処理が多ければ多いほど、定着しやすい、と言われている。目で追うよりは、声を出して読む、それよりはノートに書き写す、というように、同時に多くの情報処理が行われる方法のほうが、記憶に定着しやすいということである。最も脳を活発に使うのは「考える」ということだ。何かを教えたいと思ったときに、どうすれば生徒に「考え」させることができるか、が教える側のポイントとなる。

人材育成では、「自分で考えることができる」という目標を立てて欲しい。「考える」ためには「知識」が必要だ。家を建てる時のレンガのようなものだ。しかし、多種多様なレンガを持っていたとしても、家はできない。それらを組合せ、場合によっては加工し、手元にない場合は漆喰を固めて応急的な塊を作ることも必要だ。知識を組合せ、場合によっては仮説を立てることもあるということだ。

それらを組合せ、構造を築かなければならない。その構造がいい加減なら、すぐ崩れてしまう。論理的な思考が極めて重要、ということだ。その前に、そもそもどのような家を立てるのか、事前にイメージできていなければダメだ。言い換えれば、どのような問題を解決しようとしているのか、目的が見えていないと論理を組み立てられない。

最後のメッセージは、結局「考えろ」という言葉になった。普段の暮らしでは、あまり考えなくても済むようになっている。脳は、そのように、多くのことを習慣化して省エネ、はやりの言葉で言えばエコなのである。しかし、新しい状況や問題に直面したときには、「習慣化された行動」だけでは解決できない。その時には一気にエネルギーを投入して「考える」しかないのだ。その時には大量のエネルギーを消費するかもしれないが、良い答えを得ることができたのなら、その後はまた省エネで進むことができる。

部下に「考える癖」をつけてあげること、これが最も優れた人材育成の方針ではないか、と思う。

今回部会でまとめた「形式知集」は、3MB程度のエクセル形式のファイルに仕上げた。目次からリンクをたどって、具体的な「事例」にたどり着くことができる。それぞれの「事例」には「小説」をつけた。イメージとしては、4コマ漫画の原作のようなもので、読者にとって「自分の身の回りでしばしば起きている出来事」のような印象を与えることを意図している。少し前に書いたように、ソフトウェア産業の人々は、黒船のご威光には簡単にひれ伏すけれど、隣人の経験談はあまり聞いてくれない、という危惧があり、少しでも興味を持っていただくためのきっかけを与えたかったからである。

この「形式知集」は、日本品質管理学会に入会し、その上でソフトウェア部会に参加することで無料で入手できる。ソフトウェア部会では、おおよそ1ヶ月に一回、会合を持ち、議論を進めている。現在のテーマは、いわば「遺言プロジェクト2.0」とも言えるもので、暗黙知の形式知化を見据えた活動を始めたばかりである。「学会」と聞くと、敷居が高いというような感覚を抱く方も多いようだが、極めて泥臭い話題で、わいわいやっている。部会メンバーの紹介であれば、一回に限り「お試し参加」ができる、という仕組みも作った。この原稿が公開されるのは8月の末ごろだと思うが、時期的にもちょうど良い。日本品質管理学会の「年度」は、様々な歴史的経緯から、10月～翌年9月である。今、入会申し込みをしていただくと、丸々一年間、活動に参加することができる。

それでも踏ん切りがつかない読者のために、「形式知」の一般公開版を差し上げることにしよう。「形式知」集がどのような感じのものなのかを知るために、3事例だけを掲載した「お試し版」である。掲載事例が3個しかないことを除けば、元の「形式知集」と同じ構造をしている。おおよそどのようなことが書いてあるのか、是非ご自分の目で確かめてみて欲しい。

興味を持ったら、ソフトウェア部会へご参加を。新しい人が一人加わることで、視野が広がり、議論の範囲も広がっていく。お待ちしています。

日科技連において今までのセミナーには無かった異色のトップガン教育が10月からスタートします。2月8日に行われた講演会では、先進的な企業の社内研修の事例と研修の進め方が紹介されました。ここでは、このコース企画の背景となったソフトウェア業界の人材をめぐる危機的な課題について説明します。

人材育成の指標となる「ものさし」として、独立行政法人・情報処理推進機構（IPA）のITスキル標準（ITSS）が広く使われています。ご存知のようにITSSでは専門分野ごとに7段階の度合いでレベルを表現します。スキル・レベルを定義するだけでなく、スキル分布の実態調査、すなわち「スキルの見える化」がIPAによって行われています。この調査は平成19年から始まり、21年度の調査の詳細は、5月に発行される「IT人材白書2010 ～岐路に立つIT人材 変革期こそ飛躍のチャンス～」に掲載されております。発行に先だって行われた、ソフトウェアジャパンの講演から作成したスキル分布のグラフを図１示します。

図1．スキル・レベルの分布　　IPAの調査より

Lev1・2 ： 実務経験に入って行くための準備期間
Lev3 ： 自立した仕事ができる段階
Lev4・5 ： 特定の経験分野において部下やメンバーに対して技術指導が出来る
Lev6・7 ： 企業内の上下関係が無くても影響力を持つ真のプロフェッショナル

図１で注目すべきは、高度な技術者であるレベル6・7の占める割合が極端に少なく、たった0.9％しか存在しないのです。しかも、少ないだけでなく、２年間で1.8％から0.9％へと激減し、日本のソフトウェア産業界におけるプロフェッショナルは絶滅危惧種「レッドリスト」に値する状況を示しています。この状況は、産業界や企業にとって危機的であり、絶滅危惧種と同様に回復不能域に入ってしまうと、自力で回復することは絶望的です。

人材の「質」が、製品やサービスの「質」に大きな影響を与えることは明白です。製品やサービスの「質」を見える化することは難しいのですが、その傾向を示すデータが、同じIPAの調査で示されています。それは、ITサービスを購入する企業が、提供側のベンダー企業のIT人材の質を評価した調査です。図２に示すように、「やや不足」と「大いに不足」が90％に達しています。

図2．ベンダー企業が評価したIT人材の質

日本のソフトウェア業界は、ハードウェア（ICやサーバー）や製品ソフトウェア（OSやアプリ）の多くが、グローバルな競争に敗れる中で、かろうじて生き残ってきました。現在まで生き残った原因は、競争が国内に閉じていたからであり、グローバルな競争優位性を持っているわけではありません。海外向けのSIビジネスの多くが苦戦し失敗している現実がこのことを裏付けています。日本の市場は、最近まで供給と需要がバランスしており、質より量を供給することによって拡大を続けてきました。仕事の量が多い一つの原因は、技術進歩とビジネス環境の変化が速く、システムや製品の陳腐を追いかける再構築と移行が続いているからです。

　ITサービスの生産モデルは、マンパワーをITサービスやソフトウェアに変換するものです。マンパワーには、スキルが必要なので頭数だけでなく、質が重要であり、人材の調達と育成が企業の存亡を左右することになります。従来の育成方式は、新人を雇用し、導入教育を行い、OJTと呼ばれる、働きながら育成する伝統的な方法です。少し複雑になりますが、人材育成と価値連鎖をモデル化して図３に示します。

ITサービスの特徴は、単純化すると人的資源をエネルギーとし、ほとんど原料を必要とせずサービスやソフトウェアを提供します。製造業が原料を製品に変換するのと比べ、大きな差があります。製造業の経営感覚で考えると、例えば人的資源を原料と読み替えることによって対比することができます。ただ、原料は長い期間の人材育成による熟成が必要ですし、熟成段階で技術が変化して陳腐化するリスクも生じます。

図３を使って、企業間の競争について考えてみます。ある企業が提供するサービスの質と量は、その企業が持っている人材のタンクによって決まります。量が不足する場合には、外注することにより社外から調達することも可能です。外注できるリソースは、競争相手の企業も調達できるので、その企業の本質的な競争力にはなり得ません。企業の競争力は、人材のタンクに蓄えられている人材の価値＝人財によって決まります。日本の企業は、終身雇用による長期安定雇用の下で、OJTによる人材の育成（熟成）を行ってきましたが、ITSSのレベル6・7に相当する高度な人財が0.9％しか育っていない事実から、この方式が、進歩の速いIT分野では機能していないことが明らかになったのです。

日本のIT企業では人材の価値連鎖が機能不全に陥っており、量とコストで優れる海外の競合企業は、ベンダーをバイパスし直接顧客へITサービスを供給する「中抜き戦略」を展開します。一旦、この流れが生ずると、資金の流れも変わり、流れから孤立した企業は、急激に衰退する悲劇的なシナリオが待っています。

図3．人材の価値連鎖と競争

今、何が人材育成に求められているのか、その結論は明らかです。現状のスキル・レベル３程度の人材を大量に育成する底上げ戦略では、図２に示すように、顧客にスキル不足と受け止められており、市場ニーズに合っていません。さらに、レベル３程度では、コスト的に海外との競争力を急激に失っています。育成への投資を増額して高度人材育成を行うことが困難な経済状況下では、先ず、経営層が戦略的なデシジョンを行い、プロフェッショナル育成を戦略的に位置づける必要があります。

図4．人材成長モデル：現在の育成とトップガン育成

図４の上図は、統計的なデータから推測した、平均的な企業の年齢構成とスキル分布を人材育成のトンネルとして示しています。入社からリタイアまでのスキル分布は、成長のスピードと、レベル間の変換率を示しています。課題は、上位レベルへの育成スピードが遅いこと、育成効率が低いことです。次の時代を切り開く、レベル6・7に成長する期間があまりにも長すぎ、育成効率（レベルを上がって行く率）が低すぎることが課題です。

高度人材育成の予算を増やしただけでは、次の時代に企業が生き残るための人財を育成できません。OJTとして職務を遂行する中で並行して進んでゆく従来の育成方法では効率が悪いので、合理的な別の育成方法を考える必要があります。

非効率の原因は「仕事を遂行する＝人が育つ」を唯一の手段とする古典的な育成戦略です。よって育成戦略を大きく変える必要があります。何故、レベル4・5からレベル6・7への進化が遅いのでしょうか。レベル4・5に大きな問題が潜んでいます。多くの日本企業は、部下やメンバーへの指導を職位に頼って行う傾向があります。そうすると、高度なスキルを習得するより社内人事評価、すなわち管理的な成果を求める傾向が強くなってきます。

それでは、現代において求められる高度人材育成について考えると、

① 早く育成し長く貢献する：30代後半にはレベル6・7に達成し、実務貢献の期間を長くする。
② 積極的な投資によるプル型の人材育成：従来の育成方法ではなく、良い指導と良い機会を与え促成する。
③ ビジネスへの貢献の高い高度人材：市場の変化に追従できる柔軟スキルを持つ。

などが考えられます。

IT技術者の人材育成は、３段ロケットで表すことができます。１段目は基礎知識と入門的な職場経験で、レベル1・2と3に相当します。順調に経験を積んで自分の担当範囲の仕事を達成することができます。２段目では、１段目とは違って他者を動かすスキルが求められます。他者に影響を与える範囲は経験と共に拡大しますが、点火するには良いリーダの下でのOJTが必要になります。２段目に点火して順調に成長することがレベル4・5に相当します。

最終段である３段目では、職務上の関係を超えた技術的な影響力が求められます。書き物であったり、設計書であったり、コンサルテーションであったり、その媒体は色々ありますが、上司－部下などの階層関係を超えて影響を与えることができるスキルです。２段目で、管理事務や上位の職位に流れ、軌道をそれると３段目に点火することは困難です。現在のITサービス現場で経験を積むことだけでは、３段目に点火出来ないのが現実です。

　昨年度にIPAが行ったIT人材育成強化加速事業報告（ http://www.meti.go.jp/policy/it_policy/jinzai/IT6.htm）の「CDP」の３章におもしろい調査があります。第一線で活躍されている方約９０名にインタビューし、技術者のリアルな姿や、成功・失敗段を調査したものです。多くのインタビューでレベル4・5の壁を越えるターニングポイントのようなものが語られていることからも、３段目が経験年数だけでは点火できない「何か」があることを示唆しています。

ハイレベルな人事育成は、知識教育では意味がありません。自分で考え、問題解決と他者への影響力、めげない意欲などが必要になります。我々は2005年からこの種の研修に取り組んできました。研修生が伸びるポイントは、

① 10年程度の経験を持ち、まだまだやる気のある技術志向の強い技術者を選抜すること
② この業界で現役として第一線で活躍しているお手本となる人に接し、考え方や生き方を学ぶこと
③ 自分の考えをまとめ、客観的なレビューを受け、私見ではないロジカルな思考を身につける

などが必要になります。図４の下に示した、トップガンのトンネルを設置することです。

１０月から始まるトップガン育成の研修では、なるべく少人数のゼミ形式で、事例など実際の多面的な問題について考え、自分の考えを組み立てる訓練を行います。ゼミの時間とは別に、研修生個別に対応して、課題の整理から企画書作成まで指導する方法です。2005年から昨年までで３社、のべ200名ほどの研修を行ってきました。その実績から、このトップガン育成のプログラムは、人材をめぐる危機的な課題の一つの解決方法だと考えております。

QuaSTom（高品質ソフトウェア技術交流会）はカスタムと呼び、ソフトウェアの高品質化を追求する会員が自主運営をする任意団体です。現在会員数は130名で、今年設立19年目を迎えます。会員はソフトウェアの開発技術者（エンタープライズ・組込み）、品質保証担当者、プロセス改善担当者、研究者など産学官問わず様々な立場、また年齢層の会員が参加し、ソフトウェア産業界における各種技術動向や会員が抱える問題解決のための研究活動を実施しています。本稿ではQuaSTomにおける"人財"の成長について、QuaSTomでの活動事例を交え紹介します。

組込み・情報システムを問わず近年、システムや製品の差別化を図るための多機能・高性能化要求に伴い、それを実現するソフトウェアがシステムや製品の価値を左右する重要な要素となっています。また市場競争の激化に伴い、開発期間の短縮や高品質・低コスト化、また絶え間ない新技術への対応要求もより一層高まっています。このような状況は、結果としてソフトウェアの大規模・複雑化、また開発プロジェクトの巨大化を招き、開発現場の慢性的な人材リソース不足を引き起こしています。

これを解決するために、各企業においても人材育成へのニーズが高まり、最近では各種スキル標準（ITSS/ETSS/UISS）を活用した技術者の育成・教育への取り組みも広がりを見せています。つまり「人」をモノづくりの元として用いる材料や資材としてではなく企業の財産、「人財」として捉え育成するという考え方（以降、人財と表現する）が広く浸透し、企業の財としての「人財」に対する育成・教育への関心が高まっています。

教育には大きく分け３つの実施形態があり、それぞれ教育の目的に応じ適切な形態を選択します。その代表的な形態として、講師と複数名の受講者が対面形式で講義を行う「講義型」、OJTやワークショップや演習に代表される「実習型」、通信教育やeラーニング等の「自習型」があります。ここで注目したいのは、各種スキル標準においても「コミュニティ活動」が上述の形態を補完する一つの教育形態として位置付けられている点です。つまり社内外のプロフェッショナルとの技術交流によって、あるいは産業界における標準化活動や若手技術者育成等の社会貢献を通じて技術者自らのスキル・知識を向上させる場としてQuaSTomのようなコミュニティ活動そのものが定義されているのです。これは、近年に見られる技術の進歩や情報流通量の増加と加速化に伴い、これまで社内にあった人財の成長モデルや情報を社外に求める傾向が強くなってきていることとも深く関係しているのかもしれません。

ソフトウェア産業界においても様々な形態のコミュニティ団体が存在しています。例えばLinuxに代表される特定の要素技術に係る研究や普及促進を目的とした団体、あるいは組込みソフトウェアの管理者・技術者育成を目的とした団体、ソフトウェアテスト技術者の情報交換や技術向上を目的とした団体等、様々です。いずれの活動も特定の職種や役割、また対象とする技術領域を明確に限定し、活動しているという点では共通しています。

このような数あるコミュニティの中において、QuaSTomは、「ソフトウェアの品質」という技術領域については限定していますが、職種や役割については限定していません。したがって、参加者も必然と広範囲に及びます。その中でQuaSTomの活動の大きな特徴は「ボランタリーな活動であること」、また「実践的な研究の場であること」です。ボランタリーというのは無償という意味ではなく、会員による自主的な活動が行われているということです。また研究活動の多くは高尚な理論ではなく、実際の開発現場で使える泥臭い実践的な研究と本音の討論が中心になっています。　

ボランタリーで実践的な研究活動を通じ、結果として技術者個人の成長に繋がる、それがQuaSTomでの人財成長です。以降では、コミュニティの運営側（幹事会）およびその活動に参加する技術者の視点から、コミュニティ活動における技術者の成長とその実際について、QuaSTomでの活動の具体事例を交えながら紹介します。

QuaSTomは会員の自薦・他薦によって選出された幹事が企画・運営を実施しています。幹事の主な役割は年7回の例会の開催と分科会運営の支援です。

QuaSTomの活動には大きく分けて２つの形態があります。まず年7回開催される例会では、毎回30～40人の会員が参加し、ソフトウェア品質に関連する様々なテーマについての講演会や会員による事例紹介が行われます。いずれも演習やワークショップ形式を加えた会員同士の討論が半分を占め、毎回熱い討論が活発に行われます。一方、月単位で開催される分科会では、毎回10～15人の会員が参加し、年間を通じて特定のテーマ（現場改善、プロジェクトマネジメント、コーチングなど）について研究をしています。こちらは研究と討論が中心です。

例会でのチーム発表の様子

以降では、私がQuaSTomの会員として、また幹事として活動をすることにより得られた経験およびスキルについてご紹介します。

私がQuaSTomに入会したのは職場のソフトウェア開発業務の改善推進担当となった時でした。何をどのように改善すればよいのか、右も左もわからず悩んでいた際に、会社の先輩からQuaSTomを紹介されました。例会や分科会に参加している先輩会員の方の自発的な行動や積極的に討論に参加する姿は、とても楽しそうで生き生きとしていて最初はそれを見ているだけで元気が沸きあがりました。そして、いつからか自分も同じように参加したい、と思うようになり討論では積極的に発言をしたり、職場での改善活動の発表に挑戦するようになりました。また、職場では講演会の内容を実際の業務で試行し、その結果をQuaSTomにフィードバックすることで、新たな改善の機会を得るというQuaSTomの活動と職場を繋げるPDCAサイクルもできるようにもなりました。このように一人の会員としてQuaSTomへ参加することで、改善スキル、またコミュニケーションスキルの向上に繋がりました。

そしてQuaSTomに参加し始めて半年が過ぎた頃、副会長から幹事になってみないかとお誘いいただきました。私の幹事に対する印象は、「ソフトウェア業界で活躍しているすごい方たちの集まり」でした。というのも、私がQuaSTomに入会して初めて参加した例会で、ソフトウェア業界で非常に著名な講師の先生と会話をする姿や、大勢の会員の前でスムーズに司会進行をする姿、また私自身が半分も理解できなかった講演会の内容をわかりやすく簡潔にまとめて報告をする幹事の方の姿を見たからです。すごい方たちが運営しているんだ、と驚いたのを今でも覚えています。このような印象を持っていましたので、最初は「自分なんかでいいんだろうか？　皆さんに迷惑かけるのでは？」と消極的に考えました。しかし積極的にQuaSTomの活動に参加してきた自分の行動が認められたのがうれしく、自分が成長するチャンスかもしれない、と考え幹事に立候補しました。QuaSTomに入会する前の自分であったら、恐らくチャンスとも考えられず引き受けなかったと思います。

幹事になって最初の一年は例会の副担当として、また翌年からは例会の主担当として、テーマの決定から講師の方との調整等の準備、そして実施後のフォローまでを実施できるようになりました。 また会の進行や報告など会員の前で話をする機会が増えることで、短時間で、言いたいことをわかりやすくまとめ相手に伝える訓練ができ、プレゼンテーションスキル向上にも繋がっています。さらに幹事を担当する中でもう一つ大事なことを学びました。それはどんな作業であっても、前向きに楽しんで取り組む姿勢です。その姿勢が本人だけでなく、周囲の人も含めて活気のある職場にすることができるということを先輩幹事の行動を見て学びました。幹事を担当するようになってから職場の同僚から「毎日楽しそうに仕事してるね」と言われるようになり、結果として改善推進がスムーズに進められることがありました。これは私の行動を見た上司や同僚が改善活動に賛同してくれた結果だと思います。

一昨年の秋、会長から副会長を引き受けてくれないかと薦められました。その際、副会長としての責任を負うことで、これまでより１歩先を見て活動することができると考え「是非やらせてくださいと」即答しました。入会当時は、QuaSTomの幹事イコールソフトウェア業界で活躍する凄い方」と思っていましたが、実際には幹事を担当することで、ソフトウェア業界で活躍できるような凄い人になれるんだ、と今では思います。これからもQuaSTomの活動を通じて、業務で活かせるように成長していきたいと思います。

「社内での行動には限界がある。しかし、自発的な行動を起こす勇気がない。」

私の所属する組織では、３年ほど前までWG（Working Group）という活動により、社内業務の改善を行う取り組みが実施されていました。活動内容は残業撲滅や見積り手法の検討、資産管理に至るまで、グループごと多岐に渡り、活動の多くは書籍やWebサイトの検索から得た情報を最大限活用した改善活動でした。

しかし、私自身がFP（Function Point）法啓蒙チームでリーダーを任され、改善を進めている中で自然と「トヨタの改善活動は有名だけど、他社の取り組み事例や考え方を社内の改善活動に取り入れる方法はないのだろうか？」という思いが強く募ってきました。そんな思いの中ある時、日経SYSTEMSの「社外コミュニティに参加してみよう」という記事を見つけました。記事の中では様々なコミュニティ活動の紹介が掲載されていましたが、QuaSTomのページではガッツポーズの会員の集合写真が非常に印象的で「何かを変えられるきっかけになる！」と確信し、QuaSTomへ入会してみることにしました。

初めての例会参加当日は、「敷居が高そう」「恥をかくかもしれない」という不安でいっぱいでした。というのも私自身「開発技術者」ということもあり、これまであまり情報交換等で社外の方と接する機会がなかったからです。しかし「ようこそQuaSTomへ！京都からだなんて遠くからありがとう！」という幹事の笑顔いっぱいのひと言で不安は一掃されました。

例会は会員のニーズに応じ、「品質」をベースとしたテーマ（ソフトウェアエンジニアリング、プロジェクトマネジメント、プロセス改善、コミュニケーション等）が設定されています。その中で、私自身が毎回例会に参加することで成長を実感できているのが「コミュニケーション力」の向上です。

QuaSTomの例会は、講演会であってもその中で必ずディスカッションの時間が設けられ、毎回会員間の熱い議論が交わされています。したがって、その場の雰囲気が必然と私自身を「話さないと損！」という気持ちにさせてくれ、積極的な発言へと繋がっています。また議論においては、ある１つのテーマに対し会員からは多種多様な視点の意見や見解が出されます。それらの新しい視点を取り入れながら私自身の考えや意見を纏め、それを的確にメンバーへ伝えることで「コミュニケーション力」だけでなく「思考力」も自然と身についてきたように感じられています。このように恥ずかしがらず、自発的に自分の考えを相手に伝えることの大切さを、例会での議論を通して学び取ることができています。

以上のようなQuaSTomでの活動をとおして、現在社内では例会で持ち帰った資料を社内掲示板で共有しています。また、社内コミュニティを立ち上げ、現場メンバーと共に開発段階の品質メトリクスの検討や、工事進行基準に係る見積もりの議論を行う等、社内のソフトウェア品質向上のための改善活動を主体的に推進しています。これまで躊躇していた「最初の一歩」を踏み出すことができたことにより、困難があっても前向きに取り組もう、という自主性が養われてきていることを実感しています。今後もQuaSTomでの活動、またQuaSTomで得た幅広い知識やノウハウを社内へ展開する活動をとおして私自身もより一層成長したいと思います。そして、社内においても「新たな視野で物事を発見する楽しさ」を共有することで、より多くの社員に「気付き」を与え、相互に成長していけるような活動を繰り広げていきたいです。

例会：工場見学（JAL機体整備工場）での様子

これまでQuaSTom人財育成の実際について、QuaSTomの活動事例と共に紹介してきました。QuaSTomというボランタリーで実践的なコミュニティ活動の場が教育の一手段として技術者個人の成長に繋がっている点について、ご理解いただけましたでしょうか？

QuaSTomのようなコミュニティ活動は、社内外のプロフェッショナルとの技術交流により、ソフトウェアの開発技術に限らず、コミュニケーションスキルやプレゼンテーションスキル等、ソフトウェアの開発技術者に必要な幅広いスキルを獲得することができる１つの場でもあります。今後教育の実施形態の１つとして、また技術者個人のスキルアップの一手段として、コミュニティ活動を取り入れてみては如何でしょうか？

近年、ソフトウェアは社会に欠くことのできない存在となった。しかしその一方で、ソフトウェアに起因するエンタープライズ系のシステム障害や組込み系システムの製品リコールが多発している。特に最近では、金融システムのような重要な社会インフラや、人命に関わる製品にも及んでいる。このままでは、我が国の産業競争力にも消費者安全にも大きな負の影響を及ぼしてしまう。　その一因が、質の高い人材を生み出すシステムが機能していないことである点は論を待たない。我が国のソフトウェアは、ソフトウェアエンジニアリング（SE）に関する十分な体系的教育を受けていない技術者によって作り続けられているのだ。これは極めて憂慮すべき問題である。
この問題の解決に必要なのは、大学などの高等教育機関におけるSE教育の質の向上である。もちろんこれまでも、意識の高い研究者は自ら実践的・先端的なSE教育や産学連携を行っている。SE教育の議論を熱心に交わすNPO法人もある。経産省や文科省、経団連はいくつかの大学や大学院に対して助成を行っている。またITSS/ETSS/UISSなどのスキル標準でも高等教育との関連性が議論されている。
こうした流れを踏まえ、情報処理学会にはSEのカリキュラムの参照モデルの策定が強く望まれてきた。それによって様々なSE教育の取り組みを整理し強みや弱みを明らかにでき、さらなる改善を促すことができる。SEの学科やコースの設置もが容易になる。
情報処理学会では、1999年からアクレディテーション委員会SE分科会として，知識体系の調査、日本で適用可能なフルセットとしてのカリキュラムモデルJpn1の策定、 (特に米国における)SEアクレディテーション動向の調査などを行ってきた。2006年からはSE教育委員会として、ミニマムセットとしての情報専門教育カリキュラム標準J07-SEを策定することとした。その内容はJ07-SE領域のWebサイトにて公開されている。

J07-SEは、大学などの高等教育機関の情報専門学科におけるSE教育のためのカリキュラムモデルであり、知識項目や最低限必要なコア科目などから構成される。J07の方針に従い、知識項目としてCCSE 2004（IEEE　Computer Society　と　ACMが共同作成したComputing Curricula Series　2004年版）を参照し、再体系化を行っている。J07-SEのコア科目と年次進行例を表１に示す。ちなみに科目とは、90分×15回の講義を指す。
J07-SEを基にしてカリキュラムを開発する際には、学科やコースの特色を反映した科目をコア科目以外に追加する必要がある。例として、エンタープライズや組込み、Webなどの適用ドメイン的な特色を反映したり、要求開発やアーキテクチャ設計、テスト、品質管理、マネジメントなど技術的な特色を反映した学科やコースなどが考えられる。
J07-SEの基本的なコンセプトは"実践的"と"骨太"である。これらはエンジニアリング教育には必要欠くべからざる特性であり、産業界から強く求められている特性でもある。
実践的な側面としては、プログラミング言語の習得に留まらず開発ライフサイクルを網羅したり、理論の理解に留まらず品質・生産性・コストといった要因を重視している。個人に閉じた作業に留まらず、開発に必要なマネジメントやコミュニケーション、チームダイナミクスなどを指向している。開発者のモチベーションや、不具合につながる開発者のヒューマンエラーといった心理的側面も取り扱っている。
とはいえSEの技術進化の速さを鑑みると、単なる近視眼的な技術訓練では不十分であり、骨太なカリキュラムモデルが必要となる。SEにおいて重要なのは技術の使い方よりも"ものの考え方"そのものであるため、モデリングを習得することで「捉える力」や「考える力」「表現する力」などを、検証と妥当性確認やプロセス改善を習得することで「問題発見能力」や「問題解決能力」などを、プロセスやマネジメントを習得することで「段取り力」や「調整力」などを涵養することを指向した。またソフトウェアに留まらない一般的な工学原則も学ぶこととした。これによって、技術を単に理解するだけでなく、臨機応変に応用でき中長期的に付加価値を生み続けられる技術者の育成が期待できる。
コア科目は、情報科学基礎科目とSE科目に分けられる。情報科学基礎科目とは、論理と計算理論、離散数学、オペレーティングシステム基礎・データベース基礎といったSEの基礎となる科目である。SE科目とは、ソフトウェア構築やソフトウェア設計、検証と妥当性確認、開発マネジメントといったSE技術を扱う科目である。
実習科目は、プログラミング入門、プログラミング基礎実習、プログラミング応用実習、ソフトウェア開発実習から構成される。プログラミング入門では、教養系で実施する一般的なプログラミング入門を想定している。プログラミング基礎実習では、個人でのプログラム開発と単体・統合テストを行う。プログラミング応用実習では、与えられた要求仕様に対して個人やグループでのアーキテクチャ設計、ソフトウェア設計、プログラム開発、単体・統合・システムテストを行う。ソフトウェア開発実習では、要求開発も含めてグループでのシステム開発とプロジェクトマネジメントを行う。エンタープライズ系や組込み系など学科やコースの特色に合わせて、かなり具体的なシステムを想定した実習となる。
品質という側面からJ07-SEを捉えると、従前の日本におけるSE教育に比してかなり踏み込んだ内容であることがご理解頂けると思う。科目としてはソフトウェアプロセスと品質、開発マネジメント、検証と妥当性確認の3科目で大きく品質について扱う。他にも、ソフトウェア構築科目では単体テストツールやテストファーストプログラミングについて扱い、モデル化と要求開発、アーキテクチャ設計、ソフトウェア設計の各科目では品質特性や非機能特性、設計品質やメトリクスなどを扱う。工学基礎では、ソフトウェアだけでは実現できない安全性やセキュリティ、性能といった品質特性や、測定の原則、統計解析などソフトウェアエンジニアに不足しがちとなる一般的な工学原理について幅広く扱う。

J07-SEは高等教育機関におけるカリキュラムモデルであるが、産業界におけるSE教育に大きく参考になる内容を豊富に含んでいる。本稿に目を通した読者は一度、自社の教育が必要な知識項目を含んでいるのか、十分に体系的であるのか、実践的かつ骨太となっているのか、などを振り返って頂きたい。そしてJ07-SEを、自社の教育体系の構築・整備に役立てて頂ければ幸甚である。

【表１　J07-SEのコア科目と年次進行例】

私は1984年に株式会社リコーに入社し、電子タイプライタの事業部へ配属となりました。組込みソフトウェアという名称はまだなく、当時はファームウェアといわれており、メカ・エレキを動かすためのプログラムコードでした。先輩はメカ屋さんやエレキ屋さんばかりという状況です。技術リーダクラスの先輩エンジニアが私の指導を担当していただいておりました。指導スタイルは、私がデバッグしている横で画面を覗き込んで、いろいろと助言をいただき、問題解決するというスタイルです。今で言うところの、ペアプログラミング的なペアデバッグということになります。先輩エンジニアはエレキが専門であるため、ソフトウェアとしてどう動く、というのではなく、問題ドメインとしてこうなるはずだ、という指導が中心でした。また、夜には、ノミニケーションにも誘っていただき、いろいろと仕事以外のことも教えていただきました。私のエンジニアとしての原点がここにあります。団塊世代が新人類世代に技術伝承するという、古きよき時代でした。今でも、今年定年退職となる、その先輩との交流は続いています。

次に、プリンタのコントローラの開発に従事することになり、複数人の若手エンジニアが集まりプロジェクトを推進していくことになりました。1990年前後です。ここで、技術的には、アセンブラからC言語への移行があり、経済環境としてはバブル突入で、仕事がたくさんあった時代です。そこに、新入社員が配属されてきて、私の育成対象となったのですが。バブル時代だったこともあり、仕事は多い、新人も多い、先輩が張り付きで見るわけには行かない。そういう中で、ソースコードを引き継ぐことになったのですが、設計意図をうまく伝えられず、その場その場で、ソースコードの動きを説明するだけでした。その結果、引継ぎに1年かかったという苦い経験があります。当時、同時にスキャナのコントローラの開発も担当していたのですが、こちらは、構造化手法を採用し、設計図を作成していくことで、同じく新人エンジニアへの指導とコミュニケーションが比較的スムースに行うことができました。設計図での育成の必要性を認識した時代でした。

1990年代中盤では、会社にグループウェアが導入されて、ますますプロジェクトも大きくなってきました。発信文書も電子承認が主流となり、鉛筆で朱を入れて指導することが少なくなりました。フラットな組織になり、新人類世代からバブル世代への技術継承が途切れたのかもしれません。OJTが形骸化してきたのもこの時期でした。

2000年に入ると、プロジェクトマネジメント、プロセス改善の時代を迎えることになります。両者ともマネジメント視点の施策であり、エンジニアリングは手段という位置づけになってしまった感もあります。個人や組織のレベルでの人材育成は限界に近づき、全社的な仕組みとしての、新人教育や教育カリキュラムが求められるようになりました。それこそ、企業としての能力構築の仕組みが必須の時代となったのでしょう。一子相伝的なOJTは大きな企業では難しくなり、中小企業では逆にそれができることが強みであるといえます。今後、互いの強みを活かし、相乗効果を発揮できる活動体の出現を期待します。
ほんの四半世紀の間に、これだけの変化がありました。ここで、エンジニアの育成に関しての、トピックスをひとつ紹介します。

入社当事にお世話になったメカのエンジニアの方から「最近のメカのエンジニアは設計しとらん。線一本の大切さが分かっていない」とのお言葉をいただきました。線を引いてCADに考えてもらっている。とのこと。昔は、ドラフターに向かって考えて線を引いて、出図して、仕上がりを待つ、ことが設計だった。とのこと。それに対してソフトウェア開発では、「この関数からあの関数を呼び出せば動く」という発想が依然として多くの現場で見受けられます。設計としては、線を引くべきでないところであると、複雑に入り組んだスパゲティプログラムになってしまいます。(図2)

図2　線一本の大切さ

組込みソフトウェア開発において、この四半世紀で、オブジェクト指向やプロダクトラインなどの様々な技術が出現してきております。しかし、その根底にある「ソフトウェアの構造設計」の原理原則は変わっていません。強度設計として、モジュールの強度を上げることが基本です。この業界では「凝集度」「モジュール強度」と呼ばれています。その原理原則の上に、流行の技術を捕らえることが不可欠だ、というのが私の見解です。
時代として、背中を見て技術を盗む一子相伝の指導は難しい。特に、ソフトウェアは見えるものがないので、難しさが増しています。
設計図を育成の道具として、設計図を読み書きできるエンジニアの育成、設計図をレビューすることで組織的な技術伝承を行うことが、効果的な育成方法ではないでしょうか。

最後に、私の経験してきた育成ノウハウを列挙しておきます。お役に立てば幸いです。釈迦に説法であれば読み飛ばしてください。

●面談の場面　●週報の場面
面談では、短期的なプロジェクトのQCD必達という目標のみでなく、部下の人材育成、仕組みの改善提案、もちろん、自己啓発、という項目を盛り込んで、目標設定をすること。
週報は、結論を先に書いて、できる限り定量的に報告するよう指導すること。

●設計図とレビュー(前述)　●技術報告書
技術報告書は、目的／方法／結果／結論の構造を元に、目的と結論の対象性、事実(結果)と意見（結論）の分離、という視点で朱を入れること。

●本を読む　●外を見る　●海外へ出る
とにかく本は読んだほうが良いでしょう。同じテーマの本を10冊くらい読むと、その分野がそれなりに分かります。
外を見ることも大切です。社外の人との交流、異分野の人との交流の機会を持ちましょう。豊富な人脈は人生をも豊かにするはずです。
海外に出ると、日本が分かります。グローバルな活躍も、まずは、自分を知ることから。

今回ご紹介する「TEF(※1)札幌テスト勉強会」では、主に平日の定時以降に札幌地域の有志が集まり、ソフトウェアテスト関連のテーマで勉強会に取り組んでいます。
インターネット上の無償提供機能の活用や、活動に理解のある企業様（メンバーの勤務先企業／いつもありがとうございます）の会議室提供等により、参加費・会費は無料（実費発生時は割り勘ですが、その実績はありません）で、メンバーによる手弁当で運営しています。
現在登録メンバーは12名で、毎回の勉強会には平均7～8名の参加者があります。

• ※1 TEF：Testing Engineer's Forum ソフトウェアテスト技術者交流会
  http://www.swtest.jp/wiki/index.php?swtest.jp%2Fwiki%2Fforum

勉強会の発足は2006年。
この年の10月に、札幌ではじめて開催された「ソフトウェアテストシンポジウム2006札幌（JaSST'06札幌）」で取り組みを呼びかけたのがきっかけです。

http://www.jasst.jp/archives/jasst06s.html
JSTQB認定テスト技術者資格チャレンジプロジェクトのご紹介

JaSST'06札幌は、札幌周辺の情報技術関連の情報交換、技術向上を目指して任意で活動していた"北海道情報技術フォーラム：HIT（http://sw-quality.com/hit_forum.aspx）"のコアメンバーが、組織の垣根を超えたIT技術者の交流・情報交換を目的として地元に誘致し、東京・関西など他地域JaSST実行委員会メンバーの手厚い支援を受けて準備・開催したシンポジウムでした。

しかし、その準備中に「年に一度のイベントだけではなく、普段から継続的に取り組んで自分達のスキルやノウハウを高められないか」とメンバーで検討した結果、当時国内運営が開始されたばかりの"JSTQB認定テスト技術者資格（http://www.jstqb.jp/）"へのチャレンジを企画しました。

結局この募集に集まったメンバーは8名。試験前までに手探りで7回の勉強会を実施し、翌年(2007年)3月に札幌で初めて実施されたこの試験を受験したメンバーが全員合格。
その後もエレベータの動作に対するテスト演習問題に取り組むなど数回勉強会を実施して、当初目的を達成したプロジェクトが終了しました。
結果的には、この対応が現在の札幌テスト勉強会の第一歩になったと言えます。

－そして中断・・・
勉強会が終わり解散してしまうと、次のテーマ設定や勉強会立ち上げ（メンバー募集や調整など）がうまくいかなくなりました。
特に重要なカギを握る"メンバー集め"には、その候補者への連絡手段や呼びかけの機会が必要になりますが、札幌には広くそのことを知らせるチャネルや連絡ルートは存在していません。
また、当時は運営ノウハウも少ない状態でしたので、誰もが参加を希望するようなテーマ設定や具体的な内容検討なども簡単なことではありませんでした。
結局誰からも声が上がらず、普段の業務対応などで新たなテーマの勉強会を立ち上げるためのパワーも割けず、気がつくとずるずる約一年が経過していました。

－ようやく再開
2008年に入り、お仕事で来札された電気通信大学：西康晴氏（TEFお世話係）と（株）豆蔵：シニアコンサルタント大西建児氏のご厚意で平日定時以降に勉強会を開催することができました。
やはり著名な有識者の力は偉大です。あっという間に沢山の参加者が集まり、テストについてのノウハウを提供頂きながら参加者全員で熱い数時間を過ごしました。
そして集まってくれたみなさんに以降の勉強会運営をアナウンスできたことから、勉強会を再開することが出来たわけです。
お二人にこの場を借りてお礼申し上げます。本当にありがとうございました。

札幌テスト勉強会では、主に３つの実施形式があります。

一つ目："テストの基礎を学ぶもの"
テスト関連書籍やJSTQBシラバス（http://www.jstqb.jp/syllabus.html）などの内容をきっかけにして、ソフトウェアテストの基本的な用語や全体像、個々の要素などを把握し、普段の業務・実務作業の意味や内容、抱えている課題と対応方法などを身につけることを目指しています。

これまでにこの形式で3サイクル実施し、参加者のほぼ全員がJSTQBテスト技術者Foundation Levelに合格しています。今後は合格者が教える立場となり、地域のテストエンジニアの裾野を拡げていきます。

二つ目："ゲストの方に持ちネタを披露頂くもの"
普段地域では聞くことができないテストのノウハウをゲストの方に提供いただくものです。
地域としてのノウハウ獲得のためにとても大事な、そしてありがたい機会となります。

三つ目："企画もの"
運営担当者やメンバー、あるいはお世話係の発案で実践形式にて取り組むものです。

題材となる「仕様」をベースに、複数のグループで「仕様分析」→「テスト観点の導出」→「テストケースの作成」を実践し、各段階での大事なポイントや考慮事項、気がついたことなどをまとめながら進めています。
最終的にはこれらの成果を今後のJaSST札幌（http://www.jasst.jp/）等関連イベントや、他地域の勉強会等で発表し、外部からのフィードバック獲得を目指しています。

TEF札幌テスト勉強会の光景

勉強会運営ではいろいろな工夫を行っていますので、主なものをご紹介します。

• 知識よりも実践能力の向上を目指す場に
  勉強会では、可能な限り各メンバーが自らの頭や体を総動員して取り組んだ結果（成果物）に対して議論するなどにより実践能力の向上を目指しています。
• メンバーの目線で取り組める／気づきを得られる場に
  勉強会のテーマは、実務上の問題や課題を想定し"実務の／現場の目線"で企画・提供しており、毎回勉強会レポートを作成することでメンバーの気づきを促進しています。
• 自らの立ち位置を把握できる場に
  様々な実務経験を持つメンバーが集まり、テストプロセスや開発作業との連携情報などを意図的に含めることで、普段の実務作業の意味や位置付け、自分の立ち位置を感じてもらえるようにしています。

ここで参加メンバーの"勉強会の感想"をご紹介します。

• 勉強と実践の間にいくつもハードルがあることを感じませんか？
  せっかく勉強したことでも、いきなり実務に取り入れるのは難しかったり、試行錯誤をする暇もなく、結局勉強しただけになったりしていませんか？
  私はこの勉強会を通じて「勉強したことの実務への活かし方」を学んでいると思っています。様々な分野のテストエンジニアが集まり、それぞれの経験を活かして勉強したことの実践方法を考えることで、自分自身や、自分の会社にない考え方やノウハウを知ることもできるので、とても楽しく参加させて頂いています。
• 複数の人数で、一緒にテストケースを考えていくと、自分が考え付かなかった意見がたくさん出てきて、自分の足りないところが見えてきます。参加するたびに新しい発見があり、現在、次回テスト仕様書作成時にどのように取り入れていこうか検討中です。
  また、自分の考えと他の参加者の方の意見が合うと、ちょっと自分に自信がもてます。そして、何より他の会社の実践方法などを伺え、とても参考になり、かついい刺激となっています。
• いろいろな製品、開発規模、立場でお仕事をなさっている方々が参加されていて、それぞれの考え方・意見・悩みを知ることでき、とても面白いと思っています。
  普段の仕事のなかで、ともすると前例を踏襲したままの仕事をしてしまいますが、業務改善や調査・研究を行なうきっかけ、また、ソフトウェアテストや設計開発に対する「考え方」の整理の"着眼点"を与えてくれる勉強会として役立っています。
• テストの勉強を通して、テスト以外の要求や設計でどうあるべきなのかを考えさせられる事もあり、テストという１つのことを勉強しながらシステム開発全体のことも勉強しているように思います。
  テスト分析-設計-作成と、メンバーと共に作業を進める中ではテストについて具体的な技術情報について勉強することもでき、書籍やPCに向かうのとは違い、わからない事をその場で質問して答えてくれる人もおり、意見交換もできる貴重な時間です。
• 参加する人が各々違う仕事をして来た事もあってか、テスト勉強会を進めて行くとさまざま意見が出て来て驚きます。
  そして、今まで自分が知らなかった新しい発見(気づき)があり面白いです。
  この「発見」が、きっと、勉強会を通じたコミュニケーションの効果なんだと思います。勉強会で得た事を自分の物にして、今後仕事に役立てたいです。
• 自分の壁を乗り越える為に、一念発起して勉強会に参加しました。
  参加してみて、「テスト」に対して全員で真剣に語れる場があるのは素晴らしいと感じました。様々な立場の方々と真剣な会話をしていると、自分が知らなかった事を知るきっかけになったり、自分のやりかたが間違っていなかったんだという確信が得られたり、勇気と自信が沸いてきます。
  自分の為にも、さらには微力ながらテストエンジニアの地位向上の為にも頑張りたいです。
• 仕事上、日常生活では、作業に黙々と取り組む時間が多くなってしまいがちなのですが、勉強会では、グループでマインドマップを作成するなど、にぎやかに作業することが多く業務に追われる日々の中で良い刺激になっています。
  勉強会の中で、様々なテスト技法の例題を解きそれぞれの答えを発表し合う場面があったのですが、参加者の実務経験に基づく様々な回答が出てきて、とても面白かったです。

IT開発関連のスキルアップを考えると、IT関連従業員数や関連情報、学ぶ機会、専門組織などが少ない北海道・札幌はよい環境とは言い難いと思います。
ですから周囲の環境に頼らず、まずは自分のために、自らできることから対応していく、そして自らやると宣言してくれた方達と活動しています。
今後も同じ気持ちを持つ有志のみなさんと勉強会を継続していきますので、参加したい、やってみたいと思われる方はご連絡下さい。

ほんとうに小さな取り組みですが、地域IT技術者のそれぞれの一歩に繋がるきっかけにつながっていけばとてもうれしいです。

連絡先：TEF-sapporo-owner＠yahoogroups.jp

「未曾有の」あるいは「100年に一度」といわれるような厳しい経済情勢のなか自動車関連産業、情報家電等日本経済の牽引役である産業も大きな打撃を受けています。しかしながら中長期的にみて我が国がいわゆる組込み製品開発の分野に大きな期待があることは不変のことのように思われます。
ETSSは経済産業省の組込みソフトウェア開発力強化推進委員会において、組込み製品開発の重要な課題である組込みソフトウェアの開発力強化のための人材育成と人材活用の実現を目指し策定されています。本稿ではETSSの適用についてご紹介していきます。

ETSSは「スキル基準」、「キャリア基準」、「教育研修基準」により構成されています。 "組込みソフトウェア開発に関わる人材"を考えるためにはまず組込みソフトウェア開発に必要なスキルを明確にする必要があります。「スキル基準」は組込みソフトウェア開発スキルを体系的に整理するためのフレームワークを提示します。「キャリア基準」では、組込みソフトウェア開発に関する職種・専門分野の役割の遂行にどのようなスキルが求められるかを表現するため、スキル基準にて定義されたスキルを利用します。「教育研修基準」では教育プログラムで履修する内容がどのようなスキルに対応するかをスキル基準で整理されたスキルを用いることで対象とする教育範囲やレベルを具体的に表現します。このように、「キャリア基準」や「教育研修基準」は、「スキル基準」で整理されたスキルとそれぞれ関係を持つことになります。

図1　ETSSの構成
（拡大図）

ETSS策定の目的を「人材活用」と「人材育成」であるとはじめに述べましたが、より現場に即した表現に変えると限定的ではありますが「開発者・組織の保有している（あるいは必要とする）スキルの把握」と「教育」ということができます。人材を外部に求める場合も可視化されたスキルがあれば適正な人材像を示すことができます。図2はETSSを利用した人材マネジメントサイクルのイメージですがスキルを把握するために「スキル診断」を実施しその結果をもとに「教育」計画を立て実施していきます。教育の達成度評価のために再度「スキル診断」を行い次の教育サイクルへと進めていきます。このようにETSSの適用ということを考えていく場合まず「スキル診断」が必須となってきます。

図2　ETSSを利用した人材マネジメントサイクルのイメージ
（拡大図）

スキル診断を行うためにはまず診断したいスキルを定義します。定義したスキルをスキル診断シートとして対象者に配布、記入（項目ごとのスキルレベルの回答）していただき回収します。回収後個人、組織での着目点に沿う形での集計・グラフ化・分析等報告資料を作成するという流れになります。

ETSSスキルフレームワークは図3の構造となっています。縦軸にスキルカテゴリ、横軸にスキルレベルを判断したい粒度まで細分化していくために階層を設定できるような構造です。図4のスキルカテゴリで見られるように、『組込みシステム製品を開発する際に「技術要素」を構成要素として、「開発技術を用いて」開発を行い、「管理技術を駆使して」開発プロジェクトを管理する』ととらえ３つのカテゴリとしています。階層化は例えば技術要素であれば通信技術がある、通信技術の中には有線／無線があるというかたちで細分化していきます。

図3　スキルフレームワーク

図4　スキルカテゴリ

ある業界団体のスキル定義ではその業界特有の技術要素を4つ目のスキルカテゴリとして定義しました。ETSSは考え方のフレームワークを提供するものでありこのような拡張についても制限を設けるものではありません。
またスキル定義が総花的なものになることにも注意する必要があります。範囲を決めないで組込み製品にはどんな技術要素が必要かを挙げていくと際限がなくなります。自分たちのスキル定義には現在およびある程度見えている将来必要となるスキルまでに留めておくべきでしょう。上記とは別の業界団体の例では技術要素から計測・制御を抜いてあります！

ETSSでは、スキルとは作業の遂行能力を指し、「～ができること」を表現するものであり、知識を有するだけではスキルとは扱わないとしています。
また、ETSS では技術項目ごとに作業遂行能力の期待値（ポテンシャル）を4 段階のスキルレベルで表現します。ETSS のスキルレベル1（初級）～3（上級）は、確立された技術に関する作業遂行能力の度合いを定義し、それに加えて技術革新（イノベーション）を推進できる能力を評価するために、最上級のスキルレベル４を定義しています。

• レベル4：最上級　新たな技術を開発できる
• レベル3：上級　作業を分析し改善・改良できる
• レベル2：中級　自律的に作業を遂行できる
• レベル1：初級　支援のもとに作業を遂行できる

図5は各スキルレベルが対応すべき業務について、入力（業務の前提として期待できるもの）、処理（実現すべき業務）、出力（成果として期待されているもの）として整理したイメージです。

図5　スキルレベルごとに期待される成果物（出力）

実際のスキル診断は判定したいスキルに細分化された項目ごとにスキルレベルを判定していくことになります。図3のスキルフレームワークをスキル診断シートと仮定してスキル診断を行ったイメージを図6に示します。

図6　スキル診断結果イメージ

ある開発者個人を見た場合すべての項目について同じスキルレベルになることはほとんどないでしょう。図6にあるようにスキルレベルの高い（＝得意な技術）領域、低い（＝不得意な技術）領域が分布として見えてくるはずです。本稿では説明を割愛していますが「キャリア基準」で説明している「職種」および「職種のレベル（キャリアレベル）」の定義にはその職種が持つべき典型的なスキル分布として関連付けされています。このようにみていくと「あの人はレベルXの人だ」とか「レベルYの人が何人欲しい」という表現では正確に表せていないということが納得いただけるのではないかと思います。

スキル診断実施時の大きな課題として、個人や組織でスキルレベルの捉え方に高低のばらつきがでてしまうことがあげられます。例えば仮にまったく同レベルのスキルを持った複数の人がある人はレベル1、ある人はレベル2と申告するといったことが起こります。診断精度に最も影響するところですので注意が肝要です。このようなばらつきを抑えるために「教育」、「試行」で対応している場合が多いようですが、スキル項目内の要素をポイント化しその合計ポイントで自動的にスキルレベルが決定できる等の工夫も考えられています。また実際の診断結果を精度向上の側面からパブリックに活用できるような仕組みの構築についても調査を開始しています。

スキル診断項目はそれなりの分量になるため　また組織のスキルの状況を見るためには組織内メンバのスキルの集合が必要となるため相当な情報量となってしまいます。スキル診断結果を利用しやすくするためには可視化（グラフ化）が有効です。本稿のまとめとしてスキル診断結果をご紹介しておきます。

図7　組織全体のスキル

図7は組織全体のスキルをグラフ化した例です。小さくて見づらいですが横軸にスキル定義の第1階層、縦軸に人数をプロットしています。総数が揃わないのは「未経験もしくは確認可能な実績なし」の場合スキルレベル0としカウントしていないためです。山が低い場合スキル保有者が少ないということになります。またスキルレベルごとの分布も見てとれますので適正なメンバが配置されているかどうかの判断も容易です。

図8　生産性の高低によるスキル分布差
※ グラフ中の　赤線：スキルレベル3、青線：スキルレベル1

図8は生産性の高低（ここではC言語　230行/1人月を境界としている）によるスキル分布を比較したものです。生産性の高いグループではあるスキル項目にレベルの低いメンバよりスキルレベルの高いメンバの方が多く属しているのがわかります。また生産性の低いグループでは高いグループに比べあるスキル項目にスキルレベルの低いメンバが相対的に多く属していることが見てとれます。一般に「スキルが高ければ生産性は高い」というのは当然とも言えますがこのようなアプローチをしてみるとどのスキル項目に注目してメンバを揃えるか、あるいは教育のポイントはどのスキル項目かということがまさに可視化されます。

本稿ではごく簡単にETSSの概要と適用についてご紹介しました。SECでは今後ともETSSの普及のための活動を行って参ります。企業・業界団体等での実証実験も行っており適用の実際、ノウハウの蓄積を進めています。SECから情報発信して参りますが、機会がありましたらまたこちらでもご紹介していければと考えています。今後ともSECならびにETSSの活動へのご協力をお願いしつつ筆を置きたいと思います。ありがとうございました。

• ソフトウェア開発プロセス構築・改善
  －組込みソフトウェア向け開発プロセスガイド(ESPR)共著
• 組込みソフトウェア開発プロジェクトマネジメント
  －組込みソフトウェア向けプロジェクトマネジメントガイド(ESMR)共著
• 組込みスキル標準(ETSS)策定・普及
  －組込みスキル標準　ETSS概説書[2008年度版]　編著
  －組込みスキル標準　ETSS導入推進者向けガイド　編著

社会で求められるソフトウェアは、量・質・種類の全てについて増大の一途にあります[1]。一方で、品質と納期に対する要求は厳しさを増しています。このような厳しい状況において、大規模・高品質・多品種・高生産を確実に追求するためには、理論や経験に裏づけされたソフトウェア工学技術の体系を適切に用いることが不可欠です。
しかしソフトウェア工学の分野では、「産業―アカデミア・ギャップ」[2]の存在が指摘されています。アカデミアには良い技術や方法論が多数ありますが、その活用の場を欠き、実践性を追及できていません。一方、産業界ではときにソフトウェア工学の習得と導入が欠けています。本稿ではこのギャップを克服する方策の１つとして、国立情報学研究所が実施している産学連携に基づいた人材育成プログラム「トップエスイー」（TopSE : Top Software Engineers ）[3] [4] [5]をご紹介します。
国立情報学研究所は2004年度から2008年度まで、文部科学省/科学技術振興調整費の支援を受け、トップレベルのソフトウェア技術者の育成を目指した「トップエスイー：サイエンスによる知的ものづくり教育」を実施してきました。これまでに、1期生6名(12名が2006年度に修了)、2期生25名(企業から18名と大学院生7名)、3期生31名（企業から24名と大学院生7名）が受講しています。2009年度からは、より内容を充実させて新しいトップエスイーの教育プログラムが実施される予定です。

トップエスイーの教育目標は、受講生が「ソフトウェアシステムの背後にある本質を把握し、モデルとして具体的に表現し、理論的基盤に基づいて体系的に分析・洗練化することで、高品質なソフトウェアシステムを高効率に開発するスキル」を習得することです。
その実現のために、産業界、大学、国立研究所が密に連携し、ネットワーク家電を主な対象ドメインとして教材開発と教育、普及に努めています。具体的には、講座ごとに大学関係者と企業とで作業部会を設立し、約1年かけて教材を開発しています。特に教材の題材として、企業からは、数年先に顕在化することが予想される実問題を持ち込んでもらっています。作業部会では、様々な最先端のツールを実問題に適用し、試行錯誤を繰り返しながら、有用なツールを見極めます。ツールを実問題に適用する際には、様々なノウハウが必要となりますので、それらを顕在化し教材としてまとめあげています。
例えば講座の１つである「設計モデル検証（基礎編）」では、HDレコーダ・DVDレコーダ向けのソフトウェアの設計と組込ボード上での実装を実問題として設定し、実問題に対してモデル検査ツールの活用により設計誤りの検出・修正作業を行うことで、モデル検査技術の有効性と難しさを体得させるものとなっています。
教育を実施する講師陣として、企業側から10名以上の技術者・研究者が参画し、大学側からも国立情報学研究所をはじめとして多数の大学・研究所より教員・研究者が参画し、総勢で約30名に及びます。
受講生としては、情報系大学院相当の計算機科学の知識を有していることを前提として、企業の若手エンジニアを中心に毎年20～30名ほどが、出願書類審査、筆記試験ならびに口頭試問を経て受講が認められ、1～2年間をかけて受講しています。　さらに、全国の大学や企業においても同等な教育を実施できるように、普及のための教材作成も合わせて実施しています。

ソフトウェア開発において、技術者が有すべきスキルは多岐に渡ります。プログラマならばプログラミングスキル、アーキテクトならばアーキテクチャの設計スキル、プロジェクトマネージャならばプロジェクト管理スキルといった具合です。しかしそれぞれの職種におけるトップレベルの技術者育成を考えるとき、職種ごとに特化したスキルを修得する上での土台となる共通なスキルを識別することができます。大学院相当レベルの教育において、特定の職種に特化したスキル教育の準備と実施は有効とはいえないため、トップエスイーでは共通スキルの教育に注力しています。
その共通スキルは、実際のソフトウェア開発に着目して識別します。ソフトウェア開発プロセスを、システム要求分析・方式設計、ソフトウェア要求分析、方式設計、詳細設計、実装、テストという流れとして捉えるとしましょう。ここで、各フェーズでは中間成果物として何らかのモデルが構築されるため、ソフトウェア開発プロセスとは本質的には多段階のモデル変換工程と捉えることができます。その流れを図1に示します。各フェーズで構築される要求モデル、分析モデル、設計モデルといったモデル間の変換を経てソフトウェアシステムが出来上がるということです。

図1　多段階モデル変換としての開発プロセス

マネージャやアーキテクト、プログラマは、それぞれの立場でこれらのモデルに関わることになります。このように、ソフトウェア開発に関わる様々な職種において、モデリング能力を共通スキルの一つとして捉えることができます。ここでモデリング能力とは、良いモデルの構築・分析・検証・操作の能力を意味します。トップエスイーでは、その良いモデルを、「抽象化により事柄の本質を表わしている、最小かつ完備である、解釈の一意性が実現されているという性質を有した表現」と定義しています。
モデリングとは、狭義にはそのようなモデルを作成する行為であり、「表現のための道具の特性を踏まえた手順（モデリングプロセス）に従って対象を道具で表現していく」行為を意味しています。そのうえでトップエスイーでは、下記を備えることをモデリング能力として期待しています。

• 抽象化や具象化の操作を含むモデリングプロセスが身に付いている
• 厳格にモデル構築できる
• モデル間の関連性を把握できる
• 保守性、再利用性、非機能性を踏まえたモデル構築できる

ソフトウェアシステムには、様々な視点での切り口が存在し、その切り口に基づいたモデリングの道具も多種多様です。さらに、それぞれのモデリングの道具には固有のモデリングプロセスがあります。トップエスイーでは、モデリングプロセスを問題解決と位置付けて、様々なモデリングの道具とプロセスを習得することが、高度なモデリング能力を身につける際の有効な手法と考えています。
ここで、最先端のモデリングツール（道具）の多くは、計算機科学に基づいています。例えばモデル検査ツールであるSPIN [6][7]の習得には、前提知識としてオートマトン、時相論理、抽象解釈などが必要です。トップエスイーでは、形式的な意味論を背景として持ち、その意味論を元に開発されている約20種類のツールを導入し、これらのソフトウェアツールをシャワーの如く、繰り返し学習させることとしています。その学習の過程で、計算機科学に関する知識を深耕させることができます。さらに、ツールを実問題に適用する過程で、モデリング能力が洗練化されることになります。このプロセスを繰り返すことで、モデリング能力の深耕と計算機科学の知識の深耕の両者を同時に達成でき、その結果としてソフトウェアツールを習得しつつ新たな問題への応用力も身につくことになります。

図2　ソフトウェアツール教育の効果

トップエスイーでは、将来のエンタープライズソフトウェアシステム開発および組込みソフトウェアシステム開発において、特に信頼性、効率性、変更容易性、セキュリティの達成が重要であると捉えています。そこで、それらの各品質特性の達成に有効であり、かつ、計算機科学に基づく評価の高い複数のソフトウェアツールが存在していることを講座開発の前提としました。その結果、形式手法関係の講座が半分近く占めることになりました。トップエスイーは必ずしも形式手法の教育を標榜していませんが、形式手法が有する厳格なモデリングプロセスを学ぶことで、表現上は自然言語やUMLを用いるとしても「厳格にモデリングする」という癖を身につけさせることを意図しています。また、複数のツールを扱うことで、1つのツールに依存せず、対象分野の基本的な概念を習得させて新たなツールへの適用能力を身に付けさせることができます。
2009年度に開講する講座は、下記のとおりです。各講座の詳細はhttp://topse.jp/よりご参照ください。

基礎系

• 基礎理論：受講生が他の講座を受講し理解するために必要な計算機科学に関する知識の総復習

要求分析系

• ゴール指向要求分析：個別の要求の背後にある上位目標といった多様な抽象度から要求を分析する技術の習得
• 要求獲得・定義：要求を獲得するための基本的な技術と、それをモデル化する技術、さらに、獲得された知識や要求を仕様化し、要求仕様書にまとめあげ、評価するための技術の習得
• セキュリティ要求分析：システムの脆弱性、利用者の悪意、システムへの攻撃といったセキュリティ上の問題を予測・発見し克服する手法、および、演習を通して実際の要求モデルをセキュリティという視点から分析する方法の習得
• 超上流要求工学：問題を解決するための論理的な思考体系や発想法、および、多様性と変動性を視野に入れた情報システムを構築するための前提としてのビジネスモデリング法の習得

形式仕様系

• 形式仕様記述（基礎編）：形式仕様言語に基づく段階的な詳細化と呼ぶ技術と、仕様を直接実行する技術の２つの方向から、妥当性の確認を行う方法の習得
• 形式仕様記述（応用編）：形式仕様記述（基礎編）に引き続いて静的な情報構造にまとを絞り、上流工程からインプリメンテーションまでをつなぐ形式手法を用いた系統的な開発の方法の習得
• 形式仕様記述（セキュリティ編）：形式仕様言語を使ったポリシ・モデルの理解、および、段階的な詳細化、定理証明、モデル検査というシステム検証技術における主要な三技術を使ったセキュア・システムの開発技術の習得
• 並行システムのモデル化と検証：信頼性の高い並行システムを構築することを目的としたモデル化、検証、実装方法の習得

モデル検査系

• 設計モデル検証（基礎編）：ネットワーク家電の制御ソフトウェアを題材とした産業ソフトウェアの設計モデル検証のプロセスとノウハウの習得
• 設計モデル検証（応用編）：設計モデルの特徴に合わせたモデル検査ツールの使い分けおよびノウハウの習得
• 実装モデル検証：ネットワークを介したメッセージ通信を通して動作する分散ソフトウェアの振る舞いを網羅的に検証する技術、および計算機上で扱える程度の規模に検証問題を変換する抽象化技術の習得
• 性能モデル検証：設計モデルの性能面に関する動作の正しさを自動的に検証する性能モデル検査ツールを使用し、実際のシステム開発に適用する方法を習得
• テスティング：組込みシステムからネットワークまで対応可能な、ソフトウェア・テスティングの技術の習得
• プログラム解析：形式仕様記述に基づくプログラムの静的検証や単体テストの手法の習得

アーキテクチャ系

• コンポーネントベース開発：早期の分割統治とインタフェース中心の分析設計を系統立てて実施するためのコンポーネントベース開発手法とプロセスの習得
• ソフトウェアパターン：情報機器系のシステム開発において代表的な既存ソフトウェアパターンの適用ノウハウ、設計原則や非機能的特性からのパターンの適用範囲と取捨選択、支援環境の活用ノウハウの習得
• アスペクト指向開発：アスペクト指向に基づく関心事の分離と合成の技術、アスペクト指向プログラミングおよび分析設計の実践的ノウハウの習得

マネジメント系

• ソフトウェアメトリクス：ソフトウェア開発に「数字による管理」を取り入れ、品質の定量的評価、品質予測、手法の有効性評価、プロジェクトの状況判断といった局面で定量的な観点から議論するための基礎知識とスキルの習得

トップエスイーでは、スキルレベルとして4段階を識別し、各講座について表1に示すように該当レベルを明示しています（ただし表1は抜粋）。受講生は、1講座毎に1単位を取得し、修了制作に合格してレベル４を達成しカリキュラムを修了するためには、4単位以上を取得する必要があります。カリキュラム修了には最低1年間が必要です。成績は、頻繁に講義で出題される演習問題に対するレポートを主に考慮して評価しています。各講座は、2009年度は毎週2コマ連続で開講される15コマの講義から構成され、1コマの時間は90分です。講座は2ヶ月続き、これで1学期を構成します。1学年は5学期です。

表1　講座とスキルレベルの対応（抜粋）

表2に、各講座で使用している方法論とツールの一例を示します。受講生が、カリキュラムを修了するためには、8講座の習得により、約10-20点の異なるツールが有するモデリング技術の習熟が求められることになります。

表2　利用ツール（一例）

トップエスイーでは、受講生の修了を認定するために修了制作を課しています。修了制作とは、受講生が教員の指導を受けながら主体的に約2ヶ月間をかけて、職場で抱える実問題あるいは実問題に近い課題を設定し、トップエスイーで習得した2種類以上のモデリング技術を駆使して課題を解決し、その成果および過程において得られた知見を報告書にまとめて発表するという一連の実習活動です。
トップエスイーにおいて受講生に求められる最終目標は、表1における技術スキルレベル4に到達することであり、その到達の可否は、修了制作の発表内容を教員が評価して判定されます。従って表1に示すように、高品質な成果を生み出すにとどまらず、修了後の受講生自身や所属組織および広く一般における開発・技術活動について習得モデリング技術を活用可能となることを念頭において、(A) 解決の過程で得られたモデリング上の知見を再利用可能な方法論として一般化することや、(B) 一定の汎用性を備えてモデリング作業を支援する新ツールを生み出すことが求められます。さらに2種類以上の技術使用を義務付けることで、状況に応じた技術の使い分けや、工程・側面を超えた複数技術の組み合わせといった実践上のノウハウが習得されていることを確認しています。ただし、(B)を主目的とする場合は、作業負荷を考慮して1種類のみの技術使用も可としました。
修了制作の具体例として、平成18年度に修了した受講生の事例を以下に2つ取り上げます。

（１）	「UTMアプライアンスのログ情報解析ツールの解析」： セキュリティ機能を統合したUTM（Unified Threat Management）製品の開発にあたり、同製品が出力するログの解析ツールを合わせて開発する必要がありました。開発にあたり受講生は、機能要求の不明確さや時間効率性・拡張性に関する品質要求などを問題として識別しました。 そこで受講生は、トップエスイーで習得した技術群から、要求分析においてKAOSによるゴール指向分析、設計において品質特性駆動型設計を選択・併用し、問題を解決する形でツールを実装しました。前者は多種の目標群を達成する観点に基づいて要求を詳細に識別・分析する手法であり、後者は各種パターン（定石や手本）を再利用して品質要求を満足するアーキテクチャを導出する手法です。 さらに、これらの技術の組み合わせ方法には、これまで明らかでなかった実用上のノウハウが含まれていたため、受講生は全体を品質要求駆動型プロセスとして一般化しました。これは、開発過程で得られた知見を方法論としてまとめるという（A）の好事例といえます。得られた解析ツールの実用化が検討されており、高品質であることからも、背景理論と実用上のノウハウを共に重視して複数のモデリング技術を習得させるトップエスイーの高い教育効果が結実した形と捉えられます。
（２）	「Webアプリケーションのページ間遷移仕様検証ツール」： Webアプリケーション開発の問題として、大規模・複雑なWebページ遷移の信頼性や安全性を検証することの難しさがあります。例えば、個人情報ページに到達する前に認証ページを必ず辿っていることや、行き止まりのページが存在しないことを人手で確認しようとすると膨大な時間がかかり、さらには見落としの危険性もあります。 このような状態遷移上の性質の検証には、有限の状態空間を網羅的・自動的に探索するモデル検査が有用です。しかし、対象アプリケーションの振る舞いを有限状態モデルとしてモデリングするにあたって、必要な遷移情報が各ページ定義やフレームワークの構成定義に分散し、結果として適用コストが大きく誤りも混入しやすいという問題を受講生は識別しました。 そこで受講生は、対象フレームワークをStrutsに設定し、ページ定義および構成定義から遷移情報を抽出し、モデル検査ツールSPINが扱う有限状態モデルへと自動変換する実用的ツールstruts2spinを開発しました。つまり同ツールは、モデル検査をWebアプリケーションという実問題へ適用する際に必要なモデリング上の新ノウハウと手順をカプセル化し、誰でも一定品質のモデリング結果を得られるように自動化します。受講生は実際のWebアプリケーションに同ツールを適用し、識別した問題を解決しつつ、遷移上の信頼性・安全性検証に有効なことを確認しました。これは汎用性を備えた新ツールを生み出すという（B）の好事例といえます。同成果には学術界より高い評価が与えられており、国際会議に論文が採択されたことからも[8]、モデリング能力の洗練化を目指すトップエスイーの高い教育効果が結実した形と捉えられます。

2008年度現在のトップエスイーの3期生の数は31名です。30名程度が、一つの教室で良質な教育ができる上限値と考えられます。そこでトップエスイーでは、同等の教育を広く大学や企業に普及させて多数の優秀なソフトウェア技術者育成に貢献するために、教材の洗練と普及を進めていく方針です。その一環として、各講座の講義ノートをサイエンスによる知的ものづくりシリーズとして順次刊行しています[9]。また、文科省の先導的ＩＴスペシャリスト育成推進プログラムなど他の教育プログラムとも積極的に連携を進めています。たとえば、東大、東工大の学生を対象にした「情報理工実践プログラム」においてトップエスイーの6教材を使用しています。また、2009年度は講座の一部について北陸先端科学技術大学院大学が開設する社会人向け博士課程「先端ソフトウェア工学コース」の講座と共通化される予定です。
トップエスイーでは2008年度11月現在、2009年度4月に始まる4期生が募集されています。ご興味を持たれましたらぜひhttp://topse.jp/をご参照ください。個々の講義シラバスや協賛企業名などが掲載されています。

2004年度から2008年度までの本人材養成ユニットは文部科学省科学技術振興調整費新興分野人材養成の支援により運営されていることをここに記すとともに感謝いたします。また、本記事は文献[4][5]に基づいて、一部改変する形で執筆されました。

当社は、ソフトウェア開発の分野で数多くの実績を作ってきた独立系ソフトウェア開発企業です。お客様のニーズに合った高品質かつ創造的なシステムやサービスをタイムリーに提供することで、CS（Customer Satisfaction：顧客満足）の向上を目指しています。昨年９月、当社は「ソフトウェア技術者のCS・PSマインド育成による顧客満足度の向上」活動を推進し、お客様満足と事業部の業績を向上させる成果を達成したことが評価され、日本品質奨励賞 品質革新賞を受賞しました。今回は、企業内の改善活動をトップダウンとボトムアップの両面から働きかけた当社の事例を紹介します。

ソフトウェア開発では、プロジェクトメンバーの仕事への満足がそのプロジェクト全体の生産性や品質に大きな影響を与えることが知られています。お客様にご満足していただけるサービス／製品を提供するためには、プロジェクトメンバーの仕事への満足を向上することが必要です。そのため、当社では、PS（Partner Satisfaction：パートナー満足）の向上活動を推進しています。PSとは、ES（Employee Satisfaction：従業員満足）の概念を拡大したプロジェクトメンバーの仕事満足のことで、プロジェクトメンバーには、従業員、協力会社などプロジェクトに関わる全メンバーが含まれます。近年は、協業体制によるプロジェクト型業務が増えていることから、社員だけでなくプロジェクトで働くメンバー全員を対象としています。

現場のリーダは、プロジェクトメンバーの仕事への意欲がプロジェクト全体の生産性や品質に影響するということを体験的に理解しています。しかし、それがどのような要因に左右されるのか、また、どうすればコントロールできるのかということについては、あまり知られていません。そこで当社は、トップダウンアプローチとして、まず何が影響しているのかを測ることから始めました。PS研究会(*1 の支援を受け、日科技連による全社的なPS調査を2002年から2年毎に実施してきました。その分析の過程でPS診断グラフ（図1）を考案し、「仕事意欲・仕事満足・ストレス」の3つの指標によって、全社の組織やプロジェクトの状況がマクロに測定できるようになりました。このグラフは仕事満足と仕事意欲の2軸で構成されており、○●一つ一つはプロジェクトや組織を表します。○はストレスが低く良好な状態を、●はストレスが高く不調な状態を表します。○や●の大きさが大きいほど良好/不調の程度が大きいことを表します。調査結果から、プロジェクト間のバラつきが大きいことが明らかになっています。

図1　PS診断グラフ

次にプロジェクト間のバラつきの原因を調べるために因子分析した結果、影響力の強い因子が抽出されました。PSに影響するこれらの因子を使い、プロジェクトの状況を詳細に分析できるPS分析レーダチャート（図2）を考案しました。チャートの領域が外側に広がっているほど、プロジェクトのPSが高いことを表します。値が（＋）の因子は、プロジェクトのPSを向上させており、値が（－）の因子は、PSを低下させていることを示しています。

図2　PS分析レーダチャート

PS診断グラフとPS分析レーダチャートを活用して経年変化を比較したところ、第2回調査（2004年）でPSが低下していたため、PSにもっとも影響がある「コミュニケーション」に注目し、PS研究会松尾谷氏の協力を経てチームビルディング研修を実施しました。また、新入社員研修やOJT指導員研修にもチームビルディング研修を取り入れた結果、第3回（2006年）の調査では仕事満足、仕事意欲は改善され、PSが向上しました（図3）。しかし、ストレスは改善と悪化に二極化しています。これは、新3Kと揶揄されるほどIT業界全体の職場環境が悪化していることが背景にあると考えられます。

図3　PS診断グラフによるPSの経年変化

当社は、PS調査は2年に1回、CS調査は１年に1回実施しています。これらトップダウンの取り組みは、全社の状況を把握し対策を考えるためには必要な情報です。しかし、トップからの指示だけでは、現場の問題解決への意欲は高まりにくく、会議等で「CS獲得こそが目標だ」「PSについて考えよう」と啓蒙を図りましたが、結果は望ましいものではありませんでした。
そこで当社では、次のような取り組みを始めました。一般的にCSは顧客側の反応であり、提供（現場）側としては受身的に捉えるところを、提供側であるプロジェクトメンバーにCSを評価させることを試みました。これを当社では「主観的CS」と呼び、この測定が自己満足に終わらないよう、第三者による評価結果との差異を確認するようにしました。このことで、現場のCSに対するマインドの育成を図ると共に、現在進行中のプロジェクトのCS向上も得られると考えました。また、CSを向上させるためには、ソフトウェア技術者のPS向上が重要であると考え、PSについてもプロジェクト内での測定活動を行いました。PSをプロジェクト内で定期的に測定することで、問題への対応が早くなり、PSの維持・向上が図られると考えました。
ある顧客と当社の間で、プロジェクト単位のCS相互評価を行いました。プロジェクト単位で、その顧客が評価したCSと、当社が自己評価したCSの差異を調査しました。その結果を、PS測定を導入しているプロジェクトと、PS測定を導入していないプロジェクトで比較した結果、ＰＳ測定を導入しているプロジェクト●は、導入していないプロジェクト●に比べ、顧客評価のCSと主観的CSの差異が少なく、しかも全般的に顧客評価のCSが高くなっていることがわかりました。このことから、CS・PSマインドの育成の効果が確認できました。

図4　測定活動のCSに与える影響

企業の中では、品質や生産性の向上などの改善への取り組みが日々行われています。導入はトップダウンで進めたものの、現場では形骸化してしまう施策も見受けられます。現場が主体的に施策を導入していくためには、まず施策へ関心を持たせて、自ら考えさせ、マインドを育成する必要があります。ここで紹介した当社の顧客満足度向上への取り組みは、トップダウンによるCS・PS調査とボトムアップによるCS・PSマインドの育成が融合した取り組みです。まだまだ改善の余地は多々ありますが、これからも顧客満足度向上を目指して進めていきたいと思います。

• ※1 PS研究会
  PS研究会は、非営利の任意団体として2002年に活動をスタートしました。当研究会は、プロジェクト型の仕事環境における、人的リソースにとって良い環境やそのパフォーマンスについて学び研究し実践することが目的です。
  参加メンバーの所属する組織や企業で実践し実証することに重点を置いて活動しています。メンバー自身が学ぶと同時に、メンバーを通して企業への貢献についても積極的に取組んでいます。

SQiPは、ソフトウェア品質管理技術・施策の調査・研究・教育を通じて、実践的・実証的な
ソフトウェア品質方法論を確立・普及することにより、ソフトウェア品質の継続的な向上を目指します。