初心者のためのC#プログラミング本格入門2 - 効果が高い学習をするための準備

　この記事は初心者のためのC#プログラミング本格入門1の続きです。前回は学習方法について書きました。今回は経験者の視点から学習の準備について書きます。
　どんな学問の学習でもそうなのですが、準備をすると学習効率が高まります。C#プログラミングに於いても学習する前にするとよい準備があります。
　最初にするべき事はC#の開発環境のインストールです。開発環境（C#プログラミングをする為に必要なソフトウェア）は色々ありますが、初心者の方はひとまずVisual C# Expressをインストールするとよいでしょう。インストール方法についてはVisual C# Expressのインストーラーが優秀な上に、マイクロソフト社の説明が親切なのでインストールの手順は省略します。インストールするバージョンは最新のものをお勧めします。この便利なソフトウェアを配布しているのはマイクロソフト社です。場所は検索サイトでキーワード「Visual C# Express」を指定して検索すると分かります。
　次に行うとよい準備は、MSDNライブラリをネットから探して、お気に入り（ブックマークとも呼ばれている）に登録する事です。探す方法は簡単です。検索サイトでキーワード「MSDNライブラリ」を指定して検索を実行するだけです。検索をすると初めの方に表示されますので、そのページをお気に入りへ追加／ブックマークしましょう。この作業は英語の学習をする時に辞書を用意するのと同じです。C#プログラミングでも辞書が必要ですので、MSDNライブラリが直ぐに見られるように準備をしておきましょう。
　最低限の準備はこれで終わりです。ある程度プログラミングを経験している人は、言語仕様書と専門書を用意するとよいでしょう。言語仕様書は読み難いと思いますが、細部を知るには言語仕様書を読むしかありません。専門書については好み次第ですが、マイクロソフト公式解説書をお勧めします。
　マイクロソフト公式解説書の厚さに圧倒されるかもしれませんが、それだけに重要な事が沢山書いてあります。また正確さも折り紙つきなので、マイクロソフト公式解説書は必須と考えてもよいでしょう。マイクロソフト公式解説書以外はオライリー社の専門書がお勧めです。オライリー社の専門書も非常に頼りになります。堅い文体のものが多いのですが文体は直ぐになれます。見た目が簡単そうな専門書よりも、硬派な専門書を読む方が近道だと私は考えております。
　ただし、専門書にも人の嗜好がありますので、万人に適用できるルールはありません。本屋で現物を確かめる事をお勧めします。ネット上の評判が良い書籍でも貴方の好みに合わないかもしれませんし、ネット上の評判が悪い書籍でも貴方の好みに合うかもしれません。本当に必要な専門書は貴方だけが知っています。

インドリ流ソースコードリーディング

　ソースコードリーディングは実務や研究で良く行いますが、解説した記事や書籍が中々ないので自分で書く事にしました。先に断っておきますが、効果には個人差がありますし、状況によって最適な方法が異なります。基本的な事だけを書きますので、この記事を元に臨機応変に対処して下さい。
　私がソースコードリーディングで一番大事だと思う事は、早期に全体像を把握する事です。いわゆるトップダウン的な考え方です。理由は読むコード量を減らすのが早道だからです。また、注意力を高める為にターゲットを定めるという理由もあります。
　既存システム／ソフトウェアはコードが膨大なケースが大半です。しかし、時間は限られていますので、なるべく早く理解する事が求められています。その場合、ちょっとずるいかもしれませんが、一番早く読む方法は読まない事です。どれだけ早く読もうとも0秒にはかないません。一度に全てを読む必要はないケースが大半です。読まなくてもよいソースを読むと貴重な時間が浪費されてしまいます。読むべき状況で、読むべきソースを集中的に読むのが一番です。
　トップダウンに全体像を把握する方法は図示するです。図はUMLやマインドマップなど、何でもよいのでシステム／ソフトウェア全体を鳥瞰すると読むべきソースコードが分かりますし変更にも強くなります。元からあるソフトウェアで一番の問題はバージョンアップです。細かい単位でソースコードを読んでいると、バージョンアップした際に混乱してしまうでしょう。全体を鳥瞰しておくと、バージョンアップされても理解できますし、その優れたアーキテクチャ（設計思想）を理解して、自分の技術力を磨く事が出来ます。鳥瞰した後はボトムアップ的な考え方をします。
　全体像を把握し、読むべきソースコードが分かったら、もしくは初めから目的が定まっていたのならば、次はソースコード単位で読解します。ボトムアップ的なソースコードリーディングの方法は、コードを読んで動かすのが基本です。コードを動かして理解する具体的方法としては、テストを書く、解析用コードを埋め込む（所謂printデバッグ）の2つあります。
　テストを書くには、目的の関数／手続きをよく理解し、オブジェクトの初期化方法を知らねばなりません。自分の理解度を確かめる事が出来ます。ソースコードリーディングで大事なのは、自分が正しく理解しているかどうかです。それを確かめる一番の方法がテストです。テストが書けるのであれば、高い水準で目的のコードを理解している事の証明になります。また、安全にソースコードを修正する事が可能となります。
　解析用コードは軽視されがちですが、ソースコードを理解する上で大変有効な手段です。データの変化を見れば、コードの動きを詳細に理解する事が出来ます。ソースコードがあるのですから、積極的に自分が理解しやすいように改変しましょう。改選すると正常な動きをしなくなるかもしれませんので、念のためにソースコード管理ツールを用意すると万全です。
　その他の方法としてリファクタリングも有効です。自分好みにソースコードを変えると理解度が飛躍的にアップします。また長いコードを短くする事により読みやすくなります。応用技として、自分が興味のない処理をしているコードをばっさり切ってしまうのも良いでしょう。そうすればさらに意識を集中する事が出来ます。
　最後にソースコードリーディングを行う前に大切な事を述べます。問題領域の知識を得ておく事が大事です。ソースコードリーディングは準備も大事なのです。分かっていない事を理解する事は不可能です。問題領域の知識があれば、もしくはリーディングと並行的に行わないと処理内容が理解できません。問題領域の関する知識を学習する事を怠ってはなりません。情報処理技術は「情報命」です。
　駆け足でしたがソースコードリーディングの基本が分かったと思います。後は実践あるのみ！です。ソースコードリーディングを活用し、仕事と学習の効果を高めましょう。そうすれば、貴方への評価と、貴方の技術力は飛躍的にアップします。

ネタつつき96 - 情報伝達について

　私は色々な人に物を教えたり物事を伝えたりしています。それは社会人になってから直ぐの事です。一番最初の職業が研究者でした。世間一般のイメージでは、研究者が教育をし、人に何かを伝えるというイメージがないと思います。しかし実際は、自分が発明した技術や研究結果を発表しなくてはなりません。コミュニケーション無くして研究者は務まりません。もちろん、それから以後も伝えるという事から離れられない仕事をしています。そうした職歴から私は、教育・報告・連絡といった様々な情報伝達について日頃よく考えています。
　情報伝達は非常に難しい事柄です。情報伝達には相手がありますので、自分だけが頑張ってもどうにもなりません。自分が頑張ればどうにかなる技術的課題よりも難しいです。技術的課題は目標を定め、自分がその目標に向かっていくだけなので時間・資金・設備などの資源さえあればどうにでもなります。しかし、人間相手の情報伝達はそうはいきません。自分だけがベストを尽くしても相手に聞く気がなければどうにもなりません。それに加え、技術的課題とは違い、全力疾走で正しい事をすればよいわけではありません。相手は別の立場や思想を持っており正しさの基準さえ異なります。
　情報伝達の基本は相手がどういう存在なのかです。相手の事をよく考えて情報の選択をし、その情報を受け取りやすいように加工せねばなりません。情報伝達に於いて重要なのは、相手がその情報を受信可能かどうかという事です。自分の虚栄心を満たす為に情報伝達をするのは間違いです。ですから、自分の事は脇に置き、相手が主役だと考えて情報伝達を行います。
　情報伝達が下手な人は、自分の知識をアピールしたり、妙に学問的な正しさを強調したりして、相手の事を考えずに情報を送信します。しかしそんな事をしても自分の虚栄心を満たすだけであり、相手が受け取れない情報を送信するのは、時間の無駄以外のなにものでもありません。情報伝達の目的は、相手に情報を与える事であり、その目的が達せられないのであれば、情報伝達する意味そのものがなくなります。
　かくいう私も研究者になりたての頃は、自分が発明した技術の長所を学問的見地から述べる、お粗末なプレゼンテーションをしてしまった事があります。当然その結果は散々なものでした。重役は情報処理技術の専門的な事は分かりませんし、他社の技術者も研究開発した技術の説明を理解しきれませんでした。若き日の私が必死でプレゼンテーションして伝わったのは「よくわからんが凄い技術を発明したようだ。」程度の事でした。大失敗です。
　当初その失敗を私はよく理解していませんでした。空気の冷たさは肌で感じましたが、失敗の原因が分かりませんでした。後でプレゼンテーションの内容をよく検討しましたが、技術的には間違っておらず、発明した技術の特徴も全て述べていました。しかしそれが失敗でした。
　自社の営業マンから指摘してもらい漸く分かったのですが、「専門的に全ての事柄を網羅したプレゼンテーション」は、相手の事を何も考えおらず、自分語りしているだけの代物でした。相手が聞きたかったのはビジネス上のメリットであり、学問的な事はどうでもよい事でした。また、説明が長すぎるゆえに、何が重要で何が重要でないのかも伝わっていませんでした。人間の脳は興味がない話しをメリハリなく聞くのを拒否します。私は知らず知らずのうち、人間の脳が拒否する事を行っていたのです。
　この失敗から得た教訓は、自分が何をアピールしたいのではなく、相手が何を聞きたいのかを考えて情報を構成するべきだという事です。情報伝達に於いて主役は自分ではありません。相手が主役であり、相手に合わせて自由自在に情報を加工せねばならないのです。
　残念ながら私を含め技術職の人は、その情報加工が下手です。どうしても専門家としての見地から正しいのかを考えてしまいますし、細かい情報粒度で話しがちです。しかしながら、相手に伝わらなくては意味がありません。学問的な正しさはどうでもよいと言ってもよいぐらいです。情報粒度を粗くすると、学問的な正しさは犠牲になりますが、細かすぎると肝心な事が伝わりません。
　たとえば、プログラミングの技術解説をしている時、OSやコンパイラの実装まで詳細に解説すると、学問的に完璧な解説かもしれませんが、プログラミングの解説を期待している初心者には何も伝わりません。かといって、OSやコンパイラの存在を無視するのは不適切な場合があります。そうした情報選択と情報粒度の決定は、主題によって柔軟に決めなくてはなりません。
　もちろん、受け手も最大限の努力をしなければならない事は言うまでもありません。情報伝達は双方が相手の事を考える努力が必要です。耳をふさぎ、目を閉じている人には何も伝わらないのは当然の事です。その状態で情報を伝える事を目指すのであれば、脳に直接情報を刻み込むしかなくなるでしょう。
　纏めます。情報伝達は、相手の事をよく考え、適切な情報を選択し、適切な粒度で情報を加工しましょう。情報伝達の目的は相手に分かってもらう事であり、自分の虚栄心を満たすものであってはなりません。理論的な事ばかりに気を取られずに、主題が伝わるように柔軟な対応をせねばなりません。

初心者のためのC#プログラミング本格入門1 - 初心者の学習方法

　この記事は、初心者のためのC#プログラミング本格入門0の続きです。今回は学習方法について述べます。
　専門書を読んでもプログラミングが分からないという人の意見を聞くと、「学習方法が書かれていないから分からない」という意見がありました。そこで、初めに学習方法について書く事にしました。私がしている学習方法はプログラミング言語の関わった人が書いた本もしくは公式解説書を読み、その後で言語仕様書を読むという方法です。
　プログラミング言語もまたソフトウェアです。ソフトウェアには製作者の思想に基づき作られています。ですから、設計者の思想を読む事が一番の早道です。設計者の思想さえわかれば、半分以上マスターしたと言えると思います。残りの細かい部分は、言語仕様書でチェックすれば実務で困る事はありません。
　私はこの方法で1週間以内に、新しい言語を実務で使えるレベルまで習得する事が出来ます。具体的には、数時間で専門書を速読し、数日間仕様書とヘルプを参考にしながら実際にプログラミングをします。しかしプログラミングにゴールはありません。その後も実務で自分を鍛えつつ、コンパイラのソースコードやライブラリのソースコードを読みます。そうしていれば、仕事をする上で技術的な理由により困る事が殆どなくなります。実務で困難なのは、プログラミングで解決できる機械的な事ではなく、人間的な理由の方が多いのです。どの仕事も人間関係が一番大変です。技術職も例外ではありません。
　これは実務経験者が出来る学習法で、おそらく初心者が同様の事を出来ないでしょう。ですが、実務経験者は魔法使いではありません。実務経験者が短時間で学習できる理由があります。その理由さえ知れば、初心者でも比較的短時間で習得する事が可能となります。
　実務経験者が短時間で学習できる理由は、経験の差から生じるものです。新しいプログラミング言を素早く習得できるのは、それ以前に違うプログラミング言語を習得していた、もしくは何かの仕事で同様の事をしていたからです。どんな人間でも全く何も知らない状態から一瞬でマスター出来ません。人間の脳は魔法の道具ではありません。それ相応の脳をしていないと、正しく処理できるはずがありません。ですから、分からなくても初心者の人が気にする必要はありません。
　私が経験者の視点で見るべきポイントや考え方を書きますので、初心者の方はそれを参考に地道に勉強して下さい。学問に王道はありません。じっくり学習する姿勢で臨めば、それが自然と早道になります。肩の力を抜いて、プログラミングを楽しみつつ習得しましょう。

初心者のためのC#プログラミング本格入門0 - 序章

　私は職業柄色々な事を聞かれます。その中よく聞くのが、「プログラミングは難しい」、「C#は難しい」、「どうやって学習していいのか分からない」、「専門書を読んだが分からなくて挫折した」といった誠に残念な言葉です。これらの言葉を聞くたびに、プログラミングが大好きな私は勿体無いと思っています。何故ならば、プログラミングそのものは難しいものではなく、殆どの人ができるからです。プログラミングをするだけならば、才能や能力は関係ありません。おまけに非常に知的で楽しい行為だからです。簡単で楽しい事をやらないなんて損以外のなにものでもありません。
　しかしながら、現実にプログラミングが難しいと感じている人は沢山います。そこで私は、プログラミングが難しいという人の意見を聞いていました。その結果分かったのが、プログラミングそのものが難しいのではないという事です。難しく感じる原因は他の部分にあります。
　聞き手が相手の伝えようとする事を受け取る意思がない、聞き手の性格が歪んでいるといった特殊なケースを除いて、プログラミングを難しいと感じる原因は伝える側にあります。専門書やWeb記事といった媒体は基本的に一方向であり、聞き手が見えないという問題があります。
　何事でもそうなのですが、伝えるという行為は相手がどういう人なのかが大事です。聞き手に合わして表現を変えなくてはなりません。情報処理技術を知らないお客様と、同じプロ同士の表現方法は異なります。お客様に専門用語を並びたてても伝わりませんし、プロに対してお客様と同様に接すれば余計に伝わりません。
　ですが、技術解説記事の執筆者は相手が分かりません。Webは様々な人が自由に読めますから、どの様な人がその記事を読むのか分からないのです。それが原因でプログラミングを難しいと感じる人が出てしまいます。それを防ぐ事は原理的に不可能です。一つの記事で人類全てがプログラミングを簡単かつ楽しく学習する事は不可能です。しかし努力は出来る筈です。
　そこで私は構成を変えて、再びC#プログラミングの初心者用記事を書く事にしました。極力多くの人に伝わるように努力します。この連載で少しでも多くの人がC#とプログラミングを好きになって頂ければ幸いです。

オブジェクト指向分析とアーキテクチャの曖昧かつ親密な関係

　オブジェクト指向分析は一意で厳密な定義が存在しないため、判断が難しい事柄が沢山存在します。今回はそのうちの一つであるアーキテクチャとの関係について述べます。
　オブジェクト指向分析とアーキテクチャの関係は非常に複雑です。何故ならば、オブジェクト指向分析の定義が厳密でなく、アーキテクチャの定義も同じく厳密ではないからです。アーキテクチャと言っても色々な種類がありますが、ひとまずこの記事では「設計指向」としてのアーキテクチャについて考察します。
　先ずはオブジェクト指向分析のおさらいをします。オブジェクト指向分析は様々な解釈がありますが、共通しているのは現実をオブジェクトとして表現する点です。色々なオブジェクト指向方法論を学びましたが、私が知る限りオブジェクト指向分析は、問題をモデル化するという点では同じです。問題は分析の対象範囲です。オブジェクト指向論ごとに差異がみられますし、定義そのものが厳密ではありません。オブジェクト指向が難しい理由のうちの一つが、各工程の線引きが難しいという事が言えます。
　さらに問題を複雑化させているのは、既存システムと業務が密接に関係している事実です。情報化社会を迎えた今、まったく情報システムがない会社は珍しいです。情報システムと呼んでいない中小企業は沢山ありますが、そんな会社でもパソコンやExcelなどを使った、ある種の業務システムが存在しています。また、既存の情報システムが存在しない会社であっても、経営者の思想や業界人の習慣などから生まれた組織システムが存在します。
　さらに、問題領域の性質がオブジェクト指向分析の線引きを難しくします。OS・コンパイラ・DBMSといったシステムソフトウェアを分析する場合、現実は情報処理技術の中に存在します。システムソフトウェアは、使用方法をユーザーストーリーに定義し、人間世界の現実と技術的な現実を区別する事は理論上可能です。しかしながら、システムソフトウェアの使用方法はそれ程差異がなく、ユーザーストーリーを作成する意味はあるのですが、技術的側面から切り離して考える事は困難です。何故ならば、システムソフトウェアの焦点が技術そのものだからです。メインテーマである技術を切り離して考える事はできません。システムソフトウェアにとっては、技術領域そのものが現実なのです。
　そういった事から、アーキテクチャをオブジェクト指向分析と考えるのか、オブジェクト指向設計と考えるのかは難しい問題です。どちらで考えるのかはアーキテクチャの抽象度と問題領域によります。例えば、レイヤアーキテクチャは狭義のソフトウェアのモジュールとして考えた場合オブジェクト指向設計の産物です。しかし、もっと大局的に見て、エンドユーザーの業務体系が階層化している状態をオブジェクト指向分析すると、階層化されたオブジェクトモデルになります。
　そういった事から私は臨機応変に実利面を考慮して判断する事にしています。基本的にアーキテクチャはオブジェクト指向分析の青果物、もしくは発見されるモデルの構造と見做しています。そして、オブジェクト指向設計はデザインパターンが対応すると見直しています。その理由は、アーキテクチャとデザインパターンをオブジェクト指向設計に含めると混乱を生むからです。
　プロジェクトに参加する人全員がオブジェクト指向に精通していればいいのですが、現実はそう単純ではありません。色々なキャリアを持つ多種多様な人々が参加します。その状態で、アーキテクチャとデザインパターンの二つを、オブジェクト指向設計のもとしてプロジェクトを進めると、その二つの概念を混合して考える人や、意図が理解できない人がどうしても出てきます。ですから、アーキテクチャ＝分析、デザインパターン＝設計とシンプルに扱う必要があります。しかし、その定義は便宜上のものであり、臨機応変に対処しなくてはなりません。
　こういった曖昧な事柄は、オブジェクト指向分析とアーキテクチャの話題に限った話しではありません。それ故、情報処理技術は芸術と科学が混在した魔術とも言われています。その魔術にたとえられる情報処理技術に携わる我々情報処理技術者は、柔軟な思考を持ち臨機応変に対処せねばなりません。
　人は理系／文系、感情／理論などと二極化して考える傾向がありますが、情報処理技術者はその両方を情報として取り扱いましょう。物事は何でも二極化できるほど単純ではありません。私達情報処理技術者は硬直した考えを捨て、あらゆるものを情報として縦横無尽に活躍する事が求められていると私は思います。

実践的オブジェクト指向分析入門29

　この記事は、実践的オブジェクト指向分析入門28の続きです。前回は「継承を用いたオブジェクトクラスの組織化と単純化」を解説しました。今回は「アクセスパスのテスト」を解説します。
　今回までのオブジェクトモデル構築作業で、多くのオブジェクトを思考錯誤しながら定義する事になります。そうすると、不要なオブジェクトが残ったり、不必要なオブジェクト間の関係が定義されたりします。これらの整理整頓されていない情報を見直すために、アクセスパスをチェックしなければなりません。アクセスパスのテストを怠ると、分析作業でバグが生じる結果になります。その影響は計り知れないので、出来るだけ早い段階で分析作業にて生じたバグを取り除かなければならないのです。
　アクセスパスのテストはユースケースを用いて行います。ユースケースに記述したユーザストーリーに従い、オブジェクトの流れをチェックします。そうすれば、どのストーリーからも参照されない不要なオブジェクトや、不必要に複雑化しているオブジェクト間の関連を判別する事ができます。
　オブジェクトモデルを構築すると、不必要にオブジェクトが複雑化しがちです。しかし、オブジェクト指向分析の結果は、極力簡潔化しなくてはなりません。そうしないと、オブジェクト指向設計とオブジェクト指向プログラミングでさらに複雑化し、複雑さが手に負えないレベルにまで発展する恐れがあります。また、分析結果が複雑であると、プロジェクトメンバー間のコミュニケーションが阻害されます。分析結果の複雑化は良い結果を生みません。
　アクセスパスのテストを実施する事により、オブジェクトモデルを簡潔化し複雑さから生じる弊害を防ぐ事が出来ます。

アジャイル開発を元に考えるプロジェクトマネージャのあり方14

　この記事は、アジャイル開発を元に考えるプロジェクトマネージャのあり方13の続きです。前回は、プロジェクトマネージャが果たすべき役割を具体的に解説をしました。今回はその続きである、「新人でもそれなりに成果が出せる環境」について解説します。
　前回の記事にて「新人でもそれなりに成果が出せる環境」が大事であり、人員の流動が激しいプロジェクトでも生産性を上げる事が大事だと述べました。これからそれを可能にするにはどうすればよいのかを解説します。
　誰しも新人の頃は仕事の要領が分からず戸惑います。プロジェクトマネージャは、新人が戸惑わない仕組みを考える必要があります。プロジェクトマネージャは新人に対し、どの仕事をどのようにすればよいのかを, 具体的に指示出来なくてはなりません。ただ単に教育担当者を決め、その人に任せてしまうだけでは上手くいきません。
　担当者任せにしてしまうと、その担当者は方針が分からず困ってしまいます。さらに方針が分からない状態では、非効率的な指導方法にならざるをえませんので、担当者の生産性も落ちてしまいます。担当者の生産性を下げずに、新人でも生産できる環境をあらかじめ熟慮して決めなくてはなりません。その環境は会社に依存し、全ての会社に適用できる方法は存在しませんが、原則を述べる事は出来ます。
　基礎知識がない状態の新人を、プロジェクトに参加させないのが基本原則です。基礎知識は果たすべき役割によって異なりますが、ひとまず実装工程を元に解説を進めます。
　プログラミング言語の文法、開発ツールの使い方、仕様書や設計書の読み方、プロジェクトに関する知識、コミュニケーションの取り方は必須です。これらの基礎能力がない状態の新人をプロジェクトに参加させると、開発生産性が非常に落ちます。新人教育を効率よく行う手順および、知識の確認体制をあらかじめ熟慮しなくてはなりません。
　また、役割に関係なく新人に対して、セキュリティに関する教育もするべきです。クラッカーが新人に対して、ソーシャルエンジニアリングの手法によるクラック行為を行う可能性があります。強いコンピュータの権限を持ちがちな新人開発者は、特に目を付けられやすいので注意せねばなりません。

.NET並行処理プログラミング入門6

　この記事は、.NET並行処理プログラミング入門5の続きです。引き続きThreadクラスが持つ機能とスレッドの概念について解説します。
　早速ですが新しいスレッドの機能を紹介します。ひとまずサンプルを見て下さい。

using System;
using System.Threading;

class TimeStop
{
    static void Main( string[] args )
    {
        //約3000ミリ秒（3秒）間メインスレッドを止める
        Console.WriteLine( "時が止まる。" );
        Thread.Sleep( 3000 );
        Console.WriteLine( "そして動き出す。" );
    }
}

このサンプルコードを実行すると、まるで時が止まったかのようにプログラムが約3秒間停止し、その後メッセージを出力して終了します。メインスレッドの動きを止めたのはThread.Sleep静的メソッドです。
　Sleep静的メソッドの引数にはミリ秒単位の値を指定して実行します。Sleep静的メソッドを実行すると、引数で指定した値に等しいミリ秒間、実行したスレッドの動きを止めます。ここで注意してほしい事は、Sleep静的メソッドは正確な時間を保証できない事です。あくまでも約指定ミリ秒間、実行したスレッドの動きを止めるだけです。
　正確な時間を保証できない理由は、WindowsOSがリアルタイムOSではないからです。.NET FrameworkはOS上で動作していますので、リアルタイムな動作を保証しないOS上では正確に時間を管理できません。将来リアルタイムOSの上で動作する.NET Frameworkが登場した際には、正確な時間が期待できるかもしれませんが、ひとまず正確な時間を指定する事は不可能だと考えて下さい。続く...
　

情報処理で会社の業績を上げる方法

　以前最悪なのは社員があきらめる事の記事で状態が悪い会社について書きました。今回はその状態を打開する方法を書きます。
　社員があきらめてしまった状態が悪い会社を直すには、情報の流れを円滑化するのが最善です。その状態を人間にたとえると、血液の流れが悪くなった状態だと言えます。その状態を直すには血液の流れを正常化する必要があります。何故情報を血液に例えられるのかについては「情報とは組織／社会の血液である」を読んで下さい。これから情報処理によりこの状態を打開できる理由を詳しく述べます。
　社員があきらめてしまう理由は、自分が意見しても会社が変化しないからです。いくら愛社精神がある人でも、自分のアイデアが上司に盗まれたり、上司個人の利権を守るために握りつぶされたりすれば何時かあきらめてしまいます。そういった情報を経営者は知らないので、自分の利権を最優先に考え、会社の利益を二の次にする人に役職を与えてしまう羽目になります。
　全ての社員が会社の利益だけを考えていると、思う経営者はお人よしすぎます。個人の利益のために会社を利用しているあくどい人が居る事も念頭におかねばなりません。日本の会社は得てして、外部の事ばかり考え、内部の情報を疎かにする傾向があります。しかしそれは間違いです。
　帳簿だけを見ていても内部の情報は把握できません。戦後日本を経済大国へ導いた優れた経営者達は、そうした組織内部の情報も把握していました。古くは優れた戦国大名達も、自分の組織内の情報に関して非常に注意を払っていました。優れた経営者は組織内の情報を疎かにしません。いい加減な報道の影響もあり、情報＝冷酷という誤ったイメージが広まっていますが、本当の情報処理は人の心を重視します。人の心も情報です。人の心無くして情報システムとは呼べません。
　正しいイメージが世間に広まっていないので書きますが、実際のシステム構築は人の心を重視します。たとえば、昨今はセキュリティに関心が持たれていますが、セキュリティは機械だけがするものではありません。どちらかというと人間が行うものです。クラッカー（コンピューター犯罪者）は、基本的に機械を相手にせず、人間からセキュリティシステムを突破します。ですから、機械よりもそれを使う人間の方に重心を置いてシステム屋はシステムの構成を考えます。具体的には、セキュリティ教育をどのようにするのかや、日常の業務に支障を与えない範囲でセキュリティ対策を行う方法などを考えます。
　ここまで読んだ人の中には、戦国大名に出来るのならば情報システムなしで自分が判断するなどと、情報システムはいらないと感じる人が居るかもしれません。しかし時代背景が違います。昨今のビジネスは一分一秒を競います。より早くより各自に組織を動かさねばなりません。そのスピードに対応する為に、おのずと情報システムが必要となります。また、口下手で真面目な社員が居る事も考慮せねばなりません。情報システムがない時代は、口がうまい人が有利に働きました。しかし、情報システムを正しく構築しておくと、そういった表面的な事だけではなく、実利を考慮した経営判断が出来るようになります。
　会社が悪い状態になるのも、良い状態になるのも人と情報次第です。情報システムを活用し、組織内の血液を巡回させ、健全な会社を目指しましょう。そうすれば、自ずと社会から認められる立派な会社になるでしょう。