初心者のためのC#プログラミング本格入門37 - インスタンスの作り方

　この記事は、初心者のためのC#プログラミング本格入門36の続きです。前回は、オブジェクトと型について解説しました。今回は、型を使用する方法について解説します。
　前回、自分独自の型を定義する方法を解説しました。では、その型をどうやって使用するのでしょうか？答えは、「new演算子を使ってインスタンスを生成する」です。
　インスタンスというと、何か難しいものの様に聞こえますが、難しく考えなくてもプログラミングできます。感覚的に言うと、個々の数値の様なものです。例えば、数値という型があるとします。この場合のインスタンスとは、「１」とか「２」といった個々の値です。初心者の方はそういうふうに気楽に考えましょう。難しく考え先に進まないよりも、ひとまず前に進む事が肝心です。
　では、実際にプログラミングをしてみましょう。

class Program
{
    class Analyzer
    {
    }

    static void Main()
    {
        //型のインスタンスを生成
        Analyzer obj = new Analyzer();
    }
}

見覚えがあると思った人が多いと思います。それもそのはず、new演算子とインスタンスの作成は新しいものではなく、配列やSystem.Tupleのサンプルプログラムでもやっています。
　配列やSystem.Tupleの解説の時、手順としてやっていた事は、インスタンスの生成なのです。インスタンスの生成が、どのように役に立つのか気になる方がいるかと思いますが、それは学習を進めていくうちに徐々に分かってきます。今のところは、new演算子はインスタンスを生成しているとだけ覚えて下さい。

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

　この記事は、実践的オブジェクト指向分析入門36の続きです。前回は、機能モデルの構築について解説しました。今回は、機能モデルの構築で行う作業について具体的に書きます。
　私が所持しているオブジェクト指向方法論OMTについての解説本は古く、DFD（データフロー図）の作成が手順として書かれています。しかしながら、現状ではお勧めできない方法なので、実際に私がしているOMTの応用について書きます。
　最初にするべき作業は、現状のシステムの機能的な側面をユースケースとシーケンス図に書く事です。分析対象となるビジネスプロセスを選び、そのプロセスの概要をユースケースに書きます。そして、シーケース図に大まかな流れを書きます。ユースケースとシーケンス図はどちらを先に書いてもOKです。大まかな流れを把握したら、入力値と出力値に注目します。
　システムを機能として捉えると、様々な値がやり取りされているのが分かります。この値（オブジェクト）に注目すると、よりシステムの機能面を把握する事が出来ます。分かり難いと思いますので例を挙げます。
　例として商品の販売プロセスを考えます。お客様オブジェクトは、何らかの情報を元に店に来店します。そして、商品を選びレジで清算します。このプロセスは、お客様オブジェクトとレジオブジェクトとの間で、様々な情報（値）がやり取りされているのが分かります。また、お客様オブジェクトへ販売会社オブジェクトからの情報（値）が渡されているのが分かります。
　これらのプロセス内で発生する値（オブジェクト）に注目し、ユースケースとシーケンス図で書くと、システムをより詳細に分析出来ます。言いかえれば、機能モデルの構築とはやり取りされる情報の分析だと言えます。続く．．．

ネタつつき111 - システム屋が考えるエンジニアにとって必要な能力

　エンジニアにとって必要な能力は沢山あります。それらのうち、技術力とコミュニケーション能力がよく言われていますが、私はその２つの能力に関してはあって当たり前の能力だと考えています。技術者なのですから技術力がなければ話しになりませんし、かといってコミュニケーション能力がなければビジネスマンとして失格です。そういった細かい単位の能力ではなく、本当に必要な能力は、もっと抽象度が高いものです。かく言うシステム屋が考える能力とは創造力です。
　システム屋の私は既存の開発工程にとらわれない仕事をしています。システム屋のお仕事とは、お客様が望むものを提供する事ですから、細かい作業だけを見ていては仕事を達成できません。お客様の視点で考えると、工程云々の話しではなく「出来るか出来ないのか」しかありません。プログラミングは達成したけど設計は・・・などといった言い訳は通用しないのです。結果として役に立つシステムを提供できたか否かしかありません。ですから、もっと抽象度が高い視点が必要となります。
　私は度々「お客様の要望がまとまらない」という意見を聞いてきました。しかしそれは、ビジネスの世界では通用しません。何故ならば、受動的な態度ではプロのサービスとは言えないからです。厳しい言葉だと思いますが、私達が普段受けているサービスを思い返せば納得がいくと思います。
　私達が普段受けているサービスは、何を提供しているのかが明確です。お店へ入って「当方のサービスはお客様次第です」などと言われた事がありません。美容師ならば美容、病院ならば医療、販売店ならば販売などと目的がはっきりしています。一方、駄目なIT会社や駄目なシステム屋は「お客様が決める事で、自分たちは決めるまで何もしない」という受動的な態度を取ります。
　そういった人達は情報システムを曖昧なものだと言いますが、当のシステム屋がそれを口にするとビジネスはそこでお終いです。サービスを提供する側が曖昧で分からないものをお客様が購入する理由がありません。そんな得体のしれないものを買う人はいません。しかしながら、情報技術は柔軟性が非常に高く、応用範囲が広いのもまた事実です。ですから、その柔軟な技術を用いて創造する力が必要となります。
　情報システムは開発工程を経て製造するというのが定説となってしまっています。しかし定説を全面的に正しいと思えません。何故ならば、その根拠の元に受託開発は多重請負構造となり、様々なトラブルを生んでいるからです。それで使えるシステムが開発されればまだましなのですが、残念ながら使えないシステムは日々開発されているのが現状です。
　実際私はシステムを開発工程に沿って行っていません。お客様からの要望を聞くのと同時に、頭の中でシステムを完成させます。「要求定義が決まってから設計し、その後運用方法を考える。」などと悠長な事を言えば、お客様から「使えるかどうか分からないものなんて買えない」と一喝されてしまいます。交渉の場で「こういったシステムは如何ですか」と提案しつつ話しを進めなくてはなりません。ですから私は、お客様と話しをするのと同時に、全ての工程を頭の中で行いつつ交渉を進めます。
　また問題の解決方法は自分で作ります。情報サービスが他とは違う点は、情報技術が非常に柔軟で定まった形を持たない事です。ならば、提供者が形を作るしかありません。ですから、受動的ではなく能動的な態度をとる必要があるのです。
　私達情報技術者はクリエイティブなものを扱っています。ですから何よりも創造力が大切です。狭い視野で物事を考えず、広い視野でお客様が望むものを提供するよう心掛けましょう。

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

　この記事はアジャイル開発を元に考えるプロジェクトマネージャのあり方19の続きです。経営資源の内の一つお金とプロジェクトの関係について解説しました。今回は、経営資源「もの」とプロジェクトの関係について解説します。
　情報産業は人件費が主です。それが理由で「もの」を軽視している会社とプロジェクトマネージャが主流となってしまっています。果たして情報産業だけが「もの」を軽視してもよいのでしょか？
　結論を先に言うと、人件費が主であるからこそ「もの」に注意を向けるべきです。何故ならば、人件費が主であるからこそ、「もの」に必要な金額の割合が低く、それ故梃子の原理が働くからです。それを理解するには知識が少し必要となります。
　人件費の正体は作業時間です。たとえ月給制であっても、１月に達成した作業の数が変われば、１つの作業に費やした費用は変化します。ですから、人件費＝作業時間＊単価という法則が成り立ちます。という事は、個人の作業効率を上げればプロジェクトの利益率が高くなります。経営者がプロジェクトマネージャに求めているのは、プロジェクトの利益（どれだけ儲けたか）です。従って、プロジェクトマネージャは、プロジェクトがもたらす利益を最大化する事を考えなくてはなりません。
　そこで登場するのが「もの」です。システム開発で必要となる「もの」といえば、誰もがPCを真っ先に思いつきます。最近はPCが安く、遅すぎるPCで開発効率を下げるよりも、ある程度のスペックがあるPCを買い与えたほうが賢明です。しかし、必要な「もの」はそれだけではありません。開発系ソフトウェアも必要です。多くの人がここで考えを止めてしまいますが、実のところ会計的な「もの」はそれだけではありません。
　会計の観点からみると「もの」は一般に知られているよりも幅広く、資産全般を指す概念だと言えます。資産というのは、作業机、文房具から始まって、土地すらも含む概念です。従って、従来の残業ありきの「根性論」ではなく、作業効率を上げる環境を考えなくてはならないという事です。
　意外と知られていませんが、アジャイル開発はそういった幅広い「もの」も重視しています。アジャイル開発でよく言われている「もの」は、ホワイトボード、マルチディスプレイ、PC、開発用サーバー、明るい照明、カード、優れた文房具、オフィスのレイアウトです。
　日本では特に、オフィスのレイアウトが軽視されていますが、システム開発に於いてもオフィスのレイアウトは重要です。メンバーに直ぐに相談できる空間が必要なのはもちろんのこと、個人が集中できる環境が必要です。そういった事を考えるのがXPのファシリティ戦略です。
　システム開発は非常に高度な知的作業です。人間が快適に作業できるように熟慮する必要があります。人件費が主流を占める情報産業は特にこれが言えます。最大の費用である人件費を削減するには、小額の「もの」に対する投資を躊躇する理由がありません。残念ながら経営者はえてして、そういった実体を知りませんから、プロジェクトマネージャが開発者の代弁者にならなくてはなりません。偉そうに高みの見物をするのがプロジェクトマネージャの仕事ではないのです。開発メンバーに対する細かな気配りが必要です。
　ファシリティ戦略はアジャイル開発だけに適用できる概念ではありません。たとえアジャイル開発をしてなかったとしても、ファシリティ戦略は注目に値するものです。

ネタつつき110 - サイバーテロに弱い日本

　最近サイバーテロに関するニュースが目立ちます。ですが、セキュリティの本質が報道されていないので書く事にしました。結論から書くと、日本はサイバーテロに弱い体質をしています。
　サイバーテロを防ぐには、セキュリティを高めるしかありません。しかし、そのセキュリティの本質について余り知られていません。セキュリティといえば、非常に技術的なイメージを持っている人が多くいます。しかし、実際は技術的な問題にとどまりません。システムを運営する人間の意識がセキュリティに大いに関わってきます。
　日本の場合この意識が問題となってきます。日本は「安全神話」を掲げたり「無謬性」を信じたりと、およそセキュリティ意識とは対極の考え方をしています。セキュリティの基本的な考え方は、間違えは絶対にあり、性悪説の元永遠に対策し続けなくてはならないです。ここまですれば安全に違いない、悪い人はいない、信じれば大丈夫、ちゃんとしているから大丈夫・・・などと建前論もしくは理想損に走りがちな日本は根本から間違っています。
　そもそも、セキュリティが必要なのは悪い人がいるからであり、人間は間違える生き物だからです。安全神話などが真実であれば、セキュリティという概念は初めから存在しません。現状を簡単に言うと、家の鍵を閉めずに「泥棒なんていない。絶対に安全だ。」と言っているのに等しい状態です。この状態で「我が家だけは大丈夫」だという理論は、善い人が多くても一人の悪人がいれば破綻する理論であり、それは絶対にあり得ないという事が分かって頂けると思います。
　セキュリティ対策は、技術的な側面もありますが、人間心理や組織構造も範囲に含まれています。鍵（技術）だけがあってもそれを使わなければ（人間の運用）家にある財産（情報資産）は奪われてしまいます。そして、サイバーテロを仕掛ける真のクラッカーは、オタクではなく人間心理を熟知した社交的なエリートなのです。
　日本人は俺々詐欺にも騙され、原発は絶対安全だという言葉を信じ、誰かがなんとかしてくれると信じています。そういった「相手を信じる事から始める」だとか「自分の都合で物事が動く」という考えは、クラッカー（犯罪行為をする人）にしてみれば格好のカモです。つまり、日本ほどサイバーテロをしやすい国はないと言ってもいいぐらいなのです。
　セキュリティといえば、技術者を呼べば大丈夫だとか、セキュリティソフトをインストールすれば大丈夫だと考えている人が多いのですが、それを使用する人間がしっかりしていなければどうにもなりません。パソコンや情報システムは自分の意志を持たず、人間が適切な運用をしなければなりません。例えば、最高峰のセキュリティシステムを導入しても、権限を持つ人がハニートラップに引っ掛かればお終いです。日本では上のものを信じる傾向があり、権限を持つ人が悪い事をするわけがないと思っている節があるので、こういったソーシャルエンジニアリングの手法を使われるとひとたまりもありません。
権限を持つ人物（高い地位にいる人）が内部からセキュリティを突破する可能性も視野に入れねばなりません。そういった人を疑ってかかる組織のルールを考える事に関して、日本は非常に弱く、セキュリティ的な観点から見れば、最悪の虚弱性（弱点）を持っていると言えます。そして、クラッカーはその虚弱性を狙いますから、本格的なサイバーテロをされれば日本は壊滅すると考えなくてはなりません。
　日本の美点はお人よしな所だとも言えます。しかしながら、それも時と場合を選ばないとなりません。セキュリティ意識を高め、様々な犯罪絡みを守らないとなりません。犯罪者は待ってくれません。一刻も早くセキュリティ意識を高めましょう。

初心者のためのC#プログラミング本格入門36 - オブジェクトと型

　この記事は、初心者のためのC#プログラミング本格入門35の続きです。前回は、「自由に計算式を指定して計算するプログラム」をひとまず完成させ、繰り返し処理を継続する方法を解説しました。今回は、「自由に計算式を指定して計算するプログラム」を元に、オブジェクトと型について解説します。
　前回のサンプルプログラムは、System.Tupleを駆使したものでした。これでも一応動くのですが、Item3といった名前は分かり難いです。Item3という風な名前ではなく、Valuesなどといった名前の方が分かりやすいプログラムになります。それを可能にするのがオブジェクト指向プログラミングです。オブジェクト指向プログラミングは難しい概念ですが、少しずつ覚えて行きましょう。
　先ずはオブジェクトという用語を覚えましょう。オブジェクトとは、問題領域に存在するものを抽象化したものです。ちょっと難しいので段階的に説明します。
　問題領域とは、現在解こうとしている問題に関する事柄です。つまり、プログラミングしようとしている事柄がその範囲となります。ですから、オブジェクト指向プログラミングでは何をしようとしているのかという問題が重要視されます。
　抽象化とは、対象となるものの本質的な側面に集中するために、本質とは関係のない側面を無視することです。本質とは関係のない側面を無視するという所がポイントです。オブジェクト指向プログラミングでは、実現しようとしている事とは関係のないものを無視します。文章では分かり難いので、サンプルを使って、オブジェクト指向プログラミングで考える過程を解説します。
　初心者は一度に全てを考えようとはせず、一つずつ丁寧に手を動かすのがベストです。サンプルプログラムの全てではなく、気になる部分である「Item3」といった分かり難い名前を分かりやすい名前を変える事から考えます。
　初めに型を定義します。型というのは、今まで何度も指定してきた数値を表すint、文字列を表すstringなどの事です。実はこれらの型は自分で作る事が出来ます。早速、自分独自の型を作ってみましょう。

class 名前
{
}

//実例
class Analyzer
{
}	

定義の仕方は拍子抜けするほど簡単です。classキーワード＋名前＋{}を書くだけです。もちろん、やろうと思えば他にも色々指定できますが、問題と関係のない事は無視します。こういった抽象的な考え方が、オブジェクト指向プログラミングでは必要です。次回へ続く...

ネタつつき109 - システム屋から見たTPP

　日本はTPPについて、参加or不参加のお祭り騒ぎになっていました。TPPに参加したから野田総理は無能だとまでいいきった記者もいるぐらいです。私はそんな「お祭り」状態を冷めた目で見ていました。というのも、システム屋から見ればそれ以前の問題だったからです。
　私個人がTPP参加にどう思うかについては、決断そのものが「準備不足」だと考えております。何故ならば、参加or不参加を決めるための手順に不備があるからです。こういった国家間の契約について考えるには、現状は余りにお粗末すぎます。足りないものが多すぎるのです。
　1つめはTPPそのものの情報です。TPPの趣旨は分かりますが、それだけで契約を結ぶのか否かを考えるというのは軽率すぎます。企業間の取引において、双方の契約を「なんとなくわかるから」という理由で結ぶか否かを意思決定するという事はありえません。もし、企業のトップがその様な意思決定をするのであれば、株主からその能力を疑問視されるでしょう。すなわち、参加or不参加を考えるには、詳細な契約事項および、その契約がどのように変更されるのか（ルールの追加や削除手続きの把握）まで知らないとお話しにならないのです。
　むろん参加を決めた野田総理および国会議員は、全員がはTPPの細部まで把握しておられたと思いたいのですが、情報が主権者である国民に流れてこないのでマイナス評価しかつけられません。民間ではステークホルダーに説明をしない経営者は問題視されます。何故ならば、意思決定能力と合意させる能力がないと看做されるからです。
　これは、TPPの細部を報道しないで、ヒステリックに騒いでいたマスメディアにも当てはまります。先ずはTPPの細部（情報のソース）を提示し、結論を書かねばなりません。そうしないから、ワイドショーのノリで記事を書いているとしか思えません。従って、参加or不参加の結論そのものが信頼できません。
　次に国家戦略が不足しています。こういった契約は戦略に基づいて、参加or不参加を決めなくてはなりません。しかしながら、今に限った話しではありませんが、日本政府には国家戦略が提示された事がありません。民間ならば経営者はビジョンを示し、それに向かって歩を進めます。ビジョンを示すからこそ、ステークホルダーが付いてくるのです。ビジョンを示せない経営者は、ステークホルダーから能力を疑問視されます。
　昨今は政治不信だとよく言われますがそれは当然の話しです。国家戦略すら持たない国家に対し、信じろというのは非理論的すぎます。そんな子供じみた精神論で外交が出来るほどこの世界は甘くありません。各国が自身の国家戦略の下、日々競っているのにも関わらず、日本だけ丸腰で臨んでいるようにしか見えないので不信どころではありません。信じる要素がどこにあるのかと問いたい現状です。
　最後に参加を決めるまでの手順がお粗末すぎます。突然お祭り騒ぎになり、TPPに参加したという結果だけ伝えられてお終いになりました。これでは主権者である国民に対し、TPPについて考える必要がないと言っているのにも等しい状態です。工程が練られていない事実を鑑みると、日本政府は主権者を軽んじていると思えてなりません。むろんこれはTPPに限った話しではありません。選挙中だけ国民に対して媚を売ればいいと思っているのでしょう。しかしながら、民間の企業でこれをすれば経営陣失格と判断されます。
　私は前から疑問に思っていたのですが、なぜ国会議員達は自分たちの能力そのものを主権者に評価させないのでしょうか？仮に野田総理や民主党が英断をしたとしても、現状ではマイナス評価しかしようがありません。また、その状態を放置している民主党以外の政党についても、ステークホルダーに対して適切な行為をしていないのでマイナス評価しかしようがありません。普通の社会人は、自身の能力を評価してもらうよう働きかけます。この世は厳しく、評価できない時点で0点なのですから、能力を示さないというのは自殺行為にも等しい行為です。
「若者の政治離れ」などと報じられているのが目につきますが、非若者もこの様な稚拙な状態を許していたのですから、政治に対して適切な判断を下していません。「誰も真剣に国家について考えていない平和ボケした日本」というのが適切だと思います。
　日本の状態はTPPの参加有無以前の問題であり、まともな国家システムがない現状の方を先に考えるべきではないでしょうか？この恥ずかしいありさまは「日本人全員が悪い」のです。一刻も早く目を覚まして、国がどうあるべきなのかを日本国民全員が論ずるべきだと私は思います。

WFは何故シングルスレッドモデルなのか？

　WFを学習している人は、シングルスレッドモデルで動いている事を知っていると思います。では、何故シングルスレッドモデルなのでしょうか？多くの人がこの疑問にぶち当たると思います。そこで今回は、その疑問について、私が調べて分かった事を書きます。
　WFのスレッドがシングルスレッドモデルである理由について知るには、WFの動作原理と目標を理解せねばなりません。おさらいします。WFの最大の特徴はブックマークです。WFは距離に関係なく、プログラムの中断と再開を行えます。この素敵なブックマークは、.NETランタイム上のWFランタイムが制御する事により実現しています。
　ここまでの説明で、WFランタイムが鍵を握っている事が分かって頂けると思います。話しを元に戻します。話しの主役であるWFランタイムは、有限オートマトンであり、アクティビティをキューに格納して管理しています。シングルスレッドでなくてはならない理由がここにあります。ブックマークを有限オートマトンで実現するには、スレッドアジリティなのはもちろんのこと、プロセスアジリティでなくてはなりません。つまり、プログラムが特定のスレッドやプロセスに結び付いてはならないのです。
　スレッドが保持する変数をコンパイラとOSから見ると、メモリに割り当てられたスタック空間のデータです。このデータをプログラムから操作するには、特別な方法や手順が必要です。ここでWFが宣言的である事を思い出して下さい。特別な方法をWF側から用意すると、宣言的なプログラムではなくなってしまいます。
　なおかつ、距離に関係なくプログラムをブックマーク化するには、特定のプロセスと結びついてはなりません。何故ならば、リモートコンピュータのプログラムである事を意識すると、宣言的なプログラムでなくなるからです。いつどこでどのようにプログラムを実行するのかは、WFランタイムが管理する領域なのです。
　そして、利用者に意識させず、有限オートマトンでキューを操作するのは、ほぼ不可能と言ってもよいでしょう。もし、WFで真の並列処理を可能にしたければ、「位置独立性」、「拡張性」、「信頼性」の三つの要件を、プログラマに意識させずに満たさなくてはなりません。しかしそれをするには、高度な人工知能が必要となりオーバーヘッドが高すぎます。それが嫌ならば、プログラマが意識し、全てのアクティビティを位置に関係なく、並列でも正常に動くようにプログラミングしなくてはなりません。ですがそんな事をするぐらいならば、有限オートマトンの動作を考える必要がない、普通の並列プログラミングをする方が簡単です。
　纏めます。今のところ、WFの存在意義を保つには、シングルスレッドモデルでなくてはなりません。WF4には擬似的な並列処理をする方法が用意されていますが、WFランタイムが並列化しているように見せているだけです。これは悪い知らせの様に聞こえるでしょう。しかし、そうではありません。無闇にスレッドを使用すると大変な被害をもたらします。また、無闇に複雑化すると弊害の方が大きくなります。従って、WFがシングルモデルである事は利点が大きいと言えます。
　WFに限らず、制限は不便さだけではなく利点も生み出します。適切な利益を生み出すために敢えて制限を施したWFの設計思想と仕組みは、我々に多くの事を教えてくれます。

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

　この記事はアジャイル開発を元に考えるプロジェクトマネージャのあり方18の続きです。前回は、時間管理と見積もり技法について解説しました。今回は、経営資源の内の一つお金とプロジェクトの関係について解説します。
　システムを提供する側にとって、システムを開発する大きな理由は「儲けるため」です。営利企業は商売でシステムを開発しているのですから、プロジェクトが赤字になれば経営者はプロジェクトマネージャの能力に疑問を持つでしょう。ところが、非アジャイルの開発文化では、基本的には納品後に検品され、ある程度時間が経過したら売上になります。つまり、売掛金の期間が長く、回収できない危険性が高くなる傾向があります。また、その間にシステムを開発する側の資金が回らなくなります。
　この問題はビジネスモデルの問題であり、プロジェクトマネージャだけの責任ではありませんが、悲しい事に弱い立場の人間が責任を取らされているのが現実です。日本では特に失敗を考えず成功する事を前提にするので、プロジェクト失敗の根本的原因を考えず、形式的に誰かの頭を下げさしたり、誰かのクビを切ったりする会社が多々存在します。
　問題の根本原因は売掛金の期間が長い事ですから、仕掛品（製造途中の製品のこと）の状態のシステムでも価値を持たせればこの問題は解決します。この点に於いても、アジャイル開発の考え方は参考になります。
　アジャイル開発ではイテレーションと呼ばれる単位で開発を行います。イテレーションとは2週間程度の期間の事であり、この期間内でユーザーストーリーを実現します。そうすれば、お客様は進歩状況が分かりますし、要望とシステムのギャップも埋まります。また、イテレーションを基準とした個別契約を結ぶ事が可能となり、短い期間で売上が上がります。
　非アジャイル開発をしているところでも、スパイラル開発で同様の事を試みる会社もありますが、アジャイル開発とは違い、仕掛品でも動く所に重点が置かれていない（継続的インテグレーションという視点がない）ので、トラブルの原因となっています。
　この点から分かるプロジェクトマネージャの役割とは、仕掛品でも価値がある状態に保つ事です。プロジェクトマネージャと経営資源は切っても切れない関係であり、経営資源の内の一つお金についてもよく考えなくてはなりません。ビジネスモデルの甘さもあり、仕掛品でも価値を持たせるのは大変ですが、利害関係者にプロジェクトがもたらす価値を提示し続けないと、プロジェクト失敗と看做されます。
　マイナスの部分が目立ちますが、だからこそそれが出来れば、貴方のプロジェクトマネージャとしての価値が上がります。もし貴方が、その能力を評価されない会社に勤めているならば、辞めた方が得策なのかもしれません。

お気に入りのプリンターはEPSON製複合機

　年末に近付いてきたので、お勧めのプリンターを書きます。私が愛用しているのはEPSON製の複合プリンターです。




　私が持っているのは2世代ぐらいの前のものです。何年か前に私のプリンターが壊れてしまいました。プリンターがなければ仕事が出来ません。それで、急遽プリンターを買う事になりましたが非常に迷いました。
　プリンターは意外と沢山あります。しかも、仕事用のものですからいい加減には選べません。私は手順立てて考えました。
　先ずは、プリンターの使用目的をはっきりさせました。私が第1に望む事は、名刺・書類・年賀状・その他手紙を美しくかつ早く印刷する事です。あと、スキャナーの調子もおかしいので、種類と名刺をPCに取り込む事が出来れば助かります。
　次に考えたのは予算です。仕事で使うものですから費用対効果を考えます。高ければ書類を美しく印刷できますが、私のお仕事はシステム屋ですので、書類が最高品質の美しさになっても利益が増えません。それよりも大量の書類を印刷するので印刷速度が重要です。それらの条件を考えた結果、2万円前後で印刷スピードが早く、ある程度品質（dpi）が高く、出来ればスキャナー機能があるものがいいと結論付けました。
　選定基準が決まったら後は購入するだけです。早速私はネットでプリンターを検索しました。その結果、探し当てたのがこのモデルのプリンターです。2万円台でスキャナー機能までついていたのが気に入りました。もちろん、印刷スピードと品質もOKでしたし、デザインも好みのものでした。おまけに、使いやすくて言う事なしです。
　今のプリンターは正常に稼働しているので、また壊れたら同じモデルを購入しようと考えています。プリンター選びで困っている人は、一度このプリンターを見て下さい。きっと気に入ると思います。