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

2.人材育成

論文を書くことの大切さ

株式会社システムクリエイツ
代表取締役 清水 吉男

・技術の習得にも使える?・

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

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

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

といったものでした。

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

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

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

・論文を書き始める・

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

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

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

こうして、レビュー技法や、見積もり技法、スケジューリングなどの他、リスク管理や構造化手法もこの方法で入手してきました、また「一人レビュー」やクリーンルーム手法(のマネごと)に取り組んだときも、そして最後のプロジェクトの一つ(このとき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での研究会の活動の意味や、そこで論文を書くことの効果について書く予定ですので、ご期待ください。

プロフィール

清水 吉男(しみず よしお)
株式会社システムクリエイツ 代表取締役
派生開発推進協議会 代表

「私のほうで提案している「USDM」「XDDP」という方法を中心にして派生開発における開発プロセスの改善活動をしています。中でも、「XDDP」はいろいろな場面に応用できますので、派生開発推進協議会やSQiPの研究会などを通じてその可能性を広げる活動を行っています。また「USDM」による要求仕様の記述の精度を向上させる研究にも取り組んでいます。」

Vol.15 2011年 8月号 目次へ1. 品質へ3. SQuBOK®へ

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