aretan.jp

ICT応用S&S品質向上の技術戦略とSQuaREシリーズによるS&S品質要求定義、測定及び評価の実際¶

早稲田大学 理工学術院 名誉教授 東

４：ネット社会では利用者が加害者になってしまう事がある
５：品質を作り込むためのプロセスをデザインして実行する
６：プロジェクト包含組織及び支援組織の能力の管理
７：節電運動とかやりはじめるけど、息切れする。継続的努力が重要
９：QCDだけでプロジェクト管理ができるわけじゃない、pmbokを参照、リスク管理(R)
１１：特に問題ない内容であればプロセスを開示すればいい
赤福は冷凍してる事をちゃんと言ってればよかった
ワーゲンはディーゼルの車が悪かっただけなのに、全体的に売れなくなってしまった
昔はTQCだった。Controlは与えられたルートが守れる事、Managamentはその目標を作る事
下から上にあげられない雰囲気（風通しが悪い）
１３：プロジェクト毎にどの特性が重要かを選ぶ、３つぐらいは選ぼう（副特性）
応答時間が1.5秒以内みたいにガイドライン（基準）を作る
１７：リスク管理の考え方があれば、原子力みたいな政府の対応とかが無いんじゃないか
公園の児童遊具が危ないからなくなった、しかしそれって利用者の責任でしょう？
２２：機能が足りないというような不満からニーズが生まれる
２４：安全なものを作ろうっていうのは無理、安全は結果である。リスク回避性。
２６：システムの品質を測定するだけでなく、データの品質も測定する必要がある。
２９：スキージャンプは飛行距離は客観的、ポーズや着地の美しさは主観的
３０：うっかりミスを見つけれるような仕組みを作る必要がある
関数の複雑さが増えすぎた時に関数をわける事で、バグ率が減った。
３１：SQuaREで不足する場合は、こうふうにして属性を作る。
３３：GQM技法でもできる
３５：できる情報ニーズ
３６：ダメな子はダメな子、経験年数と技術は関係無いね
３７：このフェーズではこの測定をしますよというのを決めりゃいい
３９：要求仕様を凍結なんてできない、変化に強いソフトウェアを作るしか無い
４０：パスタ屋でやりかたを全部いうなんてしないよね
４４：システム要求とソフトウェア要求を切り分ける事が大切
４５：知ってる人はちゃんと言ってあげないとダメ、要求だけ押さえるのは悪い
４８：最重要、重要、余裕でわけるのはとても効果がある、選択理由は大切
４９：保守性とかは内部品質に関わってくる
５１：コンビニの発注管理システムとかを８人とかでやらせる
５２：不満から良くするのが改善アプローチ、不良在庫機会損失のような状況からやるのがデザインアプローチ
６７：IPAのSEC

SWQCでみんなで一緒につくる、成功体験をつくる達成感をつくる。

若手が自律的に育つ環境とは　株式会社SHIFT¶

http://jasst.jp/symposium/jasst17tokyo/pdf/D5.pdf

未経験＞トレーニー＞スクリプター＞アーキテクト補佐＞アーキテクト＞シニア
アーキテクトの定義：どっちもできる
　技術＞基盤・テスト自動化
　マネ＞案件管理・顧客折衝
どうやら先輩は膨大な前提知識をもっているようだぞ
受け取れるミットを広くするように努力した

上司の仕事を分解し、影響範囲が大きい順から勉強
営業や常駐業務に同行して実施内容から全体像を理解
必要なのはアーキテクトであって作業者ではない

手動テストチームを担当すると大変だった
考える仕事と管理する仕事を並行できない
上司も先輩もいなくなり自分しかいない

裁量＋責任で自分ごととして捉える

自動テストはとても労力がかかるわりに効果が部分的
同時にキャリアに悩み始めてモチベーション低下
誰も教えてくれるわけじゃないから、がんばるように

求人票をみてトレンドを把握する
客に提案するようにした

部分最適をいくらしても、全体最適にならない
本質的な価値は顧客に届く、そのスループットを最大化することをターゲットに

勝手に潰れられても困る
素直に事実を伝える
がんばってる自分っていう感じでヨガってるのはよくないよね

内的要因
自分にあった目標設定
勉強方法の確立

外的要因
スポンサー
見習う人たちがいる
挑戦していい安心感

お金とか叱責だと短期的な効果しかない
内発的に動かす事によって２２％じゃない部分を使う必要がある
興味関心・楽しい嬉しい・グリップ感・感謝

目標設定
長期目標は決めない
Planned Happen Stance Theory
キャリアで成功する人はだいたいキャリア的跳躍がある
点と点が線になる
などなど、積み上げ式の崩壊が起こっている

中期目標
ワクワクする目標を立てる
→貢献度で判別
→検証

例：テスト自動化アーキテクトになる、DevOpsエンジニア

中期目標を分解して短期目標に変換
Progate。。。の講座を終わらせる
Linuxでwordpresを動かす
JSTQBを取る
Agileの概念

非連続的に変化することよりもグラデーションのように連続的に改善

概要＞基礎＞応用

概要：ネット情報
基礎：薄い本、dotinstallやprogateでやる
応用：本格的な本や関連技術をさらう

外的要因の分析
スポンサーとは、理解されチャンスもあたえれる

自律的に動ける環境：都合よくはいかない、環境や裁量
判断軸が与えられると自律的に動けるように

多様な環境：狙ったように成長しない
自動化案件・QA業務・プリセールス・採用

先輩達の背中を見て育つ
異質な現場を複数体験させる
強いエンパワーメント

提案にいいねっていわれたりして、どんどん良くする
提案はだいたいしっぱいして窮地からの先輩のフォロー
やったことにたいして詰められるのは当たり前だよね

まとめ：判断軸となる全体目標と目的を与えた上で・・・

保守が大変でメリットが生きてないんじゃないかなー
とおもったら、一度最初の目的に立ち返って考えてもいい。

JSTQBは本当に勉強になった
ソフトウェアテストの教科書はいい本

メルカリでQAプロセスを構築した¶

メルカリに初QA担当としてJOINした
１５名でQA１人でやってたら、追いつかなくなった
プロダクトの成長にフォーカスをあてていく
属人化を許容していくというスタイル

ケースを作成しないって決めた
・正常系のテストの不具合率の発見の低さ
・プロダクトの理解
・探索的テストの徹底強化

エビデンスが出ないよね？→テストの実行結果にたいしてレビューすることに
不具合のあたりをつけ、システムを理解する
エンジニアと外部設計レベルのコミュニケーション
検証結果にアクセスログをエビデンスにすることで、検証結果の妥当性を向上
不具合報告の精度、不具合報告はエラーログを使う

何をリスクとして許容していくか次第とは思うけど、だいたいあってんじゃね？

組み込みとwebのQAの違い LINE¶

開発者との距離：生産性向上のため、いかに開発と協業するかというのが求められる
プロダクトに関与できる裁量：ボトムアップしやすい、現場の意見が反映されやすい
品質の重要性の浸透：すぐなおせる、専属のQAを持たない組織が存在していた
テストリソース・スケジュール：限られたテストサイクルでカバレッジを確保する
QAエンジニアの地位：やっぱ組み込みの方が普通に高い

QA組織は横串でも、仕様策定段階からコミット
プロダクトに求められている品質基準を意識する（過剰品質にならぬように）
Trivial Bugは許容していく、軽微な問題は次のサイクルに持ち越す
問題解決の領域を広くする、制約がある中でも課題解決できるように

ソフトウェアの品質保証の本質 NARAコンサルティング¶

黎明期　隆盛期　定着成長期　停滞期　再生期→発展期？

組織の現状は？
1.QMSはありますか？
・全社もしくは事業部門にある
・部門単位である
・上記のいずれもある
2.QMS活用の実態は？
・ほぼその通りに行われている
・参考にはしている
・ほぼ使われていない

品質保証とは？
品質要求事項が満たされるという確信を与えることに焦点を合わせた品質マネージメントの一部
品質マネージメント：品質に関して組織を指揮し、管理するために調整された活動
→品質計画、品質管理、品質保証、品質改善
品質保証の活動範囲は品質マネージメントのうち、品質計画、品質管理、品質改善を除いた部分
消費者の要求する品質が十分に満たされていることを保証する、体系的活動。
品質保証は品質管理の真髄、品質リスクを最小にする活動。
ソフトウェア品質保証は、全プロセス、全組織・全員参加、多岐にわたる活動
＜＜よくある誤解＞＞品質保証はまかせた

日本的品質保証：お客様が満足したという結果をもって成果を図る
欧米的品質保証：品質保証していることの「実証」を最重視して発展
ソフトウェア工学の問題：複雑性、順応性、不可視性、変更可能性

１９７０年：ソフトウェア工場
最終成果物の検査、ソフトウェアの素性を明らかにしたドキュメントが必要
日立だと品質保証部門に権限と責任がある、大変だから出荷しないほうがいい
中間成果物のドキュメント検査：最終品質の予測

１９８０年：品質管理重視
PDCA、QCの７つ道具、全員参加、小集団活動
ソフトウェア検査部門の独立（開発の全プロセスに対して関与）
クスマノさん「日本のソフトウェア戦略」
基本設計＞機能設計＞構造設計＞コーディング＞テストデバッグ
V字モデルとV&Vが出てきたのがこの時期
品質管理図はいろんなことがわかるからおすすめ
これが現在に継承され、進化しているか？
検証と妥当性確認は違う
QA PM 生産技術の強化により開発部門の自由度、自主性の剥奪

１９９０年前半：エビデンスを作る作業
ISO9000の台頭、良いプロセスが良いプロダクトを生み出す
プロセスは専門家が作るとの悪しき習慣化
監査が入るようになった、監査、監査、監査
SE-CMMが発表　プラクティスが明確、枠組みがスマート
プロセスの自由度が開発部門からさらに剥奪？
プロセスVSプロダクトの不毛な対立が勃発

１９９０年中半：オープン化
作るから使うへ、グッドイナッフ、短サイクル、ベンダーの多様化
PMの採用
誤解１：技術的問題をマネージメントで解決しようとした
誤解２：PMP取得がすべてを解決する
誤解３：PMrにすべてを押し付ける
プロジェクトマネージャーを監視する資格
課題解決に直接手を出せない
スコープが不明確（エンドユーザ指向）
一発勝負で短納期
オープンシステムのいろいろなものがでてきた

２０００年代：
本格的PMSの開発と適用、ノウハウの蓄積と活用
ISO 9001-2000（品質マネージメントシステムへ）
CMMIの発行：改善手法
PPQAの本格的な取り組み：プロセスVSプロダクトの脱却
V字モデル拡張版の提案と試行
日本的品質管理の再評価とリニューアル適用
TQC的SPI、品質改善の復活
工学的にちゃんとしてきた
ソフトウェアインスペクション：合否判定
改善じゃなくて最適化と呼ぶのはどうか
計れないものは、制御できない ISO9126
計測事象＝因果関係＋バイアス＋偶発性

QAつくりました、結果がでません。
なんでつくったの？なにをさせたいの？を明確にしよう
テストをする部門にしちゃだめ

データとれあれやれこれやれってなってるけど
ちゃんと意味わかってやってんの？
組織が成熟してきたとはいえ、もっと変えていきゃいいのに
PSP（個人）、TSP（チーム）、CMM（組織）
技術者としてこれぐらいできないといけないよってのがある
コーディングすることだけが仕事だとおもってる
ソフトウェア工学を勉強してこい

どういう勉強すればいいですか？
困ってないと勉強しない、困ってることから進める

こういうことやっちゃだめだよ
思い込みでやっちゃうのは絶対失敗するよね
言うのであれば裏とってかないといけない

まずはギブして、それからテイクしてもらう
一方的な提案にならないようにする
どうやったら俺の味方にできるか

品質保証のネガティブなイメージは無くならない？
一人一人が品質保証部門について正しい理解を示さないといけない

立ち上げの時に奈良さんは何を言う？
立ち位置をはっきりさせる
QMSを回すのが仕事、レビューとかは作業。

顧客対応をする事で、開発部門に貢献しているなど、
どう貢献できるかを考える事で、ネガティブでなくなる？

プロセスの品質保証、開発リーダーに話し合ってやる事にしている
リーダー層はわかってるが、担当レベルではわかっていない事が多い
やるって言った事を部門長がちゃんと浸透させるべき

おっさんが若い子にちゃんと意味をおしえてかないといけない

品質保証とは、作ったものに対して、責任をもつ
立ち止まって一回考える、ちゃんと道筋を立てるべき、
振り返って道があってるかを確認しよう