masanorimitake

2011年6月17日金曜日

松葉牡丹

10日ほど前、松葉牡丹の種をまいた。
いつ芽が出るかと毎日楽しみに見ている。
やっとひとつ小さな芽が出たが、
その後はひとつも出てこない。
代わりに、小さなキノコがふたつ！
梅雨で毎日雨ばかり降っているからだろう。

2011年6月16日木曜日

娘の早業

高2の娘は寝ぼすけである。
朝、ギリギリまで寝ている。
いよいよギリギリになって起きると、
いきなり制服を着て部屋から出てくる。
いったいどうやって着替えているのだろう？
まるで制服を着て寝ているかのような早業だ。

2011年6月6日月曜日

やる気の源泉

【やる気の源泉】

1）面白い（内的）　面白ければやる気が出る。（没頭する）
2）嬉しい（外的）　嬉しいとやる気になる。（ほめられる）

＜面白要素＞

＜嬉しい要素＞

2011年5月11日水曜日

面白種別

【面白種別】

1）仕事がはかどる面白さ
・意義
・没頭
・創造
・非日常
・連帯

2）知的好奇心をくすぐる面白さ
・発見
・理解

3）笑いを誘う面白さ
・予測を裏切る

4）どうなるか分からない面白さ
・ゲーム

2011年5月6日金曜日

【面白工学】

1）面白要素
　(a)意義
　(b)没頭
　(c)創造
　(d)非日常
　(e)連帯
　(f)主体性
　(g)感受性

2）面白コミュニケーション
　（a）心の対話・交流
　（b）面白交流
　（c）ストローク

3）面白真面目リーダー
　（a）面白まじめ（面白いと厳しいを使い分ける）
　（b）あたきび（暖かく厳しい）
　（c）かんかん（まず感じて、それから考える）

4）面白モティベーション
　（a）やる気圧
　（b）やりがい
　（c）働きがい

成功／失敗を予測する指標

【成功／失敗を予測する指標】

公式：　成果＝目的×能力×意欲×行動

1）目的・目標がしっかりしているか
2）能力のある人がアサインされているか
3）意欲的に活動する理由があるか
4）行動がともなう理由があるか

2011年4月21日木曜日

Project

【Project】

A temporary endeavor undertaken to create a unique product, service, or result

2011年4月19日火曜日

検討委員会を設置するメリット

【検討委員会を設置するメリット】

リーダーが明確になる
外部コストを発生させる前にじっくり検討できる
十人十色の考え方をひとつに集約できる
プロジェクトの目的・目標を明確にできる
プロジェクトの範囲を明確にできる
プロジェクトの実施内容を明確にできる
共通認識と明確な計画をもってプロジェクトの実行に移れる
どうしても無理だと思ったら引き返すことができる

プロジェクト化するメリット

【プロジェクト化するメリット】

リーダーが明確になる
メンバーに指示する権限が生じる
権力者のバックアップが得られる

2011年4月10日日曜日

敵

【敵】

人間には自分自身以外に敵はほとんどいないものである。
最大の敵はつねに自分自身である。

判断を誤ったり、
むだな心配をしたり、
絶望したり、
意気阻喪するようなことばを自分に聞かせたり

することによって、最大の敵となるのだ。

（アラン）

2011年2月27日日曜日

二日酔いしない方法

【二日酔いしない方法】

1）ビールといっしょに、ウーロン茶も注文する
2）鳥のから揚げを注文する
3）食べ物が出てくるまでちびちび飲む
4）太ることを気にしないでたんぱく質を食べる
5）なるべくたくさんウーロン茶を飲む
6）家に帰ってから飲みなおさない
7）飲み終わってから1時間は寝ない
8）寝る前に水を飲む

2011年2月24日木曜日

面白いことを創造する方法

【面白いことを創造する方法】

1）創造する本人が面白がって仕事に取り組む
　・仕事の意義を理解する
　・やらされているんじゃなくて、やる

2）まず感じて、それから考える

3）

2011年2月15日火曜日

要件定義

【要件定義】

「システムの目的」
　要件定義では、システムの目的を明確にする必要がある。
　繰り返し洗練化しながら要件を決めていく中で、判断に迷うことが何度もある。どうしても決められない場合は、最終的にシステムの目的に照らして判断することになる。判断の最後のよりどころとなるのがシステムの目的である。
　要件定義の後に続く、外部設計などシステムの仕様を策定する際も同様で、システムの目的が指針、判断材料となる。
　システムの目的は、要件定義が終わるまでに決まっていなければならない。

「要件定義の枠組み」
　複数の人間が共同で作業を行い、ひとつの成果物を作成する場合には、作業の内容が重複せず、かつ必要な内容が網羅されている必要があり、かつそれぞれの内容が整合していなければならない。そのためには何を記述するかを明確にする必要がある。
　作業を1カ月も続けて、膨大な量のドキュメントが完成しているにも関わらず、いっこうにシステムの全体像が見えてこない、という状況はさけなければならない。

「会議の目的」
　会議の目的は、メンバーがアイディアを共有し、その上で合意を形成していことである。議論を集約する術を持たないまま形式的に会議を繰り返しても、議論は収束しない。

「会議の進め方」
　プロジェクトを混乱させないために、総合的に見て妥当と思われる提案をあらかじめ用意し、会議の場で積極的に示していく必要がある。そして議論を適切な方向に導いていく。
　関係者が納得して受け入れる状況を作るには、内容が分かりやすい形で表現されていることが大前提である。図やポンチ絵で分かりやすく表現した資料を用意しておくことで、提案ベースで会議をリードできる。

「コンセプト」
　全体を貫く統一的な視点や考え方。

「コンセプトをまとめる」
　アイディアを形にすることはなかなか難しい作業である。ましてやそれをシステムとしてひとつにまとめることは至難の業だ。そのような難しい作業は個人作業ではなく、チーム作業をして行うことが重要だ。アイディアを形にしていくためには、メンバーが集まってディスカッションしながら、実現可能性を高めていく必要がある。そのためにはアイディアをシステムの機能に落とし込んでいく枠組みが必要だ。
　以下の質問に答えられて、答えが魅力的なら、コンセプトを見いだせたことになる。
　（a）そのシステムを使うと、誰がどのように嬉しいですか？
　（b）そのシステムを使うと、誰の何の問題が解決するのですか？

「共通認識の確立」
　共通認識を確立する有効な方法は、議論の中で資料を作成、その資料に基づいてさらに議論を深めていくことである。そのような目的で作成する資料は、文章よりもビジュアルに論理的に組み立てられるものが適している。UMLモデルはその代表例である。
　UMLモデルは対象同士の関係性を表現することに長けているので、さまざまな情報の関係性を整理するのにとても便利である。
　要件を決めるには、いろいろな視点から対象を議論することが必要だ。議論を通じて結果が残り、それをもとにまた議論する、という作業の反復が、共通の認識を得るうえで非常に重要である。

「WhatとHow」
　要件定義は「システムが何をするのか」「そのシステムを使った業務はどのようになるのか」というWhatを示したもので、どのようにシステムを作るのかというHowは含めない（非機能要求としてHowに対する要件の定義は行う）。しかし実現可能性を無視して進めることは得策ではない。とは言え、実現可能性にばかり目を向けると、今度は要求がねじれてくる。実現手段が要求として目的化するっことがよくあるからだ。実現する手段が先にきて、それに引きずられるようにして機能が決まるような例である。

（切り分け方法）
・機能要求　　：　＊＊機能は、＊＊を実現する
・非機能要求：　＊＊機能は、レスポンスタイム＊秒とする

「実現可能性を探る」
　実現方法が分からない場合は、要件定義と並行して、アーキテクチャを策定するチームを別途立ち上げ、両チームが連携して上流工程を進める。

「レビュー」
　レビューは非常に集中力を要求される作業で、かつレビュアーには高いスキルが要求される。レビュアーの本来の責務は、大局的な視点に立ち、対象となる成果物の不備を見つけることである。
成果物そのものではなく、作成者の誤解、認識違いを発見することも重要だ。

「主要ドキュメント」
　主要なドキュメントを決め、似たようなドキュメントを乱造しないことが大切である。

「システムの方向性を定める」
　システムを形にしていくためには、方向性を定めることが必要である。そのためにはシステムの本質をとらえる必要がある。本質をとらえるためには対象を抽象的にとらえることが重要だ。「このシステムは＊＊＊＊だ。だから＊＊＊＊のようなシステムにする」と端的にシステムをとらえることができれば方向性は定まる。
　もうひとつは目標をはっきりさせることだ。目標を共有することでメンバーの方向性も定まる。ただし、最初から目標を決められるとは限らないので、解決すべき本質的な課題を模索する中で、目標を定めていく。

「要望・要求・要件」
1）要望：　個人レベル。ヒアリングしたものそのまま
2）要求：　組織内共有レベル。ヒアリングした項目を構造化、抽象化して整理した項目
3）要件：　要求の中から重要なものを整理して、システムとして必ず実現されなければならい項目
4）要件定義：　最終的に実現すべきことをまとめたもの

「要求の粒度」
　仕様を決める上で影響力のある人が、システムの魅力を感じることができる粒度とする。

「要件定義のゴール」
1）要件定義書の内容が、その後のシステム開発の進め方を考慮したものになっていること
2）仕様検討のための情報（判断基準）が含まれていること
3）契約的な条件に内容が沿っていること

　要件定義は相手に要件を伝えるためのものである。同時に時間の短縮のために必要最小限の内容を目指す。情報は、仕様作成のすべての情報が含まれているのではなく、仕様作成に必要な判断のために方針や基準が示されていることが望ましい。つまりシステムの仕様を決めるための前提条件が示されていなければならない。

「手戻りを減らす」
　決まったことを形にしていけば、形にできない部分が決まっていない部分として把握できる。決まっていない部分を把握することで、手戻りを減らすことができる。

「要件定義の手順」
＜システム価値＞
1）関係者をアクターとして洗い出して、その責務を明らかにする
2）アクターが持つ要望を洗い出す

＜システム外部環境＞
3）3つの業務モデルでシステムが利用される環境を洗い出す
4）取り扱う商品の概念を明らかにし、ビジネスルールとする

＜システム境界＞
5）業務プロセスの各アクティビティからユースケースを洗い出す
6）ユースケースから、入出力情報を画面・帳票モデルとしてまとめる
7）外部システムからのイベントとそこで扱う情報を洗い出す
8）システムが提供する機能とデーターを明らかにする

＜システム＞
9）機能複合モデルを使ってユースケース、イベント、機能、データを結びつけて、関係を確認する
10）商品のビジネスルールを、ステートマシン図を使って示す

「プロジェクトのコントロール」
　マイルストーンごとに成果物を示し、プロジェクトのゴールに向かって着実に進んでいることが示せれば、プロジェクト・メンバーはさまざまな問題を乗り越えながらも、プロジェクトを推進していることが分かる。いちばん大切なのはプロジェクトをコントロールしているという事実で、仮に遅れていてもコントロールできていれば対処可能である。

「中間モデルの活用」
　業務プロセスモデルとユースケースモデルを合体したような中間モデルを使用すると、作業効率が上がる場合がある。

「データモデル」
　データモデルは、システムのデータは何かということを表す。それはシステム境界を実現するために必要なデータである。具体的に言うと画面や帳票の項目、イベント用データ項目を満たすデータをまとめたものである。「これらのデータがあればシステム境界を実現できます」ということを表している。

「機能モデルの粒度」
　機能モデルの粒度は、その機能名によって対象のシステムが行うことをイメージできる粒度が、最適な粒度となる。あくまでも何を行うかというWhatの視点で洗い出す。どのように実現するかというHowの視点で機能を洗い出してはならない。機能のてんこ盛りにならにように本当に必要な機能を、要件を確認しながら洗い出す。

「要件定義モデル関連図」

「共通認識を得る」
1）このシステムを使うユーザーはどのような人か → コンテキストモデル
2）このシステムはどのようなシーンで利用されるのか → 利用シーンモデル
3）このシステムにはどのような機能があるのか → 機能モデル
4）このシステムの構造はどうなっているのか → ドメインモデル
5）このシステムで扱う概念にはどのようなものがあるのか → 概念モデル

（参考文献）「要件定義マニュアル」神崎善司

「要件定義工学における成功3要素」
1）顕在化
　　①顧客のニーズを正確に把握することをゴールとして、そのゴールを見失わないこと
　　②用語集を維持すること。言葉の定義不一致は、システム開発最大のトラブルのもと。
　　　用語集維持の担当者をアサインし、ひとつの単語にひとつの意味を定義する
　　③適切な顕在化の技法（インタビュー、グループレビュー等）の選定も大変に重要
　　④ひとりのステークフォルダでは不十分。マーケットには様々なニーズが潜在する。
　　　必ず複数のステークフォルダから要件を抽出すべきである
2）選定化
　　①顧客要求を一覧表に整理して優先順位を付けて、顧客と常に意識を合わせる
　　②スケジュールを優先して3カ月単位に区切り、
　　　優先順位に従って要件を限定して開発する方向に顧客を誘導する
　　③ステークフォルダとしてマーケティング部門、お金の出所であるファイナンス部門、
　　　およびプロジェクト・マネジャーであるシステム開発部門の3者の関与が必須。
　　　この3者でスケジュール、金額、機能のトレードオフの最適化を図ることが重要
3）文書化
　　①上記ふたつの結果を見える化することもまた重要

（Dr. Alan M. Davis）