- リーダーが明確になる
- メンバーに指示する権限が生じる
- 権力者のバックアップが得られる
2011年4月19日火曜日
2011年4月10日日曜日
敵
【敵】
人間には自分自身以外に敵はほとんどいないものである。
最大の敵はつねに自分自身である。
判断を誤ったり、
むだな心配をしたり、
絶望したり、
意気阻喪するようなことばを自分に聞かせたり
することによって、最大の敵となるのだ。
（アラン）
人間には自分自身以外に敵はほとんどいないものである。
最大の敵はつねに自分自身である。
判断を誤ったり、
むだな心配をしたり、
絶望したり、
意気阻喪するようなことばを自分に聞かせたり
することによって、最大の敵となるのだ。
（アラン）
2011年2月27日日曜日
二日酔いしない方法
【二日酔いしない方法】
1）ビールといっしょに、ウーロン茶も注文する
2）鳥のから揚げを注文する
3）食べ物が出てくるまでちびちび飲む
4）太ることを気にしないでたんぱく質を食べる
5）なるべくたくさんウーロン茶を飲む
6）家に帰ってから飲みなおさない
7）飲み終わってから1時間は寝ない
8）寝る前に水を飲む
1）ビールといっしょに、ウーロン茶も注文する
2）鳥のから揚げを注文する
3）食べ物が出てくるまでちびちび飲む
4）太ることを気にしないでたんぱく質を食べる
5）なるべくたくさんウーロン茶を飲む
6）家に帰ってから飲みなおさない
7）飲み終わってから1時間は寝ない
8）寝る前に水を飲む
2011年2月24日木曜日
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）
「システムの目的」
要件定義では、システムの目的を明確にする必要がある。
繰り返し洗練化しながら要件を決めていく中で、判断に迷うことが何度もある。どうしても決められない場合は、最終的にシステムの目的に照らして判断することになる。判断の最後のよりどころとなるのがシステムの目的である。
要件定義の後に続く、外部設計などシステムの仕様を策定する際も同様で、システムの目的が指針、判断材料となる。
システムの目的は、要件定義が終わるまでに決まっていなければならない。
「要件定義の枠組み」
複数の人間が共同で作業を行い、ひとつの成果物を作成する場合には、作業の内容が重複せず、かつ必要な内容が網羅されている必要があり、かつそれぞれの内容が整合していなければならない。そのためには何を記述するかを明確にする必要がある。
作業を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）
2011年2月14日月曜日
2011年2月9日水曜日
速いフォアハンドストロークを打つ方法
【速いフォアハンドストロークを打つ方法】
1）回り込み
2）左膝を外に向け
3）体の回転を抑えて絞り
4）骨盤だけ回転させて
5）踏み込まず、頭を動かさず
6）下半身の力をボールに乗せる
1）回り込み
2）左膝を外に向け
3）体の回転を抑えて絞り
4）骨盤だけ回転させて
5）踏み込まず、頭を動かさず
6）下半身の力をボールに乗せる
2011年2月8日火曜日
2011年2月7日月曜日
セカンドサーブを必ず入れる方法
【セカンドサーブを必ず入れる方法】
●狙って、見つめて、背中をかく！
（ボディを狙って、ボールを最後まで見つめて、背中をかくようにこすり上げる）
1）ボディを狙う
2）トスを高く上げる
3）ラケットを下ろす
4）最後の最後までボールを見る
5）背中をかくようにこすり上げる
●狙って、見つめて、背中をかく！
（ボディを狙って、ボールを最後まで見つめて、背中をかくようにこすり上げる）
1）ボディを狙う
2）トスを高く上げる
3）ラケットを下ろす
4）最後の最後までボールを見る
5）背中をかくようにこすり上げる
2011年1月31日月曜日
2011年1月27日木曜日
2010年12月27日月曜日
WINDOWS7 64bitマシンにリモートデスクトップ接続したい
WINDOWS7 64bitマシンにリモートデスクトップ接続したい。
WINDOWS7はガードが堅くて、設定がなかなかやっかいである。
【接続を受け入れ可能にするための設定】
この設定により、WINODWS7マシンのログイン画面に到達可能となる。
1）コントロールパネル＞Windowsファイアウォール
2）左側のウィンドウ＞詳細設定
3）ファイアウォールの規則の表示と作成＞受信の規則
4）リモートデスクトップ（TCP受信）をダブルクリック
5）全般タブで＞操作＞◎接続を許可するを選択
6）OK
7）スタートボタン＞コンピューターを右クリック＞プロパティ
8）左側ウィンドウ「リモートの設定」
9）リモートタブ＞リモート デスクトップを実行しているコンピューターからの接続を許可するを選択＞OK
10）スリープおよび休止状態の設定＞なし
【ログインを受け入れ可能にするための設定】
WINDOWS7マシンのログイン画面に到達しているものの、ログインできない、という場合には下記の設定が有効である。
1）スタートボタン＞プログラムとファイルの検索に「mmc」と入力
2）いちばん上にmmc.exeが表示されるので、右クリックし、管理者として実行
3）コンソール画面の、ファイルメニューから、スナップインの追加と削除を選択
4）利用できるスナップインから、ローカルユーザーとグループを選択し、追加、完了、OK
5）ローカルユーザーとグループの中の「グループ」フォルダをダブルクリック
6）Remote Desktop Usersをダブルクリック
7）追加をクリックし、ユーザー名を入力
8）OK
WINDOWS7はガードが堅くて、設定がなかなかやっかいである。
【接続を受け入れ可能にするための設定】
この設定により、WINODWS7マシンのログイン画面に到達可能となる。
1）コントロールパネル＞Windowsファイアウォール
2）左側のウィンドウ＞詳細設定
3）ファイアウォールの規則の表示と作成＞受信の規則
4）リモートデスクトップ（TCP受信）をダブルクリック
5）全般タブで＞操作＞◎接続を許可するを選択
6）OK
7）スタートボタン＞コンピューターを右クリック＞プロパティ
8）左側ウィンドウ「リモートの設定」
9）リモートタブ＞リモート デスクトップを実行しているコンピューターからの接続を許可するを選択＞OK
10）スリープおよび休止状態の設定＞なし
【ログインを受け入れ可能にするための設定】
WINDOWS7マシンのログイン画面に到達しているものの、ログインできない、という場合には下記の設定が有効である。
1）スタートボタン＞プログラムとファイルの検索に「mmc」と入力
2）いちばん上にmmc.exeが表示されるので、右クリックし、管理者として実行
3）コンソール画面の、ファイルメニューから、スナップインの追加と削除を選択
4）利用できるスナップインから、ローカルユーザーとグループを選択し、追加、完了、OK
5）ローカルユーザーとグループの中の「グループ」フォルダをダブルクリック
6）Remote Desktop Usersをダブルクリック
7）追加をクリックし、ユーザー名を入力
8）OK
2010年12月20日月曜日
Windows7 64bitマシンのCapsLockキーとCtrlキーを入れ替える
Windows7 64bitマシンのCapsLockキーとCtrlキーを入れ替えたい。
【Ctrl2Cap v2.0のインストール】
1）Ctrl2Cap v2.0 をダウンロードする
http://technet.microsoft.com/ja-jp/sysinternals/bb897578%28en-us%29.aspx
2）Ctrl2Capフォルダを解凍する
3）解凍したCtrl2Capフォルダを、Ｃドライブの直下に置く
4）すべてのプログラム＞アクセサリ＞コマンドプロンプト（右クリックで管理者として実行）
5）cd￥（半角）Ctrl2Cap と入力し実行
6）ctrl2cap /install と入力し実行
7）再起動する
8）CapsLockキーとCtrlキーが入れ替わっていることを確認する
【Ctrl2Cap v2.0のアンインストール】
1）すべてのプログラム＞アクセサリ＞コマンドプロンプト（右クリックで管理者として実行）
2）cd￥（半角）Ctrl2Cap と入力し実行
3）ctrl2cap /uninstall と入力し実行
4）再起動する
5）CapsLockキーとCtrlキーが元に戻っていることを確認する
【Ctrl2Cap v2.0のインストール】
1）Ctrl2Cap v2.0 をダウンロードする
http://technet.microsoft.com/ja-jp/sysinternals/bb897578%28en-us%29.aspx
2）Ctrl2Capフォルダを解凍する
3）解凍したCtrl2Capフォルダを、Ｃドライブの直下に置く
4）すべてのプログラム＞アクセサリ＞コマンドプロンプト（右クリックで管理者として実行）
5）cd￥（半角）Ctrl2Cap と入力し実行
6）ctrl2cap /install と入力し実行
7）再起動する
8）CapsLockキーとCtrlキーが入れ替わっていることを確認する
【Ctrl2Cap v2.0のアンインストール】
1）すべてのプログラム＞アクセサリ＞コマンドプロンプト（右クリックで管理者として実行）
2）cd￥（半角）Ctrl2Cap と入力し実行
3）ctrl2cap /uninstall と入力し実行
4）再起動する
5）CapsLockキーとCtrlキーが元に戻っていることを確認する
2010年11月8日月曜日
老人の生甲斐 ～可能になった「生産と供用」
老人はよくテレビを見る。一日中テレビをつけっ放しという人もいる。テレビを見ているだけで一日が終わってしまい、翌日もまたテレビを見ているだけ、なんていうのはよくあることだろう。そんな生活を想像したことが、老人の生甲斐を考えてみるきっかけになった。
私自身はどんなとき、自分に存在価値を認めるだろう。私は「人のために役に立てた」ときに自分の存在価値を感じる。では、私はどんなときに人の役に立てるだろう。キーワードは「生産と供用」である。モノやサービスを生産し、これを供用したときに、人の役に立てる。私たちは生きている以上、少なくとも何かを生産し、さらに供用して、人のために役立たなければならない。生産しただけではダメである。供用しなければ、少なくとも供用を試みなければ、人の役に立つことはできないからだ。
モノやサービスを生産して供用し、人のために役立つことで、自分の存在価値を感じられることが分かった。では、何を生産すればよいのか。それが最初の現実的な問題である。定年退職し「さて野菜でも作ろうか」と思っても土地がなければ作れない。鍬を作ろうにも道具がない。作ってもどうやって供用すればよいのだろう。従来もこれからも、老人（特に都会の老人）が有形のプロダクトを生産し供用することは困難である。ではどうすればよいのか。
従来と現在が異なるのは、デジタル技術の飛躍的な発達と、インターネットの普及である。われわれは土地を持たないが、パソコンとインターネットは手に入れた。無形プロダクト・無形サービスであれば土地や設備がなくても、パソコンで生産し、インターネットでいとも簡単に供用できる。無形プロダクトとは、例えば論文、写真、日記、ノウハウ、コンピュータプログラム、音楽といったものである。老人にとってこれらは従来も生産可能であったが、パソコンによって生産が容易になり、かつインターネットによって全世界を相手にタダ同然で供用できるようになった。
従来の老人は、生産と供用の手段を持たなかった。いまは違う。いまの老人は「生産と供用」の手段を持つ。これは大変な社会変革である。
老人は「野菜を作ろうにも土地がない」といういい訳を失った。老人は無形プロダクトを次々に生産して、インターネット上に供用しなければならない。これによって人の役に立たなければならない。もはや一日中テレビを見ている暇はないのである。
私自身はどんなとき、自分に存在価値を認めるだろう。私は「人のために役に立てた」ときに自分の存在価値を感じる。では、私はどんなときに人の役に立てるだろう。キーワードは「生産と供用」である。モノやサービスを生産し、これを供用したときに、人の役に立てる。私たちは生きている以上、少なくとも何かを生産し、さらに供用して、人のために役立たなければならない。生産しただけではダメである。供用しなければ、少なくとも供用を試みなければ、人の役に立つことはできないからだ。
モノやサービスを生産して供用し、人のために役立つことで、自分の存在価値を感じられることが分かった。では、何を生産すればよいのか。それが最初の現実的な問題である。定年退職し「さて野菜でも作ろうか」と思っても土地がなければ作れない。鍬を作ろうにも道具がない。作ってもどうやって供用すればよいのだろう。従来もこれからも、老人（特に都会の老人）が有形のプロダクトを生産し供用することは困難である。ではどうすればよいのか。
従来と現在が異なるのは、デジタル技術の飛躍的な発達と、インターネットの普及である。われわれは土地を持たないが、パソコンとインターネットは手に入れた。無形プロダクト・無形サービスであれば土地や設備がなくても、パソコンで生産し、インターネットでいとも簡単に供用できる。無形プロダクトとは、例えば論文、写真、日記、ノウハウ、コンピュータプログラム、音楽といったものである。老人にとってこれらは従来も生産可能であったが、パソコンによって生産が容易になり、かつインターネットによって全世界を相手にタダ同然で供用できるようになった。
従来の老人は、生産と供用の手段を持たなかった。いまは違う。いまの老人は「生産と供用」の手段を持つ。これは大変な社会変革である。
老人は「野菜を作ろうにも土地がない」といういい訳を失った。老人は無形プロダクトを次々に生産して、インターネット上に供用しなければならない。これによって人の役に立たなければならない。もはや一日中テレビを見ている暇はないのである。
2010年10月30日土曜日
2010年10月6日水曜日
Gmailのショートカット
＜ショートカット・キー＞
- 下の（古い）スレッドに移動： j
- 上の（新しい）スレッドに移動： k
- スレッドを開く： o
- スレッドリストに戻る（更新）： u
- スレッドを選択： x
- スレッドをすべて選択： *a
- スレッド選択をすべて解除： *n
- 既読にする： Shift i
- ショートカット一覧： Shift ?
- 未読メールを検索： is:unread in:inbox
- 自分が送信したメールからキーワードで検索： from:me <キーワード>
- mikeからの添付ファイル付きのメールだけ検索： from:mike has:attachment
- 2010/09/01以前に送信されたメールを検索： before:2010/09/01
2010年10月5日火曜日
License Free Original Music
- STORM by masanorimitake [MP3] [CD Quality]
- YOUNG by masanorimitake [MP3] [CD Quality]
- TRAVEL by masanorimitake [MP3] [CD Quality]
- ZURE by masanorimitake [MP3] [CD Quality]
- SOBER by masanorimitake [MP3] [CD Quality]
- FRIEND by masanorimitake [MP3] [CD Quality]
- IZUMO by masanorimitake [MP3] [CD Quality]
- DANCE7 by masanorimitake [MP3] [CD Quality]
*License Free Original Music
2010年7月7日水曜日
読書
2011/ パンセ（パスカル）
2011/ 織田信長3（山岡荘八）
2011/ 意識と本質（井筒俊彦）
2011/10 音楽の感動を科学する（福井一）
2011/09 文士の哲学（夏目漱石）
2011/09 織田信長2（山岡荘八）
2011/09 織田信長1（山岡荘八）
2011/08 プリズンホテル1夏（浅田次郎）
2011/08 こゝろ（夏目漱石）
2011/0８ ジャズ喫茶のオヤジはなぜ威張ってイいるのか（後藤雅洋）
2011/07 てくてく歩き琵琶湖・近江路
2011/07 ことりっぷ滋賀･琵琶湖
2011/05 赤穂浪士 上巻（大沸次郎）
2011/05 要件定義マニュアル（神崎善司）
2011/03 スベらない話し方（夏川立也）
2011/03 ミック・ジャガーの成功哲学（アラン・クレイソン）
2011/02 コーヒーとサンドイッチの法則（竹内正浩）
2011/01 モーツァルトを聴けば病気にならない! （和合治久）
2010/12 五年の梅（乙川優三郎）
2010/12 100歳までボケない101の方法（白澤卓二）
2010/12 プロフェッショナルCIOの教科書（甲斐莊正晃／桐谷恵介）
2010/11 三屋清左衛門残日録（藤沢周平）
2010/11 知恵の樹（ウンベルト・マトゥラーナ／フランシスコ・バレーラ）
2010/11 知的余生の方法（渡部昇一）
2010/10 官僚のレトリック（原 英史）
2010/10 実践データモデリング（真野 正）
2010/09 吉田松陰（2）（山岡荘八）
2010/09 吉田松陰（1）（山岡荘八）
2010/08 一生モノのジャズ名盤500（後藤雅洋）
2010/08 高杉晋作（3）（山岡荘八）
2010/08 高杉晋作（2）（山岡荘八）
2010/08 高杉晋作（1）（山岡荘八）
2010/08 眠狂四郎無頼控 一（柴田 錬三郎）
2010/07 ビジネスリーダーにITがマネジメントできるか（淀川高喜）
2010/07 アキラ（大友克洋）
2010/06 サービスで小さな奇跡を起こす方法（林田正光）
2010/06 風の谷のナウシカ（宮崎 駿）
（年月は読了時）
2011/ 織田信長3（山岡荘八）
2011/ 意識と本質（井筒俊彦）
2011/10 音楽の感動を科学する（福井一）
2011/09 文士の哲学（夏目漱石）
2011/09 織田信長2（山岡荘八）
2011/09 織田信長1（山岡荘八）
2011/08 プリズンホテル1夏（浅田次郎）
2011/08 こゝろ（夏目漱石）
2011/0８ ジャズ喫茶のオヤジはなぜ威張ってイいるのか（後藤雅洋）
2011/07 てくてく歩き琵琶湖・近江路
2011/07 ことりっぷ滋賀･琵琶湖
2011/07 ジャズ耳の鍛え方（後藤雅洋）
2011/07 ソース（マイク・マクナマス）
2011/06 「ほめる」技術（鈴木義幸）
2011/06 「やる気」のある自分に出会える本（笹氣健治）
2011/06 赤穂浪士 下巻（大沸次郎）
2011/05 赤穂浪士 上巻（大沸次郎）
2011/05 要件定義マニュアル（神崎善司）
2011/03 スベらない話し方（夏川立也）
2011/03 ミック・ジャガーの成功哲学（アラン・クレイソン）
2011/02 コーヒーとサンドイッチの法則（竹内正浩）
2011/01 モーツァルトを聴けば病気にならない! （和合治久）
2010/12 五年の梅（乙川優三郎）
2010/12 100歳までボケない101の方法（白澤卓二）
2010/12 プロフェッショナルCIOの教科書（甲斐莊正晃／桐谷恵介）
2010/11 三屋清左衛門残日録（藤沢周平）
2010/11 知恵の樹（ウンベルト・マトゥラーナ／フランシスコ・バレーラ）
2010/11 知的余生の方法（渡部昇一）
2010/10 官僚のレトリック（原 英史）
2010/10 実践データモデリング（真野 正）
2010/09 吉田松陰（2）（山岡荘八）
2010/09 吉田松陰（1）（山岡荘八）
2010/08 一生モノのジャズ名盤500（後藤雅洋）
2010/08 高杉晋作（3）（山岡荘八）
2010/08 高杉晋作（2）（山岡荘八）
2010/08 高杉晋作（1）（山岡荘八）
2010/08 眠狂四郎無頼控 一（柴田 錬三郎）
2010/07 ビジネスリーダーにITがマネジメントできるか（淀川高喜）
2010/07 アキラ（大友克洋）
2010/06 サービスで小さな奇跡を起こす方法（林田正光）
2010/06 風の谷のナウシカ（宮崎 駿）
（年月は読了時）
2010年5月25日火曜日
UNIXサーバー
①HP （Itanium9300番台）
②IBM （Power）
③Oracle・富士通（UltraSPARC/ SPARC64）
インテル（Itanium7300番台 → Xeon7500番台）
②IBM （Power）
③Oracle・富士通（UltraSPARC/ SPARC64）
インテル（Itanium7300番台 → Xeon7500番台）
登録:
投稿 (Atom)