プロセスアセスメントに関する情報と知見の整理

9621 ワード
アセスメント 開発プロセス プロセス改善 初心者 プロセスアセスメント 初心者 テキストリンク

はじめに

プロセスアセスメントをかじった身として、プロセスアセスメントに関する情報と知見を蓄えていく。

以下の分類で整理をしておく。

  • 書籍
  • 資料（論文・発表資料）
  • 動画
  • 記事
  • メモ
  • 思いつき

「メモ」には、私が様々な人から得た知見を記録しておく。
「思いつき」には、私がふと思いついたことを記録しておく。

書籍

SEC BOOKS：プロセス改善ナビゲーションガイド

ソフトウェアプロセスの供給者能力判定及びアセスメントキット-IPA版 (SPEAK-IPA)

  • SPEAK-IPA 概説

  • アセスメントモデル SPEAK-IPA　～プロセス改善でのアセスメントモデル活用～

  • SPEAK-IPAを使ってみよう

  • SPEAK-IPA 第５部アセスメントモデルの解説

プロセスモデル

標準プロセスの例

JAXAのソフトウェア開発標準

資料（論文・発表資料）

安達賢二，「プロセスアセスメント結果の現実的・効果的活用方法の提案」，ソフトウェア・シンポジウム 2013，2013

プロセスアセスメント結果の現実的・効果的活用方法の提案.pdf
プロセスアセスメント結果の現実的・効果的活用方法の提案（添付資料）.pdf

安達賢二，「SPINA3CH実践事例 SPINA3CH×SPEAK-IPA版アセスメント併用実証実験の内容と結果の紹介」，IPA/SECセミナー，2014

後藤健太郎，「最小セットOS開発の作業改善と診断」，情報処理学会組込み研究会，2009

佐藤克，「SPEAK-IPAを用いた設計指向による公開アセスメントの試行」，JAXA/IPA 第１２回クリティカルソフトウェアワークショップ，2015

村上孝，「プロセスアセスメントの分類とアセッサ教育」，JAXA/IPA 第１３回クリティカルソフトウェアワークショップ，2016

小寺浩司，「確率論及統計論輪講 精度より成果」，JAXA/IPA クリティカルソフトウェアワークショップ2016，2016

動画

SECセミナー　SPEAK－IPA準アセッサ育成セミナー

記事

メモ

松尾谷徹氏とのお話

低いレベルのチームを改善しようとするが、高いレベルのチームの良さを分析していないことが多い。

実践！ソフトウェア品質向上のための原因分析セミナー

原因分析は4つに分類される。過去の失敗だけでなく、過去の成功と将来の失敗と将来の成功の分析もある。

  • 成功事例から得られる暗黙知を形式知化することが重要
  • 成功事例は分析されにくい
  • 成功した本人は分析の必要性を感じない
  • 成功事例は、本人には分析させないのがポイント

ソフトウェア品質シンポジウム2016の芳賀氏の講演

失敗の原因を取り除くマネージメントだけでなく、成功の要因を展開するマネージメントが必要。末端のプラクティスの存在を確認する診断・監査では、成功事例を見つけることが難しい。トップゴールから、その達成のためのサブゴール、プラクティスを確認するような上から順に確認するインタビューが必要。

2016年の白坂成功氏の講演

  • 標準に従うと差がでない。優先性もでない。
  • 要求は開発者が自分達で定義する。
  • 製造だけでなく設計を計測して改善する。

2017年のメモ（１）

  • 原則や方程式は、ある前提・制約のもとで成り立つもの。確率統計的に、考えられたもの、証明されたもの。

    • 前提・制約が変化する度に見直す必要あり。前提・制約の変化に気づくべき。
    • 時間が経つと成り立たなくなるかも、場所が変わると成り立たなくかも、人が変わると成り立たなくかも。

  • 今まで常識だと教え込まれてきたことが、実は間違っているということ（証明されていないということ）が、自分の身の回りでも、結構あるかもしれない。

    • 最近、子供向けの本で、ティラノサウルスに毛が生えました。昔の本では、ティラノサウルスに毛がありません。常識が変わりつつある過渡期でしょうか。同じようことが、ソフトウェア開発の常識にも当てはまるかもしれません。

2017年のメモ（２）

小川清さんをはじめとするいろいろ方に教えていただき、少しずつ実感できるようになってきたこと。

  • プロセスは、計測しコントロールするために、定義する。
  • プロセスは、改善点をあきらかにするために、定義する(活動が目に見えるようにする)。
  • プロセスは、トレーニングや適材適所への人の割り当てのために、定義する(活動を分解する)。
  • プロセスが定義されている状態が、目指すゴールではない、ゴール達成のための土台。

2019年のメモ

アセスメントで有事（不具合発覚時など）への対応をみれば、ほとんどのプロセスが確認できる。

  • 平時ではなく有事（不具合発覚時など）の振る舞いを見ることで、個人・組織の能力がよく把握できる。平時ではなく有事の対応からのほうが、学習・能力向上をさせやすい。 ※まだ、教えてもらっただけで、自分としては仮説の状態。ただ、自分の経験則では、活用できる有益な知見。
  • 忙しいときや緊急のときに、できなくなる・やらなくなるということは、本当にやることを理解しているか怪しい。理解していないから、やらなくなるのかも。
  • 忙しいときや緊急のときに、できなくなる・やらなくなるということは、本当は無駄な（or 価値が小さい）ことをやっていたのかも。いらないことだったから、やらなくなるのかも。

SPA研かSPEAKの研修でお聞きした話

  • プロセスモデルはアセスメント対象を観察してするための窓の用なもの。
  • プロセスモデルからプロセス領域全体の地図のようなものを頭に描いておき、インタビューで書いたことをその地図に紐づけていく。
  • 一つの事象が複数のプロセスに紐づく事象の場合もある。
  • アセッシーへのアンケートを通して、アセスメントへのフィードバックを得ることも有効。

思いつき

既存の欠陥の予見

  • プロセスアセスメントとドキュメントレビュー（キーワード検索)と静的コード解析で、既存の欠陥を予見したい。そのために、欠陥モデリングで、欠陥混入のメカニズムを理解・蓄積しておく。また、キーワード検索のために、テキストマイニングも活用する。
  • ソースコードの怪しい箇所、危ない箇所を特定するためのキーワードを抽出し、活用。例えば、「〇〇はありえないため、未実装or処理不要」というコメントがあり、elseの中が空っぽの箇所。
  • 変更開発では、ベース成果で不足している視点を抽出することが重要。例えば、状態遷移表があるかを確認。例えば、データの初期化タイミングの定義があるかの確認。なければ、その視点で、設計・検証できていない可能性が高い。
  • メールの件数を分析することで、組織構造の設計の良くないところを発見できるかも。組織構造の複雑度を下げるための設計ができるかも。

関連研究：
https://www.ipa.go.jp/files/000030061.pdf?fbclid=IwAR1Us9vW7nC6jO7GBt_lRA6JJcEfpbV5NNW2jgHMLz6BqBnqHXAKZ1P5bIs

失敗プロジェクトだけではなく成功プロジェクトもアセスメントする

成功事例を分析し、形式知化し、組織で活用するために、プロセスアセスメントが活用できるのかも。
プロセスアセスメントは、悪いことを見つけることより、良いことを見つけることに、重点をおいたほうが、効果的かも。

振り返ってみると、すでにいろいろな方から、教えていただいていた。

  • 低いレベルのチームを改善しようとするが、高いレベルのチームの良さを分析していないことが多い。（松尾谷徹氏より）
  • 失敗の原因を取り除くマネージメントだけでなく、成功の要因を展開するマネージメントが必要。（芳賀氏より）
  • 成功事例から得られる暗黙知を形式知化することは重要だが、成功事例は分析されにくい。（実践！ソフトウェア品質向上のための原因分析セミナーより）

おまけ

組織・人の行動様式を、短時間で、ざっくりと掴むための3つの視点

ある方から、「組織・人の行動様式を、短時間で、ざっくりと掴むための3つの視点」を考えてみなさいと宿題をいただいた。

それに対する答えは以下であると考えた。

  • 開始時間を守るか？
  • 反論するか？
  • 整理整頓されてるか？

2つはヒントを教えていただいたこと。１つは考えてみたこと。
アセスメントは、新たなことに気づかせるではなく、なんとなく思ってたことを、明確に認識させるだけでも、価値あり。問題を明確に認識できれば、行動に移せる。
フィードバックセッションで、アセスメントの結果に対して反論があるのは、悪いことではない。短時間のアセスメントで、全てを明らかにできるわけがない。何か明らかできていないことがあるはず。アセッシとアセッサの共同作業で、問題を明らかにしていく。

組織・人の行動様式を、短時間で、ざっくりと掴むための視点として、以下もあるかもしれない。

  • よいPCを使っているか？（組織がエンジニアを十分に支援しているか？）

関連記事