【やる気の源泉】
1）面白い（内的） 面白ければやる気が出る。（没頭する）
2）嬉しい（外的） 嬉しいとやる気になる。（ほめられる）
＜面白要素＞
＜嬉しい要素＞
2011年6月6日月曜日
2011年5月11日水曜日
面白種別
【面白種別】
1）仕事がはかどる面白さ
・意義
・没頭
・創造
・非日常
・連帯
2）知的好奇心をくすぐる面白さ
・発見
・理解
3）笑いを誘う面白さ
・予測を裏切る
4）どうなるか分からない面白さ
・ゲーム
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）面白要素
(a)意義
(b)没頭
(c)創造
(d)非日常
(e)連帯
(f)主体性
(g)感受性
2）面白コミュニケーション
（a）心の対話・交流
（b）面白交流
（c）ストローク
3）面白真面目リーダー
（a）面白まじめ（面白いと厳しいを使い分ける）
（b）あたきび（暖かく厳しい）
（c）かんかん（まず感じて、それから考える）
4）面白モティベーション
（a）やる気圧
（b）やりがい
（c）働きがい
成功／失敗を予測する指標
【成功／失敗を予測する指標】
公式： 成果＝目的×能力×意欲×行動
1）目的・目標がしっかりしているか
2）能力のある人がアサインされているか
3）意欲的に活動する理由があるか
4）行動がともなう理由があるか
公式： 成果＝目的×能力×意欲×行動
1）目的・目標がしっかりしているか
2）能力のある人がアサインされているか
3）意欲的に活動する理由があるか
4）行動がともなう理由があるか
2011年4月21日木曜日
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キーが元に戻っていることを確認する
登録:
投稿 (Atom)