ホーム » 2013 » 2月

月別アーカイブ: 2月 2013

第6回SQuBOKユーザ会勉強会に参加してきました。

投稿日: 投稿者: | コメントする

2013年2月14日に、第6回SQuBOKユーザ会勉強会が開催されました。

http://kokucheese.com/event/index/55470/

ご参考：SQuBOKユーザ会については以下のサイトを参照すると良いと思います。
SQuBOKユーザ会ポータルページ 　Facebookファンページ

今回は、小池さんと堀さんのお二人がトーカーとして発表なさいました。
参加のメモ書きを兼ねて内容を簡単に書いてみます。

小池さん：「品質保証活動(SQA)を形骸化させないコツ」

プロセスが形骸化する理由

  • 「ルールで決められているから」「規準に書かれているから」とルールを強いる。

プロセスはルールではなく、道具である。「決められているから実施する」のではない。
プロセスは、プロジェクトの失敗の予防に役立つから使う。そして使う以上はうまく使えるようにする。

  • 「開発がxxxx(プロセスなど)をしてくれなくて困る」と言ってしまう。

「データを提出する」「資料を作成する」するという作業は、プロジェクトに恩恵をもたらさないと認識する。

  • 「手順書や帳票を使ってくれない」

手順や、帳票を、現場に使ってもらえる努力をどれくらいしているか。
スタッフはサービスは精神が命であり、悪い点使いにくい点があれば、どんどん直していくこと

  • 適切なマネジメントのうえで,はじめてSQAが生きる
    目標はQCD達成だけでなく、チャレンジも盛り込むようにする。チャレンジ項目に対する評価を行なう。
    改善に対する評価がなければ、改善に対するやる気があらず、目の前の仕事しかしなくなる。
  • 「プロセス」「スタッフ」「マネジメント」のあり方の問題
    プロジェクト成功のためのサポートになるようにする。プロジェクトの成功に寄与しないと判断したならやめる。
  • 形骸化になる理由
    「開発者が、その活動がプロジェクトの成功に寄与しない」、と考えているから。
    →スタッフは貢献できているか自問自答しながら活動する必要がある。
    中長期的な組織の成長があっても、まず目の前のプロジェクトの成功させることをしないとだめ。
    悪いところだけを指摘するのではなく、いろいろな相談に乗ったり、改善案を検討したりすることが重要。

まとめ

プロセス改善に魂込めるには以下の様なことが必要である。

  • プロセスやルール、帳票などを使ってもらう努力を行なうこと。
  • 淘汰されたものは潔く諦める
    必要と判断して、残したものはまめにメンテナンスを行なう。
  • パイロットプロジェクトで試行する。
  • 常にプロジェクトの成功を考える
  • 客観的な姿勢でのぞむ

議論内容

  • メトリクスで人を評価してはいけない。人を評価するようになると正直なデータが出てこなくなる。
    人ではなく、プロジェクトという単位でみるようにする。
    人ではばらつくことがおおいが、プロジェクトという単位なら相殺されてぶれが大きくなくなるときがある。
  • 「プロセスを守りなさい」だけで縛ってはいけない。
  • プロセスの目的を考え、目的と合致しているかどうかを考えること。
  • プロセスは状況に応じて変化させていくこと。
    プロセスの標準化は、改善のためのベースラインを決めることである。決めたところからどう変えるかを考える。
  • SQAは、上位マネージャなどが判断するための情報を情報を提供するようにする。

堀さん：「ソフトウェアメトリクスの単位」

なぜメトリクスか

何かを定量的にあらわそうとすると、そのモノの本質をよく考える必要に迫られる
「神棚計画」のように、一度作成された計画の見直しがされないのはダメ。
「見積もり」→「実施」→「分析」→「見直し」といったようなサイクルを回すのが重要。

書籍「<はかる>科学」

書籍の紹介：「<はかる>科学」

http://www.amazon.co.jp/gp/product/4121019180

いろいろな「はかる」について書かれた本。
現代ではかることが難しいものに、どう向き合っているのかがわかったりしておもしろい。

本からの紹介例：
18世紀フランスで使われているいろいろな単位は群毎に異なっていた
→いまのソフトウェア開発で用いられている様々な尺度も同じような状況ではないか。

ソフトウェア開発における「はかる」

  •  step/人月
    • そもそも、コード書かなくて作成できるアプリケーションには、SLOCが登場しない
    • 保守性や移植性などを考慮されたプログラムはどうか
      よく考えられたプログラムが生産性が悪くて、コピペだらけで作成されたソフトウェアのほうが生産性がよいという評価は適切か？
    • 短時間でたくさんコーディングすれば生産性が高いのか？
    • そもそも人月って意味があるのか？
    • なぜSLOCか。

再利用しやかった。またそれしか有用な指標がなかった。新たな指標が望まれる。
Capers Jones：「SLOCではかることはゴムのように伸び縮みするものさしではかるようなもの」

  •  テスト項目数/step
    • 1件はどうカウントする？
      • Excelで書かれたテスト手順の1行が1件か？
      • マトリクスのテスト手順書はどうカウント？
    • 1つのテスト項目に複数の確認項目がある場合はどうする？

ここでは、「step/人月」「テスト項目数/step」をあげたが、他にもいろいろ似たような曖昧な指標があるはず。

単位を厳密に定義するのではなく、首尾一貫していることが大切。
→厳密に定義しないと、定義できないのではないか？

ワーキンググループの提案

ソフトウェアの様々な規模尺度や生産性を活用方法、定義、表し方、収集方法について検討するWGを立ち上げようと思っている。
期間は1年。成果はSQuBOKユーザ会やSQiPシンポジウムで発表したい。
・定性的情報/定量的情報の両方が必要
・定性的情報を、定量的には把握し、確認、裏付けをする
・定量液な情報から、定性的な情報を引き出す

議論内容

  • 因果関係をみながら対処することが重要
    レビューでよばれたとき、つくってきたもののモデルのつじつまがあっているのか？をみた。
  • モデルの厳密性や妥当性を示す、メトリクスはないか？もとのモデルが正しいか知りたい。
  • プロジェクトのわるいところは、数値を見なくても、プロジェクトを直接みることでだいたいわかる
    数値は、追認するときにつかう。
  • メトリクスの妥当性の範囲はわかりにくい。
    なので、異常値に着目することが多い。
    特性（くせ）をさっぴいて、極端に変な値になっていないか？
    →そこで悪いような値はかなりわるいケース
  • メトリクスは、「なににつかうの？」からはじめる必要がある。
    先にメトリクスありきで活用方法を考える、はおそらくうまくいかない。

次回予定

2013年3月21日(木)ということですので、ご興味ある方は、参加検討されてはいかがでしょうか。
トーカー（発表者）は募集中のようです。

ご参考

第6回SQuBOKユーザー会勉強会つぃーとまとめ
http://togetter.com/li/456060