勝手にソフトウェア保守開発

ＳＥＲＣＦｏｒｕｍ（Ｊｕｌ）

2011-07-05T09:37:00.002+09:00

この度、ソフトウェア・メインテナンス関連のフォーラムを開催します。

皆さんの参加をお待ちしております。

--------------------------------------------------------------------------------
SERCフォーラム

　　　ソフトウェア保守プロセスの成熟度を考える

主催
ソフトウェア・メインテナンス研究会(SERC)
http://www.smsg.or.jp/
--------------------------------------------------------------------------------
ソフトウェア・メインテナンス研究会(SERC)は1990年の設立以来，国内唯一のソフトウ
ェア進化・保守に関する研究グループとして，ソフトウェア保守の諸問題に焦点を当て，
さまざまな観点から解決策を探ってまいりました。

私達SERCは，ソフトウェアが社会インフラの構築・運用・維持に欠くことの出来ない重
要なコンポーネントとなった今日，ソフトウェアの品質確保が重要な課題と考えています。
ソフトウェア保守開発は既に稼働するシステム（サービス）品質の維持が必須であり，新
規開発とは異なる品質確保のための注意が必要です。そして，この品質確保のためにはプ
ロセスが重要となりますが，ソフトウェア保守開発は，大から小まで様々な案件の規模，
予め計画できない緊急の障害対応などの特徴のため，新規開発に比べてプロセスの成熟が
困難なことも，ソフトウェア保守の課題の一つとなっております。

　そこで今回のSERCフォーラムでは，「ソフトウェア保守プロセスの成熟度を考える」と
題し，ソフトウェア保守開発におけるプロセス成熟の現状と課題，今後目指すべき姿を考
えたいと思います。
　まず，当研究会研究員が，論文『 Software Maitenance Maturity Model: The software
maintenance Process Modelより』より，「ソフトウェア保守プロセス向上のポイント」
を紹介いたします。続いて，ソフトウェア保守の現場から，「ソフトウェア保守現場にお
けるプロセス成熟度向上の実践事例」を紹介いたします。
　この発表を通して，発表例の少ない保守の現状事例を聞くことができるため，これと比
較することにより自らが関係する保守部門の成熟度どの程度か判断できることになります。
さらに，ミニパネルの議論に参加して頂くことにより，今後の改善に繋がるものを持ち帰
って頂けるもの，と自負しております。

　近年，このフォーラムの後で開催される情報サービス産業協会主催の「ソフトウェア・
プロセス・エンジニアリング・シンポジウム」の事例研究やチュートリアルセッションで
もソフトウェア保守の話題が多数取り上げられておりますように、ソフトウェア保守に対
す注目が高まっております。さらに気軽に参加できるSERCフォーラムでソフトウェア保守
について考えてみませんか？

多くの皆さまのご参加をお待ちしております。

＜講師略歴＞
●高橋　芳広（SERC　研究員）
「ソフトウェアの基本は保守にあり」を信念に，ソフトウェアの保守開発や進化のプロセ
ス改善をテーマとして，実践や文献の研究を継続している。「全ては，ソフトウェア保守
から学んだ」と語り，ソフトウェア保守に関する情報発信Webサイト「勝手にソフトウェア
保守開発」を運営している。「ソフトウェア保守の１０カ条」「保守者から開発者への
１０のお願い」などの主張がある。
　情報処理学会（正会員），Association for Computing Machinery（Professional
　Member），ソフトウェア技術者ネットワーク（幹事）

●増井　和也（SERC　幹事）
　SERC創設（1990年）以来，ソフトウェアの保守開発や進化のプロセス改善をテーマとし
て，実践を通して研究を継続している（創設２年目より現在までSERC幹事）。
　ソフトウェア開発との違いをイメージ化したソフトウェア保守の「ふたこぶラクダ」モ
デルを提唱し，現在まで，各種学会等主催のシンポジウム，フォーラム，セミナー，ＩＴ
系雑誌等でソフトウェア保守や進化に関する発表多数。
2002年（2008年改訂）のJIS X0161（ISO/IEC14764準拠）原案作成委員。
2007年『～ISO14764における～ソフトウェア保守開発』（共著）。　

《開催要領》

●日時：2011年7月22日（金）13:30-17:00（受付 13:00-)

●プログラム
13:00 - 13:30 受付
13:30 - 13:40 開会の挨拶
13:40 - 14:25 SERC研究員講演１
タイトル：「ソフトウェア保守プロセス成熟度の向上のポイント
Software Maintenance Maturity Model: The software
　　　　　　　　　　　　　　　 maintenance Process Modelより」
講師：高橋　芳広（日立ソリューションズ）

14:25 - 15:10 SERC研究員講演２
タイトル：「ソフトウェア保守現場におけるプロセス成熟度向上の実
践事例と課題・・・SERC研究成果より」
講師: 増井　和也（東芝ソリューション）

15:10 - 15:20　休息

15:20 - 16:50　パネル討論
　　　　　　　　　パネラー：
　　　　　　　　　　　　増井　和也（東芝ソリューション）
　　　　　　　　　　　　高橋　芳広（日立ソリューションズ）
16:50 - 17:00　クロージング

●会場：新宿歴史博物館　講堂
　　　　　東京都新宿区三栄町22番地
JR・東京メトロ丸ノ内線・南北線「四ツ谷駅」下車　徒歩10分
東京メトロ丸ノ内線「四谷三丁目駅」下車　徒歩8分
都営地下鉄新宿線「曙橋駅」下車　徒歩8分
　　　　　地図：＜http://www.regasu-shinjuku.or.jp/?p=91＞

●定員：40名（先着順）

●参加費：SERC研究員無料，一般 1,000円
当日，会場受付にて現金でお支払いください，領収書を差し上げます（お釣り
　　　　　　のないようにお願いします）。

●申込方法：
下記申込用紙の形式に必要事項を御記入の上，SERC事務局(smsg-
secretariat[at]smsg.or.jp) に
メールにてお申込みください。
当日パネルで討論したいテーマや課題があれば申込票の最後にご記入ください。
折り返し，受講票をメールで送りますので，当日，持参ください。
定員超過でお申込をお断りする場合には，メールにてご連絡いたします。
申込み締切日以降のキャンセルは実費を頂きます。

●申込み宛先: ソフトウェア・メインテナンス研究会(SERC)事務局
E-Mail: smsg-secretariat[at]smsg.or.jp

●申込み締切：　2011年7月19日（火）

　●情報交換会：　フォーラム終了後に近隣で情報交換会を実施いたしますので，
　　　　　　　　　ご興味のある方はご参加ください。
　　　　　　　　　参加される方は実費のご負担お願いします。
　　　　　　　　　詳細はフォーラム中にご案内いたします。

=======================================================================
2011年7月 SERCフォーラム参加申込用紙

氏名 (ふりがな)： _______________ (________________________)

会社名： _____________________________________________________________

部門・役職： _________________________________________________________

住所： (〒____-______) ________________________________________________

Tel: _____________________ Fax: _____________________

E-Mail: ___________________________________

種別 (該当欄にチェック):
□SERC研究員（無料）　 □一般（1,000円）

領収書の宛名：___________________________

討論のテーマ　_____________________________________________________________

_________________________________________________________________________

_________________________________________________________________________

SS2010　6/11　午前

2010-06-14T22:08:00.002+09:00

新たなソフトウェアが生み出されるきっかけ
ドリームボート　金子勇氏

●これまでの経緯
　・学部、院（1989年～1999年）
　　→オブジェクト指向によるシミュレーション
　　→DB、OS、３D、可視化
　　→Windows　95
　　　IBM/PC
　　　インターネット（ナローバンド）
　　→リアルタイムシミュレーション
　　　こん
　　→技術的背景（95年ぐらい）
　　　３DCG専用ハードウェアの登場
　　　Windowsアクセラレータ
　　　３DCG技術がPC上でも一般化
　　→フリーソフト開発・公開
　　　NekoFligtフライトシミュレータ
　　　NiftyServeで公開
　　　　雑誌
　　　　自分のHP
　　　基本的な３DCG技術・数値計算などを
　・2000年から2002年
　　→日本原子力研究所
　　　地球シミュレータ向け歌手か
　　→３DCG関連のソフトウェア群を公開
　　　ゲーム作成者向けのサンプルを公開
　　→技術的背景
　　　３GCG技術の一般への普及（ゲーム機）
　　　シミュレーション
　　→PS2の登場
　　　エモーションエンジン
　　　確かにハードウェアは凄い
　　　ソフトウェアは
　　→当時
　　　ゲーム製作者へ向けたプログラム公開
　　　数値計算によるモーション生成（物理演算）
　　→AB法（アルゴリズムを考案）
　　　リアルタイム向け
　　　数値計算（数値積分）による運動解析
　　　制約の多いリアルタイムゲーム向きではない
　　　そこで、数値微分と数値積分を組み合わせる手法
　　　→挙動が面白い→フリーソフトサンプル公開
　　→その後
　　　フリーソフト→商用化
　　　３DCG開発会社へ(2000年～2001年）
　・未踏ソフトに参加
　　→IPA未踏ソフトに参加（2000年～2001年）
　　　物理エンジン担当→東京大学助手
　・2002年～2003年
　　→戦略ソフトウェア創造人材育成プログラム
　　　今までにないソフトウェアを目指す
　　　特任助手
　　→当時の技術的背景
　　　ブロードバンド回線の普及
　　　ISDN→ADSL→光回線
　　　※通信回線が早くなった→ソフトウェアは？
　　→個人的趣味
　　　当時P2Pに注目(2002年）
　　　Freenetに感心
　　→Winny開発
　・2004年～2010年現在
　　→大阪高裁で無罪（2009年9月）
　　→検察側上告手続き中
　・現状
　　→Winny技術基盤を使ったコンテンツの配信

●ソフトウェアが生み出されるきっかけとは
　・先行する事象
　　→新しいハードウェアやインフラの登場
　　→その一般への普及
　・ソフトウェアが世に広まるきっかけ
　　→不r-ソフトウェアとしての公開
　　→Webや雑誌などで取り上げられる
　　　→商用化などビジネス的展開
　・タイミングの問題
　　→いつソフトウェアが生み出されるのか？
　　　※ドライバを自作するぐらいの根性が必要
　　→新しい基盤ソフトウェア
　　→ハードウェアが凄いから凄いソフトウェアが作れる
　　→公開されるタイミングが重要
　　→ハードウェアの普及期
　　→時期を外すと広まらない
　・そもそも
　　→ソフトウェアは特定ハードウェアの上で動作
　　→新しいハードから、新しいソフトウェア
　・現状は
　　→PC関連の新規デバイス（あまりない）
　　　近年は新機能より低価格化
　　→通信関連インフラ道既に一般化
　・次に期待できるのは
　　→モバイル関連
　　→プログラマブルなデバイスである必要性

●プログラマさんの生きる道
　・新しいハードウェアに着目
　　→新しいソフトウェアの可能性
　・開発・公開タイミングが重要

Ｑ．フリーウェアとオープンソースについえ

Ａ．気持ちは使う人に向かっているため、
　　プログラマ向けオープンソースには興味がない。
　　そもそも、使う人はソースがオープンかどうかは意識していない。

Ｑ．公開の動機は？

Ａ．面白いと思っている技術をデモしたいという意識がある

SS2010　6/10　午後

2010-06-14T21:55:00.003+09:00

「ソフトウェア不況～ニュー・コモンへの対応～」
IT記者会　佃　均氏

●ソフトウェア不況
　・営業利益率：2006年度は7.98%→9009年は5.95%
　・業界に受け止め方の間違い
　　→リーマンショック（景気低迷）（誤）
　　→デフレスパイラル（値下げ圧力）（誤）
　　→オフショア化（コスト削減）（誤）
　・ソフトウェア産業の収益性は年を追って劣化してきた（正）
　　→142社で毎年2万人人員が増加している
　　→売り上げは伸びないのに人は増えている
　　※利益率が悪化
　　　営業利益率が6%以下ではR&Dや教育投資が出来ない

●ユーザーの投資マインド
　・新規開発から保守運用へ
　　→コンプライアンス
　　→ガバナンス
　　→セキュリティ
　　→持続可能な発展
　・サーバ統合→データの一元化→データの標準化と業務プロセスの見直し
　　→コスト削減
　　→保有から利用へ
　　※工場をどううまく運用するか。
　　※これらを情報サービス会社が掴んでいる必要がある
　　　→ユーザと向かい合うビジネスをやっている会社もある

●過剰な就業者
　・無定見な新規採用
　・安易な外注依存

●さて、何をやっていこうか
　・ユーザと向かい合うこと
　・先進の技術だけを追いかけないこと
　・作りことばかり考えないこと
　・ＩＴですべてを解決しないこと

　※ＩＴ企業の課題は、人が関与すべきこと（あえてＩＴ化しないこと）提案すべき

●トップ集団だけが儲かる構造
　・ソフトウェア受託開発業の2009年度の営業利益の前年比
　　→1000億円超　10社　営業利益率78.4%UP
　　→300億円超　16社　　　　　　　16%Down
　　→100億円超　　　　　　　　　　36%Down
　※とは言え規模の戦争は薦めない。

●ソフトウェア業界に必要な３Ｋ
　・経営
　・計画
　・毅然たる態
　※国家のＩＴ戦略は期待できない→技術者が頑張るしかない

SS2010　6/10　午前

2010-06-14T21:53:00.001+09:00

ＷＧ４　ソフトウェア進化討論
作成中

SS2010　6/9　午後

2010-06-14T21:38:00.001+09:00

ＷＧ４　ソフトウェア進化の討論
まとめ作成中

SS2010　6/9　午前

2010-06-09T09:59:00.007+09:00

10:00　開会の挨拶

10:05　基調講演「ソフトウェア工学の分岐点における、アジャイルの役割」
　　　平鍋　健児氏（（株）チェンジビション、（株）永和システムマネジメント）
●オブジェクト指向の技術だけではプロジェクトの現場がよくならなかっら
　→ソフトウェア・エンジニアリング以外の部分（人・チーム）に着目

●ソフトウェア工学に関する様々な見解
　・トム・デマルコ
　　→Ａタイプ：少数（？）
　　　投資とリターンが決まっているもの（ユーザシステムに多い）
　　　計測と制御に意味がある
　　→Ｂタイプ：大部分
　　　ハイリターンの製品（例えば、１０００万の投資で５億円のリターン）
　　　計測と制御に意味があるのか（？）
　　→ソフトウェア工学は探す場所が間違っていたのではないか

　・エドワード・ヨードン
　　ソフトウェア工学で最も大切な１０の考え方
　　→計測できないものは制御できない
　　→ピープルウェア
　　→インクリメンタル
　　→反復
　　→欠陥が下流にもれると、修正コストが増加する
　　→トレードオフは非線形
　　→再利用は重要
　　→リスクマネジメントがかぎ
　　→一貫性は「才能＋デスマーチ」に勝る
　　→車輪を再発明しない
　　→透明性を重視。何も隠さないこと

　・ヤコブソン
　　→UMLは複雑すぎた
　　　初学者にとってのエントリポイントがない
　　→ソフトエア工学は未熟
　　　方法論の評価方法すらない
　　　産業界の実践と学会の研究の乖離

　・Tomb・Glib
　　ソフトウェア工学はファッション業界のように変わる
　　→ソフトウェア工学の再建
　　　広く合意された要素からなる
　　　技術の問題と人に問題の両方を扱う
　　　産業界、学会、ユーザの支持
　　→ソフトウェア工学の再定義
　　　価値を関係者に届ける

　・Alistair
　　→ロール（メソドロジー）ではなく、顔がある人がやっている

●Agile
　・短いサイクルで並列に行う→人の学習を考慮にいれる
　・スクラム
　　製品のバックログ→スプリントバックログ→出荷可能ソフトウェア
　　※短期間に繰り返しが出来るようになった（オブジェクト指向のおかげ）
　・アジャイル開発宣言
　　プロセスとツール　　→個人との対話　　　（○）
　　包括的なドキュメント→動くソフトウェア　（○）
　　契約と交渉　　　　　→顧客との協調　　　（○）
　　計画に沿うこと　　　→変化への対応　　　（○）
　　※人間の持っている学習、コミュニケーション能力、創発性

　・リーソフトウェア開発によろビジネスの言葉になった
　・アジャイルの方向性
　　→大規模
　　→組織化
　　→リーンとの統合
　・ソフトウェア工学の誕生から、ソフトウェアプロジェクトは失敗し続けている（失敗率は下がっていいない）
　　→アジャイルもこの後破綻しないか？

　・ソフトウェア工学は前に進んでいるが、プロジェクト管理は試行錯誤の状態
　　→ソーシャル工学が必要
　　→ビジネスの視点が必要
　　これらがアジャイルの埋めるべき慮域
●ソフトウェアは「工学＋管理」ではできない。
　→ソフトウェアは「人が」「人のために」作っている
　　議論の場（コミュニティが必要）

Ｑ＆Ａ
Ｑ．人がやる気をもったきっかけの事例はないか？
Ａ．色々やりかたがある
　　・ミッションの明確化
　　・飲み会で語る（思いが一致するとやる気が移る）
　　・共感（暗黙知の共同化）

Ｑ．アジャイルの朝会は意味があるのか？
Ａ．多人数でやると意味がない（最大１５人程度）

Ｑ．アジャイルが何故普及しないのか？
　　契約がネックになっている（管理のコストをかけたくない）
Ａ．日本では契約がネックになっている
　　開発リスクとビジネスリスクを契約で分けるが問題
　　米国のアジャイルは内製が多い

Ｑ．実践データが殆どない。日本でできたらよいのではないか？
Ａ．同感

S-Open　2010年度総会　記念講演聴講記

2010-05-22T14:01:00.007+09:00

ｘフトウェア品質の新時代　作り手の品質から使い手の品質
南山大学　情報工学部ソフトウェア工学科　青山幹夫教授

●メッセージ
　→製品（ソフトウェア）の価値（品質）はユーザが決定
　　作り手（ベンダ）から使い手（ユーザ）への視点の転換
　→価値は有効に使われて初めて生まれる
　　利用＝サービス×ユーザビリティ
　　外部品質からサービス利用品質へ
　　※ソフトウェアが欲しいのではなく、ソフトウェアが提供するサービス、経験等
　　※「ものづくり」から「ことづくり」へ
　→変化：グローバル化、ネットワーク化、サービス化
　　グローバル化：ベンダとユーザの両方の多様化
　　ネットワーク化：アーキテクチャの変革
　　サービス化：価値の変化
　→変化への対応：要求工学とアーキテクチャ

●シナリオ
　→自動化の罠：２０年前に起きた「プリウス問題」
　→コンピュータ化の拡大：航空機から自動車へ
　→作り手の品質から使い手の品質へ
　→変化に対応するには我々は何をすべきか
　→まとめ

●自動化の罠：２０年前に起きた「プリウス問題」
　コンピュータによる飛行制御：フライ・バイ・ワイヤ（FBW)
　自動化：パイロットの負担を下げる
　→デモフライトで墜落事故
　　パイロットの操作ミス
　　３０フィート低空飛行－コンピュータ制御は５０フィート未満の高度は着陸と判断
　　コンピュータとパイロットとの制御の葛藤が発生
　　→ボーイングはパイロットオーバライドを採用（パイロットの制御が優先）
　→パイロットは情報システムの運用者になった→コンピュータが仮想的に生成した反力
●コンピュータ化の拡大（航空機→自動車）
　→始まりは、排気ガス規制→エンジン制御にコンピュータを使用
　→電子制御→車載ネットワークによる協調制御→社外との連携
　→ブレーキのバグ（リコール）
　　ダイムラー・クライスラー（2004年6月）
　　ＧＭ（2004年5月）
　→電子制御は差別化から標準装備に
　→安全性は高まるが、リスクも内在する
　→支援と自動化の錯綜
　→コンピュータの存在を意識しないユーザと仮想化された車
　　ユーザ＝コンピュータの非専門化
　　ユーザはソフトウェアが作り出す仮想の自動車を運転している
　→組込みソフトウェア＝実世界の擬似の問題
　　コンテキストとユーザの意図の理解が必要
　　自動車のモデル、ユーザのメンタルモデル
　→コンピュータ化（自動化／支援）の在り方とリスク
　　どこまで自動化するか
　　複数のコントローラの自動化／支援の組み合わせがもたらす課題

●情報システム開発を取巻く環境の変化
　→ネットワーク化
　→サービス化
　　ソフトウェア：所有（ソフトウェア／もの）⇒利用（サービス／こと）
　→グローバル化
　　多様性：抑制⇒活用（受容）

●ネットワーク化
　→単一システムモデルから連邦型／非集中
　→従来型開発モデルと開発組織の限界
　→ソフトウェア：「モノ」と「サービス（コト）」の２面性
　→ネットワークによるソフトウェア価値の変化と（超）寡占化
　　ネットワーク外部性
　　同じソフトウェアのユーザが増えるとユーザの利便性が増大

●サービス化
　→情報システムのビジネス効果の見直し
　→基盤のコモディティ化とビジネスマネジメントの強化

●グローバル化
　→グローバル化のもたらす２側面
　　市場のグローバル化
　　競争と協調のグローバル化
　→ソフトウェア開発へのインパクト
　　多様な要求への対応：要求工学、プロダクトライン、プラットフォーム化
　　オフショア開発への対応とコスト／生産性のジレンマ
　　標準化とアライアンス：競争領域と非競争領域の識別の必要性

●作り手の品質から使い手の品質へ
→使いたくない（？）デザイン：豊富な機能、宝の持ち腐れ
　→使いたくなるデザイン：アップルのデザイン
　　なぜ、日本ではできないのか？
　　すべての技術は国内でもあった
　　何がもんだか？なにが足りないのか
　→品質の生まれる時：サービス化による新たな品質モデル
　　品質の生まれる時
　→サービス利用品質：品質（サービス利用、製品利用）＞＞製品品質
　　付加価値＝サービス価値×ユーザビリティ
　→利用品質、外部品質、内部品質
　→使い手（ユーザと作り手（開発者／ベンダ）とギャップ
　→なぜ、デザインは難しいのか？
　　→デザインとは、人とものと環境が相互に折り合いをつけること
　　→相互の調和性
　　　物理的の調和性：ものの形としての調和性
　　　認知的な調和性：人がものを見たり、使ったりした「メンタルな働き」に伴う調和性

●変化に対応するには我々は何をすべきか（新たなアーキテクチャと開発モデル）
　→開発モデル
　　→ネットワーク×サービス×グローバル
　　→ユーザ中心要求工学
　　→サービス工学／サービス指向アーキテクチャ（ＳＯＡ）
　→アーキテクチャ
　　→ネットワーク上でのサービスのモジュール化と組合わせ
　→ユーザ中心の要求工学
　　→ステークフォルダ分析
　　→ゴールとゴール分析
　　→ステークフォルダ視点のゴール分析
　　→エンタープライズ分析
　　→ペルソナ
　　→REBOK

●まとめ
　→作り手の品質から使い手品質へ：視点の転換
　→サービス利用品質＝サービス価値×ユーザビリティ
　→変化：グローバル化、ネットワーク化、サービス化
　　グローバル化：ベンダとユーザの多様化と競争
　　ネットワーク化：アーキテクチャの変革
　　サービス化：価値とその提供形態の変革
　→変化がもたらす機会とリスク：技術とビジネス
　→変化への対応：顧客価値を生むサービス提供技術
　　ユーザ中心要求工学
　　サービス指向アーキテクチャ

＜所感＞
　第２のiPhone、iPadを生み出すことが、日本の産業再生に必要であろう。戦後デミング博士から品質工学をとりいれたことにより品質の日本を確立したように、必死になって要求工学を勉強するひつようがあると思う。

ソフトウェア・メインテナンスフォーラムのお知らせ

2010-04-25T15:18:00.003+09:00

来る５月２１日にソフトウェア・メインテナンスフォーラムを開催します。

今回は、ソフトウェア保守の品質確保に焦点をあてました。

討論の時間もたっぷり１時間半あります。

どうぞ、ご参加ください。

＜詳細＞

--------------------------------------------------------------------------------
SERCフォーラム

　　　ソフトウェア保守と品質確保

主催
ソフトウェア・メインテナンス研究会(SERC)
http://www.smsg.or.jp/
--------------------------------------------------------------------------------
ソフトウェア・メインテナンス研究会は1990年の設立以来、国内唯一のソフトウェア進
化・保守に関する研究グループとして、ソフトウェア保守の諸問題に焦点を当て、さまざ
まな観点から解決策を探ってまいりました。

ソフトウェアが社会インフラの構築・運用・維持に欠くことの出来ない重要なコンポー
ネントとなり、ソフトウェアの品質確保が重要な課題になっています。ソフトウェア保守
は既に稼働するシステム（サービス）品質の維持が必須であり、新規開発よりもさらに品
質確保のための注意が必要となります。
　その一方でソフトウェア保守には、母体となるソフトウェアの解析・理解、ドキュメン
ト不足、担当者のモチベーション等々ソフトウェア新規開発には無い課題があるのではな
いでしょうか？

　そこで今回のSERCフォーラムでは、ソフトウェア保守の第一線で活躍される方の事例を
紹介し、ソフトウェア保守における品質確保のための課題や工夫について議論する場を設
けました。

ソニー株式会社の永田　敦氏に「派生開発におけるモレ・ムダのないテスト設計」とい
うタイトルで講演いただきます。永田氏は、日本科学技術連盟のソフトウェア品質管理研
究会で派生開発の研究をされておりました。今回は最新の研究結果を紹介していただきま
す。
　さらに、当研究会研究員がソフトウェア保守における品質確保の第一線の事例を紹介い
たします。

多くの皆さまのご参加をお待ちしております。

《開催要領》

●日時：2010年5月21日（金）10:00-17:00（受付 9:30-)

●プログラム
9:30 - 10:00 受付
10:00 - 10:05 開会の挨拶
10:05 - 11:45 基調講演
タイトル：「派生開発におけるモレ・ムダのないテスト設計」
講師：永田　敦氏（ソニー）

11:45 - 13:00 昼食休憩

13:00 - 13:40 SERC研究員講演１
タイトル：「保守開発でのテストの悩み（仮）」
講師: 福島　茂雄氏（東京エレクトロンソフトウェア・テクノロジーズ)

13:40 - 14:20　SERC研究員講演２
　　　　　　　　　タイトル：「保守開発のおける品質確保」
講師：松本　道春氏（日立ソフトウェアエンジニアリング）

14:20 - 15:00　SERC研究員講演３
タイトル：「システム保守おける品質確保の取り組みについて（仮）」
講師: 谷川　俊雄氏（中電シーティアイ）

15:00 - 15:10　休息

15:10 - 16:40　パネル討論
　　　　　　　　　パネラー：
　　　　　　　　　　　　永田　敦氏　（ソニー）
　　　　　　　　　　　　福島　茂雄氏（東京エレクトロンソフトウェア・テクノロジーズ）
　　　　　　　　　　　　谷川　俊雄氏（中電シーティアイ）
　　　松本　道春氏（日立ソフトウェアエンジニアリング）

　　　　　　　　　進行：高橋　芳広氏（日立ソフトウェアエンジニアリング）

16:40 - 16:45　クロージング

●会場：明石町区民館　３・４号室
東京都中央区明石町１４番２号　TEL０３－３５４６－９１２５
　　　　　・東京メトロ日比谷線築地駅下車３番出口　徒歩７分
　　　　　・東京メトロ有楽町線新富町駅下車４番出口　徒歩１０分
　　　　　・都バス「東１５甲・乙　東京駅八重洲口－深川車庫」
　　　　　　聖路加病院前下車　徒歩１分
http://www.pb-k.jp/city.chuo.7kuminkan/akashi_map.html

●定員：40名（先着順）

●参加費：SERC研究員1,000円，一般 3,000円
当日，会場受付にて現金でお支払いください，領収書を差し上げます（お釣り
　　　　　　のないようにお願いします）。

●申込方法：
下記申込用紙の形式に必要事項を御記入の上，SERC事務局(smsg-secretariat＠smsg.or.jp) に
メールにてお申込みください。
当日ミニパネルで討論したいテーマや課題があれば申込票の最後にご記入ください。
折り返し，受講票をメールで送りしますので，当日，御持参ください。
定員超過でお申込をお断りする場合には，メールにてご連絡いたします。
申込み締切日以降のキャンセルは実費を頂きます。

●申込み宛先: ソフトウェア・メインテナンス研究会(SERC)事務局
E-Mail: smsg-secretariat＠smsg.or.jp

●申込み締切：　2010年5月14日（金）

=======================================================================
2010年5月 SERCフォーラム参加申込用紙

氏名 (ふりがな)： _______________ (________________________)

会社名： _____________________________________________________________

部門・役職： _________________________________________________________

住所： (〒____-______) ________________________________________________

Tel: _____________________ Fax: _____________________

E-Mail: ___________________________________

種別 (該当欄にチェック):
□SERC研究員（1,000円）　 □一般（3,000円）

フォーラム参加費：_________円

討論したいテーマ：

---------------------------------------------------------------------------------

SERCフォーラム　ソフトウェア進化・保守を支える基盤技術　聴講記

2010-04-22T12:47:00.005+09:00

--------------------------------------------------------------------------------
SERCフォーラム

ソフトウェア進化・保守を支える基盤技術

主催
ソフトウェア・メインテナンス研究会(SERC)
http://www.smsg.or.jp/
--------------------------------------------------------------------------------

日時：2010年4月22日（木）13:30-17:00（受付13:00-)

●プログラム
13:00 - 13:30 受付
13:30 - 13:35 開会の挨拶
13:35 - 15:00 基調講演
タイトル：「ソフトウェア保守プロセスとコミュニケーション」
講師: 山本修一郎氏(名古屋大学情報連携統括本部情報戦略室教授)
概要：　ソフトウェアの保守は，ソフトウェア価値の向上を目的とする
活動であるにもかかわらず，開発に後続する活動とみなされがちでは
ないだろうか？しかし日本における重要インフラ障害の４割が保守時の
問題だという報告事例をみると，保守と開発のコミュニケーションが
必要だと思われる．本講演では，このようなソフトウェア保守プロセス
における開発とのコミュニケーションについて述べる．
15:00 - 15:15 休憩
15:15 - 16:45 ミニパネル
　　　　　　　　　　パネルに先立ち、2名の方から以下の内容で発表して頂きます。
　　　　　　　　　　「既存システムの保守作業を向上させる技法、ツールについて」
SERCで調査研究している諸々の技法、ツールについて
機能、用途、効果を紹介します。
　　　　　　　　　　「ソフトウェア保守・進化技術の動向」
ソフトウェア保守・進化を促進し効率化させるための
技術動向について紹介します。
　　　　　　　　　　　その後、会場の皆様とともにディスカッションを行います。
16:45-16:50 クロージング
--------------------------------------------------------------------------------

13:35 - 15:00 基調講演
「ソフトウェア保守プロセスとコミュニケーション」　山本修一郎氏

●主な話題
　・ディペンダビリティと保守性
　・技術・社会的な潮流とソフトウェア保守研究
　・CMCで変わる組織コミュニケーション
　・Wikiによる開発コミュニケーション事例
　・保守コミュニケーション

●ディペンダビリティと保守性
　→ディペンダビリティとしての保守
　　・ディペンダビリティ
　　　アライラビリティ性能及びこれに影響を与える要因、すなわち信頼性性能、
　　　保全性性能及び保全支援能力を記述するために用いられる包括的な用語

　　　環境　→　イベント　→　ソフトウェア
　　　環境　←　応答　　　←　ソフトウェア

　→重要インフラ障害の原因分析
　　・開発　２１％
　　・保守　３９％　　　保守性　→　開発時の十分な考慮
　　・運用　４０％　　　運用性　→　開発時の十分な考慮

　→なぜソフトウェア要求が変化するのか

　　　ビジネスイノベーション　→　ゴールの進化　→　　ビジネスゴール
　　　ビジネスインテリジェンス　＝　比較　＝　ビジネスゴール　　→　ビジネスイノベーション
　　　現実世界の変化の兆候　→　ビジネスインテリジェンス

　　　※環境の変化、使う人の変化により要求が変化する
　　　　Ｔ社の問題も使う人のメンタルの変化（違和感）を理解できずに、
　　　　技術論と捉えたことで問題を大きくした

　→境界原理　～開発の仮説～
　　システム開発には必ず仮説の部分がでてくるから、仮説外れの制御が必要
　　・目的
　　・機能（欠陥、障害）
　　・構造（故障、損壊）
　　　↑↓
　　・境界条件
　　・自然法則、人間行動

　　※あらゆるものを変化させ使い続けなければならない

　→保守性指標の例
　　・解析性（活動記録、監視データ取得率、ソースコードコメント率他）
　　・変更性（変更内容文書化率、変更履歴記録率、構成管理効率他）
　　・安定性（母体品質、自動リカバリ機能充足率他）
　　・試験性（試験再開機能提供度、多システム連携自律試験度、再試験生産性他）

　　　※バグ管理票が見直されている

●保守研究の動向
　→ソフトウェア保守研究の進化
　　・開発技術の進化
　　・知識創造社会
　　・グローバル化
　　・OSS

　　As　Is　　　　　　　　　　　　　　　　　　　　　To　Be
　　既存資産の分析　→　保守プロジェクトの管理　→　保守の理解（アーキテクチャ、設計）

　→ソフトウェア保守研究：１０の挑戦
　　・モデル駆動保守
　　・開発プロセスとの統合：言語、保守を考慮した設計、NFR
　　・スケーラビリティ
　　・実行時保守・動的更改
　　・リノベーション／マイグレーション／リエンジニアリング
　　・逐次変更とコスト見積もり
　　・実証研究
　　・保守研究の共通フレームワーク
　　　※単にバグの修正だけではなく、非機能要件を維持する
　　・開発者の不一致
　　　不適切な担当者：未熟練者、貧弱なツール、外注、海外発注
　　　保守活動に即した専門知識
　　　※保守担当者にはソフトウェア身分階層の下位者がなることが多い
　　　※コミュニケーションにより必要な知識を注入することで解決
　　・保守理論

　→課題管理システムの社会的側面
　　・基本的なコミュニケーション媒体
　　・知識リポジトリ：組織内にある大量の知識を具体化
　　・境界オブジェクト：役割と視点の異なる参加者が共有
　　・社会ネットワークを形成
　　・ソフトウェアチーム内外の多数の関係者を結ぶハブ：
　　　コミュニケーションと調整の中心
　　・関係者全員が、共通知識とコミュニケーションに貢献

　　※課題管理システムが開発者と保守者とのバウンダリーオブジェクト（仲介役）になっている
　　　課題管理システムを利用したコミュニケーションから人脈をえる

　→質問の種類
　　・焦点の発見　　　この概念を表現する型は？
　　・焦点の構造　　　型の構成要素は？
　　・構造の理解　　　型の振る舞いは？
　　・構造間の関係　　画面とこの型の対応関係は？

　→コミュニケーションのオーバーヘッド
　　・Brooksの法則
　　　N(N-1)N　コミュニケーションパス
　　　→保守タスクを小さく分解し、適切な担当者に配分すれば、
　　　　コミュニケーションのオーバーヘッドを低減できる可能性がある

　→OSSデバッグプロセスとアクタ
　　OSSのデバッグは保守プロセス
　　省略

　　※バグ管理システムではMLも有効に活用している

　→OSSデバッグプロセスの特性
　　・多様性：多様な運用環境
　　・集合性：バグ票を用いて情報共有することで、ユーザと開発者が一緒に議論しながらバグ状況を理解
　　・社会性：ユーザの関心を保持しながら、バグの重要性、デバッグの優先順位や責任分担の決定が必要
　　・異質性：技術だけでなく、世界観や活動することなる共同体構成員の維持情報が必要
　　・同時進行性：定常的な日常業務が同時進行

●CMCで変化する組織コミュニケーション
　→CMCで変わる組織コミュニケーション
　　－企業SNSの実践から学ぶ　（NTT出版）

　※技術は不公平で、使い方によって得られる成果が全く違う

　→SNSサービスと開発組織
　　・組織変革（組織の壁を越える、場所の壁を越える、コミュニケーションの活性化）
　　・ナレジマネジメント（組織横断型問題解決、ジャストインタイムKM、仲介知）
　　・協調学習（状況依存、外化、アブダクション）
　　・知識資本（文書化リテラシー、多様な価値観の認知、他者に貢献する文化）

　→仲介知によるジャストインタイムの知識共有
　　
　　形式知　　→　内面化　→　暗黙知
　　形式知　　←　表出化　←　暗黙知
　　形式知　　→　断片化　→　仲介知
　　形式知　　←　洗練化　←　仲介知
　　仲介知　　→　共鳴化　→　暗黙知
　　仲介知　　←　公開化　←　暗黙知

　→企業内CMCのケイパビリティ
　　・電子メール　　　　仲介知
　　・企業内ポータル　　形式知
　　・企業内SNS　　　　仲介知
　　・企業内Wiki　　　　仲介知、形式知

　→情報発信者と情報流通性

　　　　　組織　　　　　　　　　個人

　　発信　Webポータル　　　　　　Wiki
　　　　　電子メール
　　　　　メイリングリスト

　　議論　電子掲示板　　　　　　電子メール
　　　　　メイリングリスト　　　チャット　　
　　　　　　　　　　　　　　　　SNS

　→コミュニケーションのモデル
　　・線形モデル
　　・収束モデル
　　・協調モデル

　　※全ては伝わらないことを前提としたモデルが必要

　→コミュニケーションとは
　　・自律
　　　自己実現　
　　　自己啓発
　　　自己選択
　　・協調
　　　矛盾調整
　　　知識探索
　　　資源配分
　　・内省
　　　反省
　　　記録
　　　自問
　　・状況
　　　報告
　　　連絡
　　　相談

　※保守が自己実現に役にたつと思えば、保守者のモチベーションは上がる
　→コミュニケーションモードの遷移
　　・自律モード
　　・協調モード
　　・内省モード
　　・状況モード
　　＜詳細略＞

　※自分の得意とするコミュニケーションモードを自覚する。得意なコミュニケーションモードばかりだと制限があるのでバランスを取ることを意識する必要がある

●Wikiによる開発コミュニケーション
　※山本氏がプロジェクトでWikiによる情報交換を使用した事例
　→Wikiによる開発活動と知識変換モード
　　＜詳細略＞

　→Wikiによる開発での知識変換モードの割合
　　・公開化：判断事項、ノウハウなどの重要事項の表明　７２％
　　・断片化：公式文書から通知すべき事項を選択　　　　２０％
　　・協働化：開発の方針や進捗を議論　　　　　　　　　　８％
　　・共鳴化：感情の共有（※）　　　　　　　　　　　　　０％
　　・洗練化：なし　　　　　　　　　　　　　　　　　　　０％
　
　　※ソフトウェアの開発には、感情の共有も重要であろう

　→TIEモデル
　　・暗黙知ネットワーク（TKN)：人、非公式な文書化、会議、対話
　　・仲介知ネットワーク（IKN)：CMC情報、ジャストインタイム、文書化、CMCログ
　　・形式知ネットワーク（EKN)：文書、完全な文書、要求仕様、コード、マニュアル、ガイドライン

　　※SNSは気軽に書ける雰囲気の組織が成功している
　　　書き続けることによりライティングスキルがあがる
　　　読んでいるうちに情報感度があがる

　→ソフトウェア開発保守知識のTIEモデル
　　暗黙知ネットワーク
　　　↓　　↑
　　仲介知ネットワーク
　　　↓　　↑
　　形式知ネットワーク
　　＜詳細略＞

●保守コミュニケーション
　→アクタ間の質問の例
　　・企画、営業、開発、試験、保守
　　＜詳細略＞

　　※必要な情報が抜けていると思ったら聞くパスを作るべき
　　　（全てを保守チーム内で解決しようとしない）

　→保守コミュニケーションの対象
　　・関係者
　　・ソフトウェア
　　・運用環境

　→要求記述の構成要素と曖昧性
　　曖昧性：範囲、内容、関係の多義性・不明性　＝　潜在的な改変要求の源泉

　　状況（アクタ）　→　イベント　→　入力　→　処理　→　出力　→　結果（アクタ）

　→改変要求と実装の追跡性
※改変時の判断（根拠）を残しておく必要がある
　　根拠　→　判断　→　改変要求

　　※残すべき情報をあらかじめ決めておく必要がある
　　　本当に必要な情報への絞込みが必要

　→エンジニアリング・ケース
　　・情勢変化
　　・IT変容の期待
　　・技術課題
　　・記述内容
　　・記述手順
　　・実施組織
　　・取り組み

●まとめ
　→ディペンダビリティと要求変化
　→技術・社会的な潮流とソフトウェア保守研究
　→CMCで変わる組織コミュニケーション
　→Wikiにより開発コミュニケーション事例
　→保守コミュニケーション

15:15 - 16:45 ミニパネル
「既存システムの保守作業を向上させる技法、ツールについて」
　SERC　Bグループ研究員　（株）SRA　方　学芬氏
　※ソフトウェア保守における文字列検索の重要性とCodeDepot
　　　　　　　　　　
「ソフトウェア保守・進化技術の動向」
　SERC　Bグループ研究員　（株）SRA　石川　雅彦氏

＜別途報告＞

ソフトウェア･シンポジュウム２０１０のお知らせ

2010-04-12T21:15:00.003+09:00

来る６月９日（水）～６月１１日（金）に、横浜開港記念館でソフトウェア･シンポジュウム２０１０が開催されます。
仮サイトは、こちら。

ここで、「ソフトウェア進化」のＷＧを開催することになりました。
「ソフトウェア進化」ＷＧは、広義のソフトウェア保守開発、つまり、『ソフトウェアを直すこと』に拘わり、我々ソフトウェア技術者は何が出来るのかを前向きに議論したいと思います。

是非、ご参加ください。

Software　Japan　2010聴講録

2010-03-11T12:58:00.003+09:00

Software Japan 2010

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
「ビジネス・エスノグラフィの普及～イノベーション人材の育成に向けて」

講演（１）：東京大学i.schoolの試み
田村　大（東京大学　i.schoolディレクター／（株）博報堂イノベーション・ラボ上級研究員）

●i.school
　人間中心のイノベーションの場

●イノベーションの実感
　セグウェイ＜ipot、Wii

　Humaney│　iPod　│　Wii
　　　　 ├────┼─────
　　　　│　　　　│　Segway
　　　　└──────────
　　　　　　　　　　　Tecnological

　構成するテクノロジーの変化よりも、人へのインタフェースが変わるほうがイノベーションの実感がある。

●人間中心イノベーション
　・必ずしも技術の変化は伴わない
　・必ず人間の行動、知覚、習慣、価値観に変化をもたらす

●スタンフォード大学　Ｄスクール
　・広義のデザインを教えている
　・IDEOが運営
　　→Small　D　形のデザイン
　　→Big　D　システムやサービスのデザイン
●世界のＤスクール
　＜省略＞
　・韓国にもある
　・日本にはない（産業と学術の垣根が高い）
　　→そこで、i.Schoolを作った
●i.school
　・新しいリーダシップの育成
　　→ダイバーシティのマネジメント
　・人間中心のイノベーション
　　→東大は1/3が技術系なのでそれを補完する人間
　・研究所の成果を活かす
　・社会的な課題
　・ProvidingRealExperience

●企業とのかかわり
　・運営資金
　・企業人が学生を一緒にI.schoolで勉強する
　　→その結果を自由に企業の持ち帰る

●基本構成
　・ステップ１：
　　エスノグラフィ、フォーサイト
　・ステップ２：
　　シナリオ・ライティング、プロトタクィピング、チーム・ビルディング
　・ステップ３：
　　ストラジック、プランニング、エグゼキューション（製造、事業運営）、コミュニケーション

●やってみて気づいたこと
　・東大生は意外な「得意」ある
　　→絵、シナリオライティング
　・東大生＋千葉大生（デザイン科学専攻）のコラボは相性がいい
　・社会参加者はチームのパフォーマンス向上に貢献する
　　→社会人着地力は高いが、ジャンプ力は低い
　・チームのインフォーマルな関係性がパフォーマンスに大きな影響を与える
　　→飲みに行くチームは良い成果を出す傾向があった
　・i.schoolでの学びは、学生の専門研究、キャリア選択にも好影響を与える

●イノベーション探検隊（ブログ）

●２０１０年の計画
　＜省略＞
　スポンサー募集中

Ｑ＆Ａ
Ｑ．大学院の教育であるが、学部生に生かせないか
Ａ．学部生も入っている。しかし、学部生は自分の専門を中心にしたほうが良いと考えている。
Ｑ．社会人をよぶためにはどうしたらよいか？
Ａ．次を考えている
　　・スポンサーシップ（冠スポンサーになってもらう）
　　・企業自前で出来なかった方法論が学べる
　　　プロセスを学ぶのではなく、やりながら熟練していく

講演（２）：フィールド・イノベータ実践知共有取り組み
塩田武志（富士通（株）フィールド・イノベーション革新Ｆ１技術センター課長）
矢島彩子（富士通（株）フィールド・イノベーション革新Ｆ１技術センター研究員）

●富士通におけるフィールド・イノベーション
　→人を主役ににして、プロセスとＩＴを統合する

●ビジネスにおけるフィールドワーク
・現場業務やサービスを、ありのままに把握する
・可視化する
・「ＩＴとＩＴ以外」ではなく『人・プロセス・そしてＩＴ』
　→事実をもとにした、様々な施策・改善の起点につなげる
　　（公式プロセス　←ギャップ→　実際の現場業務）

●フィールドイノベーションの内容
・事実を捉えることによる「可視化」
・課題領域（フィールド）をつなく「分析・改善対策案」
・「施策実現」による企業体質の強化

●エスノ・コグニティブ　インタビュー
・人間関係技術
　→フィールドワーク
　→インタビュー
　→問題解決技法
　→ファシリテーション
　→アンケート構築
・業務実態を短時間で効率的に聞き出し、お客様の現場の見える化をサポートするための手法
・インタビューのフレーム
　→基本プロセス
　→基本作法
　→基本技法

・インタビューを中心にしたフィールドワーク
　→独自の質問ワークシートを用いる
　→インタビューの進行を考える
　→インタビューの対象の選定
　→具体的な流れ
　→インタビューの進め方

●フィールド・ワーク手法を使うシチュエーション
・課題認識のずれを確認したい
・業務プロセスについて、長期スパンの分析

●技法・技術支援をするなかでの問題意識
　・手法提供からの課題
　　→第三者として入り込むため、各活動プロセスで研修で学習したものが生かせる仕組み（技術同士のつながりが見えない）
　・型が目的化
　・フィールド・イノベーション活動を支援するためにどうするきかというＦＩ目線を入れにくい
　・フィールド・イノベータの活動と技術の紐付けが未整備
　→エスノグラフィーなど、人間関係と呼ばれている調査を用いる／普及する難しさ

Ｑ＆Ａ
Ｑ．イノベータに対する現場の理解は（余剰人員対策と捉えかねないのでは？）
Ａ．１～３期に分けてやっている。
　　１期はフロンティア精神に富んだ人が多い。
　　２～３期は、１期をみて安心して応募された
Ｑ．フィールドイノベータのハイパフォーマーになる人の特性はあるか
Ａ．一番向いているのは研究者。営業も。
　　経理、生産管理出身者も向いていると思う。

パネル討論
司会：久保隅綾（コニカミノルタ　テクノロジーセンター（株）イメージング文化研究室　研究員）

Ｑ．フィールド・イノベーション活動はなにを参考にしているのか
Ａ．人間系の研究者
Ｑ．人間中心のイノベーションを生むためには無意識の行動・考えを読む必要がある。
　　インタビューによりバイアスがかかる
Ａ．その通りだと思う。
　　インタビューは事実ではなく、事実認識。
　　現場に入ってみることが重要。その補足といしてインタビューがある
Ｃ．最新の社会科学では、客観的にみるということは必ずしも最適ではないといわれている。
Ｑ．どのくらい効果的か？
Ａ．　　　共感型
　　　　　↑
　　　　　│☆ここが向いている
受身型←─┼─→批評的
　　　　　│
　　　　　↓
　　　自己主張型

　相手の立場を感じ取り、その背景を批評的にみる必要がある。
　教育が必要。
　・共感は素質が必要
　・批評はトレーニングで身につけたれる
　　（会社に入ると難しいので、大学生のうちに身につけさせたい）
Ａ．研修を通して変わっていく。
Ａ．システムエンジニアが多いが、型文化があり抵抗があるように思う
Ａ．共感型は女性が向いている。女性でないと入れないフィールドもある
Ｑ．大学のサービスイノベータの教育は？
　　自己主張型は教育で変わるのではないか？
Ａ．自己主張が出来き、共感もできるのであればそれにこしたことはない？
　　サービスイノベーションのフィールドワークの対象者は受益者になる
　　実践を教育プログラムにどうやって持ち込むのか？が課題

※紹介　EPIC 2010（東京）

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
招待講演　「課題先進国」から「課題解決先進国へ」
小宮山宏（株）三菱総合研究所理事長

●知の構造化
　増えすぎた知識と複雑な問題とうまく組み合わせる

●先進国における普及型重要の飽和
　・人工物の飽和
　　→自動車（先進国0.5台/人、中国0.02台/人、インド0.01台/人）
　　→家（1968年以降世帯数より家が多くなった）
　　※物的需要は飽和する（買い替え需要のみになる）
　・中国の成長が飽和するのもそう遠い先ではない
　　→セメントの一人当たりの投入量は2016年米国と同じ、2020年に日本と同じ
　　→車の日本の高度成長は５年（中国も５～１０年だろう）
●需要を二つに分ける
　・普及型需要→
　・創造型需要→内需
　　→うまれつつある需要
　　→これからの需要

●２１世紀のパラダイム
　・爆発する知識
　・有限の地球
　・高齢化する社会
　※新産業はここから生まれる

●答えが必要
　・ビジョン２０５０
　　→エネルギー効率３倍
　　→再生可能（非化石）エネルギー２倍
　　→物質循環システムの構築
　科学技術的に社会的に実現可能で

●エネルギー効率の向上が大切
　・イノベーションが起こる分野に重点をかける
　　→自動車（技術革新）
　　→セメント（日本の技術は頭打ち、他国へＴＴする段階）
　・総体としてエネルギー効率３倍

●ビジョン２０５０のシナリオ
　・非化石燃料　　２倍
　・総体燃料効率　３倍
　※これで現在のエネルギー消費とほぼ同じになる

●日本のエネルギー消費
　・エネルギー変換：３０．３％
　・ものづくり：３０．６％
　・日々のくらし：３９．１％
　→日々のくらしで削減、省エネでものづくり
　→理論と現実との差を埋めるのがイノベーション
　　※優秀な技術者ほと「もう限界です」という

●ビジョン
　・暖房エネルギーは１２分の１に
　　→エアコンは１０年前のものを買い換えると効率は２倍にある
　　→断熱効率を上げる（シングルガラスは日本だけ）
　　→ガス湯沸かし器は必要なエネルギー量の３０倍必要
　　　ヒートポンプならガスの２倍

●小宮山エコハウス
　実体験結果　８割減

●東大の例
　・窓の内側に２枚目の窓を設置（元をとるのが１０年）
　・エネルギー消費　４３％減
　・生活の質が上がる

●２０５０年日本の需給率
　・エネルギー　７０％
　・資源　　　　７０％
　・食料　　　１００％

●高効率製品への買い替えで削減する
　・もったいない
　　　→もったいなのはエネルギー
　・省エネは回収できる投資

●高齢化社会
　・社会に関わり続けけると、自立性が維持され

●新しい産業・新しい雇用・経済の活性化
　０から作るものづくり
　・グリーンイノベーション
　・シルバーイノベーション
　・知の構造化

●国家モデルの転換が必要
　・「坂の上の雲」の時代：途上国モデル
　・「雲に入ったら霧」：先進国モデル
　　市民の生活を良くすることを目的とし物作り

●プラチナ構想ネットワークの重層化
　・エコ・バリアフリー・ひどづくり・雇用で快適なまちづくり

●「課題先進国」日本

　いまの日本は２０５０年の世界の姿
　・小さな国土（地球）
　・小さな資源
　・大きな人口
　・高齢化社会
　・産業先進国

　※いいところを見る必要がある
　　うまき行くシナリオを探す

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
「高度ＩＴ資格制度に関する取り組みの現状：日本と世界」

講演（１）：社内プロフェッショナル認定に関するＩＰＡの取り組み
田中久也（（独）情報処理推進機構ＩＴ人材育成本部長）

●スキル標準の概況
・どのくらい普及しているか
　→ＩＴスキル標準は大企業（1,000以上）にはほぼ普及が完了したと言える
　→ＵＩＳＳの普及率は伸び悩み
　→開発系人材（ＡＳＰ、ＰＭ）が減少傾向
　　高度技術力をもつＩＴスペシャリスト等が増加
　→ユーザ企業では技術系人材が増加傾向
・技術者認定はどのくらい行われているのか
　→ＩＴスキル標準４を認定しているのは半数程度（1,000以上の起用）
　→該当者が少ない、処遇と連動しないので認識が薄れる

●ＩＴ企業大手各社の取り組み
　～プロフェッショナル制度を中心に～
・各社の使い方（事例）
　→そのまま使用（カテゴリ毎にスキル認定、職種があるわけではない）
　→既存の人事認定をＩＴスキル標準に近づける（ただし、別項目ある）
　→レベルをキャリアにカスタマイズ
　→カテゴリを自社の実態にあわせて使用している
・認定のしかた（事例）
　→～４）高度試験＋認定は部門内、５～）社内認定委員会
　→～３）高度試験＋認定は部門内、４～）社内認定委員会
・プロフェッショナルに求めらる要件
　→技術スキル、ビジネス成果、パブリック貢献（Ｆ社）
　　※技術を社内、社外に貢献
　→事業活動、認定制度への協力、後進の育成、プロフェッショナル活動
・人材育成のいしくみ
　→認定→配置→能力開発
　　（キャリア面談制度）
　　（仮免制度、パブリック貢献のため１年間メンターがつく）
　→育成計画→育成実施→育成評価
・プロフェッショナル認定に必要なこと
　→スキル評価：客観性を担保するため認定委員会でにんてい
　→業績評価：業績は各部門

●中小ＩＴベンダーのスキル標準の活用
ＩＰＡの取り組み
・中小企業向けフレームワークの作成
・導入用テンプレートの作成
・ワークショップにて説明
・事例
　→人材像を４つに絞る
　→ITSS準拠の制度をベースに独自に制定
　　（関連会社間でレベルを合わせる）

●今後に向けて
・ベンダー企業：IT人材の「質」不足
　→高い信頼性
　→国内競争
　→中国、インドとの競争
　→クラウドによるシステムアーキテクチャの変化
　→高度な人材
・育成すべき人材
　→ストラジスト、マーケティング、アーキテクトの需要増
　→ＰＭ減
・取引形態の変化
　→レガシーな取引　人月取引
　→今後の取引　　　ＳＬＡに応じた支払い
　→技術者の単価があがるためには→高スキル技術者の流動性
・ＩＴ人材が抱える不安
　→自分の将来のキャリアが不安
　→社内での今後のキャリアに対する見通し（悪い）
　→このまま仕事を続けていいのかどうか不安になる
　→自分のスキルが将来にも通用するかどうか分らない
　→自分の所属する企業がこのまま続くかどうかわからない

●プロフェッショナル認定に対するＩＰＡの考え方
・企業と技術者がwin-win
・各企業のビジネスモデルに合致しない認定（処遇）は無意味
　→技術者の人材像は各社様々
　→人材育成が基本（技術者の売値付けのためにはない）

●IPAからIT人材へのメッセージ
・岐路に立つIT人材、変革期こそ飛躍のチャンス
　→企業と技術者の成功のために
　→企業はビジョンを明確に
　→技術者各人は、キャリア自立せよ。
　　キャリアアップは自分の責任

Ｑ．認定制度は各社まちまち。ユーザ企業からみると統一が望ましい。
　　情報処理試験のような統一的な認定は必要か？
　　情報処理試験に変わるものを考えいるか？
Ａ．技術者に焦点を当てると各社の人事制度とあわないと幸せにならない。
　　現実論としては、技術認定という面では各社シビアにやっている。
　　全社でやるには相応な体力が必要である。そのため支援するしくみは必要。
Ｑ．教育予算がシビアになり、教育の投資効果、高度が増えると利点があるかの事例やメトリックスはないか？
Ａ．発想が逆ではないか？会社の事業モデルがありそれに必要な人材を育成すべき。
　　とは言え、中小企業向けに推進表彰を考えている。

講演（２）：高度ＩＴ資格制度に関する世界の取り組む
芝田晃（三菱電機（株）インフォメーションシステム事業推進本部企画部　主管技師長）●情報処理学会　ＩＴプロフェッショナル委員会
・目的
　→社会的地位の向上
　→情報処理分野の魅力の向上
・高度ＩＴ人材資格検討ＷＧ
・高度ＩＴ人材資格設計ＷＧ
●ＩＰＳＪ高度ＩＴ人材資格制度の基本方針
・国際的に通用する資格とする
　→ＩＰ３の認定取得
・ＩＴＳＳに準拠した認定制度する
・各企業が行っている社内資格制度で活用できるようにする

●ＩＰ３（International　Professional　Practice　Partnership)
・国際規格の作成

＜以下略＞

Ｑ．ＩＰ３を選んだ理由は？（他にもあるが...）
Ａ．情報処理学会がＩＦＩＰのメンバーになっている
Ｑ．ＩＰ３が世界の認証になりうるか？
Ａ．世界標準になりうる可能性はある。いまのところは２カ国
Ｑ．発展途上国に対する支援は？
Ａ．気持ちはあるが今後
Ｑ．タイムスケジュールは？
Ａ．希望は今後１～２年を目指したい
Ｑ．認証対象の人材（職種）は
Ａ．まだＦｉｘしていない。ＩＴスペシャリストからやりたい
Ｑ．認証の内容は、知識かスキル（仕事ができるた？こと）か
Ａ．どこでも通用する範囲でのスキル（仕事をやらせればできる）
　　※スキルと仕事ができることとの区分が明確でないように思う

６８回　SEA　SPIN　Meeting聴講録

2010-03-03T18:07:00.005+09:00

トヨタプリウス問題を切欠にソフトウェア・システムの信頼性／安全性を考える

●トヨタ社のリコール
　・フロアマット問題
　・アクセルペダル問題
　・ABS動作時のブレーキの不具合
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
伊藤昌夫氏「実践的組込みソフトウェアの信頼性向上」出版

●問題提起
　・自動車の制御はソフトウェア化が進んでいる
　　→高級車ECUが100を超えている
　　→現在は自動車の基本要素にソフトウェアが介在している（高級車から一般車へ）
　・ソフトウェア化は好ましいことなのか？
　・機械とソフトウェアの違い（４点）
　　→ソフトウェアはぜんち的な開発はまれ
　　　機械の場合は変わったといっても、機能追加は殆どない
　　→ソフトウェアの場合は設計内容の変更が判りにくい
　　　機械は図面で直ぐ判る
　　→１品生産
　　　工場メタファを持ち込むのが好きだが、同様の製造工程をもっていない
　　　工場メタファでは生産用の図面を起こすところで終わっている
　　→ソフトウェア品質を直接的に評価する手段はない
　　　ハードウェアは前提の試験基準により疲労試験、破壊試験がある
　　　ソフトウェアはどこまで壊れてよいか希
　　　基準をつくっても評価する手段がない
　・多くの議論が機械の延長としてとらえて良いのか？
　　とらえると今後問題が増える
　・電子制御全体をみることができない（一人で全体を見渡すことが出来る人はいない）
　・機械の場合は一寸の変更で大きなハザードはない
　　→新しい車種を起こすときは新たに全部仕様書をかかない
　　→ソフトウェアは違いだけが書いてある
　　→全体を整理できるようになっていない
　・いままで安全性の視点が欠如していた
　　→今までは大きく変わることがないので、過去の蓄積でよかった
　　　（クレームが来たら対応）
　　→ソフトエア化したとき仕様として書くのは難しい
　　→改めて、安全性の議論が必要になる
　・生産を止めて一から設計をやり直すことは難しい
　　→ソフトウェア技術者が現実にあわせて安全性を確保することが必要
　・SEA-SPINとしてアピールが必要
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
岸田　孝一氏

●視点を変える
　・プロダクト指向から　→　プロセス指向へ

●品質とは？
　・それは、ソフトウェア・プロダクトの属性である（バグの少なさ　etc.）
　　→プロダクト指向、開発者の視点
　・それは、ソフトウェアプロダクトが自際に使われるプロセスの属性である（仕事との適用性　etc.）
　　→プロセス指向、ユーザの視点

●第１のテーゼ
　・ソフトウェア・システムの信頼性や安全性の考察（モデル化や分析）は、そのシステムが実際に運用される組織あるいは社会環境と独立に、プロダクトだけを見て行うことはできない

●第２のテーゼ
　・ソフトウェア・システムの信頼性や安全性を考えるさいに、システムの機能仕様を明確化することよりも、その運用環境における動作特性に注目すべきである

●第３のテーゼ
　・矛盾のない完璧な要求仕様の開発を目指すことは無意味である。むしろ、各要件項目間の矛盾を明らかにし、システムを利用するステーク・ホルダーの間のコミュニケーションや議論に役立てることを狙ったほうが良い

●形式手法
　・ソフトウェア・プロダクトはシステムの形式的記述である
　・したがって、適切な形式手法を用いて、その挙動を解析することができる。
　・しかし、われわれがシステムを開発し利用する目的は、インフォーマルな現実世界と形式化されたソフトウェアとの間のギャップを埋めることである

●背景
　・ソフトウェア・システムの開発進化プロセスはMulti-Level、Multi-loop、MultiｰAgentのFeedback　Systemである

●組み込み
　・すべてのソフトウェア・システムは、対象アプリケーションに組み込まれたE－Typeシステムである
　・自動車や携帯電話などのハードウェアに組み込まれたソフトウェアは、さらにそれらのハードウェアが利用されるアプリケーションの中に二重に組み込まれている

●宿命
　・現実（世界）は無限の属性をもっているが、仕様そしてソフトウェアは有限でしかない
　・何らかの仮説にもとづいて、無限の現実世界から有限な仕様を切りださざるを得ない
　・仕様作成時にはその仮説は妥当なものとし受け入れられる。しかし、時間の経過とともに、その仮説は成り立たなくなる。
　・それがソフトウェア進化の主な原因である

●夢想
　・大きな異なる２つの球を考える。小さな球を適当に有限個に分割し、それらを同じ形のまま適当に寄せ集めることによって大きな球をつくることができるか？
　・パナッハ－タスキーの定理は、数学の世界ではそれが可能であることを証明した
　・有限なソフトウェア・システムをばらばらに分解し、それらを再構成して、より大きな現実世界のモデルが作れるか？

●現実・仕様・プログラム
　・アプリケーション　→　要求仕様　→　プログラム

●開発者の視点
　・仕様がアプリケーションと遭わない
　　→仕様を手なおしする
　・プログラムが仕様と合わない
　　→プログラムを手直しする
　・プログラムがアプリケーションと合わない
　　→仕様を見直して手直しする
　　→新しい仕様にあわせてプログラムを手直しする

●ユーザの視点
　・プログラムがアプリケーションと合わない
　　→PLAN-A（再開発）
　　　仕様を作り直し、その仕様にもとづいてプログラムを作り直すよう依頼する
　　→PLAN-B（現実的対処法）
　　　プログラムから仕様を再構成し、その仕様にあわせて、アプリケーション・プロセスにおけるプログラムの利用法を考え直す

　　※PLAN-Bを考えるべきだ
●定量的／定性的
　・システムの信頼性や安全性がユーザ・プロセスと関連した形でしかとらえられないとしたら、まず定量的メトリックスは使えないだろう
　・定性的な品質把握の方法は？
　・もし、それが見つかれば、比喩的ににではあるが、バナッファ－タルスキーの定理が使えるかも？？？
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
Ｑ．「アプリケーション」の意味は？
Ａ．ユーザの視点からみた仕事のこと
Ｑ．当初ユーザに合わせて欲しいと言っていたようにとられ、それが受け入れられなかった、のではないか？
Ａ．ユーザに受け入れられる説明は必要であるが、安全性と分けて考える必要がある
Ｑ．自分で運転しているという幻想があり、顕在化したのではないか？
Ｃ．逆ではないか？
　　今回は、ブレーキを踏んだのに減速しないことに違和感（恐怖）となったのではないか？
Ｃ．今回の問題は対応が早い（２ヶ月ぐらい）
　　問題が起きたときに知っていたのではないか？
Ｃ．パラメータの変更だけだったのではないか？
Ｃ．プリウスの燃費があがっている、回生ブレーキのしきい値の引き上げすぎではないか
Ｃ．もとの設定に戻した、という記事がある
Ｃ．原因が判らないので議論しても無駄。ソフトウェア提供者としてどうすれば良いのか議論したい
Ｃ．電子制御になると、人間が実際に現象が起こっているとことから離れてしまい、感覚が働かなくなり事故が多発している
Ｃ．ソフトウェア化し高機能化しているが説明責任が果たされていないのではないか？
Ｃ．品質の価値観がずれると問題
Ｃ．設計都合で物事が進んでいる。じゃ、ユーザの感覚を仕様化できないのではなか？
Ｃ．急加速の問題はないと信じているようだが、信じきるのは危ない。（電子制御は考えられないハザードがある）
Ｃ．テストの量で問題がない、と言い切ったとことが問題ではないか
Ｃ．自動車会社だからと言って慎重にソフトウェアを作っているわけではない

【所感】
　今回は開発（設計）者側の論理を主張したのが問題が大きくなった原因。だと思う。

SEA Forum Feb 2010　「セーフウェア　-　システム安全とコンピュータ」聴講記

2010-02-26T18:03:00.007+09:00

セーフウェア　-　システム安全とコンピュータ

18:30 - 19:30　セーフウェア
　～安全・安心なシステムとソフトウェアを目指して～
　　　　　　　　　　　松原コンサルティング　松原友夫
19:30 - 20:00　オープン・ディスカッション
　　　　　　　司会：新谷勝利
－－－－－－－－－－－－－－－－－－－－－－－－－－－
●なぜセーフウェアの翻訳に関わったのか
　ソフトウェア開発の仕事を始めた頃のプロジェクトは比較
的高リスクだった。
　・ある揚水発電所の水撃現象の計算（1960)
　・ある電力会社向け、電力負荷配分システム（1965）
　・ある都市銀行のオンラインシステム（1967）
　→当時からあまり進歩していないように感じていた
　著者んおNancyを良く知っていた
　安全に関するSoftware　Integrity　Levelsの国際規格を
審議するJTC1　SC7/WG9のメンバーだった
　電通大　西康晴先生からお誘いがあった

●「セーフウェア」について
　・システムの安全を体系的にまとめた書
　　→関連する幅広い専門領域を採り上げている
　　→現在の状況やアプローチを網羅している
　　→実際に起きた事故事例に基づく記述が多い
　　→Nancy　Levesonはデータ収集を含めて５年かかてこの
　　　本を書いた、そうだ
　・セーフウェアという言葉について
　　→システム安全に組織的な取り組みが必要なことを
　　　意味するNancy　Levesonの造語

●Nancy　Levesonについて
　・MITの航空宇宙工学部門と工学システム部門の教授

●産業化社会における新たなリスク要因
　・新たなハザードの登場
　　→その中には過去に低減され除去されたハザードよりずっと
　　　影響範囲が大きく発見や除去が困難なものがある
　・複雑さの増大
　　→コンポーネント事故からシステム事故へ
　・暴露の増大
　　→より多くの人がハザードに曝されるようになった
　・エネルギー量の増大
　　→高エネルギー源の発見と利用によって
　・増加する手動操作の自動化
　　→オペレータのリスクは減るように思えるが、リスクは保守、
　　　設計、監視など、より高度な意思決定にシフトするだけ
　　→オペレータがスケープゴートになりがち
　・集中化と規模の増大
　　→自動化は規模の増大と集中化を促進した
　・技術的変化の加速
　　→経験から学ぶ機会が減る

●どれほど安全なら十分なのか？
　・過去の事故から学ぶことは許されるのか？
　・事故から学ばなければならないのなら、事故の結果が悲劇的
　　結果を招きかねないシステムに対して、なにができるのか
　・リスク低減のためには、事後の事故調査に頼るのではなく、
　　事前に予測することが重要

●事故におけるコンピュータの役割
　・クリティカルシステムにおけるコンピュータの利用段階
　　→情報やアドバイスをオペレータの提供する
　　→データを解釈し制御上の決定を行う人にそれを表示する
　　→直接コマンドを出すが人間が動作を監視し入力を提供する
　　→制御ループから完全に人間を排除する
　・間接的制御もリスクを伴う

●ソフトウェアが制御するシステムの事故
　・事故調査はより困難になりコストが増加する
　　→故障している電子部品が残骸の中から見つかることはない
　　→微妙なエラーは簡単には見つからない
　・クリティカルシステムで安全を確保する方法が追いついていない
　　→実績のあるエンジニアリング技法はソフトウェアを考慮していない
　　→ソフトウェア技術者と在来の技術者間のコミュニケーションも
　　　うまくいっていない
　・常に開発が選考し安全確保のための方法は後追いになる

●ソフトウェアの神話
　・神話１：コンピュータのコストはアナログ機器や電気機械装置より安い
　　→信頼性が高いソフトウェアを開発・保守するコストは膨大になる
　・神話２：ソフトウェアは簡単に変更出来る
　　→エラーを組み込まずに変更するのは難しい
　・神話３：コンピュータは置き換えた電気機械装置よりも高い信頼性を
　　　　　　提供してくれる
　　→「故障」はしないがバグのないソフトウェアを作るのは難しい
　・神話４：ソフトウェアの信頼性が高まれば安全性も高まる
　　→仕様通りできていても安全ではない
　　→コンポーネントが完全でも事故は起こる
　　→安全性はシステムの特性であったコンポーネントの特性ではない
　・神話５：ソフトウェアを試験すること、または正しいことを証明する
　　　　　　ことで、すべてもエラーが除去できる
　　→安全性に関するソフトウェアエラーのほとんどは要件のエラーである
　・神話６：ソフトウェアを再利用すれば安全性は高まる
　　→新たなシステム固有のハザードが顧慮されていない
　　→かえって安全性が低下することさえある
　・神話７；コンピュータは機械式システムよりリスクは少ない
　　→たしかにコンピュータは安全性を高める潜在能力があるが、現状は
　　　それを十分に活かすに至っていない
　
●ソフトウェアは難しい
　・複雑である
　・離散状態システムである
　　→連続関数の扱いと比べて十分理解されていない
　・コンポーネント間のインタフェースが見えにくい
　・柔軟性の呪い
　　→「柔軟性は後知恵の墓場」
　　→課せられるべき自然法則や物理的制約がないので、とてつもなく複雑
　　　なシステムの構築を極めて容易にする

●事故原因とは
　・事象の複雑な関係
　・原因には必要条件と十分条件がある
　・原因は、それぞれが必要条件であり、それらが揃えば事象の発生に十分
　　である条件の集合によって構成される

●原因識別の落とし穴　－　過度の単純化
　・法的責任追及の観点から過度に単純化される
　・オペレータに責任を押し付ける傾向がつよい
　・機械の故障や直近の事象のみを重要視する傾向がある
　・組織的要因を軽視する

●因果関係の３階層モデル
　・事故原因の３階層モデル
　　→レベル１は事故発生のメカニズムを記述
　　→レベル２は事象が発生し得る条件または条件の欠如
　　→レベル３は事故全般に影響を及ぼす根本原因

●事故の根本原因
　・安全文化の欠陥
　　→自己過信と自己満足
　　→リスクの過小評価
　　→非現実的なリスクアセスメント
　　→低確率で過酷な事象の無視
　　→ソフトウェア関連リスクの過小評価
　　→早期の警報や兆候の無視
　・安全性に低い優先順位を割り当てること
　・相反する目標への誤った解決
　・効果的でない組織構造
　　→責任と権限の分散
　　→安全担当部門の独立性の欠如と低い位置
　　→限定だれた情報伝達経路と貧困な情報の流れ
　・効果的でない技術活動
　　→表面的な安全活動
　　→有功でないリスク制御
　　→変更に対する評価の失敗
　　→情報の不足

●事故モデル
　・古典モデル
　　→エネルギーモデル
　　→Heinrichのドミノモデル
　　→全米安全評議会モデル
　　→疫学モデル
　・事象連鎖モデル
　　→摂動モデル
　　→INRSモデル
　　→MORTモデル

●ヒューマンエラーの位置づけ
　・一般的な仮説、大部分の事故の原因はオペレータにあると
　　いうのは正しいか？
　・ヒューマンエラーは人間とタスクまたはシステムとのミス
　　マッチと見なされるべきである

●ヒューマンエラーの意味
　・ヒューマンエラーという用語は一般に次の２つの意味で使われる
　　→人間が悪いことっとしていたはずの何かをした
　　→人間が、その時点では悪いことだとは知らず、振り返って悪か
　　　ったことが分かるなにかをした。
　・この区別は、事故を減らすことｙほり、非難や罪を着せようとす
　　る場合に意味がある
　・ほとんどすべての事故はヒューマンエラーのせいにすることがで
　　きるが、そうすることは事故の予防に役立たない

●誤りをおかす能力と創意工夫の能力は同じもの
　・ヒューマンエラーは人間の適応能力と創造性の不可避的な副作用

●ヒューマンエラーは役に立たない区分
　・「ヒューマンエラー」はシステムの改善には役立たない用語であり、
　　「人間とタスクのミスマッチ」ということばに置き換えるべきだ。
　・Rasmussenの３レベル認知制御モデル
　　→スキルベースの行動
　　→ルールベースの行動
　　→知識ベースの行動

●自動化システムにおける人間の役割
　・自動化の矛盾
　　→皮肉なことに、設計者がシステムから人間の役割を除こうとする
　　　と、必然的にオペレータの仕事を複雑にして事故を起こしやすく
　　　する
　・メンタルモデルは人によって状況によってことなる
　・監視者としてての人間
　　→人間は自動化システムの監視が苦手
　・バックアップとしての人間
　・パートナーとしての人間
　　→エラーの可能性は増加するだろう
　・解決の方向
　　→オペレータのことを最初から考えて設計する

●安全性への取り組みの歴史
　＜省略＞

●システム理論とは
　・なぜ生まれたか
　　→システムの複雑性の増加には従来の科学では対処できない
　　→システム理論は科学的還元主義を補完または反発としえ生まれた
　・システムは３つのタイプがある
　　→体系的な単純さを提示するもの
　　→体系的でない複雑さを提示するもの
　　→体系的な複雑さを提示するもの
　・主な適用領域
　　→第二次大戦後に設計された複雑なシステム
　　→生物系、社会システム
　・体系的複雑さを持つシステム
　　→還元主義では複雑過ぎて説明できない
　・創発特性
　・システム理論では個々の部分ではなくシステム全体として扱う
　・用語：
　　→システム；共通の目標または目的を達成するために、全体とし
　　　て一緒に行動する構成要素の集まり
　　→システムの状態：その時点で関連する特性の集まり
　　→システム環境：全体としての行動がシステム状態に影響を及ぼ
　　　すような構成要素とそれらの性質の集まり
　　→入力／出力：システムと環境の境界を出入りするもの

●システム安全性の基本概念
　・完成した設計に安全を組み込むのではなく、設計に安全を組み込
　　むことを重視する７
　・サブシステムや構成要素としてではなく、全体としてシステムを
　　扱う
　・ハザードを単なる故障より広い意味で捉える
　・過去の経験や規格よりも分析を重視する
　・システム安全では、定量的手法よりも定性的手法を重視する
　・システム安全では、システム設計におけるトレードオフと対立を
　　重視する
　・システム安全が扱う範囲はシステム工学より広い

●ソフトウェアのシステム安全
　・ほとんどの事故はコンポーネント間のインタフェースと相互作用
　　が原因
　・システム安全技術者とソフトウェア技術者の間に深い溝がある

　　※外国には、「士農工商・・・ソフト」はない。

　・安全性の大部分は要件のエラー

●信頼性と安全性はべつのもの
　・しばしば信頼性と安全性は同じと仮定されるがこの仮定は特殊な
　　例外でしか当てはまらない
　・信頼性の定義
　　→あるコンポーネントが与えられた期間と指定された条件の下で
　　　求められた機能を実行する確率
　・事故はコンポーネントの故障の組み合わせによって起こるわけで
　　はない
　・信頼性が高くても安全でないことも、それと逆のこともある

●コンポーネントに故障がなくても事故は起きる

●信頼性評価には注意が必要
　・高信頼性を示す数値は安全性を保障しないし、安全は高信頼性を
　　必要としない
　・限定されたシステム境界内で冗長性なのでいくら信頼性を上げて
　　も、予想外の問題は防げない
　・多くの場合、事故を構成する複数の事象が独立だ、という仮定に
　　は誤りがある

●安全関連の用語定義
　・事故：ある特定のレベルの損失を引き起こす、望ましくない計画
　　外の事象
　・インシデント：損失を伴わないが、異なる状況下では損失の可能
　　性がある事象
　・ハザード：システムの環境における他の条件とともに、必然的に
　　事故をもたらし得るシステムのある状態、または一組の条件
　・リスク：事故に至る可能性、およびハザードの曝露、またあ、継
　　続期間と組み合わさったハザードレベル
　・安全：事故や損失がないこと

●安全プロセス

●ハザード分析プロセス
　・定性分析と定量分析
　・ハザードの識別

●ハザード分析のモデルと技法
　・比較的ポピュラーなもの
　　→チェックリスト
　　→ハザード指数
　　→フォールトツリー解析（ＦＴＡ）
　　→イベントツリー解析（ＥＴＡ）
　　→原因結果解析（ＣＣＡ）
　　→ＨＡＺＯＰ
　　→インタフェース分析
　　→故障モード影響解析（ＦＭＥＡ）
　　→故障モード、影響、および致命度解析（ＦＭＥＣＡ）
　　→障害ハザード分析
　　→状態機械ハザード分析
　・それぞれ利点と欠点だあるので状況にあわせて選択するひつようがある

●ソフトウェアハザードと要求分析
　・ソフトウェアに関連する事故原因
　・考慮すべきこと
　　→頭の中のモデルと仕様モデルの意味的距離を最小化する
　・要求分析のための完全性基準
　・堅牢さの基準

●安全のための設計
　・ハザードを除去する設計
　　→置換
　　→単純化
　　→分離
　　→特定のヒューマンエラーの除去
　　→ハザードをもたらす物質または条件の低減

●ヒューマンマシンインタフェースの設計
　・一般的なプロセス
　・人間特性への仕事の適合
　・セーフティクリティカルなヒューマンエラーの低減
　・適切な情報とフィードバックの提供
　・安全なＨＭＩ設計のための指針
　　→人間の能力を置き換えるのではなく、それを高めるように設計する
　　→オペレータを考慮することから設計プロセスを開始する
　　→設計の意思決定と安全解析にオペレータを参加させる
　　　他、「セーフウェア」参照

●終わりに
　・最近の事故を観察すると、システムの安全という視点が欠けてい
　　るように思える
　・我々は、システムというものの特性をもっとよく知る必要がある

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
Ｑ＆Ａ
Ｑ．Ｔ社問題は政治的な問題になっている。本質に迫ってないように
　　思う。難しいのか？
Ａ．日本の場合は犯人探しになっている。ソフトウェアの場合、何が
　　起こったのかトレースする仕掛けがない。
Ｑ．日本のメディアの場合は、データおよびその信頼性がないので、
　　そもそもの議論に入れない。
Ａ．－
Ａ．経営者の説明不足ではないか
Ａ．経営者に届いてないのではないか
Ａ．経営者の聞く気は？

Ｑ．チームにカリスマがいるとチェック機構が働かないのではないか？
Ａ．－

Ｑ．「セーフウェア」から、安全確保のためのインプリメンテーション
　　の活動をしているか
Ａ．MITから本がでている（ハズ）

Ｑ．今のシステムは人間の能力をこれているとのことだが、今後どうす
　　ればよいか？
Ａ．試作してみて評価が必要。売ってしまうのは経営判断

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

Ｔ社問題について
●思い出した人
　・桜井真一郎
　　→自らが設計した車を自分で最初にテストドライブ
　　　自分の身体は測定器より約１万倍精度がよい
●セーフウェアに関して
　・自動車がとてつもなく複雑な怪物に化けたことｓに、頭では分かって
　　いても行動が伴っていないのではないか
　　→信頼性≒安全性と考えていた
　・ドライバー（オペレータ）おせいにしたがる文化が見える

SEC主催セミナー　ソフトウェアデータ白書２００９　聴講記

2010-02-10T13:21:00.006+09:00

ソフトウェアデータ白書２００９の効果的な活用法

IPA　独立行政法人　情報推進機構
SEC　ソフトウェア・エンジニアリング・センター

研究員　森下　哲成氏
研究員　小倉　隆氏氏

１．はじめに
２．定量データ活用の背景
３．定量データ活用の利点と課題
４．定量データの実践的活用方法と事例
（１）見積り
（２）計画
（３）コントロール
（４）評価
５．実践的活用をサポートするツール
６．まとめ
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
１．はじめに
●本セミナーの目的
　→データの活用の仕方やポイントを理解する
　→「分かる」から「使える・できる」ための実践力向上

２．定量データ活用の背景
●IT産業を取り巻く環境
　理想：システムへの要求が増大、安全・安心の確保要請が増大
　　　　→低コスト、短期開発
　　　　→多機能、高性能
　　　　→信頼のおけるマネジメント
　　　　→トラブル発生未然抑止
　現実：不適切な見積り、生産性の見誤り、人海戦術的な対処方法での対応
　　　　→ＫＫＤ
　定量データに裏づけられたマネジメントの実施が不十分

●ユーザ・ベンダ間の納得感の欠如
　「やりたいこと」と「できること」の整合が必要だが...
　・共有しやすい見積手法がない
　・初期の使用は固めにくく、早期契約時の適切な見積りが困難
　・要件決定の遅れ、プロジェクト途中での仕様変更の発生
　→両者間の無理な、不整合によるプロジェクトの破綻

●工事進行基準の適用
　プロジェクトの進捗部分について「成果の確実性」認められる場合に適用される
　→高い精度と確実性、客観性が求められる

　定量的マネジメントの強化、実践が急務

３．定量データ活用の利点と課題
●定量データの必要性
　定量データが集まれば・・・こんな活用が出来る
　ユー、ベンダ間の合意形成
　→ユーザ
　　経営層：IT投資、概略計画の妥当性、実現性の目安
　　業務・情報システム部門
　　組織長・スタッフ：予算数値、根拠の制御
　　　　　　　　　　　ベンダからの見積の比較と評価、強み／弱みの認識
　　プロジェクト管理者：計画策定、目標値の制定、ＱＣＤの妥当性評価
　　　　　　　　　　　　予実差異の分析、完了評価、開発能力の評価
　→ベンダ
　　経営層：自社の強み・弱み、生産性などの開発力の認識
　　ＰＭＯ
　　品質保証部門：定量データベースの構築
　　　　　　　　　自社プロジェクトのベンチマーキング、モニタリング
　　プロジェクトマネージャ
　　プロジェクトデータ：規模、工数、工期、品質の見積り、計画策定、制御
　　　　　　　　　　　　オフショア等、外部委託先評価
●定量データ活用の一例
　省略

●定量データ活用における課題
　なんとはなくイメージはついている。でも、あと一歩が踏み出せない
　要因は？
　・どのくらいパワーがかかるのか？
　　→管理者（管理組織）や開発現場の負荷がきになる。
　・データを効率よく収集、分析できるか？
　　→どのような環境やツールを用意すればよいのか分からない。
　・開発現場のマネジメントをどうすべきか？
　　→現場の反発に遭った場合、どう対処するのがよいのだろう。
　・定量化のメリットをどのように説明するのか？
　　→現場を説得し、巻き込むための材料がない

●定量化に取組む前の「取組み」
　闇雲に取組んでも成果はでない。なぜなら･･･
　・主にＱＣＤの観点で目標とすべきこと、つまり
　　「問題意識と改善の必要性」が明確でなければならない。

　・目的実現によって「何が得られるのかを具体的」に示し、
　　関係者間で理解、共有しておく必要がある
　　例えば、品質が上がるとなにが嬉しいのかが明確であること

　・定量化活動（プロジェクト）のオーナーを明確にし、その
　　人が「強い意思を持って推進する」ことが重要である

　・欲張ることなく「コアな問題・課題の解決に絞り込んで」
　　取組むべきである。

●課題と対応事例（１）
　Ａ社の事例：費用対効果の説明
　課題：収益に直接結びつけることが難しい定量データ活用の費用対
　　　　効果をどのように説明するか？
　対応策
　　・目標：赤字０＝トラブルプロジェクトの撲滅
　　・施策：定量的プロジェクトマネジメントの強化と組織的推進
　　・結果：部門毎に、赤字、トラブル（実行予算オーバー）の額と、
　　　　　　定量的データ活用度合いを、経年変化を交えて相対評価
　　・補足：現場での監視（モニタリング）のためにレビューや監査が
　　　　　　必要で、実際のトラブル撲滅に効果を発揮

●課題と対応事例（２）
　Ｂ社の事例：利用価値のあるデータ
　課題：収集した会社データから分かることを単純にフィードバックしても
　　　　現場では使えないとい言われてしまう。
　対応策
　　・目標：現場からのデータ提供～活用のサイクルの確実な実施
　　・施策：特定部門およびそこの顧客別のデータ白書を作成
　　・結果：自部門のためのデータ提供という意識があり、定量化に
　　　　　　取組む納得感が高い
　　・補足：データの傾向の有無に関わらず、強み・弱みの評価、
　　　　　　対策を行うことで、現場との信頼関係構築が可能

●課題と対応事例（３）
　Ｃ社の事例：開発の目標設定と評価
　課題：生産性向上に特化し、開発時の目標設定と評価を確実に実施
　　　　するための施策をどうするか？
　対応策
　　・目標：ＦＰによる生産性の計測をよび評価
　　・施策：要件定義終了時の生産性目標と、リリース後の実績を
　　　　　　会議で確認
　　・結果：生産性目標の設定および評価の定着
　　・補足：実行に強制力を持たせるとともに、担当役員を含め、会議
　　　　　　のなかで繰り返しＦＰ（生産性）に言及することが重要

●ＳＥＣの取組みとデータ白書の目的
　日本のソフトウェア業界発展のために
　　・モノサシとしての精度を高めていく
　　・新たなモノサシや課題抽出の切り口を提案する
　　「ソフトウェア開発データ白書」として公開
　　（２００９年度は２２企業、２３２７プロジェクトのデータ）
　→定量的アプローチによる科学的マネジメントの普及拡大へ

●データ白書２００９の構成
　１章　背景と本書の目的
　２章　収集データについて
　３章　分析について
　４章　収集データのプロファイル
　５章　プロジェクト主要要素の統計
　６章　工数、工期、規模の関係の分析
　７章　信頼性の分析
　８章　工程別の分析
　９章　予実分析、生産性クロス分析

●データ提供企業
　２２社（省略）

４．定量データ活用の背景
●ソフトウェア開発ライフサイクルから見た活用事例
　・見積り
　・計画（プロジェクト計画策定）
　・コントロール
　・評価
　※答えを一つにもとめないデータ活用方法の提案

●見積り
　（１）「工数見積り」データ活用ポイント
　　　　→規模に基づく工数の妥当性確認について
　　　　　（５０％信頼幅による妥当性検証の方法）
　（２）「工期の見積り」のデータ活用ポイント
　　　　→工数に基づく工数の妥当性の確認について
　　　　　（９５％信頼幅での限界認識の方法）

●「工数の見積り」のデータ活用ポイント
　プロジェクトの規模と工数との間に定式性や特性を見出し、
　規模に対する適正な工数範囲を目安にできるようにする

●ポイント：規模と工数のデータ活用
　規模と工数の関係に、傾向や相関がみえれば
　・工数見積の妥当性確認に利用
　　→±５０％の信頼幅に入っていれば、妥当性が高いとみなす
　　　（差異理由や他の見積り手法との整合性などの分析、チェックは必要）
　　→±５０％の信頼幅に入っていなければ、差異理由によっては
　　　　見直し、ブレが大きいようであれば、際原因を追究する
●留意点
　・規模が大きくなると規模の増加率以上に工数が増大する
　　→一般的に規模が大きくなると関係者も多くなり、間接的な工数が増加する
　・誤差が大きい可能性を考慮する
　・データファンクション、ＤＢテーブル、画面、帳票、バッチなど、複数の規模測定要素の関係をみる。また、その上でＦＰ規模やＳＬＯＣ規模との関係も合わせて利用する
　・ソフトウェア開発プロジェクトのデータは正規分布していないことが多い
　　→対数に変換するとほぼ正規分布とみなせることが多い。
　　→「正規分布」であることを前提としている相関係数の有意性や回帰式の予測値の信頼区間推定を求めることができる
　・両方もしくは一方のデータを対数スケールに変換すると相関が明確化
　　→白書では散布図の表記において、必要に応じ対数スケール表示を取り入れいる
　・元のスケールに戻すと有効範囲（誤差）は右上方向に開く
　　もとのデータに戻し、±５０％の信頼幅を示すと・・・
　　→規模や工数が大きくなるに伴い信頼幅が広がるため、規模と工数の関係など、
　　　妥当性の検証時はそれを考慮して判断する必要がある

●「工期の見積り」のデータ活用のポイント
　プロジェクトの工数と工期との間に定式性や特性を見出し、
　工数に対する適正が工期範囲を目安にできるようにする

●ポイント：工数と工期のデータ活用
　工数と工期の関係に、傾向や相関が見えれば...
　・工数から工期の妥当性チェック
　・工期短縮の目標値の目安
　・工期短縮のリスク度合いの目安
　　→工数と工期を見積もる際、期間短縮や納期の要求に対し、
　　　それが対応可能かどうか、信頼幅９５％の加減を限界の
　　　目安として判断する

●ポイント：工数と工期の分析結果とデータの見方
　データの関係性
　・新規開発では工数と工期には正の「相関」が見られる
　　→ばらつきはあるが、工期（月数）は工数の３乗根に概ね比例している
　・散布図の分布状況
　　信頼幅９５％の下限値より下にはプロジェクトはほとんどない
　　→工数に対する工期の実現可能性を考える上で目安になりそうである

●【参考】母体規模別のＳＬＯＣとテストケース
　ソフトウェア改良開発における見積りは、新規開発に比べて、以下のように改良開発の特性を考慮したテスト量の見積りが重要である
　・既存の母体システムにおける品質面でも考慮
　　（既存システムの品質が思わしくない場合、品質を確保する作業が必要）
　・テスト巻き込み規模（変更の際に影響を受ける部分を表す規模）の把握

　データ白書２００９では、改良開発のプロジェクトを対象に、SLOC規模とテストケース数の関係を母体規模にしめしている
　・母体規模を大（２００K以上）・中（５０～２００K）・小（５０K未満）の３つに分ける

　→実行値として規模だけではなく、母体の規模も考慮し、テストケース数や、
　　生産性を加味した見積りや計画策定が必要

●計画（プロジェクト計画策定）
　・工数、工期の妥当性の確認
　　→プロジェクト全体、工数別の工期、工数の適正度の評価
　　→計画実現の達成度、リスク度の把握
　・工数（要員）山積みの妥当性の確認
　　→工数比率と工期比率を利用した工数山済み妥当性確認の方法
　　→計画実現の達成度、リスク度認識
　　→工程別の実現工数比率からの妥当性確認の事例等

●利用・想定事例
　・ケース１：発注側の要件として工数を優先する場合、開発規模を小さくするため
　　　　　　　機能を削減するか、または分割開発により工期をずらえい、機能毎の
　　　　　　　優先度を必要時期を協議する
　・ケース２：発注側が工期に拘らない場合、コストを守ることを前提に、工期を
　　　　　　　±５０％信頼幅の中央部近傍の工期を提案する
　・ケース３：開発対象機能（規模）を優先する場合、±５０％信頼幅の中央部近傍
　　　　　　　の工期を提案するとともに、±５０％信頼幅の工数を提案する

●工数山済みの妥当性の確認
　工程別の工数、工期比率の関係を見出し、プロジェクト全体から、
　さらに詳細な見積、計画、評価などに利用できるようにする。

５．実践的活用をサポートするツール
　プロジェクト診断支援ツール
　https://sec.ipa.go.jp/project_assessment/TopMenu.do
　※ユーザＩＤの登録要（ログオフ時にデータは消える）

　スタンドアロン型診断支援ツール
　http://sec.ipa.go.jp/tool/pasa.html

６．まとめ
　・データ白書はデータの宝庫ではあるが、全ての答えがそこにあるわけではない
　・見積や計画策定について、過去の事例を参考に、まずは自分で行うことが重要
　・自分の見積や計画の妥当性を確認するためには、データ白書を紐解く

Ｑ＆Ａ
Ｑ．診断ツールを使って、データを提供できるか？
Ａ．いまは消える仕掛けにないている。
　　提供したいのであれば、別途相談
Ｑ．開発５工程の定義はどうなっているか
Ａ．データ白書を見てくれ（共通フレームをもとにしている）
Ｑ．プロジェクト診断支援ツールの説明のためにＳＥＣジャーナルをコピーして良いか？
　　また、セミナー資料はどうか？
Ａ．社内であればコピー可
　　ダウンロードできるようになる（急ぎであればコピー可）

JaSST '10 Tokyo （1日目）

2010-01-28T08:47:00.005+09:00

今回は、１日のみの参加です。

【本日参加予定のセッション】
10:00～　オープニングセッション
10:15～　Successful Software Management: 17 Lessons Learned
　　　　成功するソフトウェア・マネジメント:　17の教訓
　 Johanna Rothman (Rothman Consulting Group, Inc.)
13:00～　テスト設計・自動化
　　　　～モデルベースドテストの萌芽～
　　　　■D2-1
　　　　　状態遷移表を用いた状態遷移テストの自動化
　　　　■D2-2
　　　　　テスト条件生成支援ツールの開発　CEGTest
　　　　■D2-3
　　　　組込みリアルタイムＯＳのＡＰＩテストの実施
　　　　■D2-4
　　　　マルコフ連鎖モンテカルロ法によるソフトウェアテストケースの設計
15:10～　テクノロジーセッション
　　　　■D3
　　　　ソース解析ツールの活用による品質確保と全体品質の管理・統制方法
16:30～　メトリクス
　　　　～測る、量る、図る、諮る、謀る？～
　　　　■D4
　　　　テスト技術者のためのソフトウェアメトリクス入門
　　　　- 信頼性を測定し予測する正しい作法 -
18:30～　情報交換会
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
10:15～　Successful Software Management: 17 Lessons Learned
　　　　成功するソフトウェア・マネジメント: 17の教訓
　 Johanna Rothman (Rothman Consulting Group, Inc.)
【１７の教訓】
１．あなたが何をすれば報酬がもらえるかを知る
　　→肩書きと仕事の内容を一致させる必要有り
　　→一致させないと期待されていない仕事をしてしまう可能性あり
２．実際にできる仕事の計画をする
　　→脳はマルチタスクはできない
　　→仕事を切り替えると、コンテクストをかえる必要があり
　　　時間がかかる・忘れるなどのリスクがある
３．そのときの最優先事項に集中（優先すべきは一つしかないことを受け入れる）
　　→重要度と緊急度を間違えない
　　　緊急作業をしないようにするための作業が重要な作業
４．部下に相談せずに期限等の約束しない
　　→プロジェクトは生き物（報告を聞いていても、話しているいま変わっている可能性あり）
５．作業に最適な人を雇う（適材適所）
　　→多様な人材を雇う必要がある
　　→常に疑問を発する人は、効率が下がる可能性はあるが、危機を救う可能性もある
６．良いチームを保つ
　　→良いチームは解散しない（再結成が困難）
　　→チームワークを乱す人は排除する
７．押し付けの援助や細かすぎる管理の排除
　　→過剰な管理はよくないが、行き詰まりをみつける必要はある
　　　（正しい答えはない）
　　→ある会社の例
　　　３０分作業が止まったら、上司に報告
８．人の多様性に敬意を払う
　　→一人一人の特性に合わせた説明が必要
　　　全体像が知りたい人・なすべきことだけが知りたい人多数いる
９．週１回（１対１）のミーティング
　　→１対１のミーティングが重要
　　→１対１でないと信用が築けない
　　→１５分／回で良い
　　→話すこと
　　　・達成したこと
　　　・進捗
　　　・課題
　　　・助けて欲しいこと
　　→うまく行っていてもフィードバックがないと不安になる
１０．仕事の時間の中でトレーニングの時間をとる
　　　→米国では昼食の時間に勉強会をしている
　　　→非公式な場での情報交換の場が必要
　　　→自己啓発の時間ももつ必要がある
１１．部下の手柄を認める
　　　→部下の手柄を認めことが自分が成果になる
１２．仕事の出来ない人をクビにする
　　　→うまくいてない人がいると、全体のパフォーマンスが下がる
　　　→解雇ができないなら、プロジェクトから外す
　　　→問題の人に正直にフィードバックする
　　　　（１対１のミーティングで毎週すると効果的
　　　　　改善される可能性がある）
１３．結果は時間に比例しない
　　　→就業時間制限すると生産性があがった事例有り
　　　→改善には時間がどう使われいるか記録するのが効果的
　　　　特に自分で記録すると無駄な時間に気づく）
１４．自分の間違いを認める（受け入れる）
　　　→出来るだけ早く認めて、次に進む
　　　→過ちの否定、責任転嫁が良くない
　　　→間違いを責めるのではなく、正すにはどうしたらよいかを考える
　　　→過ちを認めることが、完璧に近づく
１５．よい仕事を承認し、讃える
　　　→報酬は必要であるがそれだけではダメ
　　　→プラスのフィードバックでよい
　　　→上司でなく同僚でも良い（同僚の投票でも良い）
　　　→感謝の言葉でもよい
　　　→どうやって讃えるかを、チームで討議しても良い
１６．休暇（バケーション）をとる
　　　→燃え尽きると仕事ができなくなる
　　　→休まないと
１７．自己管理
　　　→一番にあげる教訓
　　　→１～１６を自分に行う
　　　→感情の管理も必要
　　　　イライラを感じるのであれば、原因を探る
　　　　（演者は日誌を書いている）

技術者でも偉大なマネージャになれる

Ｑ＆Ａ
Ｑ．＃６チームを作るときに、嵐が起きたときに抜け出すためになにをすべきか？
Ａ．活動は仕事をベースとしている。
　　一緒に仕事をすることに意義がある。
Ｑ．＃１０　ボトムアップ的な管理だと思うが、トップダウンの管理とのバランスはどうすれば良いか
Ａ．サーバントリーダアプローチ
　　個人的には次の優先順位が良いと考える
　　１．部下　２．顧客　３．組織
　　ただし、人による
Ｑ．多様な人を集める必要があが、チームを解散しないと多様性が失われるのではないか？
Ａ．性格（個性）に多様性が有る人を集めると、時間が経っても多様性は失われない
　　技術的な多様性は失われるリスクがある。
Ｑ．同じ仕事（チーム）のマネージャを続けると弊害がある。変わる目処があるか？
Ａ．場合によりけり
　　（自分の場合）
　　・１０年は長い（５年はなんともいえない）
　　・長く勤めて悪いことはない
　　・長く勤めると視野が狭くなる可能性がある。それをどうやって広げるか
　　注意点
　　・下した判断の結果に責任
　　・フィードバックのシステムをつくり上げているのか
Ｑ．改善点を上司にどういやって伝えたら良いのか
Ａ．「問題に対する答えをもってきました」という言い方はしてはいけない
　　こういうやり方があるというオプションを用意するという提案をする
　　提案をし、判断を上司に委ねる

■D2-1 状態遷移表を用いた状態遷移テストの自動化

１．状態遷移テストとは
　●状態遷移のコンポ
　・状態
　・イベント
　・アクション
　・遷移
　●オーソドックスなテストは手動
　・テスターの集中力に依存
　・テスト設計が属人化
　●通常は捕獲再生ツール
　・テスターの集中力には依存しない
　・テスト設計の問題は残る
　・プログラム変更にあわせたテストケースの修正が困難
　・エラー発生時に中断

２．今回の自動化ツール
　●動作環境
　　Quickテストから呼び出される
　●入力
　・状態遷移モデル
　●ツール
　・表作成ツール、自動実行モジュール
　●利点
　・プログラム変更時には状態遷移モデルの変更のみでよい
　・テストによる状態の巡り方を最短にする
　・エラー発生時には初期状態に移る
　・実行オプションにより状態の巡り方を変えられる
　　→順番
　　→ランダム

３．適用事例
　●CAD/CAMソフトに使用
　　→２～６回のテストで回収
　　→力ずくのテストができるようになった
　●Webブラウザのお気に入りの追加
　　→
　　→
Ｑ．適用実績の状態数は
Ａ．４～１０個

■D2-2 テスト条件生成支援ツールの開発　CEGTest
１．組み合わせてスト
　●さまざまなテスト設計技法を利用して、できるだけ少ないテストケースで網羅する
　●直交表系
　　・直交表
　　・HAYST法
　●デシジョンテーブル系
　　・デシジョンテーブル
　　・原因結果ぐる阿附技法

２．原因結果グラフ技法
　●入力やイベント（＝原因）の組み合わせと、出力（＝結果）との関係をブールグラフ化しそこからデシジョンテーブルを作成する
　●手順
　　・仕様から原因結果テーブル
　　・原因結果テーブルからデシジョンテーブル
　　・デシジョンテーブルからテストケース
　●問題点
　　・仕様から適切な原因結果テーブルができない
　　　グラフの質は作成者の質に依存
　　・デシジョンテーブルの作成ができない
　　　お手本がない
　　　規模が大きいソフト→ノード大・論理が複雑
　　　再作成のてま
　　・誤りがないか検算しなくてはならない
　　　手作業
　　・無償のテストツールが見つからない
３．支援ツール（CEGTEST）の紹介
　　●特徴
　　・Webブラウザで操作
　　・キーボードでなくマウス操作
　　・デシジョンテーブルは自動生成
　　・原因結果グラフを作りながら、デシジョンテーブルが作成できる
　　●デモ
　　　省略
４．効果想定
　　●条件
　　・CEGTEST使用
　　・Excle使用
　　作業時間の比較
　　●結果（１１例）
　　・８０％の作成
　　・複雑になればなるほと効果は多くなる
　　・手作業による誤りが少なくなる

５．今後の取り組み
　・グラフ作成時の工夫
　・制約に関するテスト
　・テスト実施との連携
　　http://softest.cocolog-nifty.com/labo/CEGTest/

Ｑ．組み合わせロジックは論理網羅だとすると、柔軟性があるはず。
　　人が判断してよいとされている箇所は、ツールがどうあつかっているのか？
Ａ．開発途中なので今後の課題

■D2-3 組込みリアルタイムＯＳのＡＰＩテストの実施
1.オープンソースの組込み向けＲＴＯＳとそのテストの現状
　●オープンソースを製品として使用するに品質保証が重要
　●オープン素づの組込み向けＲＴＯＳ（TOPPERS）
　・包括的なテストは未実施
　・マルチプロセッサ環境
　→明大でテストスイートの開発（将来オープン化）
２．ＡＳＰカーネルの仕様
　＜省略＞
　・１２１個のＡＰＩがある

３．ＡＰＩのテスト概要
　●統合仕様書に基づいてＡＰＩ発行前後のシステム状態の変化を確認する
　●作業フロー
　・テストシート作成
　・テストファイル作成
　・テストシートテストファイル手ビュー
　・テストプログラム生成
　・テストプログラム実施
　・結果確認

４．問題点（発生したばらつき）と対策
　●問題
　・ＡＰＩに特化した仕様に対するテストケースは同じ
　・カーネル全体の振る舞いに関するテストケースにばらつき
　　→仕様書の構成に問題あり（１万頁の理解が必要）
　・同値分割の粒度にばらつき
　　→粒度に対するポリシーがない
　●対策
　・仕様書の確認が必要な部分の意識あわせ
　・関連各社でポリシーの作成
　●テストプログラムのばらつき
　　→テストプログラムを自動生成

５．ＴＴＧ（ＴｏＰＰＥＲＳ　Ｔｅｓｔ　Ｇｅｎｅｒａｔｏｒ）
　●メリット
　・開発工数削減
　・テストケースの保守性、可読性
　他
　●結果
　・１６００件のテストケース
　・バグ１２件（仕様書　５件、ソース　７件）

６．今後の課題
　●仕様とテストケースの対応付け
　●テストポリシーの定義

Ｑ．ターゲットＣＰＵは特定しているか
Ａ．特定している。
Ｑ．ターゲットの異なる部分はどうなるか
Ａ．ターゲット非依存ではない。結果的に依存部もテストされている
Ｑ．論理カバレージはどうなっているか
Ａ．アセンブライメージでカバレージ１００％
Ｑ．ＯＳのテストと一般のＡＰとの違いは
Ａ．ターゲット依存部がＯＳ固有となることが違い

■D2-4 マルコフ連鎖モンテカルロ法によるソフトウェアテストケースの設計
　●自己紹介
　　信頼性評価ツール（SRATS)

　●背景
　テストケースの評価をどうするか
　・テスト設計技法は沢山ある
　　→なぜよいのか？理論的裏づけ
　・経験則の本質
　　プログラム処理の境界にバグがあることが多い
　　代表値だけで大丈夫だ
　　各命令は最低１回は実行しておくべきだ
　　バグはたった２つの組み合わせで発生しやすい
　●発表の目的
　・経験則を確率・統計的に扱うモデルの考察
　・テストケース設計と確率・統計
　●ソフトウェアテストのモデル
　・テスト関数の出力が１となる領域を効率的に探す手がかりは入力領域の特徴
　　ソフトウェア入力領域→テスト→０：成功、１：失敗
　　例えば、
　・同じ結果を出力する領域の代表値をテストする
　・統計モデルとして
　　同値クラス：同じ結果を出力する確率が高い入力
　＜以下略＞
　　目的は面白そうなのだが、未だ話が遠そう…

Ｑ．データ蓄積中のソフトウェアの変化にどう対応するのか
Ａ．経験則はソフトウェアの仕様と関わらずにとれるものを使う

＜電源がないため、更新頻度はおちます…＞

ソフトウェアの「開発」と「保守」　何が違う？

2010-01-26T22:24:00.002+09:00

ソフトウェア・メインテナンスフォーラムのお知らせです

みなさんお越しください。

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
ＳＥＲＣフォーラム：ソフトウェアの「開発」と「保守」　何が違う？
　　　　　　　　　－ＳＬＣＰの観点からその関係を明確にする－
　　　　　　　　　　　　主催：ソフトウェア・メインテナンス研究会

　SERC(ソフトウェア・メインテナンス研究会)は，1990年設立以来，国内唯一のソフト
ウェア進化・保守に関する研究グループとして，ソフトウェア保守の諸問題に焦点を当
て，さまざまな観点から解決策を探ってまいりました。
　今回，改めてソフトウェア保守とは何かについて，SLCP（ソフトウェア・ライフサイ
クル・プロセス）の観点から「ソフトウェア開発」との相違点を中心に考えてみようと
いうフォーラムを企画しました。
　ソフトウェアに関する作業について「開発」「設計」「プログラミング」「保守」な
どの言葉が一般的に使われますが，それぞれの言葉の領域，上下関係，包含関係などか
なり曖昧なまま今も使用していることが多いのではないでしょうか。一方，ソフトウェ
ア保守作業（広い意味の稼動後や既存のソフトウェアの変更・修正）は，ソフトウェア
ライフサイクルの３分の２以上を占めるという報告もあります。
　ソフトウェアの「開発」「保守」「運用」のスコープ／相違点を明確に定義した規格・
ガイドにISO/IEC 12207:1995/AMENDMENT 2:2004（JIS X0160:1996/AMENDMENT 1:2007）
やIPA/SEC刊行の「共通フレーム2007（第２版）」などが存在しています。これらは
"SLCP"と呼ばれている規格・ガイド群です。
　今回のフォーラムを通じて，ソフトウェアの保守作業が実際にどの程度存在している
のか，保守プロセスは確立されているのか／いないのか，確立されているとしたらどの
ようなものなのか，開発プロセスや運用プロセスとの関係はどうあるべきか，共通フレ
ーム2007（第２版）等で示された保守プロセスをどう活用するのが良いか，参加者の皆
さまのソフトウェアのご経験を基に活発な論議ができればと考えております。

　今回のフォーラムでは，共通フレーム2007の初版，第２版の編集委員会主査という重
責を歴任された富士通・村上憲稔氏に，基調講演をお願いすることができました。共通
フレーム2007の作成意義，発行までの経緯，活用の仕方と有効性，第２版の改訂内容
（含む保守プロセス）などについて，興味深いお話が聞けるのではないかと思います。
　SERC幹事講演１では，ISO/IEC14764:1999，2006のJIS原案作成委員会委員を歴任し，
当研究会編「～ISO14764による～ソフトウェア保守開発」の編集リーダである増井和也
氏（当研究会幹事）が，ソフトウェアの「開発」「保守」「運用」の使用実態，課題，
課題解決のアプローチについて独自の理論をお話します。
　SERC幹事講演２では，同じく当研究会幹事・田中創氏がシステム運用の視点から見た
ソフトウェア開発・保守の考え方について，ＩＴＩＬ視点やＳＯＸ対応から見た保守と
開発の違い，運用現場が期待する保守・開発の役割や意義をお話します。
　最後のミニパネルでは，ソフトウェア開発，保守，運用の区分けのあるべき姿につい
て，会場の皆さん，事例発表者で活発なデスカッションの機会を持ちたいと考えており
ます。
　既存のソフトウェアを修正，機能追加，カスタマイズに関する作業の改善，品質向上，
生産性向上，要員のモチベーション向上を推進する上でヒントが多く得られる機会とな
ればと思います。多くの皆さまのご参加をお待ちしております。

《開催要領》

　●日時：2010年2月26日（金）10:00-17:00（受付9:30-)

　●プログラム
　　 9:30- 10:00　受付
　　10:00- 10:05　開会の挨拶　　　　　SERC代表幹事
　　10:05- 11:40 基調講演　　　”超上流”そして”保守と開発”のプロセス管理が
　　　　　　　　　　　　　　　　プロジェクト成功への条件
　　　　　　　　　　　　　　　　～共通フレーム2007をどう活かしていくか～
　　　　　　　　　　　　　　　　　　　村上　憲稔氏（富士通）
　11:40- 13:00 昼食休憩
　13:00- 13:40　SERC幹事講演１　なぜソフトウェアで「開発」と「保守」を分けるべ
　　　　　　　　　　　　　　　　きなのか
　　　　　　　　　　　　　　　　　　　増井　和也氏（東芝ソリューション）
　13:40- 14:20　SERC幹事講演２　運用現場から見た保守・開発とは
　　　　　　　　　　　　　　　　　　　田中　創氏（アイ・ティ・フロンティア）
　14:20- 14:40　休憩
　14:40- 16:30　パネル討論　ソフトウェア開発，保守，運用の区分けのあるべき姿とは
　　　　　　　　　　進行　　：高橋　芳広氏（日立ソフトウェアエンジニアリング）
　　　　　　　　　　パネラー：増井　和也氏　（東芝ソリューション）
　　　　　　　　　　　　　　　田中　創氏　（アイ・ティ・フロンティア）
　16:30- 16:40　連絡事項

　●会場：日本橋公会堂　集会室（洋室４）
　（地下鉄　半蔵門線・水天宮駅から徒歩2分）
　　http://www.city.chuo.lg.jp/sisetugaido/horu/nihonbasikokaido/index.html
　　　　　　
　●定員：40名（先着順）
　
　●参加費：SERC研究員1,000円，一般 3,000円
　　当日，会場受付にて現金でお支払いください，領収書を差し上げます（お釣りのない
　　ようにお願いします）。
　　
　●申込方法：
　　下記申込用紙の形式に必要事項を御記入の上，SERC事務局(smsg-
secretariat＠smsg.or.jp) に
　メールにてお申込みください。当日ミニパネルで討論したい職場の課題があれば記載く
ださい。
　　折り返し，受講票をメールで送りますので，当日，持参ください。
　　定員超過でお申込をお断りする場合には，メールにてご連絡いたします。
　　申込み〆切り日以降のキャンセルは実費を頂きます。

　●申込み宛先: ソフトウェア・メインテナンス研究会(SERC)
　　E-Mail: smsg-secretariat＠smsg.or.jp
　　URL: http://www.smsg.or.jp/

　●申込み〆切り：　2/19（金）

=======================================================================
2010年2月 SERCフォーラム参加申込用紙

氏名 (ふりがな)： _______________ (________________________)

会社名： _____________________________________________________________

部門・役職： _________________________________________________________

住所： (〒____-______) ________________________________________________

Tel: _____________________ Fax: _____________________

E-Mail: ___________________________________

種別 (該当欄にチェック):
　□SERC研究員（1,000円）　 □一般（3,000円）

フォーラム参加費：_________円

ソフトウェア進化で見えてくるもの（その２）

2010-01-11T14:23:00.003+09:00

今回は、ソフトウェア進化という見方の利点を考えたいと思います。

では、ソフトウェア進化の利点はなんでしょうか？

多数ありますが、主なものは次の３点だと考えます。

１）完全なソフトウェアという幻想からの覚醒

　『バグのないソフトウェア』、『正しい要求仕様』など、完全なソフトウェアという幻想があるれています。

　曰く、「ソフトウェアの開発時にバグのないものをつくれば、保守はいらない（容易）」
　また、「要求定義を十分に行えば、仕様変更は防げる」
　たしかし、ソフトウェア開発時の品質を上げれば、そでないものと比べて保守は容易になりますし、不十分な要求定義が仕様変更が多発する原因になっていることもあるでしょう。

　では、保守がいらないくらいに開発品質をあげるには、仕様変更が不要になるまで要求定義をおこなうにはどれだけの時間が要るでしょうか？、

　「そんなの判らない！」と、思う方もあるのではないでしょうか？

　はい、それが正解です。

　前回述べた通り、環境に適用するソフトウェアが良いソフトウェアです。そして、ソフトエアの取り巻く環境は時々刻々と変わります。要求される品質レベルも、ユーザニーズも変わっていきます。
　従って、変更が不要な完全なソフトウェアを目指すのでなく、変更が容易なソフトウェアを目指すべきでしょう。

２）プラグマティズム暴走の防止

　ソフトウェア業界には、完全なソフトウェアという幻想があるにも関わらす、体力や時間というプラグマティズムがあります。

　ここでいうプラグマティズムとは、「本当はこうしたいのだが人が足りないからここまでしかできない。」「理想はこなのだが、時間や予算のできる範囲でやろう。」というようなことです。

　これは、完全幻想があるからこそプラグマティズムが発生するのではないでしょうか？

　確かに、体力や時間など物理的な制限はあるでしょし、無視することはできません。しかしながら、その制限が過大に評価されてやらないことの隠れ蓑になっているのではないかと危惧していますj。

　ここで、体力や時間等の制限も『適用すべき環境の一部』と考えれば、制限に囚われる挑戦的な仕事ができるものと考えます。

３）考えるべき環境の拡大

　ソフトウェアが適応すべき環境は様々なものがあり、それらの人の思いは変わっていきます。
　例）
　・最終利用者（システムのサービスを利用する人）
　・サービスの提供者（システムのサービスを提供する人）
　・システムの構築者
　・システムの保守者
　・システムの運用者
　・法監督官庁や法律
　・マスコミやスズメ
　等々

　しかしながら、ソフトウェア技術者はそれら全てを意識していないのではないだろうか？大多数のソフトウェア技術者は、発注者がサービス提供者であればその時にサービス提供者が満足いくかどうかのみを意識するでしょう。
　ところが、その時にはサービス提供者が良いと思って決めた仕様でも、サービス利用者が使ってみて使いにくかったら、サービス提供者は不満になるでしょう。

　ソフトウェア進化（ソフトウェアは環境に適応する）と考えると環境を意識するため、ソフトウェア技術者の視野を広げる効果が得られることになります。

ソフトウェア進化で見えてくるもの（その１）

2010-01-06T21:11:00.003+09:00

話題は昨年の１１月末のソフトウェア進化に戻ります。

まず最初ににソフトウェア進化について説明します。

生物の進化論は未だ争点はありますが、基本の考え方の「適者生存」は定説となっています。

つまり、「環境に適応した個体（種）が生き残る」ということです。

「強いものが生き残るのではなく、環境に適応したものが生き残る」という言い方もされます。

この環境に適応するというアナロジーはソフトウェアについてもうまく当て嵌まります。

つまり、ソフトウェアはそのソフトウェアの使用される環境に適応したものが使い続けられることになります。

ソフトウェアはあることにより価値があるのではなく、使われることにより価値が発生するものですので、使い続かれるるソフトウェアが価値が高いといえるでしょう。

そして、ソフトウェアが使い続けられるために、使われる環境に適応し変化する必要があります。

さらに、使われる環境も変わっていきますので、適応のための変化は継続することになります。

この変化をソフトウェア進化と呼ぶことにしましょう。

では、環境とはどういったものでしょうか？

例えば、ハードウェア、利用者のニーズ、法律・制度等々。ソフトウェアの利用にかかわる様々なものがあります。

つまり、ハードウェア、利用者のニーズ、法律・制度等々ソフトウェアの使用環境およびその変化に適応させるためソフトウェアを変えることがソフトウェアの進化です。

こういうと、ソフトウェア進化はソフトウェア保守も含まれることが想像できると思います。

しかし、ソフトウェア保守がけでなく、ソフトウェア開発・保守作業すべてをソフトウェア進化ととらえることが出来ると考えます。

では、ソフトウェア進化ととらえると何が嬉しいのかを見て行きたいと思います

謹賀新年

2010-01-06T20:58:00.003+09:00

＜大変遅ればせながら＞

新年　明けまして　おめでとうございます。

昨年末は更新が滞っておりましたが、

新年パワーアップしてソフトウェア保守に関する話題を

お届けして参ります。

よろしくお願いします。

SEA Forum Dec. 2009 聴講録

2009-12-22T18:01:00.006+09:00

-------------------------------------------------------------------
　　　　　　　　　　　　SEA Forum Dec. 2009
　「いまだから聞けるクラウドコンピューティング：その現状と展望」
　　　　　　　　　　主催：ソフトウェア技術者協会
-------------------------------------------------------------------
　クラウドコンピューティングという用語がメディアを賑わすようになって
　から暫く経過しています。定額給付金やエコポイント等、日本における適
　用例も報告されだしました。しかしながら、その実態はまだまだ不明なも
　のがあり、単なるASPではないかという声さえあります。
　今回、IPA戦略企画部にて、この用語が世間に広く知られる前から、その動
　向に注目し、IPAにおける研究会をコーディネートしてきた保立氏による　
　「クラウドコンピューティング概要、米国の実態等」について聞く機会を
　設定しました。
　　　　　***************** 開催要領 *****************

１．日時：2009年12月22日(火) 18:00受付, 18:30開始, 20:00 終了

２．プログラム（予定）
　　18:00 - 18:30　受付
　　18:30 - 19:30　クラウドコンピューティング：その現状と展望
　　　　　　　　　　IPA戦略企画部　保立久幸
　　19:30 - 20:00　オープン・ディスカッション
　　　　　　　　　　　司会：新谷勝利　
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
●クラウド・コンピューティングとは？
　インターネット上の”どこか”にあるハードウェアリソース、ソフトウェア
リソース、データリソースをユーザがその所在や内部構造を意識することなく
利用できる形態。
　・2006年にGoogleのEric　Schmidit氏が使ってから一定の認知が得られる
　　ようになった。
　・発言者によって異なった意味で使われることが多い。
●クラウド・コンピューティングの定義(NIST)
　「（複数のユーザにより）共有された設定・調整可能なコンピューティング
資源（ネットワーク、サーバ、ストレージ、アプリケーション、サービス）の
プールに、簡易かつオンデマンド・ベースでネットワークからアクセスが可能
なモデルのこと。該当コンピューティング資源は、最小限の管理努力またはサ
ービス提供者の関与により迅速に提供・解除される。」

　クラウドコンピューティングの５つの特徴（NIST)
　・On Demand and Self Service
　・Broad Network Access
・Resource Pooling
　・Rapid Elasticity
　・Measured Services
　※日々改訂されている

●NIST(National Institute Of Standards and TAechnology
　NISTとは、「（米国）標準技術局」の略。

●クラウド・コンピューティング出現の背景
　・ネットワークのブロードバンド化
　　－＞ソフトウェアのサービス化
　・インターネットの普及
　　－＞情報大爆発
　　　－＞圧倒的なコンピューティングパワーを持つ企業の出現
　・コンピュータ単体の性能向上の停止（熱によりCPUの性能向上がストップ）
　　－＞分散化の進化
　　　－＞スケールアウトの技術の進化
　これらが組み合わさってクラウド・コンピューティングが出現した

●クラウド・コンピューティングのメリット
　・コスト：
　　高額の業務用アプリケーションを購入したり、自前でシステムを
　　構築する必要が無いのでIT投資を節約できる
　・スピード：
　　クラウドでは非常に頻繁にサービスが更新される
　・拡張性（スケーラビリティ）：※発表者はこれが最大の特徴と考えている
　　企業（ユーザ）が業務拡大したいときには、それをグランド業者
　　に伝えれば、必要なコンピューティングパワーやストレージがほ
　　ぼ自動的についかされる。資金力のない中小企業は自ら大きなリ
　　スクをとることなく業務を拡張できる。

●クラウド・コンピューティングのサービス・モデル(NIST)
　・SaaS（Software　as　a　Services)
　・PaaS（Platform　as　a　Services)
　・Iaas（Ifrastructure　as　a　Servieces）

●クラウド・コンピューティングのサービス・モデル
　クラウド・コンピューティングは貸し出すリソースに応じて分かれる
　・SaaS：アプリケーション
　・PaaS：ミドル～OS
　・Iaas：ハード

●クラウド・コンピューティングの導入モデル（NIST)
　・パブリック・クラウド：
　　一般国民や大きな産業グループにより利用される
　・プライベート・クラウド：
　　一組織により運営される
　・コミュニティ・クラウド
　　複数の組織により共有され、共通意識を有するコミュニティにより支援される
　　※あんまり聞かれない
　・ハイブリッドクラウド：
　　クラウドインフラが２つ以上

●クラウド・コンピューティングの導入モデル（経済産業省）
　・Creativeなクラウド：クラウド基盤を活用して、情報爆発に対応した新サービスが登場
　・Radicalなクラウド：新規導入時に、中間Stepを経ずに一気に導入するアプローチ
　・Incrementalなクラウド：既存IT環境を経て着実に進化させるアプローチ

資料はこちら

●プライベートクラウド導入の動き（民間企業）
　・「クラウドの技術は使いたいが、外部のクラウドサービスは利用できない」というユーザ・ニーズの応えて台頭してきた
　・ユーザ自身でクラウド的なデータセンターを運用することを前提に「導入可能なクラウド技術のパッケージ」としての製品が登場
　・既存のIT事業者の得意な分野である

●国内大企業のクラウド・サービスの選択肢
　・国内大企業は日本の大手ベンダーが提供するクラウド・サービスが導入の選択肢と考えている
　　※米国の主要なクラウド・ベンダーの割合は低い

●クラウド方の市場
　・クラウド型の国内市場は2013年に１兆1000億円に、一方、従来のSI型の市場は9000億円減少

●日本のクラウド・サービス提供企業の活動
　＜詳細略＞
　富士通のクラウド関連サービス
　・平成２２年度に数百億円規模の設備投資
　・信頼性と安定性を武器に、クラウド事業を拡大させる※
　・「館林システムセンター」に新棟完成（2009年11月）
　NTTデータのクラウド関連サービス
　NECのクラウド関連サービス
　日立のクラウド関連サービス
　日本ユニシス

●クラウド・コンピューティングの技術
　・データセンター関連技術
　・仮想化の技術
　・スケールアウトの技術
　・大量処理の技術

●データセンター関連技術
　・PUE＝データセンター全体の消費電力／IT機器による消費電力
　　（Power　Usage　Effectiveness)
　・MSのデータセンタはアジアではシンガポールと香港に建設
　・クラウドの稼働率
　　日本の大企業の期間情報システムの稼働率：99.8%
　　米国の大企業の期間情報システムの稼働率：98.0%

　　※Google、Amazonなどの稼働率99.9%は低くないのではないか

●仮想化技術
　・自社でプライベートクラウドを構築するには、インフラのスケーラビリティを理解しておく必要がある
　・OVF（Open　Virtualization　Format）
　　異なる仮想ソフト同士で仮想マシンのイメージファイルをやりとりできるようにするための標準フォーマット

●スケールアウトの技術
　・クラウド・コンピューティングの中核となる技術
　・クラウド・コンピューティングでは、いろいろな点でスケールアウトする仕組みが取り入れられている
　・RDBではスケールしないのでkey-valueストア方のデータベースが使われる
　・一貫性をゆるくしたeventual　consisitencyが採用される

●CAP定理
　・CAP定理
　　テータの一貫性、システムの可用性、システムの分散の３つのうち２つしか自手右舷できない
　　クラウドでは可用性と分散性が重視されているため、一貫性が犠牲になる傾向がある
　・ACIDからBASEへ
　　A：処理が完了か未実効のどちらかであり中間状態をとらない
　　C：データに矛盾がないこと
　　I：処理間の依存関係がないこと
　　D：処理結果はシステムに障害が発生しても完全に保存されること

　　B：可用性重視
　　S：状態の厳密性は追求せず
　　E：最終的に一貫性のつじつまがあえばよい

●スケールアウトの技術
　・各層でスケーラビリティの仕組みが重視される
　・Bigtableの例＜省略＞

●大量データ処理の技術
　・MapReduce：Googleが開発（非公開）
　・Hadoop：Googleの学術論文から開発されたオープンソース版
　　タスクを複数の分割してそれぞれを別のノードで並列処理することで全体のスループットをあげる仕組み

●クラウドの中身
　・Windows　Azureはクラウド・コンピューティング実現の仕組みを公開している
　　※クラウドの中身の勉強にお勧め

　・WebロールをWorkerロールの間にキューを利用してスケールしやすくしている

　　図（省略）

●日本のクラウド・コンピューティング（まとめ）
　・日本の大手ベンダー
　　既存の顧客のシェアをキープするためにプライベートクラウドに注力
　・日本のスタートアップ企業
　　既存のコンピューティング資源を持たないスタートアップ企業にとってクラウド・コンピューティングは便利なもの
　　クラウド・コンピューティングを利用して成功している企業がでてきている（頓知ドット、mixiでアプリケーションを提供している企業　など）
　・日本のソフトウェア技術者も…
　　クラウド（雲）のなきあでどのようなことが行われているか、最新のクラウド関連技術はフォローしておく必要があるのではないか？

●クラウド・コンピューティングを利用している企業
　・クラウド・コンピューティングを利用して成功している企業がでてきている
　　→セカイカメラはAmazonEC2を利用している　
　　→mixiのアプリケーションの一つ「サンシャイン牧場」

【質疑】
Ｑ．アプリケーションを開発するときに、クラウドを意識しなければならないか？
Ａ．主にデータベースが大きくかわる
　　例）RDB→key-value型
　　　　メモリ・キャッシュ
　　今後のソフトウェア技術者もクラウドの仕組みを作る必要がある
Ｃ．RDBがなければダメなものは工夫がいる
Ｑ．自社のサーバでRDBを使っていたものをIaasに移行できないのか？
Ａ．Iaasの場合は同じだが、ネットワークの遅延を考慮する必要がある
Ｑ．個人情報を扱うガイドラインはあるのか？
Ａ．経済産業省の担当だが、今後の課題（直近ではＳＬＡがでてくる）
　　EUは個人情報を外国に出してはいけないという法律がある
Ｃ．GoogleのデータクラウドはEUに閉じている
Ａ．米国では米国のサーバをＦＢＩが見ることができるので問題となったことがある
　　ＩＰＡのアンケートでは国外にデータがあることは気にしないという回答が多かった
　　→未だ重要なデータをクラウドにだすことを考えてないのではないか
Ｑ．クラウドとセキュリティの資料はどのタイミングで公開されるのか？
Ａ．ＩＰＡの研究会は応募制（参加したら資料がもらえる）
Ｑ．クラウドの研究会の資料の公開タイミングは？
Ａ．ＩＰＡのサイトでパブリックコメントのための公開　２月下旬、コメント反映版が３末
Ｑ．国内のクラウドはどのような動きがあるのか？単なるデータセンター（偽者）でなく、安く、早く使えるものはあるのか？
　　日本でちゃんとクラウドをやるためには、広い土地で税金を安くするような政策をとらないと実現しないのではないか
Ａ．クラウドの定義は広い
Ｑ．ミッションクリティカルや個人情報をやっていないのに、企業はクラウドをやっていると言っている。おかしいのではないか？
Ａ．同感である。簡単にできるものをやっているようだ。
　　クラウドの判定をしてもしかたがないのではなか
Ｑ．国内のクラウド事例は、クラウドの定義にあっていると思うのか。判定自体が難しいのではなか
Ａ．判定はあきらめた。定する立場ではない
Ｃ．クラウドにだまされなければ良いのではないか
Ａ．クラウドの定義をつきつめても実利はないのではなか
Ｑ．クラウドに移せるものと移せないものがある。日本の企業は移せるものと思って居る人がいるのではないか？
Ｃ．今の基盤システムを移すことは無理であり、クラウドの特性にあったビジネス（サービス）を考えることは有意義であろう
Ｑ．クラウドの本来はパブリッククラウドだろう。日本の企業はプライベートクラウドを行っているがどうか？
Ａ．定義によるが、個人的にはプライベートクラウドは本来ではない
Ｃ．何か出来るか何が出来ないかをはっきりさせないで、なんでもできると思わせることがいけないのではないか？
Ａ．既存の基幹システムをクラウドの移行できないのは理解されている。スタートアップの資産の無い企業には有効である。トラフィックが大きく変動するのは有効であろう
Ｑ．エコポイントはクラウドを使う予定。それができるのであれば他もできるのではなか？
Ａ．エコポイントはわからないが、データを暗号化して置き、復号はクライアント側で行っている事例がある
Ｑ．クリティカルなアプリケーションがクラウドに乗っていく。事故が起きたときの対策はあるのか？
Ａ．ＩＢＭを中心に考えている事例がある
Ｑ．障害が起こったときの責任の所在等は大丈夫なのか？
Ａ．基幹システムは９９．８％にくらべて、クラウドのほうが高い。それをどう評価するか？
Ｃ．稼働率の背景議論しなければいけないのではないか
Ａ．理論値（机上の計算値）を言っていると思われる
Ｑ．民間の大手の個人情報をパブリッククラウドに上げた事例はあるのか
Ａ．自分の知る来限りない

第67回 SEA-SPIN Meeting 「CMMI高成熟度の実践的意義を考える」聴講録

2009-12-15T17:41:00.005+09:00

-------------------------------------------------------------------
　　　　第67回 SEA-SPIN Meeting (December 15, Tuesday, 2009)
　　テーマ：「CMMI高成熟度の実践的意義を考える」
　　　　　　　　主催: SEA プロセス分科会（SEA-SPIN）
-------------------------------------------------------------------
概要：
今回は，最近のCMMI高成熟度をめぐる状況を概観し，高成熟度プラクティスを実装す
ることの実践的な意義について議論したいと思います。

1. 日　時：　2009年 12月 15日(火) 18:00 ～ 20:00
2. 会　場：　東京工業大学　大岡山キャンパス
3. プログラム：
　　コーディネータ　端山毅
　　17:30 - 　　　開場
　　18:00 - 18:40 情報提供　　　　端山毅（ＮＴＴデータ）
　　　　　　　　　「CMMI高成熟度の概要と現状」
　　18:40 - 19:50 質疑・意見交換
　　　　　　　　　ディスカッサント
　　　　　　　　　乘松　聡（乘松プロセス工房）ほか
　　19:50 - 20:00 クロージング (次回予告、及び後片付け等)
-------------------------------------------------------------------

● 情報提供　端山毅（ＮＴＴデータ）「CMMI高成熟度の概要と現状」

世間では最近あまり話題に上がらない。
端山氏がPM学会の寄稿を発表。
NTT-Dのある部署が、レベル５達成。
それらの、紹介。

●背景
　→2,000年：通産省が調達問題の検討の中でSW-CMMを取り上げた
　→2001年～2002年：産学官で議論
　　・ソフトウェア開発。調達プロセス改善協議会
　→レベル５競争
　→2006年CMMI　V1.2リリースに合わせて、SCAWNPI評定の新方針発表
　　・高熟度の解釈明確化
　　・高成熟度守便評定者資格を分離
　　・３年の有効期限
　→2007年9月から新方針適用

●CMMIの意義
　→CMMI：プロセスモデル
　　・経験的に効果であると考えられるプラクティスを体系的に整理して、効果的なプロセスの特性を記述したもの
　　・プロセスそのもではない。→その通り実装するものではない
　　・過去の経験をまとめたノウハウ集
　　・プロジェクト管理や品質管理の話ではない
　　・開発方法論ではない
　　・開発や管理のプロセスを自ら定、現実に合わせて改善、改革し続けいく組織的な活動の教科書
　　・学び、習い、思う
　　・同じ道を志す者同士で議論しなければ、理解できない

　→時組織にあったプロセスを、現実の事業環境の中で生み出し、使い、発展させるためのビジネス思想

●SCMPI評定の実施状況
　→図（略）
　→評定件数全体は増加傾向
　→高度達成件数は半減（2007年9月方針の変更以降）
　→海外では年末に山がある
　→2007年9月に駆け込みあり
　→2008年年明けから、厳密な評定が始まったため件数減少
　→日本でも件数は増加傾向
　→日本のピークは年度末
　→海外の現地子会社でもあり
　→３年間で複数評定結果を公開している企業グループ
　　日本と海外両方とっている

●高成熟度の監査について
　※結構重い。
　OPP：組織プロセス実績
　QPM：定量的プロジェクト管理
　CAR：原因分析と解決
　OID：組織改革と展開

　＜詳細　後日＞

●高成熟度の意義
　→事業目標とプロセス改善目標の関連の明確化
　　・どのプロセスになぜ焦点をあてるのか
　　・それがどれほど事業に貢献するのか
　→プロセス改善と測定／定量的管理の関連の明確化
　　・測定することで、どんな制御が利かせられるのか
　　・自分たちで制御できるものは何か
　　・制御できないものは何か
　→プロセス実績を統計的に幅で把握
　　・どのくらいの確率か
　　・相関係数は？
　→プロジェクト途上で、結果を予測し、目標達成するためにコントロール
　　・先を見越した管理ができるようにする
　　・どういやって目標を達成するのか

●高成熟度への挑戦
　→その組織にとって高成熟度が必要か熟慮
　→レベル３とレベル４との間は大きい（※レベル３の有効期限が切れる前にレベル４が取れず、再度レベル３を申請した事例もあり）
　　・レベル３達成後、その実践継続が重要
　　・事例とデータの蓄積が必要
　　・プロセス定義や測定項目の修正、詳細化が必要
　→プロセス改善の意義、定量的管理の必要性について、再検討が必要
　→プロジェクト視点からプロセス視点への転換
　　※レベル３までは、プロジェクトの実績を評価
　　　レベル４では、プロセスで切り、プロセス毎の結果を評価する

●良いプロセスとは
　→CMMIモデルに書いてある通りのプロセスを実装しても、事業に役に立たない
　→第三者には、「良い」プロセスがｋどうか、判断不能
　→役に立つプロセスとはなにか
　　・合目的性
　　　経営課題の解決、事業目標の達成に貢献するか
　　　プロセス改善の必要性が、事業の観点から合理的に説明できるか
　　・継続性
　　　長く使われた実績のあるプロセスは良いプロセスである
　　　実務者の支持・信奉
　　　修正履歴
　　　　－無視されていない
　　　　－修正前より良いはずだ
　→CMMIだけでなく、自組織について深く知る必要がある

●まとめと今後
　→CMMIはベストプラクティス集であり、過去を未来に伝えるものだった
　　※ベテランは決まったやり方がある。－若手は聞いていない。なんでやるのか理解していない。
　　※レベル３までは、この使い方がある。
　→取り組む組織は世界的に増加の一途
　→CMMIを前提とした知識／経験が流通している
　　・海外企業との交流、議論では有意義→グローバルには必須
　→高成熟度部分は、製造業等のモデルを基礎としつつも、システムj開発プロセスのモデルとしては、実装が確立していない
　　・初心者には敷居が高くなった→下火になったように見えた
　→CMMIは研究ロードマップとして未来予言に変質した
　　・プロセス実績モデル（予測モデル）を前提としてエンジニアリングプロセス、プロジェクト管理手法
　　　※まだ未だ研究ネタは沢山ある

　　・経営課題とプロセスの関係
　　・外部技術導入による改革推進方法

●質疑・意見交換
Ｑ１．システム開発のプロセスはモデルが確立していない。統計的な管理をしようと思った動機はなにか？
　　繰り返しの作業に統計的な管理をするのはわかる。システム開発は繰り返しの作業は薄い。
　　なぜ統計的管理がはまると思ったのか？
Ａ１．とっかかりとして製造業を真似したいという思いはわかる。勝算があったかどうか不明。
Ａ２．統計的な考え方は、昔と違う。今は統計的な考え方が強化されている。
　　　どう思うのか？を質問と考えいた。なぜ、疑問に思ったのか？
Ｑ１．なんとなくうまくいかないと思った。
Ａ２．インスタンス間の、インスタンス内で反復性がある事を想定しているのではないか？
　　　統計的な方法はうまくいくはずと考える
　　　Ｙｅｓ：１４名（エビデンス有り：１）
　　　Ｎｏ：４名（エビデンス有り：０）
Ｑ２．基本ソフトでは反復性があった
Ａ２．役に立つと思った人の根拠は
Ｑ３．実験を繰り返している状況。定量的にうまくいった例はまだない（言いすぎ）
Ａ２．当初（９０年代の終わりごろまで）は統計的な管理図が有効だという方向はなかった。ＣＭＭＩから統計的なプロセス管理が良いとなった。Ｖ１．２のころから、統計的管理強化しようと思う人が多くなった。
　ＣＭＭＩレベル３は確立したベストプラクティス。
　レベル４，５は確立したとは言えない。
　※レベル３まではＮＯという人は少ないが、レベル４、５では議論が分かれる

Ａ１．プロセス志向で理想のプロセスに見える。プロセス毎に組織を分けると統計的にはやりやすいが、人間的には無責任な組織になりやすい。仕事にたいする思いがなく、機械的にやることになる。（次工程はお客様という考え方がない）

Ｑ３．それは成熟度以前の問題ではないか？

Ａ１．意義を考えずにプロセスに人を分割するとそうなる。まず、意義を考えないといけない

Ｑ２．レベル３の評価はプロジェクト単位にやっていることが多い。そのご組織として対応することによりプロセス志向になる。

Ｑ４．レベル４は統計的は途中制御が重要と考える。しかし、実際にやってみると変動幅大きかったり、途中制御はレビューぐらいしかない。途中制御はレビュー以外あれば教えて欲しい。

Ａ１．すり抜けバグを減したい。途中工程ですりねけバグを制御するモデルを作った事例がある。

Ｑ５．レベル５を取得した。自社はソフトを製造業としていとらえている。ソフトの価格を量と生産性で測っている。途中でコストを予測し対策するモデルを作った。また、最終製品のバグ量のコントロールするために途中のバグ量を測っている。

Ｑ２．「夢をみている感がある」との発言の夢とは？なにを目指しているのか？

Ｑ１．最初高成熟度を目指していた。が、レベル３の強化をやりなおしている。
　　　品質・コスト・出荷の約束がまもれるヒントがあれば良い。
Ｑ２．それなら、高成熟度でなくとも良いのではないか？中成熟度でも良いのではないか？
Ｑ１．確かにその通りで、現実は低成熟度を積み上げている。
　　　昔から６シグマをやっていた。ハードウェアはなじんでいた。ソフトの部門はおつきあいだった。
　　　レベル３を繰り返しているうちにデータがたまり始めた。もしかして使えるかもという感になっている
Ｑ６．プロジェクト管理からプロセス管理への移行は、生産プロセスのアナロジーではないか？
　　　とすると、人間が問題になるのではないか？人間の問題ではなく、使うべきツールや手法を成熟させる必要がある。

Ｑ７．レベル５の組織は自発的に一人一人が統計的手法を勉強している。全体的なＲＩＯは、良いのか？

Ａ２．高成熟度の組織で働いている人は楽しいのか？

Ｑ６．高成熟度のＲＩＯはどうなのか？

Ａ２．レベル認定のＲＩＯと、プロセス改善のＲＩＯがある。
　　　レベル認定のＲＩＯは良くない？
　　　プロセス改善のＲＩＯが議論されていることが多い。
　　　※効果的でないものは排除されているはずといっている。
　　　　成功例はプラス。マイナスなものは、途中でとまっているか発表されない。
　　　　そのヒット率が知りたい。
　　　　中成熟度でやりつくした人が高成熟度になるのだろうか？

Ｑ４．レベル２、３で改善していても、レベル４、５にならない。
　　　レベル４、５が高コストといわれるのはそのせいか？

Ａ２．レベル４、５が高コストと言っているのは、全員に教育するとそうなる。
　　　統計的な教育はＳＥＰＧだけでよいのか、関係者全員にすべきかは議論が分かれている。
　　　レベル４がコストが高いというのは幻想ではないか？

Ｑ４．レベル３自体が高コストなのではないか。レベル３を徹底すれば、４になりやすい。
　　　レベル３にしがみついているため高コストになる。今までのしくみを直すことが嫌なため、高コストと言っているのではないか？
　　　最初から５を目指すべきではないか？

Ａ２．哲学の差がＬ３を目指すのか、Ｌ５目指すのかがある
　　　最終的なゴールをＬ５を目指す人にとっては、Ｌ４の壁は理解できない。
　　　積み上げと、最終ゴールを目指すのかどちらが正しいとは言えない。

Ａ１．経営者は変革というのが仕事であるが、その変えるための土台をつくるのがＣＭＭＩではないか？

Ａ２．Ｌ５をゴールとして目指すのと、レベルを積み上げるのと時間の差はない。
　　　Ｌ３あたりが変えにくいのではないか？レベル３は危険な（継続が難しい）領域ではないか？

Ｑ３．Ｌ３のあとにＬ４を抜いて、Ｌ５を取り組んだほうが良いのではないか？

Ａ２．賛成者　２名。良いという意見もある。
　　　評価者の立場からいくと難しい。

Ａ１．Ｌ５から降りてきてなにが必要かを考えて、必要なものがＬ３、Ｌ４だった。という取り組みはあり。

ソフトウェア進化につい（【進化以前】）

2009-11-30T17:51:00.007+09:00

引き続き、ソフトウェア・メインテナンス研究会の合宿で考えたことを紹介します。

【ソフトウェア進化以前】

　今回の合宿で、ソフトウェアの開発・保守に関する諸問題を「ソフトウェア進化」という概念でまとめられる確信を得た（ような気がします）。

　それ以前は、ソフトウェア保守は「リスク管理」で整理出来るのではないかと考えていました。

　大雑把にまとめると次のようになります。

　Ａという保守作業をするか、しないかは、次の条件で判断する。

　○保守作業Ａすると判断する条件

　　Ａをするためのコスト＜Ａをしないことによって発生しうるコストの期待値（１）

　　または

　　Ａをしないことにより、合意したサービス品質（※）に達しない（２）

　○保守作業Ａをしないと判断する条件

　　Ａをするためのコスト＜Ａをしないことによって発生しうるコストの期待値（３）

　　かつ

　　Ａをしなくても、合意したサービス品質に達する（４）

　※合意したサービス品質とは顧客とのＳＬＡだけではなく、組織内でも顧客の満足度やロイヤリティを確保するために必要なサービス品質の目標を設定しておく必要がある

　例えば、ドキュメントを例にとると、

　・納品条件のドキュメントは（２）の条件により作る

　・納品物以外のドキュメントで後に役に立つと思われるものは、作るためのコストとそのドキュメントがなかった時に発生するコストとの多寡により、（１）、（３）の条件で作るかどうかを決める。

　また、ドキュメントを整理することによる情報の欠落のリスクと、整理されていることによる調査時間の短縮の可能性を比較して決める。

と、下手に整理せずに履歴情報として保存したほうが良いのではないかと考える。

SERC　１９年度キックオフ合宿（２日目）

2009-11-28T09:37:00.002+09:00

SERC（ソフトウェア・メインテナンス研究会）　１９年度キックオフ　合宿２日目合宿
【全体会議】
　・各グループの活動計画と討論
　Ａ：保守ドキュメント
　Ｂ：ソフトウェア保守の基盤技術
　　　アンケート
　Ｃ：運用保守のＳＬＡと改善
　Ｄ：広報・啓蒙
　　　個別テーマ（ソフトウェア保守の経済、ソフトウェア保守の価値）
　・フォーラム
　　２０１０年２月～７月にかけて、各グループ１回（Ｄグループ２回）のフォーラムを実施予定
　　※フォーラムは広く多くの人と議論することを一義とする　　　

　特にソフトウェア保守のドキュメントは、ソフトウェア・メインテナンス研究会の開始当初から研究されていて昔の財産が存在していた。

【感想】
　様々な立場の方と活発な議論があり、大変良い刺激を受けた。

　しかし、とことどころにネガティブな発言がみられ残念あった。

　例えば、次のようにポジティブに考えられないだろうか？

　・コストの制限で保守ドキュメント整備できない

　　→作らない・改訂しない保守ドキュメントを明確にして、原価を低減する

　・納品ドキュメントと保守に必要なドキュメントが違う

　　→保守に必要なドキュメントを明確にし、お客様に納品物にするよう働きかける

　※刺激を受けて考えたことは別途掲載します。

【昼食】
　清水区の日の出寿司：つけ丼（￥1,050）

　マグロのヅケを想像していたが、通常のマグロ丼だった。

　さらに、タレを丼にかけるのではなく、丼の具をタレにつけて食べるという指示が店からうけた。（個人的には、海鮮丼でも同様にしているので、敢えて言われことではないのだが。なので、つけ丼か？）

　値段の割りに、具のマグロがたっぷりあり、味も美味しいい。コストパフォーマンスは最高でだった。

　日の出寿司の建物は昭和２０年代の建築とのことであり、お世辞にも綺麗だとも機能的だともいえない。しかし、食べ物には店の概観は良くはないが、安くて美味しいものを出してくれるところがある。

　一方、その対極としてファミレスなどのチェーン店がある。見かけも味もある水準は保っているが、期待値を大きく超える驚きはない。

　そこで、ソフトウェアのプロセスや組織の成熟度を思い出した。

　同様に飲食店のプロセスや組織の成熟度というものがあったら、ファミレスやチェーン店は成熟度が高い値となる一方で、この店の成熟度は高い値にはならない思われる。

　ＣＭＭＩを代表とするソフトウェアのプロセスの組織や成熟度は、大企業やチェーン店の水準を保つためには有効であろう。しかし、小規模な組織やイノベーションを起こすような組織を評価するためには使えない。

　成熟度ありきの考え方ではなく、自分の組織がなにを目指すかによって評価の指標を変える必要があると考える。その一つの選択肢が、ＣＭＭＩであろう。

【SUICAその後】

　清水に来る時にSUICAでトラブッタので、帰りの切符は券売機で購入する。しかし、二ノ宮までの分しかなかった。

　平塚駅で清算しようと清算機に切符をいれると、エラーになり結局は改札口で清算することにした。

　改札口では、紙の表を見て計算していた。つまり、JR東海とJR東日本ではシステムがつながっていないことが問題であり、SUICAとTOICAの連携の問題ではなかっようだ。

　今度、切符が買える範囲ではどうなるか疑問になった。多分自動改札は通れず、駅員さんに通してもらうことになると思う？

　次の場合どうなるか、知っている方がいたら教えてください

　・新幹線以外のJR線（例えば、東海道線）

　・乗車駅と降車駅のそれぞれがJR東日本とJR東海のどちか一方にあり、R東日本とJR東海の境界をまたいだ乗車区間で

　・乗車時に降車駅までの区間の乗車券を購入

　とき、降車時に自動改札が通過できるか？

SERC　１９年度キックオフ研修

2009-11-27T07:22:00.010+09:00

今日より２日間、SERC（ソフトウェア・メインテナンス研究会）の１９年度キックオフ研修の様子をお伝えします。

今までは２泊３日とじっくりと時間をかけて議論してきましたが、今年は「１００年に一度」というやつで一泊二日に短縮。しかも、近場の静岡市清水区で行われます。

私の最寄り駅は、ＪＲ東海道線の平塚で清水にでるには、微妙な位置です。

新幹線を使うと、小田原で乗り換えるか、新横浜まででなければなりません。

小田原と静岡両方に止まるものは数が限られます。

時刻表をよくよくみると、そのまま東海道線を乗り津だのと殆ど変わりませんので、
ＴＶ東京の番組のようにローカル線の旅を選びました。

●７：１１分　平塚発　熱海行きに乗車
●８：０４分　熱海で静岡行きに乗車
●９：１０分　清水駅に到着

「ブー」
SUICAで、改札を通ろうとすると、エラーになり開かない。

当然、こんなこともあろうかと、SUICAと~~TOYOTA~~TOICAの相互利用が可能であることは、事前に調べておいたのだが…

仕方なく、駅員さんに聞くと、「熱海より東から入った場合には使えない」とのこと。
これが、「相互利用可」というのかと思いつつ、現金で清算する。

これが、苦難の始まりだった。

清水駅から会場までの交通は、徒歩、シャトルバス、公共バス、水上バスとあるが、せっかくだから水上バスを選択。時間も十分ある。

案内の地図を見ると多少歩かなければならない。

でも、着いたら会場まで０分なのでと、自分にいき聞かせ歩き出す。

５分経過、乗り場らしいものはない。

１０分経過、それらしい雰囲気すらない。

しかたなく、工事の人に聞いてみると、しばし考えた後
「うーん。あの、観覧車が見えるところだよ」
と、のたまわった。

一瞬にして理解しました。

多分、行きたいところが観覧車の下だろう。
行過ぎてしまったのだ。

こうなったら、歩くことに。
「世界が歩けと言っているのだ」と、解釈することに。

１０：００とうとう着きました。
清水マリンパークに、清水港ビル

歩くこと４０分、内臓脂肪は何グラム減ったのだろうか？

【全体討議】

●今後の全体予定計画
・１９年度の報告書事務局提出：2010年9月6日（月）１つのWordで提出
・SMS（ソフトウェア・メインテナンス・シンポジュウム）2010　10月8日（金）予定
・フォーラムを増やす
・SERCのWebサイトは検討中
・各グループの活動の重複は、事務局がチェック

●各グループ活動計画案（課題）
・Ａグループ
　→別途検討
・Ｂグループ
　→保守の基盤
　→アンケート
　　　経済調査会に依頼する（変更なし）
　　　依頼する内容・解析をワーキンググループで検討
　→保守の広報方法
　　　フォーラムに呼ぶ
　　　発表会・報告会
　　　社内SNS
・Ｃグループ
　→SLAの深堀
　　保守の維持管理・進化・あるべき姿とは
・Ｄグループ
　→広報・啓蒙
　→ソフトウェア保守の経済
　→ソフトウェア保守の価値・評価

●各グループ討議
・Ｄグループの月次研究計画の作成

１７：３０終了

●情報交換会（１８：００～１９：３０）
いわし料理　「善（よし）」

※「いわし」は旨かった。

●二次会
　元楽器屋だったというワンショット・バー（店内にはギターが並んでいた）

●三次会
　宿泊先のホテルの一室
　新たな伝説生まれる

【追分羊かん伝説】
　二次会で、清水名物の追分羊かんを持ち込んだ。

　某代表幹事は、いきなり「下品」とのたまう。

　買ってきた人の立場はどうなるのだ。と、思って居ると。

　２口目も手を伸ばす。

　評価は、「なんとも言えない、味がする」に変わっていた。

　そして、三次会の席に姿を現した某代表幹事口からは、「追分羊かんは、ベストワン」との言葉が漏れた。

　「君子豹変する」とは、このことだろうか？

　追分羊かんの詳細は、こちらをご覧ください。

【○川氏　青汁伝説】
　何故青汁が？

　誰が持ち込んだのか、皆が持ち込んだおつまみの中に冷凍の「青汁」があった。

　当然、皆が敬遠する。
　八名信夫のＣＭ「まずい！もう一杯！」のイメージが定着しているからだろう。

　突然、引き付けられるように手を出す石△氏。

　止める間もなく袋を破り、氷の状態の青汁を欠いて口に入れてしまった。

　○川氏は苦悶の表情を浮かべながら、「旨い」という。

　皆は言葉を信じて良いのか、態度を信じて良いのか判らない。
　そこで、もう一口食べてもらうことになった。
　（当然、自分は実験台にはなりたくはない。）

　そこから、石△氏のショーは始まった。

　絶妙な間合いで、皆の突っ込みを誘う○川氏。

　「これを飲み干してヒーローになる」と、ちびちびと口に入れたり、一気コールを要求する。
　（無理強いする一気コールは見たことはあるが、一気コール自体を無理強いされるのは初めてだった…）

　不味いことは皆が判っているのだから、一言「不味い」といえばそれで済むのに、一貫して「旨い」といい続ける石△氏、状況を楽しんでいるとしか思えない。

　長いパフォーマンスの末に全部飲み干した○川氏は、驚くべきことを口にした。

　「このことブログには書かないでくださいよ。」

　え、それって、書けということか？

　それにしても、石△氏の間合いは絶妙である。人を引き付ける素晴らしい才能があるのではないだろうか？

　今後も○川氏のウォッチは欠かせない、面白いショーが見ることができるのでは無いかと思った。ことである。

保守の効率とは（その１）

2009-11-21T09:51:00.004+09:00

ご無沙汰しました。

来週、所属しているソフトウェア・メインテナンス研究会の１９年度のキックオフ清水であります。

それを前に、３年計画で保守の価値の評価をしたいと思い立ちました。

切っ掛けは、ソフトウェア保守作業の改善をするにあたり、成果をどう評価しようかと考えたことです。

結果的には、保守品質が上がり、原価が下がればよいのですが、その指標はというと難しいものがあります。

問い合わせや問題の発生頻度や難易度が変わらないのであれば、原価や、品質を測ればよいのですが、そうは単純ではありません。

解決すべき問題の発生頻度や難易度等様々条件は、日時とともに変化します。

そこで、ソフトウェア保守の効率を考えるすえで、どんな条件があるのかから整理しようと考えています。

第33回 S-open主催ホットセッション（速報）

2009-11-10T13:41:00.010+09:00

第33回 S-open主催ホットセッション
■■クラウド時代での顧客満足獲得に必要なエンジニアマインド ■■
■■～エンジニアのワーク・ライフ・バランスとは～ ■■
日　時：２００９年１１月１０日(火)
第一部：第33回 S-open ホットセッション
14:00～　挨拶
14:10～　講演１　森川滋之氏
　　　　タイトル：「顧客満足度とライフワークバランスをともに向上させるための考え方」

15:10～　講演２　原田奈美氏
　　　　タイトル：「業務ニーズとサービスをコーディネートさせるチカラ」

15:50～　休憩

16:00～　特別講演　丸山純孝氏
　　　　タイトル：「バランスは取ろうとするから失敗する」

16:30～　パネルディスカッション
　　　　クラウド時代での顧客満足獲得に必要なエンジニアマインド
　　　　～エンジニアのワーク・ライフ・バランスとは～

17:45 終了予定
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
＜会場到着開催待ち＞

＜講演１　森川滋之氏＞
　タイトル：「顧客満足度とライフワークバランスをともに向上させるための考え方」

ライフワークバランスを向上させるためには、起業精神が必要。
そのためには、営業に関わる必要がある。
プロジェクトの成否は、営業の段階できまっていた。

●講師自己紹介
　・1963年生まれ
　・1987年TIS入社
　・2005年ITコンサルタントとして独立
　・2008年株式会社　ITブレークスルー設立
　・2008年『SEのための価値ある「仕事の設計」学』上梓、以後『奇跡の営業所』など著作４作
　　誠BIz.IDに「奇跡の無名人たち」連載中

●クラウド時代のトレンド予想
＜現在＞
　・SE、プログラマなどITエンジニア
　　↓
＜クラウド化の進展＞
　　↓
＜数年後＞
　　↓
　・コンサルタント（兼セールス）：大多数
　・構築系エンジニア：一部
　　※どちらにもなりきれない中途半端な人は別業界へ

●ライフワークバランスのよい人のセミナー参加姿勢
　・ノウハウ系のセミナー
　　○：成果が出るまで素直に試してみる
　　×：自分にあてはまらない理由を探す
　・考え方系んおセミナー
　　○：講師が何を選択してきたのかを聴こうとする
　　○：自分に引き寄せて聴く
　　×：そんな話よそでも聞いたよ・・・

●ライフワークバランスのよい人の時間管理

　・時間管理自体にストレスを感じないようにする
　　－自分にあった方法でやる
　　－やりやすい方法でやる
　　－うまくいってなくても気にしない

　・定期的に実績を捕捉する
　　－ダメな自分をはっきりと知り、ダメでない自分を目指す
　　－できていない理由は、いつでも単純

　・構造化する
　　－考えなくてよいとことでは、考えないようにする（自動化、ルーチン化）
　　－うまくいってない理由は面倒くささ⇒面倒に感じない方法を探す
　　　※文章のテンプレート
　　　※机上整理（箱をよこに置き、使い終わったら箱にいれる。－机上にのこさない。後で一度に片付ける）

●ライフワークバランスの良い人に共通するプロフィール
　・家族やパートナーを大事にしている
　・プライベートな時間を大事にしている
　・仕事の時間を大事にしている
　・ストレスが少ない
　・不平・不満・愚痴・泣き言・悪口・文句が少ない
　・実績が上がっている

　ななとなく気持ちのよいように思いませんか？
　　↓
　Yes!でも、そんな気持ちはもてない。なぜ？

●ビジネスは急速に難しくなった
　＜神田昌典『全脳思考』より＞

　・当社のバリューチェーンを前提に、中小企業向けＳＦＡ事業に対するＫＳＦを見出すために４Ｐを議論したい。在庫予測プログラムとの相乗効果に結びつけるか？

　・標準テンプレートをレコメンデーション昨日として活用し、ＩＴ熟成度のＫＳＦの実現を効率的に行うプロセスデザインの切り口を知りたい。

　・ＩＤ監査業務をペーパレスで行うことを依頼されているが、エンドーポイント向けソリューションを見出す情報ネットワーク活用を同時に提案するには、どんな切り口が最適か？

ＩＴ業界、特に業務アプリケーションについては１５年前からこんな感じ

●必要な仮説検証の試行錯誤
　・くじけやすい人は論理的な正解を求める人、くじけない人は成果がでるまで繰り返す人

　　仮説⇒検証⇒仮説（の繰り返しの速度が速くなっている）

　※この高速化が、クラウドの進展の理由（作っている暇は無い）

　しかし、試行錯誤の繰り返しは苦しい！⇒継続するためには「自分軸」が必要

●仕事がうまくいかないのは、「自分軸」が明確でないから
　・誰に
　・何を　　　　　　　　　　　　　　　　　　　　　　⇒　この重ね合わせが自分軸
　・なんにこだわって（※利他的なほうがよい）

＜ワーク＞
　自分の時間軸を５分で考える。
　・誰に：ソフトウェア技術者に
　・何を：仕事をする上での誇りやりがいを
　・なんにこだわって：自分・家族を含めた多数の人の幸せ

●自分軸がはっきりしていれば、やりたい仕事がやれるようになる

　自分軸の把握＞専門性の深耕＞市場の発見＞市場の獲得＞属性の合う顧客との取引
　※キーになるのは提案力と企画力

●顧客は何にをもって「提案力」ないいうのか？
　顧客側の「自分軸」が最初の５％以内で明快でない提案書は、コンペに勝てない
　⇒顧客側の「自分軸」聞き取れば、勝率は飛躍的に向上
　⇒顧客の「自分軸」が理解できれば、長期的な取引が可能になる（顧客が満足するから）

　・誰に
　　－ユーザは誰なのか？
　　－利害関係者は誰なのか？
　　－意思決定者は誰なのか？
　　－支持者／反対者は誰なのか？
　・何を
　　－導入後、どのように変わるのか？
　　　どのような効果がもたらされえるのか？
　　　（ユーザは？経営者？会社は？顧客は？etc.）
　・何にこだわって
　　－導入における課題は何なのか？
　　－導入における不安は何なのか？
　　－支持者／反対者それぞれの根拠はなんなのか？

※自分の「自分軸」を考え、次に顧客の「自分軸」を考える。
※やり続けていると、自分と顧客の「自分軸」が一致する。
　「自分のやりたいことと、顧客の要求がトレードオフにならくなる。」

●ライフワークバランスのよい生き方
　・「誰に」×「何を」→継続→ノウハウの蓄積
　・こだわり、自分らしさ

お問い合わせ先：
URL=http://www.itbt.biz/
mail:info.itbit@itbt.biz

Ｑ＆Ａ
Ｑ．「自分軸」と現在求められているものと合わない場合、どうすれば良いか？
Ａ．配置転換を求める場合にも、「自分軸」を見出す必要がある。
　　「なんに拘っているか」しっかりしていると、他はなんでも一緒との境地になった

＜講演２　原田奈美氏＞
　タイトル：「エンジニアのキャリアパスとやりがいと感じると」
●自己紹介
　・デバック工学研究所からＩＰＡに出向しＣＤＰ担当
　・飽きっぽい性格から転職
　・モチベーション、ＩＴエンジニアのやりがいに興味あり
　・日本プロジェクト・マネジメント協会　オンラインジャーナルに「働きやすいプロジェクト環境のために」を連載
●クラウド時代に求められるＩＴエンジニア像
　・クラウドのインパクト
　　－作るから、使う
　　－垂直分業から、水平分業へ役割分担が変わる

　・求められるＩＴエンジニア像
　　－ＩＴを作る技術よりＩＴを生かす技術が需要になる
　　－経営や組織運営の知識＋ＩＴの高度利用に関する知識を持った人材

●ＩＴエンジニアのキャリア
　・「トップクラス」の人材はどのように作られるのか（METI：ＣＤＰ）
　　　－トップクラスの人にインタビューし、違いをさがす
　　　－職種毎の共通パターン

　　　→２０１０年春、全調査結果を公開予定

　・約半分のインタビューをへておおよそ判ったこと
　　　→選択的・自主的なキャリア形成をしているひとは意外とすくない
　　　→「偶然」「たまたま」「白羽の矢」「やれといわれて」チャンスを生かす
　　　　　担当業種の広がり、深まり
　　　　　管理範囲の拡大、権限・責任の拡大　　　　⇒夢中で仕事をしているうちに、レベルが上がった
　　　　　担当プロジェクト、技術範囲の広がり
　　　　※計画された偶然理論

●ITエンジニアがやりがいを感じるとき
　・これまでのモチベーション論（７つのモチドラ）
　　－自己実現・スキルアップの可能性
　　－自己評価の正当性
　　－リーダーの資質・人脈
　　－コミュニケーション状態
　　－プロジェクトの運営体制
　　－業務上のストレス
　　－業務外のストレス
　　※長期的には、お金では効かない。

　・同調査で「やりがいを感じ入ると時」もヒアリング中
　　－お客様
　　　感謝の言葉
　　　安定稼動
　　　「あなたがいてくれるなら」
　　－技術
　　　新しい技術の調査・検証
　　　既存概念との対応（同じところと違うところ）
　　　「Aha！」の瞬間
　　－メンバー・開発者
　　　自分のツールが使ってもらえてる
　　　開発が楽になった
　　　生産性があがった
　　　理解してもらえた
　　－技術者の資質
　　　好奇心旺盛
　　　めがない心
　　　楽観的
　　　柔軟性がある（一つのことにとらわれない、色々な人の意見を取り入れる）
●事例
　・ＩＴサービスマネージャ（コールセンター）
　　－女優の様な日々（相手にあわせて役柄を作って対応する
　　－怒鳴られることを、自分のものにしない。
　　　クレームを自己と切り離す。（仕事は仕事自分は自分）
　・ＩＴアーキテクト
　　－自分は教祖になりたい（自分のつくたものを皆に使ってもらいたい）

●エンジニアマインドを作る教育体系の考え方
　・Ｗｅｂ時代、クラウド時代でも、人材育成フレームは同じでよい
　　－基礎知識・・・マナー、メール、ＩＴの使い方、税務、業務、英語等
　　－役割別知識・・・プロジェクト管理、チームビルディング等
　　－業務・業界知識
　　－サービス・技術知識
　　※Ｗｅｂ時代、クラウド時代において変える必要があるのは、サービス・技術知識領域でよい

●お問い合わせ連絡先
デバッグ工学研究所

＜休憩＞

＜特別講演　丸山純孝氏＞ビデオ
　タイトル：「バランスは取ろうとするから失敗する」
●自己紹介
　・（株）東芝研究エンジニア（８年）から独立
　・自分はバランスは考えていない
　・３社の経営（メルマガ、ブログのサポート）
　・メルマガ発行（ビジネス書の紹介）を趣味としていたものを仕事
　　エンジニアがビジネス書を斬る

●バランスということは考えていない
　・バランスというと、ライフとワークが敵対関係になる。
　・快（人生は楽しい）がキーワードになる
　・楽しくないときどうするか→目的を考える
　・仕事は、人生を楽しむための手段。
　・ライフ・ワークアンバランスの仕事力
　　→ライフかワークかどちらかに振り切ってみる。
一度振り切ってみると、どの配分がよいの分かる。
　・全力で遊ぶ、全力で仕事をすればどうすればよいか
　　→目の前のチャンスをつかむ
　　　－イベントにでるために、仕事を早く終わらせた→得るものがあった
　　　－モトクロスに誘われてやってみてよかった
　　　－ヨットを誘われて楽しんだ（仕事も頑張らねばと思った）　
　・仕事・遊びとも人との関わりが必要（パートナーマネジメント）
　　→出来ることと出来ないことを明確にする
　　　（「やってくれるはずでしょ？」「いえできていません。」これが悪い）
　　→期待値（期待と結果の不等号が感動）
　　　成果　＞　期待値　：　感動
　　　成果　＜　期待値　：　不満
　　　－期待値を上げすぎない
　　　－一度設定した期待値を上回るように努力する
　・せめぎあいのなかで、起きていることを大切にする（クリエイティブチョイス堀内浩二）
　・やったら楽しいか、回りが幸せになるかどうかでやりたいことを決める
　　そして、一生懸命やる。その結果、ライフをワークのバランスがとれる。
　

＜パネルディスカッション＞
　クラウド時代での顧客満足獲得に必要なエンジニアマインド
　～エンジニアのワーク・ライフ・バランスとは～
☆イントロダクション
●電力サービスの歴史
　・電力供給の変遷
　　工場直結型発電
　　　　↓
　　直流供給（近距離）
　　　　↓
　　交流供給（遠距離）
　　　　↓
　　スマートグリッド
　・技術革新
　　蒸気タービンと交流方式＋電力メータ→広範囲への供給が可能
●ＩＴシステムの変遷
　１９８０年　メインフレーム
　　　　　　　　　↓
　１９９０年　クライアントサーバ
　　　　　　　　　↓
　２０００年　Ｗｅｂシステム
　　　　　　　　　↓
　２００７年　クラウドコンピューティング

●電力サービスの変遷とクラウド

●クラウドアプリケーション
　・非同期処理
　　－マルチコア／ＣＰＵでの処理の多重化
　　－通信処理の多重化
　・分散処理
　・ＢＡＳＥ
　　－可用性を優先し、ソフトステートで状態管理を行い、最終的に一貫性だけを保障する
　・構築の概念への影響は少ない
●クラウドアプリケーションえ
　・BigTableではなにが起こるか
●企業システムへの影響例
　・ネットワークの信頼性と遅延への対応
　・異機種接続への対応
　・変化への対応
　　－サービスは常に頻繁に激しく変化する
　　－新たなサービスの登場
　・顧客要件をどのように見極めていくか

●何が必要か
　・イノベーションのタイミング
　・ビジネスの先見性
　・リソース活用（効率化）

●エンジニアに対する変化
　・複数世代での共同作業
　・役割のボーダーレス化

●エンジニアに求められるのは？
　・人脈形成
　・ビジネス視点
　・技術革新への追従

●具体的には・・・
　・自立型のワークスタイル
　・人間関係の変化
　・大量情報時代

＜パネル討論＞
Ｍ．顧客満足には
Ｐ１．顧客の自分軸を大事にする
　　　誰に、何を、何にこだわっているか
　　　ユーザ企業からみると、ＩＴベンダーが怖い企業。
　　　完成しなかった時の影響度合いはユーザ企業のほうが大きい。それを理解する必要がある
Ｐ２．顧客満足度を考える上で誰にとってか（複数のプレイヤーを意識する）
　　　何があれば満足するかをきちんと定義する
　　　合格点を目指せばよい
　　　何を実現したいのかを、話を良く聴く
Ｍ．出荷することが目的となっていることがあるのでは？
Ｍ．クラウド時代の心構え。
　　日経システムの連載の「多読の技術」が必要では？
Ｐ１．最初に「ＶＴＡＭ＋メールシステム」を担当した時、
　　　マニュアルを１日で読めと言われた
　　　　→目次を眺めて、キーワードを拾って読んだ
　　　　→先輩より褒められた。その技術が必要
　　　技術についていくためには、精読では不可（多読が必要）
Ｍ．偶然（シンクロニシティ）に備える必要があるのでなないか
Ｐ２．偶然と思えるようなことでも、必然である
　　　出会いを大切にする。
　　　クラウド時代について、現在は変わり目にある。
　　　技術は変わっても、既存の考え方の枠組みで対応できないような変わり方はしない。
　　　既存の枠組みの中の差分として捉えると、吸収が早い。
　　　同じ枠組みを持っている情報が早い人から聞くと、吸収が良い
　　　→コミュニティなどに参加することが良い
Ｍ．コミュニティについて
Ｐ１．技術者のコミュニティをやっている。
　　　コミュニティを立ち上げるには
　　　　→ハードルを低くする
　　　　→リーダが引っ張らずに役割を振る
　　　　→イベント性を持たせる
　　　　例）居酒屋で飲む→幹事持ちまわる
　　　　　　　　　　　　→山手線一周
Ｐ２．インタビューで、社内コミュニティ、社外コミュニティの大切を訴える人が多い
　　　自分の意見と違っても良いという多様性を認めることが出来るようになった。
　　　その点でもコミュニティは大事
Ｍ．ライフワークバランスに補足したいことは
Ｐ２．ＩＴ業界は３Ｋとか７Ｋと言っている。それを真に受けてはよくない。
　　　受け取り方は、本人次第である。
　　　第一人者になるだけでなく、後輩を育てることや家事にチャレンジすることによりバランスをみつければよい。
　　　これが、唯一絶対のバランスはない。
Ｐ１．バランスをとろうとすることは良くない
　　　自分が仕事を楽しくてやる分にはよいのではないか？
　　　偶然から始まっていても、「自分軸」を見つけているのではないか？
　　　例）某社で海外のプログラムを調査し導入するする部門に回されて腐っていた人がいる。
　　　　　ある時、名寄せのパッケージに出会い。それを広めるうちに、のめりこんでその延長で独立して、
充実した生活を送っている。その人も、切欠は偶然だが、その後「自分軸」をみつけた。
Ｐ２．米国で「トライアスロン」を趣味というと、ライフワークバランスがとれていことの証拠になる
　　　毎週１０時間以上の、練習が必要。それがとれとれるのは、ライフワークバランスがとれていということになる。
　　　日本でも同様なものがあると良い。
Ｑ．モチベーションには、気質＋モチドラ７（環境）がある。トップクラスのエンジニアは周りの環境も変えられるのか？
Ａ．トップクラスは多様性と考えて、参考程度でも良いのではないか。自分の受け取り方からかえてはどうか？
Ｑ．ワークライフバランスはつきの２点ある
　　・自分でコントロールできる範囲
　　・組織的（マネジメント）な範囲
　　自分でコントロールできる範囲はよいが、マネジメントサイドはどう考えればよいか
Ｐ１．「奇跡の営業所」という本を書いている
　　素人ばかりの営業所が、半年後に３ヶ月連続にトップになった。
　　その時やったこと
　　・体制変更：本社の指示（ピラミッド型）に反抗しペア型
　　・ＯＪＴ
　　・報告書の廃止：所長が作文し、その分皆で共有
　　・成績が悪い人は切らない、つぶれる時は営業所一緒（運命共同体）
　　自分の嫌なことは止める。
　　自分たちの居場所を作る。
Ｑ．同じ事を言っても、受け取り方が違う人に応じてどう使い分けるか
Ｐ２．人に応じて与え方を変える必要がある。そのために、日頃のコミュニケーションで見ておく必要がある。
Ｍ．ちょっとした行動にでるので、見る必要がある。
Ｐ１．営業のトップの人は、人のいういことを良く聞く（見ている）。

ソフトウェアの保守性（その２－２　インデント）

2009-11-04T08:02:00.003+09:00

ソフトウェアの解析性（インデント）

【解析性】
　解析性はソフトウェアの保守性を構成する重要な要素である。

　この解析性は、次の２点を示す。
１）問題が生じた際に原因となるポイントの特定しやすさ
２）新たに生じた仕様変更で修正すべきポイントの判りやすさ

　ところで、人間の頭脳の短期記憶の容量には制限があるため、プログラムのつくりにより解析性の良し悪しが出現する。

　次に解析性に影響のある特出を記載する

１～６は、ソフトウェアの保守性（その２－1)http://soft-mainte.blogspot.com/2009/10/blog-post_13.htmlをご覧ください。

７．仮想的な構造：ブロックおよびインデント

　人間の短期メモリは優秀でありません。一方、パターン認識力が備わっており、これで短期記憶を補う必要があります。
　この、パターン認識力を最大限に利用するためは、ネスティングされたブロックを各レベルに応じて右側に移動させるインデントスタイルづけが必要です。インデントを単なる見易さと侮る無かれ、見やすい＝脳の不可軽減→あまったパワーを解析に使える。

　このインデントスタイルは、ツールで合わせることはできません。このため、規約を作り各担当者が規約を守る必要があります。
　しかし、このインデントスタイルには、正解はありませんので、プロジェクトが変わると規約の内容も変わることがあります。また、個人の好みもあります。しかし、保守においてソースを修正する場合には、既存のインデントスタイルに合わせるべきです。
　たとえば現行の規約にあわないと直すところだけでも合わせようとしがちですが、同じソースの中に異なるインデントスタイルが混在することにより、解析性は著しく落ちることになります。
　どうしても、インデントスタイルを変えたいときには計画的なリファクタリングで行う必要があるでしょう。

＜インデントスタイルのルール＞
　・好みのスタイルガイドを入手して（またはプロジェクトの規約）、そのフォーマッティングルールを把握し、自分が記述するコードで厳密に適用する。使い捨てるコードであっても例外としない。
　・未知のシステムを扱う場合は、ある程度の時間を費やしてそこで用いられるフォーマッティングスタイルを把握しておき、コードの追加や変更を行う際には、そうしたスタイルを必ず適用するようにする
　・使用するエディタの設定（タブ位置、タブの挙動、自動インデントのレベル）を作業するコードのスタイルに合わせておく。
参考　Code　Quality　毎日コミュニケーションズ

９．制御構造
１０．ブール式
１１．コードの認識性と凝集度
１２．依存関係と結合
１３．コードブロックのコメント
１４．データ宣言のコメント
１５．識別子の適切な命名法
１６．依存関係の局所性
１７．曖昧性
１８．検査性

SEA Forum Oct 2009（速報）

2009-10-28T13:12:00.004+09:00

-------------------------------------------------------------------
　　　　　　　　　　　　SEA Forum Oct 2009
　　　いまだから、まだ聞ける SQuaRE～ISO/IEC 25000シリーズ～とは？
　　　　　　　　　　主催：ソフトウェア技術者協会
　　　　　　　　　　10/28 @ 新宿歴史博物館・講堂
　　　　　　　　　　　　　　参加者募集
　-------------------------------------------------------------------
プログラム（予定）
　　　13:00 - 13:30　受付
　　　13:30 - 15:00　SQuaRE の概要
　　　　　　　　　　　込山俊博（日本電気）
　　　15:00 - 15:30　Break
　　　15:30 - 16:45　オープン・ディスカッション
　　　　　　　　　　司会：田中一夫（アイエックス・ナレッジ）
　　　　　　　　　　パネラー：奈良　隆正（NARAコンサルティング）
　　　　　　　　　　　　　　　中山　優紀（日立SAS）
　　　　　　　　　　　　　　　大西　建児（豆蔵）
　　　　　　　　　　パネル・メンバーを含めて会場全体での討論
　-------------------------------------------------------------------
＜参考資料＞こちら
※配布資料は参考資料に＋αしたもの。

＜13:00 - 13:30　受付＞
●品質の規格の数字
　・SQuaRE　25000シリーズ（次世代規格－作成中）
　・9126
　・14598
●標準化の概略（参考資料参照）
　・ISOとIECがジョイントテクニカルコミュニティで行っている
　・ＳＣ７
　　ソフトウェアエンジニアリング→ソフトウェアシステムエンジニアリングにスコープを拡大
　　（最終目的のためには、ソフトウェアエンジニアリングのドメインでは狭すぎる）
　・情報処理学会・情報規格調査会にＳＣ７対応の委員会を設置
●コア・パートと拡張パートに分かれている。
　コア・パートを先に使うべき。
　拡張パートは、特定分野に使う（例えば、パッケージ）
●データの品質の評価とりこんでいる（旧来との相違点）
●プロセス品質は扱っていない。
●発行は１年強後
●それまでは、現行のものを使用する
　・ＩＳＯ／ＩＥＣ　9126
　・ＩＳＯ／ＩＥＣ　14598
●評価と測定
　・評価するためには、測定する必要がある
●ソフトウェアの測定
　・製品そのものを測定
　・作業のプロセスの可視化
　・結果・パフォーマンスを数値化
　・評価対象と測定対象は必ずしも一致しない
　　→プロセスを評価するために製品を測定
　　→製品を評価するためにプロセスを評価
●メトリクス＝測定量＋測定方法
　※国際標準では、「メトリックス」という言葉は使わない方向
　・測定量
　　　↑
　・算出式
　　　↑
　・測定方法

　・尺度（Scale）：解釈を与えるためのものさし

●基本測定量・導出測定量・品質測定量
　・単体か、複数かの構成によって言葉を使い分ける
　　→単体の測定量
　　→複数の基本測定量から計算される測定量
　・使い分けることの意味
　　→基本測定量：収集するデータを重複無く整理する
　　→導出測定量：測定の目的に合致したメトリックスを定義する
　・品質測定量

●尺度
　・名義尺度
　・順序尺度
　・間隔尺度
　・比尺度

●品質メトリックス要素の分類（資料参照）
　全部とれというわけではない、重要な品質特性を決めて必要なものを取捨選択する

15:30 - 16:45　オープン・ディスカッション
　　　　　　　司会：田中一夫（アイエックス・ナレッジ）
　　　　　　　パネラー：奈良　隆正（NARAコンサルティング）
　　　　　　　　　　　　中山　優紀（日立SAS）
　　　　　　　　　　　　大西　建児（豆蔵）
「SQuaREに期待できる事／期待できない事」
＜パネラー＞
●奈良
　Ｑ．用語の定義
　　８０４２、ＩＳＯ９０００シリーズ、ＩＥＥＥ　ＳＴＤ　７２９等の過去の用語の定義との関係か？
　Ａ．過去の定義は目を通している、変えているものもあるし、リンクしているのもある
　　旧ＩＳＯ９０００定義は参照している。２００５年に変わった定義と考え方は合わないので取り入れていない。
　　基本的には外部で決めている定義は、目を通し使えるものは使っている。
　　・SQuaREシリーズの整合性を第一としている
　Ｑ．マネジメントの部分を充実して欲しい。規格によって用語が違うと、混乱する。
　Ａ．団体が違うと言葉の定義の違いはさけららねい。
●中山
　品質保証担当。SC7-WG6に参加している。
　ISO9126を見てアイディアが一致したことに感動した。
　品質にとって知識が無い人も造詣が深い人も、規格をみることにより同じ土俵にたてること望む。
＜会場＞
Ｑ．ＩＳＯ９１２６ではプロセス品質を扱っているのに、SQuaREでは扱っていない。何故か？
Ａ．このＷＧに割り当てられたスコープは、ソフトウェア製品の品質となっている。
　　プロセス評価の対象は、別のＷＧに割り当たっている。

Ｑ．内部品質の内部レビューの例があるが、要求仕様書の例はないか
Ａ．内部メトリックス（２５０２２）で扱うべきだが、まだ現在は評価の網羅できていない。
　　今後の宿題としたい。

Ｑ．品質要求の定義は？（例、非機能要求、機能に対する満足度があるが）
Ａ．品質工学の定義と近い。
　　機能がありそれを満足するための品質がある。
　　基本的考え方はそうであるが、品質要求が定義されているかは、確認したい。

Ｑ．各国の利害や政治的背景がありまとまり難い。
　　ある程度の大枠はまとまると期待している。詳細になると国内と合わなくなる可能性がある。
　　国内でメトリックスという言葉が定着している。用語の統一には、期待していない。
　　標準をそのまま持ってくるのではなく、勉強会を開くなどし実際の使い方を深めるべき。
　　それを海外にもっていく動きをして欲しい。
Ａ．標準は妥協の産物なので、そのまま使えるわけではない。
　　作ったが良いが使われないことが多い。産業界で使われるように努力してゆきたい。

Ｑ．JUASのH氏の講演を聞いた。大企業のシステム停止時間は、日米比は１：１０（日本の品質はよい）
　　海外からCMMとITELをひっぱてくることはない。
　　品質に対する温度差を感じることはないか？
Ａ．規格制定の場で、個人およびコンテクストにより違いが出てくる。
　　基準として使う（認証）→欧米が強い。日本の場では、企業の努力目標として使うというメンタリティが強い。
　　各人のもつ専門性の違いがでてくる。自分の専門性を広く

Ｑ．欧米の人は、商売に使いたい（コンサルの道具）。
　　もっとビジネスに使える仕組みに使えるように、方向を持っていかなければならない。
　　政府の調達要件など、ロビー活動をすべきではないか？
Ａ．（N氏）
　　邪な考えに反対。商売に使うとなるとＩＳＯ９０００のようになる。
　　欧米人は商売に使おうとしている。それにのってはいけない。
　　国民性の違いがある。国民性が発揮できるようなものにすべき。
　　規格を多数作って意味があるのか？
　　語彙を統一し、話が通りやすいようにする。程度でよいのではないか？
Ａ．規格にする場合には、世の中にどのような役に立つかを明確にする必要がある。
　
Ａ．邪な人がでるのは、賛否ある。

Ｑ．ＷＧ１０、２０、２４をやっている。
　　一番の目的は、用語の統一にある。
　　日本といえば品質と世界では考えられているにも関わらず、国内で品質議論は聞かない。
　　品質データをちゃんと集めているのか？なぜ、広まらないのか？
Ａ．各企業はやっているけど、オープンにしない。
Ｑ．確かに部分的に聞いているが、そうであれば広く知られていないのはもったいない。
Ｑ．情報団体の構成メンバーと話していると、品質に対して興味が無い。
　　その理由は派遣体質の会社だろう。
Ｑ．極めて品質の意識が高いところは、この程度のことは恥だとおもう。
　　埋もれているところがある。
Ｑ．アンケートをとったら９１２６を知っているのは、１～２割りであった。
　　企業体質によるのではないか？
Ｑ．知られていないのと、やってないのは違う。
　　企業として取組む時に、参照すべきものが必要となる。
　　十年後に「品質の日本」が死語にならないように、
　　標準に関わる人の責任は、作るだけでなく、普及していることにある。
Ｑ．外部品質の安全性がある。日本では安全性と信頼性と同じと考えている人がいる。
　　バグが０でも、安全でないケースがある。
　　予想外のインターラプションがある。
　　安全性は設計不良ではないか？設計品質の評価にたいするアプローチはあるか
Ａ．安全性は、使用性の一部として取り上げられている。
　　安全性と内部品質・外部品質との相関関係は把握し切れていない。
Ｑ．安全性は難しいものであるので、これからが大変でしょう。
Ｑ．JUASでは障害抑制性、効果性をやっていた。
Ａ．機能安全性はナンシー（※）んの本ではどのように書かれているのか
Ｑ．ナンシーさんの本は、機能安全性という狭い範囲ではない。心理学、人間工学等々総動員する必要がある。
Ｑ．SQuaREは、Whatの面でやっている。
　　日経コンでは、「代替手段があればよい。」と、言う回答があった。
　　品質に関するメンタリティが変わってきたのではないか？
Ａ．対象とするものにもよるのではないか？
Ｑ．品質は概念なので、人に依存する。
　　概念を見える尺度を人に見える形にするために、指標がある。
　　システムの規模により、視点が違うので広がらないのではないか？
Ａ．スケールの範囲が人により年代により違うのではないか？
Ｑ．スケールの絶対値を出して欲しくない。
　　コンテクスト抜きで絶対値が一人歩きする。
Ｑ．敢えて出すことにより、広がることもある。
　　数値の背景を紐付けてあればよい。
Ｑ．誤差が大きいものだとの認識する必要がある。
Ａ．標準では具体的な数字は出していいない。
Ｑ．ＩＰＡ／ＳＥＣは独立法人（存続は政府しだい）だが、
　　各社がやっていることを広めるというのは、誰かがやらなければならない。
　　ＳＥＣがやるべきだが、人的リソースは無い。
　　現行は、各企業からの支援によっている。

※セーフウェア　松原氏訳

平成21年度第一回エンピリカルソフトウェア工学研究会（速報）

2009-10-26T09:41:00.009+09:00

平成21年度第一回エンピリカルソフトウェア工学研究会
【プログラム】
［第1部］
10:00-10:05 開会の挨拶
松本健一
（StagEプロジェクト代表／奈良先端科学技術大学院大学）
10:05-11:35 特別講演
New Challenges in Software Measurement（逐次通訳あり）
Prof. Reiner R. Dumke（教授／ドイツ・マグデブルグ大学）
10:35-12:00 Q&A

（昼食）
［第2部］
13:00-13:10 開会の挨拶
後藤祐介（文部科学省研究振興局情報課）
13:10-13:55 基調講演
ソフトウェア開発紛争事件からみる構築過程見える化の重要性
北岡弘章氏（弁護士／きたおか法律事務所）
14:00-14:45 基調講演
ソフトウェア開発過程における文書の契約書としての意義付け
内布光氏（教授／東京経済大学）
14:50-15:20 StagEプロジェクト現状報告
楠本真二（大阪大学）
飯田元（奈良先端科学技術大学院大学）
15:35-16:55 パネルディスカッション
ユーザとベンダ間の紛争を解決するために
ソフトウェアタグはどのように機能するのか？
モデレータ：久保浩三（教授／奈良先端科学技術大学院大学）
パネリスト：北岡弘章氏（弁護士／きたおか法律事務所）
　　　　　　　　　　　内布光氏（教授／東京経済大学）
　　　　　　　　　　　松本健一（StagEプロジェクト代表／
奈良先端科学技術大学院大学）
16:55-17:00 閉会の挨拶
井上克郎（大阪大学）
－－－－－－－－－－－－－－－－－－
【速報】
10:00-10:05 開会の挨拶
松本健一
（StagEプロジェクト代表／奈良先端科学技術大学院大学）
10:05-11:35 特別講演
New Challenges in Software Measurement（逐次通訳あり）
Prof. Reiner R. Dumke（教授／ドイツ・マグデブルグ大学）
　　　　　　（逐次通訳　奈良先端大　川口先生）
●自己＆研究室の紹介
　・１９６０年代に数学の勉強を始める（ＭＦのころ）
　・（最初）ソフトウェアの自動生成の研究
　　→要求仕様から
　　→様々な困難があることが分かった
　・ソフトウェアメトリックスを開始
　・ソフトウェア工学（主に品質管理）に取り組んでいる。
　・他にも色々なソフトウェア工学に取り組んでいる。
　・カナダ、スペイン、日本の大学と共同研究
　・企業とも連携
　　→自動車の組込みソフトの品質保証
　・研究結果を広めるため出版多数
●ソフトウェア計測
　・品質保証に使うには、メトリックスのみでは不足している。
　・ソフトウェアの計測に関して、今まで多数言われている。
　　Dumke氏の見解
　　→ソフトウェアは知識そのもの、知識そのものを測るのは難しい
　・ソフトウェアメトリックスは、簡単に測れて、有効に使えるものが良い
　　→正しい理解ではない
　　→メトリックス間の関係をつなぐ必要がある
　・メトリックスはいくつ測ればよいのか？
　　→ソフトウェアを使用する環境による
　・メトリックスの例
　　→規模、バグ密度等々沢山ある
　　→プロセス（CMMI）
　・メトリックスの問題
　　→測定と統計学的誤り
　　　（量的な誤り、割合、統計としては少なすぎる量、分散が大きい）
　　→メトリックスすべき量の質の問題（直接数値として測れるもの、数値化に工夫が要る物）
　・メトリックスの進化
　　→計測値→計測行為→計測プロセス→計測プロセスの統合→計測プロセスが基盤に組み込まれる
　・国際基準（ISO15939）
　　→測るものを決める→事前準備→計測
　・計測結果の評価が必要
　　→計測するものが間違っている可能性がある
　　→多くのメトリックスが提唱されている
　　→正しく評価できるか明確になっていない
　・ソフトウェア計測の領域
　　→指標
　　→単位
　　→フェーズ
　　→手段
　　→フレームワーク
　　→戦略
　・ソフトウェア計測の
　　※オブジェクト指向は再利用のために考えられた、今では、必ずしも正しいくないといわれている。
　・ソフトウェア計測のシステム
　　→目的
　　→計画
　　→手段
　　→量（対象の量）
　　→値
　　→単位
　　→経験
　　→ツール
　　→リポジトリ（結果の蓄積が重要）
　・フレームワーク（計測の改善に使用する）
　　→Zuse
　　　メトリックスから計測の実行までを階層化
　　→ISO15939
　　　DKM手法
　　　ゴールを設定し、メトリックスを決める
　　→６σ
　　　大企業で使用されている
　　　統計上の異常値を問題として扱う
　　→Ｅ４
　　　定義の操作の両面を扱う
　　　ファンクションポイントは、扱う単位系が異なるという問題がある。
　　　組込みソフト向けに単純化
　・eMeasurment
　　→Webを基盤とした計測システム（オンランを用いたコンサル、教育、測定、評価等）
　　→Wikkiを用いたプログラム開発モデルを研究中
　　→ISOの認証もオンラインでできるのはないか
　・ソフトウェア計測には、ソフトウェアパラダイムを考える必要がある
　　OOSE→CBSE→SOSE→AOSE（AOP、FOD、EBD、AOSE)
　・パラダイム間のメトリクスの経験知が使えるか
　　→OOSEの、メトリックスと閾値など経験知が蓄積されている
　　→欧州ではSOSEを適用することが一般的（！！！）
　　→SOSEを計測するときに、OOSEの経験知はつかえるかどうか疑問
　　→そのまま使える方法を考案
　　　新しいパラダイムを提案する人は、適応結果を提供しないのが一般的（OOSEでもそうだった）
　　　パラダイム間の経験知（閾値など）比較するときの係数をかける
　・メトリックス影響元関係
　　・図（略）
　・e計測
　　→異なるパラダイム間の娶りkkするの比較
　・異なるレベルでの比較（図　略）
　　SPM：プロセスの確立
　　PIM：プロセスの改善
　　EPM：プロセスを定量的に評価
　　SPM：プロセスの計測評価が勧z年にできる
●今後の課題
　・一般的な計測・評価のプロセス
　・計測の教育
　・異なるパラダイムのソフトウェア間の評価の違い
　・自然言語
　・Webベース
　・コミュニティによる支援、組織
　・事前計測
　・計測プロセスの複雑化への対応
　・計測データの国際的なリポジトリの作成
　・計測のセットを確立
※講演時間はマイナス１分（と、計測していることを示す）

Ｑ．パートナー企業としてＶＷがあるが、どんなことをしていてたのか？
Ａ．ソフトウェアの品質保証の共同研究（特に、組込みソフト）＋ソフトウェア情報管理
　　物理的なものと比較できるので、興味深い。
Ｑ．車は安全性が必要だ。ソフトアの安全性はどう評価しているのか？
Ａ．他の車の企業ともやっているので、ＶＷ以外の話をする。
　　ジーメンスやＢＯＳＥと一緒にやっている。
Ｑ．何を測ればよいのか具体的な項目が知りたい
Ａ．故障の平均時間、コードに関する一般的なもの、コードカバレージ等
Ｑ．今までのメトリックスは設計後のもの、上流工程で品質を上げるための測定値
Ａ．モデルドリブンアーキテクチャをやっている。
　　モデルからコードの自動生成。モデルが正しければ品質が保証される
Ｑ．計測では取り組んでいるか
Ａ．モデルに関する計測もやっている（詳細は、論文を参照してほしい）

－英語による、質問と回答（聞き取れず？？）
13:00-13:10 開会の挨拶
後藤祐介（文部科学省研究振興局情報課）
　・文部科学省の委託で実施。
　　→５ヶ年計画の３年目
　　→高い成果がでている（と評価されている）
　・政府の情報通信政策
　　→政権交代下で予算編成を行っている。
　　→政策の中心は子供手当て等になり、科学技術政策は埋没する可能性あり
　　→一方米国では、科学技術を優先課題としてクラウドなど新技術にお金をかけている
　　→米国に対抗し重点化する必要があると考えているので、（文部科学省としては）実行する

13:10-13:55 基調講演
ソフトウェア開発紛争事件からみる構築過程見える化の重要性
北岡弘章氏（弁護士／きたおか法律事務所）※「SEのための法律入門」
●法的観点からの見える化
　・法的紛争の解決
　　→証拠に基づき事実を確定し、法律を当てはめる
　　　「証拠」が重要
　・ソフトウェア開発
　　→法律家（あるいはユーザ）からみてソフトウェアは見えないもの
　　　（最終的に説得しなければならない裁判官が分からない）
　　　　※分かっている、建築・土木の請負契約に比較して判断しがち。
　　　ソフトウェアは可視化が難しい
　　　　建築請負←→ソフトウェア開発
　・可視化≒証拠化（裁判所に見えるようにする）

●ソフトウェア関連訴訟の特殊性
　・ソフトウェア関連訴訟の認識
　　→訴訟関与者側の問題点
　　→３者にIT技術に関する専門性および取引実情に関する認識不足
　　→争点との関連も不明確なまま難解な書類が多数提出
　　※主張が噛み合わず、争点が拡散し、証拠が増える
　　※通常のものは短縮化しているのに、ソフトウェア関係は長い
　　　・知財関係（ほぼ１年）
　　　・ソフトウェア（２～３年）

●民事訴訟法上の原則
　・自由心証主義
　　→裁判所は、証拠法則の制限をうけることなく、争いのある事実につき、口頭弁論の全趣旨および証拠しらべの結果を斟酌して自由な心証により事実主張が真実にお合致するかどうかを判断
　　　証拠の証明力の評価を経験則の範囲内で裁判官は自由に判断できる
　・証拠方法の制限
　　→民事訴訟法上は特になし
　　　違法収集証拠（ケースバイケース）
　　　※メールなども証拠として採用されるケースが多い

●訴訟対応
　・主張と立証
　　→裁判では、立証できるかがポイント
　　　証拠には主として人証と書証があるが、一般的に書証のほうが信用される
　・ソフトウェア訴訟の専門性への対応
　　→専門的な知識のある裁判官が必ずしもソフトウェア訴訟を担当するわけではない
　　→専門的委員制度
　　　ソフトウェアの専門家が一般的な説明をする
　　→専門調停
　　※委員の経験に引きずられるので、公平間が損なわれる可能性がある
　　　確固たる業界慣行はない

●開発紛争における証拠
　・自由心証主義→あらゆるものが証拠
　　→書面
　　　契約書、現状分析調査報告書、システム提案書、基本設計所、内部設計書、議事録、メール等
　　　※議事録の内容の解釈すら揉める
　　→人証
　　　証人尋問での証拠→陳述書※これが重要されることがある。主張のストリーが分かりやすい
　　→検証
　　　実質２年にわたるシステムj稼動の検証実験
　　→鑑定
　　　適切な鑑定人の確保が問題（書ける人がいるのか？）

●民法上の原則
　・契約の成立
　　→申込と承諾による当事者の意思表示の合致
　　　口頭の約束でも契約は成立
　・契約自由の原則
　　→契約内容を自由に定められる。また、契約の方式についても自由（方式自由の原則）
　　→契約書の締結は、原則として契約の効力発生要件ではない
　※契約書があったとしても、契約内容が争点となり得る

●ソフトウェア関連訴訟の争点
　・債務の本旨に従った履行
　・小規模企業が発注者の場合
　　→契約書がない。仕様が規定した文書がない
　　→双方の理解が大きく食い違う
　　→仕様変更の過程が不明確
　・大規模開発契約
　　→契約書はあるが、契約の基本内容についての認識に大きな隔たりがある
　　　※旧来のシステムをそのまま、オープンシステムに移行して欲しい。と、いう場合に食い違いが発生する可能性が多い
　・開発途中での履行不能を理由とする契約解除を巡る紛争
　　→履行期において、社会通念上履行不能といえるかどうかが最大の争点
　　　将来予測を含む判断
　　　立証がそうとう困難
　　→損害論
　　　算定の困難性（中断時の出来高、不要となった軽視、待機人員への評価）

●開発委託を巡る紛争
　・東京地裁H16/3/10判決
　　※双方言い分があり、落ち度がある。というのが北岡氏の実感

●開発契約の内容確定
　・現状分析調査報告書
　　→開発契約と一体ではない（この案件の場合）
　・提案書
　　→契約と一体をなすもの
　　　被告も争っていない
　・契約書があったとしても、それだけで契約内容が確定するわけではない
　・小規模な開発の場合
　　→契約書が存在しない
　　　ケースバイケース
　・ユーザ側の能力が低い場合は、ユーザー側有利に参酌する場合

●基本仕様書の位置づけ
　・基本仕様書の検収
　　→裁判所の判断
　　　仕様の「凍結」は「確定」と同義ではない。
　　　※用語を正しく定義して書くべし
　・基本設計書の検収のみで、仕様の確定（契約範囲の確定）、仕様変更の問題は解決しない

●打ち合わせ議事録
　・打合せ議事録
　　→仕様の確定のための重要な証拠
　・議事録等の限界
　　→法的紛争を念頭においた記述がない（用語の定義等）
　　→概念の不統一性の問題
　　※あえて費用追加を書かずに、寝技に持ち込もうとする場合がある

●仕様変更の問題
　・仕様か否かは裁判所にとって明確でないことが多い
　　→契約内容の確定の問題
　　→打合せ議事録の記載

●まとめ
　・紛争への対応（議事録等紛争を意識したものになっていない）I
　・属人性の排除
　　→紛争の延引としてプロジェクト・リーダ等の交代
　・共通の「用語」
　　→他者を意識した見えるか
14:00-14:45 基調講演
ソフトウェア開発過程における文書の契約書としての意義付け
内布光氏（教授／東京経済大学）※日立情報出身

●はじめに
　・従来から、ソフトウェア開発取引を巡ってユーザ・ベンダ間でトラブル・法的紛争が絶えない
　　→裁判事例になじまない。（紛争が長引く）
　・ソフトウェア開発形態の変化・多様化

●ソフトウェア開発取引の意義
　・ソフトウェア開発取引は、「無」から「有」を創作することを目的とする取引
　　→外見では完成したかどいうかは分からない
　　→ユーザの要求を満たしたものか、ユーザが実際に使用してみなければわからない
　・ユーザの業務処理用ソフトウェアは、本来、ユーザ自ら（もしくは主導）で開発することが望ましい。
　　→ユーザの業務情報が、ベンダへの開示、使用等により漏洩の危険
　　→ユーザには開発能力・技術等が無い場合が多い、ベンダに開発を委託

　※日本は自社の独自業務やりたがり、パッケージをつかってもカスタマイズする。
　　今後も、業務ソフト開発はなくならない（であろう）

●ソフトウェア開発取引の法的性質
　・ソフトウェア開発取引は法律行為
　　→法律行為とは、法律効果を生じさせる行為
　・法律行為の典型は、契約
　　→契約は、当事者（ユーザとベンダ）の合意により成立
　・契約は、原則としえ「口頭（口約束）」だけで成立
　　→文書で契約を取り交わさなくて良い
　・ソフトウェア開発契約では文書化が絶対
　　→文書化のメリット
　　　合意内容の確認
　　　契約内容の備忘記録
　　　裁判上の有力な証拠

●「請負」型ソフトウェア開発の特徴
　・請負型
　　→ある仕事を完成させる
　・「仕事」の内容を特定することが重要
　・請負人（ベンダ）に「仕事完成」と「瑕疵担保」の責任が負わされる

●法的紛争の背景
　・ソフトウェア開発は、知的・技術的作業であり、作業内容・進捗状況が見えずに分かりにくい
　　→家の建築：作業内容、進捗状況が一目でわかる
　　　開発プロセス・作業内容を標準化し、可視化が重要

　・開発ツール・部品化や第三者ソフト・FOSSなどの利用
　　→開発成果の権利関係が複雑化
　　→不具合や保守等に対する責任があいまい

　⇒「共通フレーム」に準拠し、記録（文書化）が重要

●仕様確定の重要性
　・「仕様」を確定せずに開発作業が開始される場合が多い
　・なぜそうなる
　　→ユーザが側にIT技術者がいない（ソフトウェアの知識が乏しい）場合が多い
　　　現場のニーズ（使い勝手等）を要求定義・仕様に盛り込めない
　　→ユーザは、できおるだけ「早く」「安く」の結果を求めたがる
　　　ベンダに任せっきりで、仕様について十分な打合せ等ができない
　・ソフトウェアの仕様が確定しない開発はエンドレスになりがち
　・なぜそうなりやすい
　　→時の経過とともにユーザの要求内容が膨らみ、次々と仕様変更となる／いつまでも仕様が確定しない
　　→仕事の完成基準となる「ものさし」がないので、ものさし＝検査仕様書等も作成できないので検査もできない。

●仕事評価の困難性
　・仕事は完成したか
　　→外見上完成したかどうか分からない
　　　ユーザの実際環境下で使用（実機テスト）
　・なぜそうする
　　→ソフトウェアは、コンピュータで使用しなければ真価を評価できない
　⇒ソフトウェアを使ってみて、所定の機能・性能が発揮できなければ法的紛争の原因になる

●裁判で争われた紛争原因
　・債務不履行　　　　　　　　　　９件　３５％
　・瑕疵担保責任　　　　　　　　　６件　２３％
　・債務不履行および貸し店舗責任　３件　１２％
　・著作権帰属又は侵害　　　　　　３件　１２％
　・その他　　　　　　　　　　　　５件　１９％

　裁判の争点の７０％が
　→ソフトウェアが完成できない／していない
　→ソフトウェアに不具合がある／使用に支障がある

●開発過程における文書の意義
　・ソフトウェア開発取引（請負型）の紛争予防は「仕事内容」、「取引条件」の明文化が大事
　・仕事内容と取引条件は、契約の重要事項
　・開発過程における打合せ・確認で確定
　　→打合せ資料・議事録、確認書等も契約内容を構成

●取引条件の文書化
　・年引き条件には、当事者が対立する事項が多い
　　→契約金額、納期、再委託等
　・取引条件（契約内容）は、「契約自由の原則」により当事者が自由に決定できる
　・当事者の利害が対立する事項については、両者の力関係により取引条件の有利・不利が左右されがち

●モデル契約書の意義
　・取引の透明性・適正性を確保するための契約書の標準化
　　→業界（JISAやJRITA)が「モデル契約書」を策定
　　→METI「情報システム・モデル取引・契約書」を公表

●仕事の内容の文書化
　・仕事の内容は、ソフトウェア仕様書などで具体的に特定し、明確化
　・仕事の進捗は、開発スケジュール表などで管理
　・仕事の完成は、検査仕様書、検査成績書などで評価
　・仕事の成果（プログラム）は、操作説明書などで容易に使用

●ソフトウェアタグと法的効果
　・ソフトウェアタグ
　　→ソフトウェアの開発中に収集された管理データや品質情報をパッケージ化したもの
　・ソフトウェアタグの利用目的
　　→製品品質の把握
　　→開発状況の把握
　　→紛争処理
　・ソフトウェアタグの作成
　　→ソフトウェアに対するトレーサビリティ
　　　法的紛争の際の適正開発の立証が容易
　　　ソフトウェアの不具合等自己の原因究明、早期復旧が容易
　・タグ情報をユーザ・ベンダが共有
　　→ユーザ・ベンダ間の紛争予防の効果（付属的効果）

●まとめ
　・ソフトエア開発取引では、仕事内容と取引条件の明文化が必要
　・ソフトウェア開発過程では、標準化した手順に従い作業内容・進捗状況の可視化が必要
　・事故対応・紛争処理時では、ソフトウェアに対するトレーサビリティが必要
　　→ソフトウェアタグ

14:50-15:20 StagEプロジェクト現状報告
楠本真二（大阪大学）
飯田元（奈良先端科学技術大学院大学）
●目的
　ソフトウェア開発が適正な手順でで行われたかどうかを表す実証データと「ソフトウェアタグ」としてソフトウェア製品に添付し、ユーザ／ベンダー間で共有する。

●研究グループ
　・ソフトウェアタグの規格化
　・ソフトウェアタグ支援ツールの作成
　・ソフトウェアタグの可視化と評価の技術

●成果
　・ソフトウェアタグの規格化
　　規格第１.０版を作成
　　→タグに使用するメトリックスは、ユーザとベンダーで事前に合議する
　・ソフトウェアタグ支援ツールの作成
　　→ソフトウェアタグサービスフレームワーク
　　→標準的なインフラライブラリ
　　　生データをタグに取込む
　　　データの定義、運用計画の支援
　・ソフトウェアタグの可視化と評価の技術
　　→表示用ツールの作成

15:35-16:55 パネルディスカッション
ユーザとベンダ間の紛争を解決するために
ソフトウェアタグはどのように機能するのか？
モデレータ：久保浩三（教授／奈良先端科学技術大学院大学）
パネリスト：北岡弘章氏（弁護士／きたおか法律事務所）
　　　　　　　　　　　内布光氏（教授／東京経済大学）
　　　　　　　　　　　松本健一（StagEプロジェクト代表／
奈良先端科学技術大学院大学）
●Ｑ＆Ａ
Ｑ．日本では暗黙の貸し借りの習慣があるのではないか？
　　・仕様変更を言う。これくらいはやってやる。
　　・前回やってくれたので、多めにみよう。
Ａ．貸し借り（暗黙の合）がある。そのことは裁判所も認識している。
　　証跡から真意を推し量るつもりでいる。
　　事案）現場の当事者は合意ができているが、代表者の説得ができないために紛争に発展することがある。

Ｑ．情報量の差があがあり、発注者側が不利になるのではないか？
　　車などは、利用者が有利。
Ａ．力関係では契約時には発注側が強い場合がある。
　　ある程度、工程が進んでしまうと、ベンダー側が強くなる。
　　一概にどちらが有利不利は言えない。
　　専門性があるほうが説明責任を尽くしていないと判断する可能性が高い。
　　消費者と企業ほどの修正はしないが、斟酌する場合がある。
Ｑ．時代により変わってきているのではないか？
　　・ユーザ側の協力責任　・ベンダー側の説明責任　両者をみるようになってきた。
Ａ．裁判官を証拠を理解するところから始めている。
　　裁判官のあたりはずれがある。
Ｑ．融通の効く日本の社会で、ソフトウェアタグは根付くのか？
Ａ．融通性を保ったまま開発しても、記録に残り、紛争の予防になるのであれば意義がある。
Ｑ．タグには裁判官に証憑を残す意味あるのではないか。
Ａ．共通基盤にのることで、紛争が単純化することで役に立つのではないか？
Ａ．情報処理産業は契約書を作るという意味では、コンテンツ業界に比べて進んでいる。これからその内容をつめていけばよい。
　　契約を争う裁判で証拠になるのは議事録になる。品質の証拠で争点を絞るという意味では、ソフトウェアタグは有効になるのではないか？
　　根付くかどうか絞り方。
Ｑ．ソフトウェアタグの目的に裁判は含んでいるのか？
Ａ．Ｙｅｓ
Ｑ．裁判に耐えるための条件を感じているか
Ａ．まだ議論は進んでいない。
　　コストの問題で、捏造はしないのでないか？
Ｑ．常に揉めるのは「仕様変更・追加」なのか「仕様不良なのか」である。タグに載せる情報で、解決できるのか？信頼関係が無い場合のせないのか？
Ａ．信頼が大事である。信頼できないところに大事なシステムを任せるのはおかしい。
　　両者は紛争にしたくないはずである。共通の認識に立つために必要。
Ａ．揉めるケースは「仕様変更・追加」である。要件定義もタグにとりこむことを考えている。
Ｑ．要件定義が曖昧な場合は、ベンダーの責任とされる判決が多いように思われる。実際にはどうか？
Ａ．扱った実感では、必ずしもそうではないが、社会通念として専門家の責任とされることが多い。
Ｑ．要件定義の取り扱いは、請負か準委任によって違うのか
Ａ．準委任は発注者側の責任、請負は受注者側の責任。
Ａ．準委任と請負は明確分かれていない。契約書に明記されていないない場合には、実態の作業条件等で判断する。一般的には明文化されていないことが多い。
　　要件定義は準委任、開発は請負でやるこもある。
　　法的処理をする場合には、実態に合わせてどちらかに割り当てるしかない。
Ｑ．ソフトウェアタグは、運用を含まないのか？
Ａ．もともとのアイディアは、ｌ開発・保守・運用をカバーしようとしていた。現在は、第一段階として開発を想定している。
Ｑ．＜聞き取れず＞
Ａ．請負型の場合には、最初から最後まで文書が必要という意味である。
Ｑ．ソフトウェア契約に特化した法律を作り、紛争を減らそうとする動きはないか？
Ａ．行法の話か？それであれば、その発想は聞いていない。
Ａ．ソフトウェア開発の部分で特別な法律は必要ない。
　　ソフトウェアの場合は多様性があり進化が早い、法律が作れないのではないか？
　　紛争の多発を法律で解決することはできないと考える。
Ｑ．値だけ入れても意味が無いのではないか？
Ａ．標準値、業界値が必要。
Ｑ．準委任や派遣を請負にすることに、ソフトウェアタグが役にたつか？
Ａ．タグが契約形態に影響は与えないのではないか？
Ａ．タグ自体が契約の一部なので、問題ではないか？
　　タグがあるから安心して請負に出せるというということを検討する、
Ｑ．タグでやるべきことがやりましたとといえば過失がないといえるか？
Ａ．過失がないとは言えないが、ソフトウェアが完成していないというクレーにには使えるのではないか？
Ｑ．タグの中身は業界側は判るが、ユーザ側が判らないのではないか？
Ａ．タグによりユーザ側が標準値をつくることができる。
Ｑ．数字の読めるユーザにはできるが、そうでないユーザにできなのではないか？
Ａ．素人にも判るうなものにすることを議論している。
　　医療の世界では電子カルテにより、単なるメモから診療情報としてデータが取れるようになり、価値がもつようになった。ちゃんとやると診療報酬が増えるようになった。
　　ソフトウェアタグもインセンティブが必要であろう。
Ｑ．標準化の今後の取り組み予定
Ａ．ＳＥＣと協力しＪＩＳ化を目指している。ＩＳＯに委員をだしている。
●まとめ
・弁護士としてはソフトウェア開発の紛争は受けても儲からないので、タグが普及してトラブルを減らして欲しい
・標準化が進まない世界なので、期待する
・開発は性善説にたつ、もしもの時に記録をみればよいという発想でやっている。
　ユーザの立場等不足しているので今後考えていく。

16:55-17:00 閉会の挨拶
井上克郎（大阪大学）
　今日は法的な問題を中心に議論した。法律で使うためには、タグを改良する必要がある。使えると部分も見えてきた。

作業チェックリストが厚いのも作業モレの原因に

2009-10-21T08:13:00.003+09:00

プロジェクトや障害の反省会を聞いていると、次のような結論に聞くことが多々ある

　原因：作業漏れ（作業手順書、チェックリストになかった）
　対策：作業チェックリストや手順書に追加する

　しばしまて、今でさえ十分に厚い作業チェックリストを、さらに増やしてどうするのだ。

　人間の集中力には限界があり、作業項目があまりにも多いと急速に集中力が低下する。
　その閾値は、人により、その時々のモチベーションにより違いが有るが、大量の作業項目を一連の動作として正確に行うことは出来ない。

　つまり、作業手順書やチェックリストの項目を増やせば増やすほど、手抜きが意識・無意識に関わらず発生しやすくなるのだ。

　この場合、作業チェックリストを厚くするのではなく、ツールによる機械化を行うか、さもなければ、作業を適切な大きさに分割することで、解決すべきだ（と、思われる）。

デグレード事例集（その１）

2009-10-20T08:08:00.002+09:00

これから、デグレード事例集を作って行きたい考える。

尚、機密情報保護のため顧客・システム名等具体的な情報は伏せるが、実際に起きた例である。

【区分】ユーザインタフェース

【現象】障害ログを監視していたが、ソフトウェアをバージョンアップところ通知されなくなった。

【原因】障害メッセージに誤字があったので、バージョンアップのタイミングで修正した。
　　　　ここため、ユーザ側の監視条件を外れてしまった。

【教訓】ユーザインタフェースは、上位互換を保つ必要がある。
　　　　この場合も、設定ファイルで旧メッセージを出力することを選択できるように必要があった。

【感想】ユーザインタフェースの変更は、ユーザにとって負荷が大きい。変更により便利になることよりも、変わった事の不便を感じることが多い。
　　　　Windows　Vistaが広がらなかった原因の一つであろう。

保守が顧みられないのはソフトウェアだけではないのか

2009-10-19T07:52:00.003+09:00

いささか旧聞であが、八ッ場（やんば）ダムの計画中止発言で揉めている。

私には、論ずるべき情報が不足しているので、是非を判断は保留する。

しかし、いきなり中止を発言した、前原国土交通大臣のやりかたにも問題はあるが、

中心反対派の主張にも頷けないとことがある。

どうも、反対派の主張は、

建設費（※保守を含まない）＜　中止のための費用

と、言う言い方になっているように思われえる。

ソフトウェアは作ってしまっても、使わないのなら保守費はかからない。

しかし、建築物はそうはいかない。

物理的な構築物は使わないと老朽化の速度は激しい。そのため、必要・不必要に関わらず運転する必要がある。また、ほうっておくと災害にいたるのて定期的な補修がひつようとなる。

特にダムは泥がたまるという問題もある。

どうも、中止反対派の主張にはこれらが盛り込まれていないように思われる。

歴史の長い産業すらこの調子なので、さらに歴史の新しい「ソフトウェア保守」の必要性や、費用が意識されないのは止むを得ないということなのだろうか。

今こそ、ソフトウェア保守教育に投資を！

2009-10-16T08:08:00.003+09:00

先日のセミナーで「たびとさん」と一緒になったので、セミナー終了後軽くアルコールを飲みながら保守についての話をした。（「たびとさん」は私にとって、所属会社は違えども師匠筋に当たる方）

どうも、このご時勢でソフトウェア・メインテナンス研究会の活動に支障がでそうとのこと。

会社から会費が出しえもらえない、会員が多数発生するとのこと。

しかし、ソフトウェア保守の研究が大切なことは論を待たない。

今は種蒔きの時期ではないだろうか（成果の刈り取りの時期でないことは間違いない）。

その種蒔きの時期に、将来を見据えて歯を食いしばっり人財に投資すべきであろう。
それが、「米百俵」の精神だと考える。
※お前は会社の存続に責任のない立場だから言えることだ、と言われれば反論は不可能ではあるが．．．

政府も子供の教育にお金をかけるのは結構なことであるが、社会人の教育（特にソフトウェア産業）にももっとお金をかけて得欲しいものである。（そういえば、以前教育費に補助があるという話があったが、最近あまりきかない。どうなったのだろうか？）

その日は、たとえ「たびとさん」と高橋の二人になっても、「保守の研究・広報・啓蒙」を続けようと誓い合った。ソフトウェア保守の「私塾」を開くことも検討。

意図を同じくする同志がいることは、心強く、ありがたいことである。

『インクリメンタル開発を支援する技術と環境』（速報）

2009-10-14T08:12:00.007+09:00

第21回 SRA-KTL Technology Seminar
テーマ：『インクリメンタル開発を支援する技術と環境』
講演者：神谷年洋氏（産業技術総合研究所）,
葉雲文（SRA）, 西中芳幸（SRA先端技術研究所）
日時： 2009年10月14日（水） 14:00 〜 17:00　受付　13:30〜
場所：全国情報サービス産業厚生年金基金　「JJK会館」7階会議室
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
１．コードクローン研究の進化と支援技術の展開
　　産業技術総合研究所　神谷　年洋氏
●コードクローンとは
　・ソースコード中に同一あるいは類似したコード断片があるとき、
　　それらをコードクローンという
　・コードクローンはソフトウェア保守を困難にする
　　－バグ修正や機能変更が困難になる
　　　（コードクローンにバグが含まれると、すべてのコード断片に
　　　　ついて修正を検討する必要がある）
　・大規模ソフトウェアでは、開発者がコードクローンをすべて覚えて
　　おくことは不可能

●コードクローン検出・分析技術の特徴
　・対象はソースコード「半」構造化文書
　　－エラー、不完全（部分的）、方言
　・コードクローンの定義は存在せず
　　－プログラミング言語のエンティティではない
　・見るべきスケールの（落）差が大きい
　　－コードを編集するときの規模（数十行）←→コード全体の規模（数万行、数千万行）
　　－全体（的な傾向）を見るための手法、編集のための手法

●対策・応用

●研究の深化・分化
　・１９９９の検出ツール
　　－行（diffのような）
　　－プロダクトメトリックス
　　－ASTのハッシュ
　・２００９の検出ツール
　　上記に加えて
　　－トークン
　　－文字列
　　－ASTの部分木（isomorphism、edit　distamce)
　　－PDGの部分グラフ
　　－実行トレースの部分列
●CCFinderX（あるいは－X)とは
　・コードクローン検出・分析ツール
　　－CCFinderXはwww.ccfinder.netで配布中
　・検出
　　－大規模
　　－複数の言語
　・分析
　　－クローンメトリックス
　　　・着目すべきクローンのヒント
　　－対話的分析GUI
　　　・ソースコード中を追いかけていく

●CCFinderを利用するツールたち
　・対話的分析
　・検索
　・コード編集
　・樹状図
　　－ソースコードの変更追跡
　・診断ツール

●開発組織
　・フラット・管理者不在
　・技術志向で素早く決断
　・ときには混沌も

●要求
　・手持ちのコードを分析できること
　・既存の研究プロジェクトに適用できること
　・スケーラビリティがあること
　・（後輩・配布）他の人も使えること

●フィードバック
　メール／「ソフトウェア工学工房」での配布
　・「Xというプログラミング言語に対応してくれ」
　　－「当社のコーディングルールに対応してくれ」
　　－＞ハードコードしているから無理
　・「何行以上のコードクローンを見ればいいのか」
　　－＞コードクローンの定義とは？
　　－たった３行のコピペでもアウトの判例（米）
　・「GUIがスケールしない」
　　－JVMでつかえるメモリは制約が厳しく、メモリマップとI／Ｏも、
　　　グラフィックアクセラレータのなし。

●Quartet（2009)
　・開発者の懐刀になれるような
　・研究者アイディアを素早く実験できるよいうな
　　→ツールキット
　・ツールキット＋サンプルツール
　　－アプリケーションではなくコードとしての再利用
　　－APIのデータはファイルではなくコンテナ型
　　－オープンソース

●コードは再利用できないもの
　・汎用性の階層
　・汎用性の階層に応じて再利用可能なコードが流通
　　→再利用できるようなコードはすでに誰かが書いている
　・再利用？→汎化か保守
　「再利用可能なコードを書いている」
　　→車輪の再発明じゃないかまずチェックしてください
　　→プログラミング言語／ライブラリの開発組織にコミットしてください

●小さなマイルストーンが成功のもと
　・マイルストーン
　　→２重のチェック：到達確認、軌道修正
　　→リスクドリブン、インクリメンタル、インテーション
　・小さなマイルストーンに分解できすまでにGOサインを出すこと
　　→失敗（捨て去る）ことを覚悟すること（新規開発／修正／更改を問わず）
　　　・文字通り　long　shot＝ばくち

●UIは利用者の顔を見て

●アルゴリズムはハードウェアを見て
　・古きよき時代：クロックは上昇するもの、メモリはランダムアクセス、時間・空間量によるモデル
　・現在：ヘテロなプロセッサたち、メモリ？レイテンシ／スループット→アムダールの法則
　　↓
　・座学と実学の両方必要
　・ハードウェアの特性を知らないと空論を振り回す羽目に

２．検索駆動型ソフトウェア開発支援環境
　　（株）SRAニュービジネス戦略本部　葉　雲文氏

●検索駆動型ソフトウェア開発とは？
　検索エンジンを含む情報検索ツールを利用し、「いま目前にある」開発作業に必要となる知識を情報を調査、活用しながら、ソフトウェア開発諸活動を効率よく進める方法

　・検索される対象
　　　外部のウェブ
　　　開発済みシステム
　　　各種文書
　　　社内のリソース
　　　メーリングリスト
　　　開発中のシステム
　　　etc.

●The WHY：　検索駆動型ソフトウェア開発

　・ソフトウェア開発の本質
　　－ソフトウェアシステムは一つの情報空間（Information　Space)
　　－ソフトウェア開発は知識労働である
　　　→農業労働：なにもないところから物質を生産する
　　　→工業労働：複数の物質を別の物質に変換させる
　　　→知識労働：なにもないところから物質的な存在でない情報空間を創出
　　－ソフトウェア開発者は情報収集を情報創出を繰り返す
　　　→原材料は知識と情報である
　　　→全ての知識は開発者の頭にあるとは限らない
　・必要な情報を適時に収集、獲得する能力はソフトウェア開発の品質と効率に多大な影響を与える

●ソフトウェア開発には検索は欠かせない
●検索駆動型に関する研究動向
　・ソフトウェア開発における検索の重要性を確認
　　→開発活動の２４％－４０％は、ソースコードから情報を検索
　　→同僚との打ち合わせの４０％はソースコードに関する情報
　・ソフトウェア開発者の情報検索プロセスの解明
　　→ファイル名や識別子は重要な手がかり
　　→Just-in-time　comprehension
　　→コメントはJust-in-time　comprehensionの役割を果たす
　・検査技術を利用して開発の諸活動を支援する方法
　　→学習、理解、要求追跡、バグ発見、再利用、Intelligent　Editorライセンス管理、プログラマー同定、タスクアサインメント

●検索の重要性の例

●開発者の情報検索プロセス
　・検索のきっかけとなる行為
　　－４０人がタスク記述中の単語サーチ
　　－８人がEcllipseのPackage　Explorerでブラウジング
　・関連性の判断
　　－fileの名前で関連性を判断
　　－識別子をみて、関連性を判断
　　－関連ありそうなコード断片だけを注目￥
　・依存性のトレース
　　－７０分間で６５個の依存性を追跡

●産業界の動向：次のGoogleへの争い
　・general　purpose　search
　・social　search
　・vertial　search
　・desktop　search

●ソースコード検索エンジン
　・ソフトウェア開発者に特化した検索エンジン（vertical　search）
　・ソフトウェア開発企業に特化した検索エンジン（enterprise　search）

●ソフトウェア開発者の検索エンジン
　・米国最新調査結果
　　　よく利用　　　５９％
　　　たまに利用　　３９％

●codepot
　・目的
　　－ソースコードを知識のアセットとして管理、活用
　　－ソフトウェア開発の生産性を品質向上に資する
　　－開発者の技術スキルの習得と共有を支援
　・アプローチ
　　－全社のソースコードを検索可能なポータルに集約
　　－利用可能な膨大なOSSも同一なインタフェースで検索
　　－ソースコードにノート（メモ）を加える機能により、保守システムと外部ライブラリに関する知識を蓄積、共有

●codepotの高度かつ高速な検索機能
　・ソースコードに特化した検索方法
　　－文法アウェアな検索
　　　→コード、コメント
　　　→ファイル名、クラス名
　　　→メソッドの利用、定義
　　　→シグネチャー
　　－コードクローン検索
　　－強力なフィルター機能
　　　→プロジェクト別、ライセンス別、パッケージ別

●codepotにより開発効率と品質向上
　・再利用、学習、保守、プロジェクト管理と製品検収

●codepotにより開発効率と品質検証
　・再利用
　　－組織横断的な再利用を簡単にする
　　　→初期コストなし、既存コードを登録するだけ
　　　→OSSも再利用対象になる
　　－再利用する開発者と支援
　　　→black-box　ライブラリとして組込み
　　　→white-box　一部のコードを修正して再利用
　　　→glass-box　認知負荷の低減によりバグが減る
　　－共通コードを割り出し、コンポーネント化

●codpotにより開発効率と品質
　・学習
　　－アルゴリズムの実装方法
　　－APIの利用方法の学習と共有
　　－プログラム・イデオム（call　chain）
　　－利用しているOSSシステムのコードを理解
　・保守
　　－修正する場所の把握と発見
　　－修正の影響範囲の把握
　　－ソースコードにノートをつけることにより、保守知識を蓄積、共有
　・プロジェクト管理と製品検収
　　－社内アセットを一元的なアクセスインタフェースを通して、プロジェクトの提案と見積り段階でも活用
　　－製品検出で望ましくないコードの検出
　　－問題コードをプロジェクト横断的に一気に固定

●まとめ
　・codepot
　　－高速、強力な検索機能
　　－大規模なコードにも対応
　　－ウェブベースシステムなので、利用がシンプル
　　－再利用、学習保守、管理といった多様なタスクに利用可能

３．ライブラリの軽量化とユーザビリティ
　　SRA先端研究所　西中　芳幸氏

●多機能で高機能なライブラリ

●確かに、多機能で高機能ではあるのですが．．．
　・ほんのちょっとしたことをするだけでも、常に１５００クラス群がついてくる
　・ほんのちょっとしたことをしたいだけなのに、OpenGLやQuickTimeのAPIまでついてくる
　・三次元グラフィックとマルチメディア以外の機能が目立たない
　・様々な機能が複雑に関係し合っていて、説明しにくい／理解しにくい

●MotR：Motley　Reservoir（雑多な貯蔵庫）
　・提供している機能を一言でできる程度の粒度にモジュール化することで、「つかいやすさ」を改善したい。
　・必要な機能だけを提供する小さなライブラリを組み合わせて、コンパクトなアプリケーションを構築できるようにしたい。

●ライブラリが「理解しやすい」とは
　・ライブラリを理解するために知ろう、分かろうとする情報が入手できること
　・現状は、これらをウェア部の検索や更改サイトの情報などを見て、調べながら、理解する。

●ライブラリが「理解しやすい」とは
　・ライブラリの実際の振る舞いを見るために、サンプルコードを書き、動かしてみるための環境が容易に整えられること
　・現状は、これらを逐一調べられたり、ダウンロードしたり、設定したりしながら利用している。

●MotRでのモジュール化を通して分かったこと
　・モジュール群を共有するための場所が必要になる
　・変更は、小さなライブラリのリソースで行われる
　・小さなライブラリを頻繁にリリースする、アジャイル型の開発スタイルになる
　・コンパイルをして、テストして、デプロイする作業が頻繁に発生する

　→開発ライフサイクルの自動化が必要

　・モジュール更新を行うと、そのモジュールを利用するモジュール群が影響をうける可能性がある
　・影響を受けるモジュール群は、コンパイルし直して、テストしなおす必要がある
　・影響は、推移的に波及する
　・モジュールの数が増えてくると、全体の整合性の確認を手作業で行うことは現実的に不可能

　→継続的なインテグレーションが必要

●MotRのためのモジュール型ライブラリの開発
　モジュール型に適した開発を進めるために、いくつかのツールやサーバを導入した

（１）ソースバージョン管理
　・分散型のMercurial

（２）依存関係の解決
　・Apache　Maven（採用）
　・Apache　lvy
（３）コンパイル、テスト、デプロイ作業の自動化
　・コンパイル、テスト、デプロイ作業の自動かもApache　Mavenで行う

（４）共用リポジトリ
　・Mavenリポジトリマネージャを導入する

（５）継続的インテグレーション
　・Hudson

●利用する
　・使われているクラスが含まれているライブラリを探す
　・必要なライブラリのバージョンを特定する
　・特定したライブラリををダウンロードしてくる
　・特定したライブラリが依存するライブラリを調べ、探してダウンロードする
　・コードの実行をためすためのクラスを定義し、mainメソッドを定義する
　・クラスパスを設定し、コンパイル・実行環境を整える
　→Mavenリポジトリマネージャの上に、MotRサーバを作成する

※スライドはＫＴＬのサイトにＵＰされるとのこと

ソフトウェアの保守性について（その２－１）

2009-10-13T07:59:00.003+09:00

ソフトウェア保守性について（その２）が、途中だったので追記

【解析性】
　解析性はソフトウェアの保守性を構成する重要な要素である。

　この解析性は、次の２点を示す。
１）問題が生じた際に原因となるポイントの特定しやすさ
２）新たに生じた仕様変更で修正すべきポイントの判りやすさ

　ところで、人間の頭脳の短期記憶の容量には制限があるため、プログラムのつくりにより解析性の良し悪しが出現する。

　次に解析性に影響のある特出を記載する

１．一貫性
　人間の認識性を高め短期記憶容量を節約するために、命名、フォーマット等様々場面で一貫性が必要である。

２．式のフォーマット
　一般的には、一般性をもったフォーマットが良いでしょう。
　しかし、特定の状況に注意を向ける目的で、内部的な一貫性のないフォーマットを使うことも、解析性を上げるためには必要です。
　例えば、式の評価順序が言語で決まっている場合、評価の優先順位を明示するカッコは不要ですが、式の評価順位に詳しくない初学者でも理解が早いように、あえて余分なカッコをつけることもあります。

３．ステートメントのフォーマット
ステートメントの記述ルールは式の場合よりも単純ですが、プログラマーがこうしたルールを遵守しているとも限りません（また、遵守しなくても大きな問題にはならないことが多い）
　returnステートメントをifステートメントと同じ行におき、複数ある場合はインデントを合わせるのも可読性を上げる効果があります。

４．命名規約
　コードの可読性について考え限り（理解性とはことなり）、識別子につける名までの規則はそれほど重要ではありません。識別子の名前に期待されるのは、一見してその役割がわかることと、用途に応じた長さになっていることです。
　例えば、ループカウンターに”i”を使うことや、クラス名に長い名前を使うことが一般的で、また可読性を損なうことにはなりません。

５．ステートメントレベルのコメント
　コードにコメント行を挿入しておくことで、その可能性を高めることができます。ただし、すべてのコメントがこうした方向で貢献しているわけではありません。」
　確かに、コードの意図やそのように書かれた理由などを文章で書き記した、コメント行の存在は有益です。しかし、ステートメントを見れば一目瞭然な内容を文字で書き記しただけのコメントは、無用どころか有害な存在です。
　こうしたコメントはソースコードの内部の貴重な場所そ占有（※）と同時に、プログラマーがコードを読むときに注意をそらされてしまい、これら自体の保守に取られる手間も無視できないからです。
　※ソースコードを読むときの、短期記憶のスペースをとってしまいます。
　　ソースコードがウィンドウからスクロールアウトされると、覚えていることが困難です。その、貴重な表示領域を無益なコメントがあるとそれだけで有害です。

　
６．バージョン管理用のコメント
　プログラムを見ていると、コードの一部がコメント化されている箇所に遭遇することが良くあります。
　こうしたコードの扱い方は、視野の中の貴重な場所を占有し、読む側の注意をそらすため、プログラムの可読性を低下してしまいます。コードを「後から必要になるかもしれない」のでコメントに残しておく、あるいは「以前はこうしていた」というメモ代わりにコメント化しておくというのは、バージョン管理には誤った考え方です。
　また多くの処理系では、コメントのネスティングが許されていないので、コンパイル時にエラーを引き起こすおそれがあります。

　プログラムに手を加える祭に不要化したコードについては、痕跡を残しておかないくらいでの覚悟で、潔く削除してしまうべきで、それは、バージョン管理システムに任せる必要があります。
－－　時間切れのために詳細は、後述する

７．仮想的な構造：ブロックおよびインデント
８．式、関数、メソッドの長さ
９．制御構造
１０．ブール式
１１．コードの認識性と凝集度
１２．依存関係と結合
１３．コードブロックのコメント
１４．データ宣言のコメント
１５．識別子の適切な命名法
１６．依存関係の局所性
１７．曖昧性
１８．検査性

ソフトウエア・メインテナンス・シンポジウム　２００９　　速報

2009-10-08T07:42:00.008+09:00

ソフトウエア・メインテナンス・シンポジウム　２００９　　
「データから診るソフトウェア保守」

●　日時：2009年10月8日(木)　09:50-19:00（受付 9:30から）

●　プログラム

9:30- 9:50　受付開会
　 9:50-10:00　開会（７Ｆ)

　10:00-12:00　基調講演　「JUAS ソフトウェア・メトリクス調査　開発と保守
　　　　　　　　　　　　　　～保守技術者に元気を！～」
　　　　　　　 (社)日本情報システム・ユーザー協会　専務理事　細川　泰秀　氏

　12:30-14:00　昼食休憩

　14:00-14:50　招待講演「ソフトウェア保守の実態調査結果」
　　　　　　　 (財)経済調査会　高橋　昭彦　氏

　14:50-15:50　SERC各グループの活動報告および次年度の活動計画　その１

　　　Dグループ　「SERCの考える保守とは」増井　和也　氏
　　　Cグループ　「保守のアウトソーシングを考える」　　　田中　創　氏

　15:50-16:10　休憩

　16:10-17:10　SERC各グループの活動報告および次年度の活動計画　その２

　　　Bグループ　「保守作業改善の基盤技術調査」　　　　　石川　雅彦　氏
　　　Aグループ　「保守用ドキュメントとは」　　　　　　　福島　茂雄　氏

　17:10-17:20　ソフトウェアメインテナンス研究会について
　　　　　　　　代表幹事　岸田　孝一　氏

　17:30-19:00　情報交換会（２Ｆ）

●会場：場所：全国情報サービス産業厚生年金基金会館(JJK) ７階会議室
　　　　　　 (東京都中央区築地4-1-14)
　　　　http://www.jjk.or.jp/map.html

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
【8:20】まだ平塚駅。小田急線への振り替え輸送も停止のアナウンスあり。
　　　　遅刻は確定的。
　　　　プログラムを午前と午後、入れ替えてくれないかな…
【7：40】平塚駅
　　　　「強風のため東海道緯線停止中」、動く気配なし。
　　　　間に合うまでのリミットは、8:17　果たして動き出すかどうか？
【10:00】平塚駅
　　　　開始時刻を過ぎるが、まだ停止中。
　　　　果たしてどうなっているのか？
　－電池が切れた．．．

【13:30】無事到着（午前の部は終了）

14:00-14:50　招待講演「ソフトウェア保守の実態調査結果」
(財)経済調査会　高橋　昭彦　氏
１．当会のご紹介
　　－省略
２．平成２０年度ソフトウェア保守に関する調査の概要
　●調査機関
　　平成２１年２月～３月
　●調査票の構成と概要
　　調査票I：調査先組織の概要とソフトウェア保守の考え方などに関する調査
　　調査票Ⅱ：調査先組織（部門）におけるソフトウェア保守の代表的な個別事例に関する調査
　●調査票配布状況
　　配布社数：３８８３社
　　調査票回収状況：１７３社
３．ソフトウェア保守に関する調査結果のクロス集計
３．１　分類項目「調査票　ソフトウェア保守プロセスの標準化
　●ＳＬＡ：プロセス標準化しているグループは、そうでないグループにくらべてＳＡＬの導入が高い
　●ドキュメント：標準化済（新たにドキュメント作成が多い）、未標準化（開発時のドキュメントを流用）
　●体制：標準化済（開発と兼任）、未標準化（運用と兼任）
　●費用の算出方法：標準化済（昨年度実績と比較）、未標準化（受注者の見積り）
　●工程別工数：標準化済、未標準化あまり差がない（ふたこぶらくだと若干違いあり）
　●母体規模：標準化済（大）、未標準化（小）
　●実施規模：標準化済（大）、未標準化（小）
　●技術者単価：標準化済（大）、未標準化（小）
　●受注者側の作業工数：標準化済（大）、未標準化（小）
　●受注者の料金：標準化済（ばらつき小）、未標準化（ばらつき大）
　●年間ソフトウェア保守費用：標準化済（ばらつき大）、未標準化（ばらつき小）
　●工数比率（調査・分析）：ほぼ同じ
　●工数比率（設計）：標準化済（ばらつき大）、未標準化（ばらつき小）
　●工数比率（製造または修正）：標準化済（ばらつき大）、未標準化（ばらつき小）
　●工数比率（テスト）：ほぼ同じ
　●工数比率（移行）：標準化済（ばらつき小）、未標準化（ばらつき大）
３．２「ソフトウェア保守用ドキュメント」
　●ＳＬＡの導入状況：保守ドキュメントを新たに作成するところが、ＳＬＡを締結する割合が多い
　●作業体制：開発時のドキュメントを使うグループが専任が多い
　●工程別工数比率：ほぼ同じ
　●ソフトウェア保守費用の算出方法：新たに保守ドキュメントを作るとことが前年度参考が多い
　●ソフトウェアの母体規模：設計ドキュメント流用が多い
　●実施修正規模：新規保守ドキュメント作成が大きい
　●技術者単価：ほぼ同じ
　●受託者側の作業工数：新規保守ドキュメントが大きい
　●技術者単価：ほぼ同じ（開発時のドキュメントの技術者単価のばらつきが大きい）
　●実績ベースのソフトウェア保守工数：ほぼ同じ
　●工数比率「調査分析」：新規保守ドキュメントが若干少ない
　＜以下略＞

４．今後の課題
　●調査票の設計について
　　・ソフトウェア保守に関する調査項目の検討
　　・ソフトウェア開発やシステム運用に関する調査項目との相関検討
　●調査票の配布先について
　　・調査配布先の絞込みの検討
　　・ソフトウェア保守業務受託者に対する調査の検討
　●調査結果の分析
　　・複数年度に跨る調査結果の分析を検討
　　・調査結果や分析結果の公表の方法を検討
　●調査と分析体制について
　　・ソフトウェア・メインテナンス研究会と連携
　　・奈良先端技術大学院大学との連携
　　・経済産業省「ソフトウェアメトリックス高度化検討委員会」との連携
Ｑ．「システム運用とソフトウェア保守の兼務」が分からない
Ａ．システム運用にヘルプデスク、オペレーションを含まないとした場合に分からない
Ｑ．標準化されているところ、「プログラム・システム運用」が多い、仮説があるのか？
Ａ．標準化されているとことは、規模が大きいという仮説。
Ｑ．保守ドキュメントを新規に作成し、開発ドキュメントを使わないということはないのか？
Ａ．開発ドキュメントが全くだめで、作り直しの場合。
Ｑ．ふたこぶらくだと違う理由はあるのか？
Ａ．X0161に沿っていないので、工程のくくりが違うせいではないか？
　　時代が違ってきているのではないか？
　　ふたこぶらくだの根拠がないのではないか？
Ｏ．厳密に区分できてないのではないか？
Ｏ．アンケートの質問が悪い。
　　開発担当者が兼任していることも考えられる。
Ｑ．印象に残った結果
Ａ．・ふたこぶらくだ
　　・標準化しているほうが契約単価が低い
Ｑ．成功・不成功はとれないか、それにより工程配分が違うのではないか
Ａ．プロジェクト毎にとれるので、問うことはできる。

14:50-15:50　SERC各グループの活動報告および次年度の活動計画　その１
●Dグループ　「SERCの考える保守とは」増井　和也　氏
　１．グループのミッションと活動方針
　　・ミッション（再確認）
　　　→当研究会活動の広報・ＰＲ
　　　→ソフトウェア保守研究の体系化
　　・活動方針（例年通り）
　　　→各メンバーの経験と個人の考えを尊重し活動
　　　→各メンバの多様な活動パワーを前提に活動
　　　→幹事会、他グループの意見、研究成果のとりこみ
　　　→複数活動テーマを主査の下に平行実施
　　　→活動テーマは、最終的に主査がまとめる

　２．本年度の主要活動項目とスケジュール
　　・主要活動テーマ
　　　→保守者のモチベーション向上要素
　　　→ISO/IEC　14764（JIS　X0161>の啓蒙・広報
　　　→ソフトウェア保守の経済
　　・活動スケジュール
　　　→月例作業部会
　　　→広報活動（フォーラム）
　　　→報告書の作成
　　　→合宿研究会

　３．次年度活動計画（概要）
　　・「ソフトウェア保守プロセスの成熟度」に関する研究
　　・「保守者のモチベーション向上要素」に関する研究（継続）
　　・「ソフトウェア保守の経済」に関する研究（継続）
Ｏ．ＩＳＯ／ＪＩＳはソフトウェア開発ベンダー向けのものではないか（業務系がない）
Ａ．まだ使われていないので、今後の検討
Ｏ．保守開発者のマニュフェストなどにまとめてはどうか
Ａ．はい。
Ｏ．マネジメントを加えて欲しい
Ａ．はい。
Ｏ．成熟度もがんばって欲しい。
Ｏ．ビジネスモデルの提案のできる技術者が必要であろう。

Ｃグループ　「保守のアウトソーシングを考える」　　　田中　創　氏
　モチベーションを上げるためのＳＬＡを定義した
　次年度は、ＳＬＡと原価低減

16:10-17:10　SERC各グループの活動報告および次年度の活動計画　その２
Ｂグループ　「保守作業改善の基盤技術調査」　　　　　石川　雅彦　
　１．ソフトウェア保守に関する共同調査
　　　経済調査会　高橋氏発表参照

　２．保守作業改善の基盤技術調査
　　２．１　ソフトウェア保守性を評価する目トリックス手法
　　　・内容
　　　　（１）欠陥混入と除去に関する開発プロセスのアクティビティ分析
　　　　（２）開発プロセスの各段階における欠陥の混入と除去のメカニズム
　　　　（３）欠陥データマトリクス（発見時点と欠陥発生源）
　　　・インスペクションによる指摘事項がから欠陥する（インスペクション、テスティング）の効率計算の自動取得
　　　・今後の課題
　　　　－オブジェクト指向開発における欠陥発生早期予測手法の適用方法
　　　　－テスト労働依存型ソフト信頼性成長モデル
　　　　－影響波及解析利用の保守作業見積りに役立てる提示手法
　　２．２　ツールの評価
　　　（１）CCFinder
　　２．３　ソフトウェア保守の研究動向調査
　　　（１）Mints論文要約
　　　　　　テストケースに余分なものを取り除く
　　　（２）ICSM
　　３．今後の活動
　　　（１）方針
　　　　　－ソフトウェア保守の外部動向を考慮した活動
　　　　　－ソフトウェア保守の研究動向を考慮した活動
　　　　　－使える基盤技術の模索
　　　　　－情報の集約と公開
　　　（２）検討項目
　　　　　－保守改善の儀儒

Ｑ．ソフトウェア保守性とここの（インスペクション）と合っているか
Ａ．「ソフトウェア保守性」と違う。
Ｑ．インスペクションから残バグの予測にインスペクションの精度は気にしているか
Ａ．過去のデータの積み重ねより精度を確保してから予測する

Ａグループ　「保守用ドキュメントとは」　　　　　　　福島　茂雄　氏
　●メインテーマ
　　予定：ドキュメント研究
　　　　　→大規模調査のためのアンケート作り
　　実績：ドキュメント研究
　　　　　→困っている場面を抽出し対策を検討
　●サブテーマ
　　予定：各自テーマを決めて実施
　　実績：一部のみ実施
　　※メインテーマで、困っている場面を話し合っているのでフラストレーションが解消された
　●案件の打診と把握
　　・困っていること
　　　→計画外の”突発的な変更要求”で、急ぎの回答を求められる。
　　　→短時間で要件を正確に把握しなければならない。
　　・検討と対策、必要な文書
　　　→必要な文書は要求文書であるが、文書がｋで必要な情報をすべて表現するのは難しい。
　　　→電話やメールだけでなく、対面での打ち合わせ機会も必要
　　　→フォーマットやプロセスをあらかじめ定義
　●障害対応における課題と対策
　　・困っていること
　　　→調査が長引くといそがせられる
　　・検討と対策
　　　→稼動再開優先
　　　→事例ごとに顧客と話し合っておく
　●見積り精度向上

Ｑ．見積り精度の向上とは（プロジェクト管理に失敗した時はどう考えるか）
Ａ．計画変更も含む。
Ｏ．見積りの精度と言う言葉はよくないのではないか？
　　当たる当たらないでなない。（全員で合議すること）
Ｏ．保守固有の見積りの方法や手段の提示
Ａ．「見積り精度」では、「見積りの条件の合意」だろう。
Ｑ．いつごろ施策がでくるのか？
Ａ．アドホックにやっている。素早く結論をだしたい。

17:10-17:20　ソフトウェアメインテナンス研究会について
　　　　　　　代表幹事　岸田　孝一　氏
SERC　１９年

2009/11/26-28　KickOff合宿 in 米子

４つの研究グループ（増えるかもしれない・再編成）

会費
・法人　　１５万（５名まで研究員）
・個人　　　５万
・シルバー　２万
・学生　　　２万

－以後情報交換会－

職場外教育の効果

2009-10-06T08:24:00.003+09:00

先日のRE2009で筑波大の中谷先生が社会人職場から大学へ受け入れて教育を行った場合、「終了直後は今日聞く効果がでるが、1ヶ月後のフォローアップでは元の木阿弥に戻ってしまう。」ということを仰っていた。

それを聞いて、以前聞いた救急医療教育の池上先生の話を思い出した。

職場から少数の人が、教育をうけにきて新しい知識や方法を学んで現場にもどってっても、今までのやり方をする人が多数派を占める。そこで、意図しない再教育が行われてしまう。特にリーダのやり方と違うと、それが顕著である。

そのため、現場全員が新しい手法を学ぶ必要がある。とのこと。

新しい知識や手法の教育は、全員は無理でも「リーダ＋若手」の組み合わせのような、リーダを中心に行う必要があると考える。

アンケート依頼

2009-10-04T00:06:00.002+09:00

昨日の要求工学シンポジュウムで、筑波大の中谷先生よりアンケートの依頼があったので紹介します。

対象は、ソフトウェアの「要件定義」を担当する技術者（要求技術者）とのこと。

今後の要求技術者育成によるソフトウェア業界発展のためにご協力お願いします。

詳細は、要求技術者のテクニカルスキルに関する調査を参照ください。

※調査票には６０分程度となっていますが、１０分程度でできるそうです。

JISA要求工学シンポジウム2009　受講録

2009-10-02T12:50:00.007+09:00

JISA要求工学シンポジウム2009
～要求開発を担う人材のための知識体系化とベストプラクティスの調査研究

「JISAでは平成18年度より3年間にわたり、技術委員会・要求工学WGを設置し、要求工学の実践的な調査研究を　実施して参りました。今年度は3年間の活動成果のご報告と、平成20年度特に重点を置いて調査した顧客視点　での事例及び要求プロセス人材のための知識体系をご紹介いたします。」（案内の一部）

1．日時：2009年10月2日(金) 13：00～17：20
2．場所：東京ステーションコンファレンス　「503会議室」
東京都千代田区丸の内1-7-12サピアタワー5階　TEL:03-6888-8080
3．主　催：(社)情報サービス産業協会

シンポジウム・プログラム
日時講演タイトル講演者
13:00 開会司会　鈴木律郎（情報サービス産業協会）
13:05～14:05 要求開発を担う人材のための知識体系化とベストプラクティス(調査研究報告) 青山　幹雄　（南山大学）
14:10～15:00 IT業界の過去の功罪から学ぶ
～全社システム再構築、或いはERP導入における過去の功罪から学ぶ尾木　巧永　（伊藤忠テクノソリューションズ）
15:00～15:20 休憩
15:20～16:10 システムノウハウの見える化について八木橋　英男（日本証券テクノロジー）
16:15～17:05 要求プロセスを担う技術者教育中谷　多哉子（筑波大学）
17:05～17:10 クロージング青山　幹雄　（南山大学）
－－－－－－－－－－－－－－－－－－－－－－

13:05～14:05 要求開発を担う人材のための知識体系化とベストプラクティス(調査研究報告) 青山　幹雄　（南山大学）
●概要
　・活動目的：現場における要求工学の活用推進
　・２００８年度活動内容
　　→要求工学知識体系（REBOK：Requierments　Engineering　Body　Of　Konwoledge)[リーボック]の枠組み作り
　　　－ユーザとベンダが共に利用できる知識の整理、体系化
　　→アナリストだけでなく、エンドユーザ、経営者、PMにも役に立つ
　・これまでの活動内容
　　→ベンダおける要求開発事例集
●要求工学実践の課題－要求工学の位置づけと課題
　・要求：ベンダとユーザの不幸な関係の始まり
　・付加価値の源泉×失敗の最大の原因

●要求工学実践の課題－要求定義がシステム品質に及ぼす影響
　・要求定義が品質へ最大の影響：向上とリスクの両面

●要求工学実践の課題　要求工学実践の課題
　・要求工学に内在する難しさ
　　→技術：要求知識工学、ドメイン知識
　　→スキル：コミュニケーション
　　→取り巻く環境：多様なステークホルダ、マネジメント、ビジネス環境
　・要求工学の人材不足、ステークホルダ参画の妨げ
　・現場で要求工学を貸すようできる知識体系

●要求工学実践の課題
　・ソフトウェア工学知識体系（SWRBOK）－要求の部分は浅い
　・BABOK（IIBA)－高度
　・CPRE
　・IRBE－初心者
　・ITSS－中、高度

●SWEBOKの要求部分

●BABOK　V.2.0
　・要求獲得
　・エンタープライズ分析
　・要求分析
　・妥当性の確認
　・ビジネス分析の計画とモニタリング
　・要求管理とコミュニケーション

●REBOKの目標
　・人材像
　・ドメイン
　・知識体系
　・記述内容
　・レベル
　・認定

●REBOKのアプローチ
　・要求工学の多様性と利用のスケープ

●要求に関わるステークホルダに必要な知識の体系
　・要求アナリスト：ユーザの要求開発者、ベンダーの情報システム部門
　・要求の利用者：エンドユーザ、ＰＭ
　・要求工学の理解者：経営者、CIPなど

●要求のスコープを要求アナリストの役割
　・要求の３つのスコープ
　　→ビジネス／製品、（情報）システム、ソフトウェア
　・要求アナリストの役割
　　→ビジネスアナリスト、システムアナリスト、ソフトウェアアナリスト

●要求工学の知識体系モデル
　・知識要素：要求開発と管理、ドメイン知識、ヒューマンスキル

●REBOKのREBGOKの５原則
　・REBOKを作るための方針　

●REBOKの知識体系
　・SWEBOKを基礎に、要求工学の内容を強化した知識体系
　・実践の考慮点：要求工学ベストプラクティスで補完（主に管理系）
　・主要８知識
　　→基礎、プロセス、獲得、分析、仕様化、検査評価
　・計画と管理
　・考慮点
　※NTTデータのMOYAの例

●REBOKの知識体系の考慮点
　・要求工学ベストプラクティス：３５件
　・実践事例巣：約２０件

●ベストプラクティスの構造
　問題→解決→事例

●ベストプラクティスの記述例

●役割と知識レベル
　＜レベル＞
　　１．意味を知っている
　　２．内容を理解している
　　３．内容を他者に説明できる、利用できる
　　４．それを用いて、分析などを行える。
　　５．複雑な問題に対して適切な方法の選択と遂行、指導ができる。
●今後の課題
　・要求工学知識体系REBOKの詳細化とレビュー
　　→フレームワーク、知識要素、知識レベルの妥当性
　　→知識要素の具体化とレビュー
　・ＲＥＢＯＫに基づく人材育成ガイドラインの策定
　　→著式要素の学習ガイドライン
　　→ベストプラクティス、事例集の整理
　・要求工学普及の推進

Ｑ．要求（問題とソリューション）なので、分析はないのか？
Ａ．要求分析相当すがわかる。
　　・問題が何かがわからない。（難しさ）
　　・そのご分析する。
　　・文書化

Ｑ，ＲＥＢＯＫとＢＡＢＯＫとの関係
Ａ．ＢＡＢＯＫはは現行の知識体系の一つで特に関係あるわけではない。
　　現場で何が必要で、それが現行のどの知識体系見ればよいかを整理するのが目的

Ｑ．ユーザに受け入れられるか
　　ビジネスとして独立してなりたつか
Ａ．ＢＡＢＯＫは、関係者全員の役割を明確にした。現在の日本は難しい。
　　現在直ぐにビジネスに直結するかというと難しい。
　　長い目でみたときの付加価値の源泉になる。そのため人材育成が必要。そのための知識の整理。

Ｑ．「システム要求」「ソフトウェア要求」を分けている理由はなぜか
　　体系はどこまで細分化されるか
Ａ．「システム要求」「ソフトウェア要求」役割による（例えばＩＴ部門とベンダー）。しかし、クリアーに分かれるわけではない。
　　当面は知識要素の整理、テンプレートはそれぞれの企業のノウハウが詰まっていないと使えないので、一般的なところを目指している。

14:10～15:00 IT業界の過去の功罪から学ぶ
～全社システム再構築、或いはERP導入における過去の功罪から学ぶ尾木　巧永　（伊藤忠テクノソリューションズ）
＜前置き＞
●要求工学を強化しないと、海外のベンダーに負ける

●ソフトウェア業界は次の２点からの脱却が必要
　あいまいからの脱却
　我流からの脱却（問題があったときに、どこに戻ってよいかわからない）

●全てを知らなくてもテンプレートで作れるようになっている。→逆にＳＥをだめにしている。

１．過去の功罪から学ぶ
●失敗のメカニズム（失敗とは、顧客満足度が下が、システムが動かない）
　・曖昧な状況から開始
　・役割分担がかけない
　・異なる企業文化で歩調も合わない
　・形式的なレビューの繰り返し
　・意思決定／判断の基準も材料もない
●プロジェクトの成功要因
　・正確な状況把握（可視化）
　　→状況把握
　　→可視化
　・プロジェクト運営の確立(PDCAサイクルの形成)
　　→PDCAサイクル形成（特に意思決定）
　　→優先順位付け
　　　プロジェクトマネジメント幻想からの脱却（PMBOKだけやったら管理だおれになる。現場にあわせたやり方が必要。）
　　→コミュニケーションの環境
　・ベンダーからのバックアップ体制
　　→支援環境
　　　（顧客の後ろ向きな言葉をさえぎる。その時間を前向きな議論につかうように仕向ける）
　　→ベンダー・プロジェクトマネージャ、メンバーへのカウンセリング
●過去の功罪から学ぶⅡ
　・前者システムのコンセプト・EPRパッケージのコンセプトの伝播不足
　　経営哲学の徹底不備
　・トップダウンによる導入方法が結果的に”現場ありき”の進め方に
　　トップ方針の頓挫
　・経営戦略とIT構想／システム化の非同期
　　ROIの追求
　・安直な導入プロセスによる、全体最適化の頓挫（ものを見てしまうとユーザ現場の意見が強くなる）
　・ベンダーのSE能力の低下
　　SEの能力の低下
●過去の功罪から学ぶⅢ
　・待ちの姿勢　　　：言われたことには対応するが、言われたことにはしない
　・気に入られたい　：お客様は神様　
　・御用聞き　　　　：提案することはせず、常に御用聞きの姿勢
　・私作る人　　　　：システム機能中心で、事業貢献するか否かは関与しない
　・危機意識の欠如　：納期遅れ、品質
　・機能中心
　・SEのご都合
　・人依存の体質
　・おたくの集団

●参考：失敗のシナリオ
　・曖昧な取り決め
　・期待一杯
　・判断基準不明
　・大雑把
　・ベンダー任せ
　・べき論で開始：（本当にそうなの）
　・人任せ　　　
　・経営との断絶
　・命令指示不在
　・俗人的なながれ

●開発終了後の顧客の言葉　「高い勉強代につきました」
　　・顧客側とベンダーの役割分担
　　・経営者の役割がわかった
　　・BPRとシステムは両輪（顧客、コンサル、ベンダーの

●教訓：「見積りをするところ」で顧客への説明が必要
　　・どこが概算で、どこが正式かをはっきりさせ、意思決定が遅れるとコストが増大することを顧客に説明する
　　･どういう手順でやるかを説明（教育）する
２．ＲＯＩを最大化させるべきポイント
●重要論点・ポイント（討論・インタビュー）の抽出と合意形成
　・テーマとゴール
　・情報収集
　・IT活用の視点
　・Pjt.の俯瞰／相関
　・推進上の論点
　※情報システム部門の人材と技術のたな卸しをしてもらう

●短期構築のための規格構想
　・なぜ故再構築が必要か
　・思い付きの発想や声の大きい人に注意
　・プロジェクト全体の俯瞰

●施策のブレークダウン（導入効果の分析・評価・予測）
　売り上げ拡大<-->経費最適化

●経営の可視化と業務改革システム構築の全体
　・ベンダーがやること・コンサルがやること、自社でやるべきことを明確にする。
　・ライフサイクルを念頭におく考える

●RIOを最適化する手順

３．短期構築・ＥＰＲ導入にあたり
　・経営との融合
　・ITライフサイクル
　・自社の事業構造
　・可視化
　・ゴール
　・利害関係
　・雛形／参考
　・パートナー選定
　・ROI評価
　・改革力の維持

●初期段階で両者が共有。確認すべき内容（原理・原則）
　※プロジェクトは必ずトラぶるもの。トラぶったときどこに戻るか？

●まとめ１プロジェクト成功の”べからず”集
　・自社に使えるか否かの内容に終始して議論するな
　・ROIを追求・評価しないまま現場中心の「ユーザはお客様・神様」の思考でどうするな。
　　※しかし、顧客の立場も考える
　・全ての問題を拾うやり方をするな！正しい・解決すべき問題を拾う
　　全ての問題を拾っても、解決すべき問題・課題を判断するのは難しい。

●まとめ２プロジェクト成功のポイント
　・企画の段階
　・ＢＰＲ優先か、構築、ERP導入優先か
　　→成果物と役割分担を明確にする。
　・ROIの向上
　　→優先順位をどうやって決めるかを明確にしておく

●まとめ３大型SI案件　成功の極意
　・どこで、なにがきめられるのかを知る
　・TOPの役割の自覚予算・チーム作りに関与
　・パートナーシップの重要性の認識

Ｑ．若手ＳＥの育成（レベルアップ）をどうするか
Ａ．現在苦労している。
　　・大きな案件を自分でとりにいかせる（ＯＪＴ）：成功
　　・体系的な教育をしていないので、後継者が育たない。
　　　→要求工学は覚えようとしない。体系をＩＮＰＵＴし、現在のやり方と比較させる

Ｑ、顧客側に関与するのはどうするばよいか
Ａ、ＳＥと顧客役員と連携する
　　・狙って一緒にトイレにいく。困っていることがあるので、３分ほしいと言えば、１００％ＯＫ
　　・熱い話がしたいと思わせる

Ｑ、役に立つＰＭＯを作る秘訣。（管理のみでない）
Ａ、問題のあるプロジェクトを役員に説明する。
　　火事はかならずおきる。小火でとどめるために、ＰＭＯが必要であることを幹部・顧客を説得する。

15:20～16:10 システムノウハウの見える化について八木橋　英男（日本証券テクノロジー）
　システムの改修と機能拡張が中心

●「システムノウハウの見える化」検討経緯
　・検討のきっかけ
　　→基盤システム大規模開発終了後の、確実なるノウハウ引継ぎが重要
　　　　ノウハウ継承物件の明確化
　　　　担当領域別のノウハウ保持者の見える化（だれがどのようなものを持っているか）
　・検討タスクの立ち上げ
　　→検討期間：２００７年５月～８月
　　→検討体制：各本部・部より１～２名参画（計：１４名）
　　→運用開始：２００７年９月基準から

　
●ノウハウ継承物件の見える化
　・課題　ノウハウ継承物件の明確化
　・対策　システム資産管理台帳の作成
　　→システム資産管理台帳の構成
　　　　文書
　　　　プログラム
　　　　シエル
　　　　その他
　　→システム資産管理台帳の報告サイクル
　　　　期毎
　　→実物紹介
　　　　システム資産管理台帳
　　　　システム資産管理台帳報告書
　　　　システム資産管理台帳報告書グラフ

●担当領域把握の見える化
　課題　担当者別のノウハウ保持者の把握
　対策　ノウハウマップの作成
　　・ノウハウマップの構成
　　　　アプリケーションノウハウマップ
　　　　システム技術ノウハウマップ
　　・ノウハウマップの報告サイクル
　　・ノウハウマップの運用
　　　　原本：　人事部提出
　　　　報告書：PMO提出

●アプリケーションノウハウ把握の見える化
　・ノウハウマップ（アプリケーション系）：アプリケーションノウハウ保持者把握
　　→ノウハウ種類：要件定義・システム設計
　　→ノウハウ把握単位：システム・業務区分・小分類
　　→ノウハウレベル：　５段階で設定（レベル３以上が望ましい）
　　→ノウハウ対象者：社員
　　　　　　　　　　　協力会社要員（リーダクラスと合議、価格評価にはしようしない）
　　→ノウハウ評価者：社員については本人深刻、マネージャ評価

　　※トップがいなくなったときのために、２番目でも見られるようにしている。

●システム技術ノウハウ把握の見える化
　・ノウハウマップ（システム技術）：技術項目別のノウハウ保持者の把握
　　→ノウハウの種類
　　　　環境技術・・・システム環境構築技術
　　　　運用技術・・・システム運用技術
　　　　利用技術・・・システム開発技術
　　→ノウハウ把握単位：大・中・小分類技術
　　→ノウハウレベル：５段階で定義（レベル３以上がのぞましい）
　　→ノウハウ対象者：社員
　　→ノウハウ評価者：社員については本人深刻、マネージャ評価
　・資格対応
　　　→職能資格とプロフェショナル資格の二本立て
　　　→ITSSのスキルレベル定義ち対応づけ
　　　　ITSSスキルレベル←対応→当社の職能資格階層・クラス←対応→プロフェッショナル認定資格

●QMS・ISMS・ITMSに於ける位置づけ
　・技術スキル・業務知識環境プロセス
　　→業務別ノウハウ：ノウハウマップ（アプリ系）
　　→技術スキル別ノウハウ：ノウハウマップ（システム技術）
　・教育管理プロセス
　　→技術レベル診断
　　　　ノウハウマップ
　　　　ＩＴスキル診断
　　↓
　「ノウハウマップ」は社員の知識やスキルの育成が第一義

●「システムノウハウの見える化」効果
　・ノウハウマップのレベル向上
　　→重要な分野でレベルが低い領域のノウハウレベル向上運動
　　→ナンバー２のノウハウ維持要員の育成（ノウハウの重層化）
　　→協力会社要員に依存している領域の社内要員育成
　　→ノウハウレベル向上計画と、社内・社外研修計画（２、８月）の連動
　・戦略要員異動
　　→ノウハウレベルのシュミレーションに基づく要員異動に立案
　・システム規模変動とノウハウ維持要員との妥当性確認
　　→システム規模の変動（増大）に対する適正要員数の確保
Ｑ．これがあると、人員削減に対応できるのか
Ａ．人員削減の影響がみやすい

●「システムノウハウの見えるか」今後の課題
　・ドキュメントの整備
　　→業務ノウハウの要点整理（維持工数とのトレードオフ）
　　→システム全体把握ドキュメントの整備
　　　（データフロー）
　・ノウハウ把握対象部分の拡大
　　→管理部門のノウハウ拡大
　・要件定義書の様式見直し
　　→要求と仕様のペア記述化
　　→要求の階層記述化－「要求階層＝ノウハウマップ（アプリ系）のノウハウ把握単位」
　・プロジェクト別チーム体制のノウハウ充足度チェック
　　→プロジェクト別のチーム体制に連動したノウハウ状況のチェック

16:15～17:05 要求プロセスを担う技術者教育中谷　多哉子（筑波大学）
●背景
　・要求仕様書がステークホルダの「必要」とは独立に作成される現実
　・あるプロマネの独り言
　　→技術者は、ぶ厚い要求仕様書をつくるのですが
　　→お客さんの要求をきいとも、聞かなくても、同じ厚さの仕様書を作ることができてしまうのです。
　　→作られた仕様書をみただけでは、お客さんにちゃんと話を聞いて作成されたものなのか、そうでないものかわかりません。
　　これではソフトウェア開発失敗要員の乗員に「要求獲得の失敗」が挙げられも無理はない

●教育者のターゲット＝プロの技術者

●教育の目的
　「要求の根拠をえる」ことの重要性に気づけるようになること
　→要求には根拠がなければならない。
　→システムは、真の問題を解決できなければならない
　→根拠のないシステムへの要求は、無意味な要求変更を誘発させる危険がある

●教育コースの設計
　・教育スタイルの選定
　　→座額、例題演習、討論、ロールプレイング・ゲーム
　・手法の選定
　・プロセス
　　→３日以内（※現場を４日以上離れられない）
　　→必須：要求仕様書の作成

●教育コースのゴール
　要求の合理性とは？（What,Why,How）
　・そもそも要求とは何かを考えること
　・根拠のない要求の危険性を理解すること
　・根拠をえるための手段を学ぶこと
　・手段教育の方針
　　→手段を習得することを目標とするよりも、手段が存在することを知ってもらうことを目的とする。
　　→なぜならば、技術者は「必要」であることが分かれば自ら学ぶ時間を割き、取得することができる。
　　　（はず）

●要求プロセス

●教育スタイルの選定
　・基本型＝座額
　　→要求工学導入
　　→企業内研修
　　→大学学部教育
　・ゲーム
　・ロールプレイングゲーム
　　→顧客を経験することによって顧客の気持ちを理解する
　・例題演習型
　・自己評価型
　・ワークショップ型

●選択した教育スタイル
　・基本的な知識の習得→座額
　　→要求工学入門
　　→要求仕様の品質
　　→ソフトウェア開発における要求変更の実態
　・顧客の心を理解する→ロールプレイング
　・知見の共有→ワークショップ
　・要求仕様書の作成→研究成果の最終演習

●ワークショップの例

●手法の選択
　・要求工学技術マップ
　・各事象の特徴と教育の焦点
　・RODANのメタモデル
　・教育に選択した手法
→お客さんがどういう世界を望んでいるかを理解し、要求に落とし込むことができるようになる。

●プロセスの決定
　・第一段階：ステークホルダを取り巻く世界を理解する
　　第二段階：要求抽出
　　第三段階：要求の定義
　・L1：インタビュー→L2：役割依存分析（ステークホルダの立場、背景を可視化）→L3：CATWOE分析（各ステークホルダの世界観、価値観を可視化）
　・L４：所有者別ゴール分析→L5：交渉→L6：シナリオ分析、クレーム分析→L7：ユースケース分析、ミスユースケース分析

　※説明をする場合、相手の顔色が分かる場所に立たないことが多い。

●成果
　・受講後：要求の根拠の受容性に気づいた（成果あり）I
　・1ヵ月後：元の木阿弥（原因不明）

Ｑ．技術者以外の人が受けることは可能か？
Ａ．チームの中に者がいたほうがよい。

第64回 SEA-SPIN Meeting 　聴講録

2009-09-29T18:17:00.006+09:00

------------------------------------------------------------------------
　　　　第64回 SEA-SPIN Meeting (September 29, Tuesday, 2009)
　　　　　　　　　　　EuroSPI 2009 参加報告
　　　　　　　　　　　　　　参加者募集
　　　　　　　　主催: SEA プロセス分科会（SEA-SPIN）
　　　　　------------------------------------------------

　今月の話題は 9月2～4日にスペインのアルカラで開催された EuroSPI 2009
　の参加報告です．報告者は，会議初日に Software Process Optimization
　(SPO) のチュートリアルを行い、引き続いて SPI Mqanifest Day のワーク
　ショップにも参加された岸田孝一さんと伊藤昌夫さんのお２人です．

*****************開催要領*****************

1. 日時： 2009年 9月 29日(火) 18:30 ～ 20:30
2. 会場：（株）日立システムアンドサービス本社
　　　　　　　　　　　 20F　コンファレンスホールＤ
3. プログラム：コーディネータ　田中一夫
18:00 - 18:30 受付及びネットワーキング
18:30 - 19:45 EuroSPI 参加報告
　　　　　　　　　　岸田孝一（SRA-KTL)
　　　伊藤昌夫（Nil Software) ほか
　 19:45 - 20:00 休憩
20:00 - 20:30 質疑・意見交換
20:30 - 20:45 クロージング(次回予告、及び後片付け等)

EuroSPI 2009についてはこちらを参照ください。
------------------------------------------------------------------------
18:00 - 18:30 受付及びネットワーキング
18:30 - 19:45 EuroSPI 参加報告
●岸田氏
　EuroSPI Infomation
・EuroSPI　Main　Page:
　　　http://www.eurospi.net/
　　－Initiative
　　－Conference
　　－Publication
　　－Experience　Library　目だった論文がある
　　　　・Login　Name　＆　Password（表示されているものを使える）
　　－ECQA（e-Laerningで教育と資格がとれる）
　わたしとEuroSPI
　・2006春にブタペストのフォン・ノイマン協会で講演したのがきっかけ
　・その年の秋、フィンランドでの会議で基調後援者として招かれた
　・以後、２００７（ドイツ）、２００８（アイルランド）、そして今年（スペイン）と４年連続して参加
　全体の印象
　・参加者の規模は１００人をやや超える程度（われわれのSSと同程度）※SEAのSS
　・プログラム構成は産学ミックス（産業界の経験報告のほうが多い）
　・ただし、経験報告のほとんどは産学協同（補助金をもら条件：マルチナショナル、産学協同）
　・欧州が中心だが、南北アメリカ、中近東も含めて国際色豊か（フランスはあまり来ていない。東欧等多い）
　・SPIに限定せず、ソフトウェア技術＆ビジネス全般を話題にしている
　・言語は英語だがNon-Native　Speakerが多い
　・Tutorialの運営方法がユニーク（大勢の聴衆を集めて受講料を稼ぐのではなく、少数のワークショップ形式）
　・通常のプログラムの他に新しい試みが去年から始まった：
　　－Euro　Certificate　Day　（去年と今年）：資格の紹介（この資格をとってこう良くなった）
　　－SPI　Mainfest　Track（今年）
　２００６　in　Joensuu
　・日本からの参加は岸田氏１人
　・Off-Shore開発については　Ita　RichardsonさんのTutorialが面白かった
　　－オフショアに成功して賃金があがったので、オフショアをうけられなくなった。
　　　そのごどうするか？
　　　→その一環：オフショアの受け方のセミナー
　・AgileについてのPekka　AbrahammsonさんのKeynoteはよくまとまっていた
　・町外れの農場で行われたSocial　EventでのCarol　DekkersさんのSpeechもよかった
　２００７　in　Postdam
　・Conquest200と同時開催
　・日本からの参加は岸田氏＋小島氏（SRA）
　・Conquestには岡崎さん（IBM)
　・Soft技術者のMotivationについてのNathan　BaddooさんのTutorialは学ぶことが多かった。
　　Motivationの調査
　・Kati　Vilkkiさん、ta　RichardsonさんのKeynoteが良かった。
　　前者はAgile　Methodの世界展開（ノキアの成功例）
　　後者はアイルランド
　　（自動車と医療に集中）
　２００８年　in　Dublin
　・日本からの参加は岸田氏＋静永氏（SRA)
　・Tutorialと並列して行われた　Euro　Cetificate　Dayに参加
　　Mikros　Biroさん　クロアチアがEuroに参加するためにEuro　Cetificateを取得するとのこと
　・アイルランドのソフトウェア工学センター（Lero)所長
　　（月並み）
　・第３Keynote

　２００９　in　Alcala
　・日本からの参加は岸田氏＋伊藤氏＋小嶋氏（SRA)＋片平氏＆宮本氏（JAXA)
　・岸田氏＋伊藤氏のTutorialは成功
　・SPI　Manifest　Dayのワークショップに参加（ワークショップでは宿題がでて、１１月にリリースされる予定）
　・来年の会場はグルノーブル（フランス）８月末から９月はじめ

●伊藤氏
　概要は岸田氏が先にはなした。
　会場は世界遺産（歴史のあるまち）
　街
　　・セルバンテスの家訪問（歴史と文学の街）
　　・世界文学中もっとも偉大と同時ににもっともカーニバル的小説
　会議
　　・穏やかな参加者
　　・落ち着く規模
　興味をもった話題
　　・安全性を重視するシステムと認証
　　　－（原発の）安全性という目標に対する特別な要求
　　　　規格にしたがってレベルが高ければ安全といえるのか？
　　・ユーザビリティの位置づけ調査
　　　ＳＭＥでのＷＥＢ開発におけるユーザビリティ（ＳＭＥ：中小企業）
　　　使用時品質にどう向き合うか
　　　→試行錯誤の世界になりやすい
　　　→ユーザ（エンドユーザ）を巻き込むことが必要（現行のプロセスが適用できない）
　　・ソフトウェア　プロセスライン
　　　ＳＰＥＭの拡張、ＶＰとＶ（変異）の設定（ＶＰ：Valiation　Point、V:Variant
　　　実務、ツール、実行時の動的変更
　　　→対象に合わせたプロセスモデルがつくりやすい
　　　→ツール化できる
　　　→要求が変わったときに、プロセスを動的に変更できるしくみがつくれるか

　　　Ｑ．プロセスに対してツールとはなにか？
　　　Ａ．昔の統合プロセス支援環境（ツール側がプロセスを提示）
　　まとめ
　　・全体としては、認証や規格の話題が多い
　　・しかし、おそらく心情は違う
　　　→「ＳＰＩのためのＳＰＩの議論」ではない
　　　→分別くささや教条主義とは無縁
　　　（自分たちの抱えている問題を素直に述べている。リアルな世界をプロセス視点で考えている）
　　　→カーニバル的・ポリフォニー的

　　※日本のプロセスの議論も昔はこうだったが、今は一寸疑問（教条主義的なものがみられる）。

●写真の説明
＜省略＞
　
＜日本の文化＞
　ヨーロッパと違って、泥臭い話がでてこないのはなぜだろうか？
　１）現場・部門ごとにプロセスができないのではないか。
　２）そのため、上からもってきているのではないか？
　３）現場の人がでてこない。支援部門がでてくるので、生々しい話がでてこない。
　４）現場の人のみとしてはどうだろうか。
　５）現場の人＋ＳＥＰＧがよいのではないか。

【感想】
　別途。

夜は眠るもの

2009-09-29T08:14:00.005+09:00

パソコンや携帯電話を使った生活で、睡眠のリズムが乱れ健康に悪影響を与えているといわれています。

そのなかで、面白いサービスが登場しました。

「夜は眠るもの」　午前0時に閉まる2D仮想空間「ニコッとタウン」のこだわり9月28日14時25分配信 ITmedia News

　「だって夜は眠るものじゃないですか」。営業時間は、午前10時から午前0時。Webブラウザ上で利用できる2D仮想空間「Nicotto town」（ニコッとタウン）は営業時間の決まった規則正しい仮想空間だ。

　アバターを着替えさせたりチャットしたり、ブログを書いたり、ゲームをプレイして楽しめる。2008年9月に正式公開し、09年9月5日には登録者数が30万を突破。月間ページビュー約3億のコミュニティーに成長した。

　深夜は一般的に、チャットサービスやオンラインゲームが盛り上がる時間だが、ニコッとタウンでは、一部のゲームエリアを除き、仮想空間すべてをクローズする。早々に店じまいをするのは、「夜は眠るもの」だから。ニコッとタウンを運営するスマイルラボ（スクウェア・エニックス100％子会社）の伊藤隆博社長は、平然と笑う。

●ニコッとタウンが午前0時に閉まるわけ

　理由は、ユーザーに眠ってもらうためだけではない。「日本人は途中で『帰りたい』と言いづらい。飲み会をいったん締めて、行きたい人だけ2次会にいくのと一緒で、午前0時にいったん終われば、『あぁ終わりですね』と帰りたい人は帰れる」。居心地のいい場を目指しているという。

　男女比は3対7。圧倒的に女性が多い。20～40代が75～80％。このサイトで初めてコミュニティーや仮想空間に触れる初心者ユーザーも多いという。

　日本人向けに特化した空間作りが特徴だ。「世界一かわいい」と自負するアバターや、浮世絵師の絵を参考にしたタウンデザイン、インターフォンを押さないとほかのユーザーの部屋に入れない仕組みは日本ならではだ。

　「グローバリゼーションは、徹底したローカライゼーション」――日本ならではの繊細な“もの作り”こそが世界に対抗するための手段だと、伊藤社長は話す。

＜以下略＞

日米を中心とする資本主義社会は、ひたすら便利に向かって突き進んできた。
しかし、便利と人間の生態とは、必ずしも一致しない。便利になれば、人間の心身の健康をくずすことにもなっている。

また、今や２４時間サービスの便利さは、差別化にもならない状況であろう。

「ニコッとタウン」のこだわりは、便利を目指してきた社会に一石を投じるものであろう。

翻って、ソフトウェア保守も２４時間サービスがあるが、ライフラインを除いてはシステムを休める時間も必要であろう。１日のうちにシステムを止める時間を作ることはＣＯ２の削減にもなり、一石数鳥になる。

と、いうのは我田引水だろうか？

※とはいえ、稼動のピーク時とともに、障害が起き易いシステムの起動停止が増えるのではあるが…（笑）

職場で迷惑なくせ

2009-09-28T08:12:00.001+09:00

職場で迷惑な癖の記事がでていた。

【働きビト】職場に蔓延する“迷惑”なクセ「ペン回し」や「独り言」もNG9月25日12時3分配信オリコン

　社会人の常識・非常識から恋愛事情まで、様々な分野でのスタンダードを探るコラム、オリコン『働きビト』。社会に出ると「いろんな人がいるなぁ」と感じることも多々あるだろう。そこで、第12回目は『勤め先の席のお隣さん（もしくは近くの席）の“気になるクセ”』についてリサーチ。その結果、寄せられた回答には、ふと聞こえてくる【独り言】（1位）や【貧乏ゆすり】（2位）に「仕事がはかどりません！」（千葉県/20代/女性）などのSOSが届いたほか、少数ながら【ペンを回す】、【指をポキポキ鳴らす】といった何気ない仕草に迷惑している人もいた。

同僚や上司の“気になるクセ”、主な回答一覧こちら

　仕事が順調でも不調でも、何かの拍子で自然にポロリと口から出てくる【独り言】。誰にでも身に覚えのあることだとは思うが、職場では「独り言が多いと、自分に話しかけているのかと反応してしまって集中できない」（千葉県/20代/男性）、「少しなら仕方ないし、自分も言ってしまうことがあるけれど、常にネガティブなことをボソボソ言い続けられるとこちらが滅入る」（京都府/20代/女性）と、度が過ぎるとそれが“迷惑行為”となってしまうこともしばしばある様子。

　【貧乏ゆすり】も同様、「苛立っているからやっているんだろうけど、視界に入るとこちらまでイライラしてくる」（東京都/30代/男性）というように、やはり度が過ぎるのは禁物。相手にまで不快感を与える要因になってしまう。執拗に【髪の毛をいじる】動作もそれに匹敵するようで、「邪魔ならまとめるとか、切るとかすればいいのに……。いつもチェックばかりして鬱陶しい」（東京都/30代/女性）と、何てことのない仕草でさえも、やはり常識を越えるような場合は、不快感を与えることになる。

　また、「“仕事してます”とでも言うかのようにあからさまに強く叩かれたり、必要がない時でもずっとENTERキーをうるさく叩かれたりするとイライラする……」（兵庫県/20代/女性）と、実は【強く（PCの）キーボードをたたく】（7位）音も周りの人にストレスを与えているようだ。このほか【ペンをカチカチならす】（8位）、【飲み物を飲む時に音をたてる】、【乱暴な引き出しの開閉】など、普段何気なくやってしまいそうな動作にも手厳しい意見が目立った。

以下略

私にも思い当たることがある。

ディスプレイに向かって話しかける（独り言）人はごく当たり前だし、一昔まえは、ＰＣが遅いと言って団扇で扇いでいる奴もいた。

ペン回しも入社してから覚えたものだ。最近は、キーボードなので、滅多にしないが…

全部アウトでねぇ。

でも、集中していればあまり気にならないもの、もう少し寛容になってもよいのではないだろうか？

「ソフトウエア・メインテナンス・シンポジウム　２００９」紹介

2009-09-27T07:59:00.007+09:00

私が所属する「ソフトウェア・メインテナンス研究会」のシンポジュームの紹介です。

目玉は、社団法人日本情報システム・ユーザー協会（略称：JUAS）の細川専務理事の「JUAS ソフトウェア・メトリクス調査　開発と保守　～保守技術者に元気を！～」についての基調講演です。

ソフトウェア保守の現場を活気付けたい方は是非いらしてください。

＜以下案内の抜粋です。＞

--------------------------------------------------------------------------------

　　　　　ソフトウエア・メインテナンス・シンポジウム　２００９　　

　　　　　　　　　「データから診るソフトウェア保守」

--------------------------------------------------------------------------------

　SERC （ソフトウェア・メインテナンス研究会）は、国内で唯一のソフトウェア保守に
関する研究グループとして1990年12月の創立以来これまで、ソフトウェア保守の諸問題に
焦点を当て、さまざまな切り口からその解決策を探ってきました。
　今回のシンポジウムも、ソフトウェア保守の実態について、データに基づいた発表を中
心にプログラムを構成しました。

　午前の部では、社団法人日本情報システム・ユーザー協会（略称：JUAS）の細川専務理
事に「JUAS ソフトウェア・メトリクス調査　開発と保守　～保守技術者に元気を！～」
についての基調講演をお願いしました。細川さんは新日本製鉄で情報システムの仕事をし
た後、同社のITビジネスも手掛けたので、ユーザーとベンダーの両方の立場を経験してい
ます。JUASでは、多様な活動を行っており、今回は、その中から毎年データを各社から集
めている「ソフトウェアメトリックス調査」から、我々、技術者が元気になる講演をして
頂きます。

午後の部も、データから診るソフトウェア保守ですが、経済調査会が取っているデータ
を基に高橋さんに発表して頂きます。

プログラムの最後は、SERC を構成する各グループからの、第18年次の活動報告と次年
度の活動計画の発表です。

なお、シンポジウム終了後、情報交換会を開催いたしますので、講演者・参加者の方々
の自由な意見交換および情報交換の場として役立てていただけければ幸いです。

------------------------------------------------------------

　　　　　　　　　　開催要領

●　日時：2009年10月8日(木)　09:50-19:00（受付 9:30から）

●　プログラム

9:30- 9:50　受付開会
　 9:50-10:00　開会（７Ｆ)

　10:00-12:00　基調講演　「JUAS ソフトウェア・メトリクス調査　開発と保守
　　　　　　　　　　　　　　～保守技術者に元気を！～」
　　　　　　　 (社)日本情報システム・ユーザー協会　専務理事　細川　泰秀　氏

　12:30-14:00　昼食休憩

　14:00-14:50　招待講演「ソフトウェア保守の実態調査結果」
　　　　　　　 (財)経済調査会　高橋　昭彦　氏

　14:50-15:50　SERC各グループの活動報告および次年度の活動計画　その１

　　　Dグループ　「SERCの考える保守とは」増井　和也　氏
　　　Cグループ　「保守のアウトソーシングを考える」　　　田中　創　氏

　15:50-16:10　休憩

　16:10-17:10　SERC各グループの活動報告および次年度の活動計画　その２

　　　Bグループ　「保守作業改善の基盤技術調査」　　　　　石川　雅彦　氏
　　　Aグループ　「保守用ドキュメントとは」　　　　　　　福島　茂雄　氏

　17:10-17:20　ソフトウェアメインテナンス研究会について
　　　　　　　　代表幹事　岸田　孝一　氏

　17:30-19:00　情報交換会（２Ｆ）

●会場：場所：全国情報サービス産業厚生年金基金会館(JJK) ７階会議室
　　　　　　 (東京都中央区築地4-1-14)
　　　　http://www.jjk.or.jp/map.html

　　　　東京メトロ日比谷線・都営浅草線「東銀座駅」６番出口より徒歩３分
　　　　都営大江戸線「築地市場駅」Ａ３番出口より徒歩５分

●定員：100名（先着順）

●参加費：

　一般は情報交換会付きで　5,000円、情報交換会なしで　4,000円、
　ＳＥＲＣ研究員は1,000円
●参加方法
詳細は、ソフトウェア・メインテナンス研究会を参照ください。

ソフトウェアの保守性について（その２）

2009-09-25T08:25:00.003+09:00

【解析性】
　解析性はソフトウェアの保守性を構成する重要な要素である。

　この解析性は、次の２点を示す。
１）問題が生じた際に原因となるポイントの特定しやすさ
２）新たに生じた仕様変更で修正すべきポイントの判りやすさ

　ところで、人間の頭脳の短期記憶の容量には制限があるため、プログラムのつくりにより解析性の良し悪しが出現する。

　次に解析性に影響のある特出を記載する

１．一貫性
　人間の認識性を高め短期記憶容量を節約するために、命名、フォーマット等様々場面で一貫性が必要である。
２．式のフォーマット
３．ステートメントのフォーマット
４．命名規約
５．ステートメントレベルのコメント
６．バージョン管理用のコメント
７．仮想的な構造：ブロックおよびインデント
８．式、関数、メソッドの長さ
９．制御構造
１０．ブール式
１１．コードの認識性と凝集度
１２．依存関係と結合
１３．コードブロックのコメント
１４．データ宣言のコメント
１５．識別子の適切な命名法
１６．依存関係の局所性
１７．曖昧性
１８．検査性

－－　時間切れのために詳細は、後述する

保守性について（その１）

2009-09-24T08:24:00.003+09:00

「保守性」という言葉がよく使われるが、その実態がソフトウェア保守開発の現場で語られることは少ない。

ここで保守性について、おさらいをしたいと思う。

●保守性の指標

一般的に保守性の指標ＭＩ（Maintainability Index)は次のように定義されている。

ＭＩ＝１７１－５．２×ｌｎ(ave Ｖ）
　　　－０．２３×aveＶ(g')
　　　－１．６２×ｌｎ（aveＬＯＣ）
　　　＋５０×sin（root（２．４ＰｅｒＣＭ））

　　　※root（）は、カッコ内の平方根を表す。
ここで、
　ave Ｖ:Halstead複雑度の平均（計算密度）
　aveV(g')：サイクロマティック複雑度の平均（論理的な複雑性）
　aveＬＯＣ：コードの平均行数（コードのサイズ）
　ＰｅｒＣＭ：コメント行存在比率の平均パーセント（コードの視認性）

●Halstead複雑度
　プログラムが合計Ｎ個の演算子とオペランドで、ｎ個の異なった演算子とオペランドをつかっているとすると、そのHalstead複雑度　Ｖは次のように定義される。

　Ｖ＝Ｎ×log(n) （logの基底は２）

　このHalstead複雑度の平均をとったものが、ave Ｖである。

●サイクロマティック複雑度
　プログラムの全ステートメントが最低一回は実行されるためのテストケースの数

　このサイクロマティック複雑度の平均をとったものが、aveV(g')

●コードの平均行数（aveＬＯＣ）、および、コメントの行数の割合（ＰｅｒＣＭ）

このＭＩを計算するツールは多数存在する。
・Lachesis Eclipse
・JetBrains's IntelliJ IDEA IDE MetricsReloaded
・CheckStyle
・PMDM

しかしながら、こららの指標に頼り切ることは危険である。

この指標を上げることに盲従すると、かえって保守性が悪いものができる。

この指標は全体のなかの問題のありそうなところを探す切欠に使う程度に留めるべきであろう。

最後は、人間の判断が必要である。

ソフトウェア保守開発に必要なツール（その１）

2009-09-22T06:44:00.002+09:00

ソフトウェア保守開発には、未だ未だ欲しいツールがある。

逐次紹介していきたい。

今回は、文字列検索機能の強化版である構文解析機能のある文字列検索機能。

プログラム修正の影響範囲を調査するには、文字列検索機能を用いて修正に使用する変数を調査する。

しかしながら、次の理由で同じ変数名を検索するだけでは不十分である。

１）関数のパラメータや、値の受け渡しによる名前の変更
　例）　変数　'a'の値の範囲を増やす場合。
　　・変数　'a'　を検索する
　　・”b = a”と、'a'の値を代入している変数'b'があれば、変数'b'も検索する必要がある。

２）クラスや構造体中で、同じ名前を使用している場合
　クラスや構造体中で、同じ名前を使用している場合には、変更の影響を受ける変数か、そうでない変数かが判りにくい。
　ファイル名等で検索範囲を絞ることが出来るが、この時漏れが生じる可能性がある。

このため、言語の構文解析を意識して文字列検索をするツールがあると便利である。

１）関数のパラメータや、値の受け渡しによる名前の変更されたものも出力する。
２）クラスや同じ構造体の範囲内の文字列を出力する。

デグレード防止とモチベーションの関係

2009-09-20T22:35:00.002+09:00

ソフトウェア保守開発においては、デグレードは禁忌すべきものである。

このデグレードを防止することと、保守担当者のモチベーションに浅からぬ関係が有る様である。

デグレードを防止するには、直さないことが一番である。

しかしながら、問題を直さないことが、保守担当者のストレスや無力感につながっている様である。

どうも、技術者（人間）は問題を抱えておくのが苦手なものである。

判らないものを判らないまま、不具合を直さないまま抱えると、ストレスが生じる。

そして、判らないことがあれば、判った気がするまで調べたい。具合があれば直したい。

そこでデグレード防止のため、不具合を直さずに運用回避を提案することには非常にストレスを感じる。

また、修正を提案してた場合、デグレード防止を理由に却下されると無力感を生ずる。

これは、実際に聞いた話。

問題点の修正の要否は、利用者への影響だけでなく、担当者のモチベーションも考慮すべきであろう。

そして、利用者への影響は小さくても、場合によっては大胆に直すことも必要であろう。

（勿論、それに合わせて、十分な事前検討と動作確認が必要なことは言うまでもない。）

サービス品質と作業効率の関係

2009-09-18T12:41:00.002+09:00

先日、リアルの世界でサービス品質と作業効率の向上の議論をした。

その時、言い尽くせなかったことを記載しておく。

議論の切欠は、「サービス品質の向上と作業効率の向上は相反するもので、両者を目指すことができない。」と
いう発言から。

ミクロの世界でみるとそれも一理あるが、マクロ的に見れば両立できるものである。

サービス品質と作業効率の関係を図示する。

任意のサービスのサービス品質と作業効率の関係は図のような線で表すことができる。
Ｐ１の線で考えてみよう。
同じプロセスでサービス品質をｑ１からｑ２にあげようとすると、作業効率はｅ２からｅ１に下がる。
確かに、最初の指摘どおりで、サービス品質と作業効率は相反する。

しかし、これは同じプロセスＰ１だからであり、プロセス改善によりＰ２の関係がもたらされれば、（ｑ２、ｅ３）の状態になる。つまり、サービス品質も、作業効率も上げることができる。

これが、プロセス改善が意味するとこだと、私は考える。

勝手にソフトウェア保守開発

ＳＥＲＣ Ｆｏｒｕｍ（Ｊｕｌ）

SS2010 6/11 午前

SS2010 6/10 午後

SS2010 6/10 午前

SS2010 6/9 午後

SS2010 6/9 午前

S-Open 2010年度総会 記念講演聴講記