秋山浩一現在地 Tokyo, Japan 自己紹介 Software Testing Specialist. フォローしている 224 フォローされている 826 リスト 111 Twitter歴 1,217日 （2009/01/29より） ツイート数 12,400 （10.1件/日）
影響力
ツイートの並び順 : 新→古 | 古→新
もし、そうだとするとSFマトリクスの今後の課題に書いてある「SFマトリクスから結合テストケースを作成する際の詳細な手順（３機能連携など）、および適切なカバレッジの基準」って、2-スイッチカバレッジで良いのでは？ #SQiP2011 posted at 11:13:46 齊田さん： SI系企業の品質保証部門では、1人あたり約50名を見ている。製品系企業では17名。製品系は自分でテストもしている場合があるので少ないのではないでしょうか。 #SQiP2011 posted at 11:19:20 齊田さん： 「品質保証部門の管理対象の広がり × 全社の成熟度（1~5段階）」でポジショニングマップを作成し、品質保証プロセスの発達段階（進化）を定義できるのではないかという仮説を立てました。 #SQiP2011 posted at 11:26:59 齊田さん： 品質保証部門のプロセスが段階的に進化するためにすべきこと、1. 品証で管理ルールを作り展開する、2. ラインと品証が一体となった活動、3. 品証は管理から共有へ。 #SQiP2011 posted at 11:34:33 齊田さん： 品質保証部門の最終形態は品証が直接管理するのではなく（管理対象部門は減り）新しい価値を生み出す品証部門になるべき。つまり、組織間の情報共有や相談窓口の役割、また、社外事例ノウハウの自社への取り込み、お客様の要望分析や結果の共有などの役割を担うべき。 #SQiP2011 posted at 11:38:10 齊田さん： まとめ。はじめは管理することがゴールだと思っていたが、品質保証部門として新たな価値を創造していくことが重要でないかという議論になった。 #SQiP2011 posted at 11:44:51 向山さん： 決定的なものはないが、ツールを使ったあいまい用語件数チェック、最終更新日付・時刻を見る（夜中未明だったらあやしい）、作成と承認の日付が離れているとトレーサビリティの問題の可能性があるなど。 #SQiP2011 posted at 12:19:08 千綿さん： 想定外をなくすためには「予見可能性：問題が発生する可能性があることを事前に認識できたかどうか」と「結果回避可能性：問題発生を防止する方法はあったのか？」を結果レビューし、書きものにして情報を共有し、それを要件に盛り込んでいく。 #SQiP2011 posted at 12:29:24 千綿さん： 各工程での品質確保の判断には、工程完了時に報告される情報だけではなく、中身を見ていくことがポイント。また、厚生完了条件だけでなく、工程開始条件も重要。 #SQiP2011 posted at 12:31:42 千綿さん： その3。プロジェクトの健全性の判断、すなわち、プロジェクトがこけそうな兆候をつかむ方法を考えたい場合は、EVMを使って工程×コストの関係を管理していくとよいでしょう。 #SQiP2011 posted at 12:35:43 千綿さん： 「品質意識」の向上が一番重要。そのために「身近な話題で、従業員の心に響く情報発信」、「体験型の教育、参加型の活動」、「何よりも重要なのは、目標、想いを共有」していく。 #SQiP2011 posted at 12:47:09 SQiPシンポジウム、まもなく最後のパネルセッションが始まります。パネルの司会は吉澤智美（さとみ）さん。パネリストは、栗田太郎さん、笹部進さん、山浦恒央さん、細川宣啓さん。アドバイザーとして特別公演の前村孝志さんです。 #SQiP2011 posted at 15:45:28 「ソフトウェア品質エンジニアリングと聞いて何を思い浮かべますか？」という話題。まずは、山浦さん。「品質エンジニアよ、大志をいだけ」。日立ソフトウェアエンジニアリングに29年務め、2006年から東海大学大学院組込み技術研究科に勤めています。 #SQiP2011 posted at 16:05:02 品質エンジニアには高度な技術と想像力が必須。品質は技術者の良心でありプライド。プログラマはソフトウェアを開発します。品質エンジニアは品質を改善します。品質制御のすべてのプロセスでプログラマに対して指導的な立場をとるべき。 #SQiP2011 posted at 16:08:54 次は、笹部さん1972年にNECに入社しました。入社して3年目にソフトウェアに転じ、3年前に退職。1992年からSPC(SQiPの前身）のお手伝いをしています。 #SQiP2011 posted at 16:10:14 細川さん、レビューの専門家です。「社会影響の大きさ、専門性と技術領域の広さ、シンプルだが強力である、原点回帰、現場・現物・現実、“恐れ”の制御、欠陥エンジニアリング、一人で成立しない分野」といったキーワードでかたれるのではないか。 #SQiP2011 posted at 16:23:22 「ソフトウェアを作るときに伝統的なTQMは役に立つのか？ NECでは応用して成果を上げている。 もちろん、ソフトウェアなりの品質会計という考えをいれてきた。」笹部さん。 #SQiP2011 posted at 16:46:51 前村さん： 使う側の立場から質問させてください。ロケットの世界ではソフトウェアの失敗が毎回ある。品質を作ることは使う人に安心感をあたえることと思っているんですが、「大丈夫です」としか言ってくれない。証明や可視化は？ #SQiP2011 posted at 16:54:07 笹部さん： 原因と結果。因果関係の理屈がわかっていれば安心してもらえる。ソフトウェアは可視化するのが有効な手順。あるべき姿を描くのは難しいので、考えたことの網羅性で安心していただく。 #SQiP2011 posted at 16:56:51 栗田さん： それは不可能です。できることは、モデルを作ってその範囲で確認することだけ。あとは、プロセス（進め方）を確認してもらい安心してもらう。あとは、第三者検証会社にみてもらうが、第三者検証会社が問題ないかという話が出てくる。 #SQiP2011 posted at 16:59:00 大野さん殴り込みキター： ソフトウェアの世界で、問題に対して問題なくものを作る（制約した状態にして、制約した範囲にのみ保証する）という方法があります。 #SQiP2011 posted at 17:11:49 細川さん： ルールを決めると、ルールの呪縛で考えることをやめてしまうという問題がある。過去の古典を踏まえてより良い工夫・改善を継続してくわえていけばよい。 #SQiP2011 posted at 17:21:24 山浦さん： ソフトウェアは縛られる物理的法則が全くない。何をやってもOK。人による選択肢が広すぎる。「心地よい制約を付けてあげると良いのではないか（構造化設計技法とか）」品質については、プロセスに制約を付けると良いのではないか。 #SQiP2011 posted at 17:24:13 笹部さん： 情報のリソース、知識のリソースをもっとつぎ込みたい。ICTの発達により以前より情報がうまく回る仕組みを作りやすくなっている。これからそれを考えていきたい。 #SQiP2011 posted at 17:25:58
製糸メーカーのジャガード・モケット織物生産システムの事例。巻き取られた糸の芯のところにRFIDを埋め込み生産管理した。試して動かして試して動かしてなので、アジャイル以外しようがなかった。稼働して2年、バグゼロ。 #SQiP2011 posted at 14:34:20 ドキュメントはメモ的なものだけど、タイムチャートとかを最初に作った。メンバーは80%稼働。納品後はバグ2件（ごめんさっき聞き間違えたらしい）、ただし機械調整てきなもの。 #SQiP2011 posted at 14:37:30 一回の作業単位の中で、前の作業単位で出た問題を解決してきた。新しいメンバーに対して「ドキュメント読んでおいてください」よりも、少々時間がかかっても全員でワークショップをやって立ち上げた方が成果がでた。 #SQiP2011 posted at 14:39:27 タスクの平準化をソフトウェアにも適用した。全く異なる機能実装イテレーションに対しても同じ粒度で平準化することで見積もり制度・実績ともあがった。 #SQiP2011 posted at 14:42:52 三井さんの講演が終わり、これからパネルです。まずは、自己紹介から。「みなさんこんにちは。日本HPの湯本です。テストツールの導入支援コンサルをしています。Quality Centerといいます。1階にパンフレットを置いたので持って帰ってもらえるとうれしいです」 #SQiP2011 posted at 14:55:52 「永田です。会社では品質保証をしています。何をしたら世間で言われているようにアジャイルで上手くいくのか。本に書いてあるような順調な時ばかりじゃない。本にあるのは設計者側のテストかなと思う。品質保証のテスト（システムテスト）の話が抜けている。外国の本を読んでも」 #SQiP2011 posted at 15:01:15 永田さん： 「バックログインフレーション問題」がある。要求・変更・追加をアジャイルで受けているとどんどんバックログが増えてしまいませんか？ このマネジメントをどうするんですか？？ #SQiP2011 posted at 15:02:31 永田さん： さらに、品質が悪ければバグの対応も開発に積みあがります。品質保証にも回帰テストが増えます。あれ？ どうするんですか？？ 基本的なところができていないとバックログがインフレーションします。どうしたらよいか聞きたい。 #SQiP2011 posted at 15:04:22 湯本さん： アジャイルで失敗したらプロジェクトやめちゃえばよいといわれると実際は困る。そのプロジェクトは、アジャイルじゃなくて、ウォータフォールだとできるのですか？ #SQiP2011 posted at 15:17:43 永田さん： アジャイルだからプロジェクトが失敗するのではなく、ウォータフォールだって失敗しただろう。アジャイルだと2週間でまずいことがわかって止められるということが良いともいえる。 #SQiP2011 posted at 15:20:33 会場の金子さん： ポイントはアーキテクチャ。アーキテクチャが明確だからアジャイル？明確じゃないからアジャイル？ アーキテクチャがきれいでアルゴリズムがわかっているからアジャイルがうまくいくのかどちらなのか？ #SQiP2011 posted at 15:26:44 三井さん： 3つくらいのアーキテクチャを考えてその良し悪しを検証するイテレーションを行うこともある。また、優秀なアーキテクチャをアジャイルチームのオブザーバに配置することもある。 #SQiP2011 posted at 15:30:31 永田さん： 「要求プロセス」の議論がアジャイルでは不足していると思う。要求が直接バックログに入ってしまうのはおかしい。ここ（要求プロセス）をちゃんと考えないといけない。 #SQiP2011 posted at 15:32:24 昔からいいねと言われてきたことがいいのは分かっているので、明日のためにじゃあ、どういう方向で進むの、どんなコンセプトが大切なの、アジャイルやって何が新しくわかったのということを話してほしい。 #SQiP2011 posted at 15:36:16 会場質問（さかいさん）： ウォータフォールとアジャイルの共通点の話が多い。アジャイルの良さとしては「失敗がすぐにわかる」という話はあったが、他にどういったことがあるのか？ #SQiP2011 posted at 15:40:37 製糸工場の生産システムの例で言えばアジャイルを使ったことで、具体的になぜ早く、品質が上がったのか、その原因が語られてなかったのが気になっていたのですが、そういう人だったのか。 #SQiP2011 posted at 15:47:26 にしさん： アジャイルって基本的に外人が考えて、輸入して喜んでいる人がいて、現場が活性化するからいいって人がいるんだけど技術的に優れているところがよくわからなくて、品証の人は「開発者のプラクティスだから」っていう。 #SQiP2011 posted at 15:57:39 にしさん： 私は、アジャイルはソフトウェア工学の正統的な進化形だと思っているのだけれど、明日の品質保証につながるポイントをみなさん話してみていただけるといいのでは。 #SQiP2011 posted at 15:58:30 永田さん： ソフトウェア工学的には特別なことはないと思っている。良い点はQA、テストエンジニアが「農耕型から狩猟型」になること。朝練でKPTをまわすのはスケジュールをデイリーで管理していること。情報がダイナミック流れる。そこにQA・テストが参加するのが良い。 #SQiP2011 posted at 16:01:58 
|
last update 05/28 17:14
ツイート検索
Recent
Archives
Friends
Hashtags
Stats・Feed |
