2017年6月22日木曜日

勉強するということを表した画像に考えさせられる

勉強するということを表した画像に考えさせられる|@Heaaart - アットハート:

 今回の元記事はずいぶん前、2年ほども前の記事なのですが、「勉強する」とはどういうことなのかを表した秀逸な画像を紹介する記事があったので、ご紹介したいと思います。この元記事もさらに元を正せば@Hetare_Takumuさんのツイートだそうで、自分は知らなかったのですが、当時ネット上で話題になった画像なんだそうです。

 「勉強する」とはどういうことかを表した、その画像がこちら(↓)。能天気にお花畑を眺める人に対し、勉強して知識を持つ人にだけ見える世界がある。その世界は決してバラ色なんかじゃなく、世界的な環境破壊や国と国の諍い・経済格差・食料問題など様々な問題が見えているのかもしれません。

 ただこの画像だけでは、むしろ勉強なんかせずに麗らかなお花畑を楽しむ方がいいのではないかと思ったりしますが、実はこの画像には続きがあって、それがこちらです(↓)。

 勉強しない人が見ていたお花畑の世界、そして勉強した人だけに見える様々な問題を抱えて荒廃した世界、それだけで終わりではなかったのです。さらにさらに勉強を重ねた人だけに見えるのが、さらにその上の世界。それは、この世界が抱える様々な問題を解決する明るい未来かも知れませんし、悟りを開いた人に見える静かな水面のような世界を表しているのかも知れません。もう一つ、この画像が意図してか意図せずか分かりませんが、高く積み上げられた本は今にも崩れそうです。まるで知識だけに頼って見た未来は、ちょっとしたアクシデントでもろくも崩れてしまうことを示唆しているようにも見えます。

 人は、「勉強する」ことに理由を求める時期があると思います。例えば、高校受験や大学受験の勉強に苦しむときなど、なぜ勉強しなければならないのか、日常生活に困らない程度の知識があれば十分じゃないかという問いに悩まされる時があるでしょう。以前、学歴によって生涯賃金に大きな差があるという記事の中で、刹那的ですがいい大学を出れば生涯賃金が2億円も違うという事実も勉強の理由として説得力を持つと書きました。

 今回ご紹介した画像は、そんな刹那的で反面教師的な教えではなく、「勉強することで見える世界が違う」ということを的確に表現しています。40歳を超えて人生の半ばくらいまで経験した自分でも、この画像が示す「世界が変わる」というのはかなり説得力を感じます。生きている世界が違うとでも言いましょうか。

 同じようなことを、自分はよく「次元が違う」という表現をします。勉強している人としていない人、頭のいい人とイマイチな人は、「次元」が違うのだと。

 例えば現実世界にはいませんが、一次元の世界に生きている動物がいたとしましょう。この動物は、直線上を行ったり来たりすることしかできません。その一次元動物にとっては、例えばアリのように二次元の世界に生きる動物の存在を想像できません。概念すら無いと言う方が正しいでしょう。平面上を動くことができるアリが偶然にも一次元動物の移動可能な直線上に現れることがあるかも知れませんが、二次元動物のアリにとって一次元動物は認識可能ですが逆は普通は不可能というわけです。我々は縦・横・高さという三次元の空間に生きています(時間という概念を含めた四次元と言う人もいますが、ここはある程度自由に移動可能な軸のみを考えます。時間は一方向で、しかも自由には行き来できませんからね)。三次元動物の我々にとって、アリのような二次元動物も一次元動物も、そしてもちろん他の三次元動物もリアル世界における存在として認識できます。

 しかし、もし我々の知らない4つ目の次元があって、その四次元の世界に生きる動物がいたとしたら、その動物はたまたま三次元の我々の前に姿を表すことがあるかも知れませんが、我々からすればそんな四次元動物の存在は普段は認識することができません。四次元動物がどんな姿をしていて、どんな世界が見えているのかは我々には想像がつかないというわけです。我々がごく稀に宇宙人の痕跡を見つけるにもかかわらず宇宙人に正面切って出会わないのは、宇宙人が実は四次元以上の次元に住んでいるからだという説もあって、それはそれで説得力があると思いますが、その話はまた今度に譲りましょう。

 つまり言いたいことは、勉強している人としていない人、その違いは住んでいる次元の違いにもなぞらえるほど大きな溝があって、勉強している人の世界から勉強していない人の世界は認識可能ですが、その逆は不可能です。自分のレベルと同等かそれ以下のレベルは認識可能なわけですから、勉強すればするほど、頭が良くなればなるほど、見える世界が広がるということが言えるでしょう。一方で我々に与えられた命は等しいので、同じ時間の命を生きるのであれば、勉強して多くの世界が見える方が濃い人生を送ることができるのではないかと思うのです。

2017年6月21日水曜日

ついにメガバンクに「大失職時代」がやってきた!

ついにメガバンクに「大失職時代」がやってきた!(週刊現代) | 現代ビジネス | 講談社(1/4):

 山ちゃんウェブログでは、人工知能(AI)が人間の仕事を奪っていくという趣旨の話題を何度も取り上げてきました。今回もそのうちの1つですが、元記事は週刊現代によるものです。歴史ある大衆紙ですが、そういうところでもAIによって社会の仕組みがごっそり変わってしまう可能性を示唆しているのが面白いところです。

 取り上げられているのは、いわゆる「銀行員」という仕事。2013年「やられたらやり返す、倍返しだ!!」なんてキャッチコピーで一世を風靡したドラマ「半沢直樹」の舞台が大手メガバンクだったことは記憶に新しいですが、その中で銀行員という仕事は中小企業の社長よりもはるかに上位に描かれています。銀行からの融資に頼る中小企業の社長を一番下に、それを審査する銀行員がその上に位置し、その銀行員も自分の銀行に帰ればヒエラルキーの下の方に位置するという構図でした。ドラマの中だけでなく一般的にも、メガバンクの銀行員といえば、いわゆる頭脳派で高給取り、銀縁メガネに冷静な性格というようなイメージではないでしょうか。彼らは紛れもなく、社会の上層に位置するエリートです。

 そしてAIが奪っていく仕事は、まさにそんな「頭脳派エリート」の仕事です。従来より、肉体系ブルーカラーの仕事はその多くを機械に奪われてきました。もっとも体力的にツラい仕事は、機械に奪われるというより「肩代わり」させてきたという方が正しいかもしれません。そして銀行の事務作業もそうですが、ホワイトカラーの仕事の中で比較的単純な作業については、IT化の流れの中でコンピューターが肩代わりしてきました。日本ではいまだ重要な事務を紙の書類で行なうことが多いので、元記事にあるように人間の出番もまだまだあるのが現実ですが、米国などを見てみるとペーパーレスは確実に進んでいて、人間の出る幕はどんどん少なくなっています。そして、ホワイトカラーの中でも上位に位置する「頭脳はエリート」の仕事、具体的には今回話題に上がっている銀行員だけでなくトレーダーや医者・弁護士や裁判官など、頭がいいことをウリに社会のヒエラルキーの上位にいた人たちの仕事を奪っていくのがAIです。

 大手メガバンクの三井住友銀行は、今後3年間の間にITやAIをもっと取り入れて作業の効率化をはかり、約4000人を新たな事業部門に移すと言います。銀行はもはや以前のような「殿様商売」としていられる状況ではなくなり、なりふり構わずコスト削減に向かっているのです。従来の、顧客から預金を集め運用することで儲けるビジネスモデルは、経済の中でそうそう有望な投資先がなくなってきています。積み上がった預金で国債を購入して金利を受け取る利ザヤ商売も、日本銀行によるマイナス金利政策によって旨味は多くありません。そこで、投資信託や保険商品の手数料ビジネスや不動産ローン、カードローンといったところを収益の核にしようとしています。経営コンサルタントの加谷珪一氏によれば、銀行はジリ貧で、できることと言えばコスト削減しかありません。「銀行員」という頭脳派エリートに払っていた、高い給料を削減するためのAI導入と言うわけです。元記事では、みずほ銀行の管理職(40代)の言葉として、次のような談話が紹介されています。

単純な業務に関しては人間よりもAIのほうが正確で速いに決まっている。そうなると近い将来、これまでの銀行員が行ってきた業務は大きく様変わりするでしょう。
今は個人の資産運用の相談業務には行員が対応していますが、すぐにロボットが対応するようになるはずです。企業の有価証券報告書を分析するアナリストの仕事も必要なくなるかもしれません。また、資産運用を行うディーラーもいなくなり、AIが売買するようになるかもしれません。
最近は店舗でも、ATMコーナーに行列ができるほど混雑することはなくなりました。現金は銀行でなくともコンビニで引き出すことができるし、そもそもスマホなどで決済するケースも増えているからでしょう。
銀行の店舗は街の中心地にありますが、多くの人が現金を使わなくなれば、店舗は要らなくなりますし、何台ものATMを置いておく必要もなくなる。いずれ支店は半減してしまうのではないか。私自身も近い将来、どんな仕事をしているのか、想像もつきません。

 融資の審査や書類の作成を行なってきた人。その書類にハンコを押すだけの中間管理職。これまでの銀行業務の「中心」にいた人材から用済みになります。確かに銀行特有の煩雑で複雑な書類作りのノウハウなどがあるのでしょうが、それもルールが変わったら用済みになるノウハウです。ルールが変わっても新しいルールのもとで力を発揮できる人材、そういう人材だけが生き残っていく世の中になるのかもしれません。

2017年6月20日火曜日

エンジニアが「見捨てたくなる」発注者の特徴とは?

エンジニアが「見捨てたくなる」発注者の特徴とは? | システムの「外注」成功の鉄則 | ダイヤモンド・オンライン:

 今回の元記事は、細川義洋氏が自らの著書「システムを「外注」するときに読む本」を宣伝したものですが、自分のようなメーカー系ソフトウェア開発でも多かれ少なかれそういうところがあると思ったので、ITシステムの発注者に関して考えてみようと思います。細川氏のタイトルには「エンジニアが発注者を見捨てる」という刺激的な言葉が踊っていますが、お金をもらってシステムを作り上げるプロであるべきITベンダーのエンジニアが、「発注者=お客様」を見捨てるなんてそんな不遜なことが本当にあるのでしょうか。

 この問いに細川氏は明示的には答えていませんが、タイトルからも文脈からは明らかにYesというご意見、少しフィールドは違いますがソフトウェア開発という立場にいる自分も、おそらくこれはYesなのだろうと思います。「お客様を見捨てる」というほどではなくても、受注側も人間ですので「本気を出していない」というプロジェクトはおそらくあるだろうと思います。

 プロジェクトに本気を出していなくても、そこはITのプロですから、露骨でない程度・契約上の違反にならない程度に「手を抜く」ということになります。そうして「手を抜いて」作られたシステムは、発注者側にとって「負の遺産」になってしまいます。手を抜かれたプロジェクトに共通するのは、要件定義ではユーザーや業務のことを表面的にしか捉えず、基本設計や詳細設計もやっつけ仕事でどこかのプロジェクトの雛形を使い回したもの、実装に至ってはほとんど二次外注に丸投げで動けばいいやというソースコード。いい加減な設計・実装は試験工程で問題が出ますが、出る杭を打つ方式でもって何とか不具合を抑え込む。出来上がったシステムは、ある不具合を直せば別のところに不具合が出てしまう絶妙なバランスの上で何とか動いているシステムで、おいそれと機能追加や不具合修正もできません。運用工程になって顧客側ユーザー部門から不満が噴出しても、発注者のIT部門担当者はもう後の祭り。ITベンダーを問い詰めても、「契約は履行しました」「不具合の修正やユーザーのための機能追加・修正は別途お見積もりです」とそっけない対応。改善や機能追加には法外な見積もり金額が提示される... 結局、何千万・何億と掛けて構築したITシステムは使い物にならず、ドブに捨てたも同然だったり、丸々作り直しなんて笑えない話もちらほら。

 世の中には、そんな不幸なITプロジェクトもたくさんあると聞きます。もちろん、仕事としてITシステム構築を請け負っているベンダー側にも責任があるでしょうが、ITベンダーのエンジニアだけを責めても仕方ありません。ITシステムの構築は、単なる買い物ではないのです。どちらかというと家を建てる時の設計・工事発注に近いものがあります。ITシステム発注者の立場にある方は、あなた自身の自宅を建築する設計付き工事だと思ってみてください。お金を出す側だからと言って、ご自宅の設計・工事を他人事のように「まぁ上手くやってくれ」なんて他人事の態度でいられるでしょうか(よほどのお金持ちはそうかもしれませんが、自分を含め多くの人はそうは行きません)。お風呂にはこだわりたいとか、スペースを有効活用した間取りにしたいとか、子供が遊んでいるところをキッチンから目が届くようにしたいとか、ベランダでバーベキューするのが夢だったとか、太陽光発電でエコに貢献したいとか、...とにかく自分の家であれば、「思い」を設計事務所や工事業者にたくさんぶつけられると思うんです。もちろんその夢を全て予算の中で達成するのは難しいかもしれませんが、そこで設計・工事業者との交渉をたくさん行なうことになります。そのときの発注者の強い「思い」こそが、設計・工事業者側を本気にさせるのです。

 それなんです。ITベンダーのエンジニアは、これから作り上げるITシステムに「思い」をたくさんぶつけてくれる発注者に本気を出すのです。発注担当者の「思い」が無くどこか他人事という態度は、今回のシステムは大して重要なシステムじゃないんだという無言のメッセージになって、ITエンジニアたちをシラけさすことになるのです。

 発注担当者として、コンピューターやネットワークといった最新技術を駆使したITシステムのプロジェクトを成功させる一番のカギは、技術に精通していることでも業務に精通していることでもなく、「思い」というとても人間的で感情的な部分にあるのではないかと思うのです。

2017年6月18日日曜日

“人類最後の職業”はプログラマーだ――プログラミングを学ぶ意味とは

“人類最後の職業”はプログラマーだ――プログラミングを学ぶ意味とは | 文春オンライン:

 この山ちゃんウェブログでも、人工知能(AI)が人間の仕事を奪っていくという方向の話をいくつも取り上げてきました。体力のある人が得意とする肉体系の仕事は機械が、体力派ではないものの単純な事務処理は従来のコンピューターがその仕事を奪ってきました。現在のビジネスの世界で高給を取っているのは基本的には頭のいい人なのですが、そんな頭のいい人が高給で迎えられてきた頭脳系の仕事すら今後はAIが奪っていくと考えられています。人間に残されるのは、体力系もダメ、単純作業はダメ、頭脳系もダメとなったとき、いったい人間に残される仕事とはいったいどんな仕事だろうかと考えたとき、大きく次の2種類の仕事ではないかと考えています。1つはコンピューターやAIのおこぼれにあずかるような仕事(例えば、機械やコンピューターのメンテナンスなど)です。そしてもう1つは、体力でもなく頭脳でもない才能が評価されるような仕事(例えば芸術方面や宗教方面、水商売系など人間の心をいやすような仕事)ではないかと。

 そして今回取り上げさせていただいたのは、カドカワ株式会社代表取締役社長の川上量生氏による、プログラマー最強説です。プログラマー最強と言われると、現在のプログラマーという職業に就いている方々から、プログラマーなんて「IT土方」はやめた方がいいですよなんてコメントが付くかもしれませんが、ここで言う最強とは、いずれ機械・コンピューター・AIに取って代わられる体力系・単純作業・頭脳系の仕事の中では、最後まで残る部類の仕事ではないかという意味です。つまり、人間からAIに頭脳系仕事の主体が変わっていく過渡期においては、AIに指示を出す人間つまりはプログラマーが重要な役割を果たすということです。もちろん川上氏は、すべての人間がプログラマーになるべきだなんて言われているわけではありませんが、それでもプログラミングを学ぶことはすべての人が行なった方がいいと言われており、自分のそのご意見には全面的に賛成します。

 ある意味逆説的でとてもあまのじゃくな言い方ですが、自分が思うすべての人が「プログラミングを学ぶべき」というのは、必ずしもプログラミングそのものを身に付けることが目的ではありません。いわゆる汎用AIとか強いAIと呼ばれるような、そこに魂が宿る種類のAIが世に出てくるのはまだまだ当分先です。現在のAIは機械学習をベースにしたもので、途中の学習の過程が人間に追い切れないという意味で意思を感じられる場合もありますが、極論すればあくまでも電卓の延長線上ではあります。AIに仕事をしてもらいたければ、コンピューターを使う人間の側が仕事を定義したりデータをそろえたり、うまくいかない場合のデバッグさえ人間が行なう必要があるのです。何となくAIと言えば万能で、声で命令すればそれを理解して仕事をやってくれそうに思いますが、それはあくまでもサービスとして誰かが膨大な仕事をしたから可能になっていることです。つまり、当面の間はAIやコンピューターの強力な頭脳や知能を使うためには、人間側がかなりコンピューターにすり寄って行かなければなりません。そして、コンピューターへのすり寄り方を一番効率よく学べるのが「プログラミング」だと思うのです。

 川上氏が言われるのは、まわりに溢れているコンピューターの気持ちを理解できることが、これからの人間に必要な能力だということです。現在様々な企業の採用面接で重要視されている能力の一つに「コミュニケーション能力」がありますが、それは人間との関わりがない仕事はほとんど無いためでしょう。これからはコンピューターとの関わりがない仕事もほとんど無くなってくるでしょうから、人とだけでなくコンピューターとのコミュニケーション能力も重要になってくるはずです。そんなコンピューターとのコミュニケーションを学ぶには「プログラミングを学ぶ」ことが一番の近道だと思うのです。

2017年6月16日金曜日

超巨大スタートアップGE - ソフト開発のアウトソーシングを全面否定するGE

超巨大スタートアップGE - ソフト開発のアウトソーシングを全面否定するGE:ITpro:

 今回の話題はソフトウェアのアウトソーシングということについての是非論です。自分自身の仕事が電機メーカーのソフトウェア開発者という立場であることもあって、この山ちゃんウェブログでは以前に、企業は望むと望まざるとにかかわらず、いかなる業種・業態であれ、ソフトウェアという土俵で戦うことになるという趣旨の記事を書いたりしました。その中で、プログラムを書けるレベルのソフトウェア的思考回路は、非ソフトウェア企業のビジネスマンにとっても必須の能力になるだろうと言いましたが、今回のゼネラルエレクトリック(GE)のソフトウェア内製化という方針転換は、自分の持論を裏付けてくれるような気がします。元にしているのは、中田敦氏によるITproの記事です。

 まずは元記事に掲載されている、GEのジェフ・イメルト会長兼CEOの言葉を以下に転載させて頂きます。

産業界の多くの企業が20年前に進めた『デジタル筋肉(マッスル)』のアウトソーシングが、今日には敗者であると我々は学んだ。今後、GEのすべての新規採用者はコード(プログラミング)を学ぶことになる。彼ら全員がソフトウエアを書けるようになるとは期待していないが、デジタルの未来における『可能性の芸術(アート)』は、必ず理解しなければならない。

 実はイメルト氏のこの言葉は、これまでの産業界の常識とは全く逆を行くものです。80年代以降、多くの企業がソフトウエア開発のアウトソーシングを進めてきました。日本でもいまだオフショアなんて言葉を使って、インドなど海外に製品プログラムさえも外注するケースが多く見られます。自分の勤める会社でも、製造と合わせてソフトウェアの設計開発を関連会社などへ移そうという動きがあります。その最大の目的はコスト削減。ソフトウェアの設計製造はそのほとんどのコストが人件費ですので、大企業では自社の社員より安い給料で仕事をする外部(海外も含めて)へ委託するケースが多いのが現状です。

 しかしここへ来て、GEはソフトウエア開発のアウトソーシングを全面否定しました。さらに、今後は営業や財務、業務部門など部門も含めて、全員がプログラミングのなんたるかを理解して、デジタル化を実現するすべを理解しなければならないとまで主張するのです。全く正反対への方針転換と言ってもいいでしょう。

 トップの言葉を裏付けるかのように、GEは2011年カリフォルニア州サンラモンにソフトウエア開発拠点を開設し、2000人ものソフトウエア開発者やデータサイエンティスト、デザイナーをかき集め、同社が推進するインダストリアルインターネット(IoTの産業版を表す言葉)を実現するためのプラットフォーム「Predix」や、その上で動く様々なアプリケーションを開発しています。

 アウトソースからインソースというこの方針大転換は、一体どういうことなのでしょうか。GEのファウラーCIOは、情報システムの74%をアウトソーシングしていたことを「ナレッジキャピタル(知識の資本、蓄積)」を失う行為だったと振り返ります。

 リーマンショック以来の先行きが読めない世界では、アイデアを早く実装して顧客に試して貰い、フィードバックを得て良いものへ改善していくというアプローチが取られます。シリコンバレーでは「リーンスタートアップ」と言われる考え方で、仮説の構築・製品の実装・軌道修正という過程を迅速に繰り返すビジネス開発手法で、最近は日本でもPoC(Proof of )なんていう言葉で同じようなことをやっています。簡単に言えば「お試し」なのですが、試食とか試着のような製品を試してもらうよりも、顧客に試してもらって改善点を見つけフィードバックすることで一緒に製品やサービスを作り上げて行こうという考え方です。

 そのために必要なのは、アイデアを素早く実装し顧客からのフィードバックもすぐに実装に反映させる極めて高い「ソフトウェア開発力」です。アイデアも顧客から得られたフィードバック(中田氏は「学び」と表現されています)も、それを反映した実装(ソフトウェア)こそがキモです。「ナレッジキャピタル」と言う言葉は、日本では様々な人が知を持ち寄って交流することで新たな価値を生み出す場というような意味で使われるケースもありますが、ファウラーCIOのうところのナレッジキャピタルは文字通りの「ナレッジという財産・蓄積」という意味で、ではナレッジとはどういう形で蓄積されるのかと言えば、それは「ソフトウェア」という形なんだというわけです。

 自分は、IoT時代の産業ビジネスの世界では、製造業だけでなくサービス業・農業までもが、その競争力の源泉はナレッジなんだと思います。そして、ナレッジを実装したものがソフトウェアですから、ソフトウェア開発力というのは企業の競争力そのものと言うことができると思います。そう考えれば、他社との差別化を行なうための競争力の源であるソフトウェア開発を外部に依存する「アウトソーシング」では、ビジネスの世界を勝っていくことはできません。自分がソフトウェア開発者と言う立場なのでついつい手前味噌になってしまいますが、企業の競争力の源は「ソフトウェア開発力」だということを、日本企業の経営者も噛み締めてほしいものですね。

2017年6月15日木曜日

[C#] Excelファイルを簡単に読み書きする方法

 今回は久しぶりの元ネタなし、プログラムそのものに関する話題です。今回解こうという課題は、C#のプログラムでExcelファイルの内容を読んだり書いたりしてみようというものです。とは言っても、Excelファイル上のグラフや図などを相手にするのではなく、単にセルに入力された文字列を取得したり、セルに書き出したりという基本動作だけのシンプルなプログラムを作ってみます。

 手元にはちょっと古いVisualStudio2010しかなかったので、これでやってみますが、もちろんもっと新しいバージョンのものを使っても一向に構いません。Excelファイルをプログラムから読み書きするために、Microsoft.Office.Interop.Excelというライブラリーを使用します。ソリューションエクスプローラー上で [参照設定] を右クリックし、こんな画面(↓)からMicrosoft.Office.Interop.Excelを追加してください。

 それではプログラムを書いてみましょう。直接Microsoft.Office.Interop.Excelを扱うのは面倒なので、ExcelAccessorという名前のラッパークラスを準備してみます(↓)。コンストラクタでExcelファイルのパスを指定し、セルの値にはインデクサを使用してアクセスします。Microsoft.Office.Interop.Excelの中ではセルはRangeというクラスのオブジェクトですが、扱いが面倒なのでここでは文字列で扱うことにしましょう。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Microsoft.Office.Interop.Excel;
using System.Reflection;
using System.Threading;
namespace Yamachan
{
    public class ExcelAccessor : IDisposable
    {
        private Application excelApp;
        public Workbook Workbook
        {
            get;
            private set;
        }
        public Worksheet SelectedSheet
        {
            get;
            private set;
        }
        /// <summary>
        /// セルの値。インデックスは1始まりであることに注意。
        /// </summary>
        /// <param name="row">行番号(1始まり)</param>
        /// <param name="column">列番号(1始まり)</param>
        /// <returns>セルの値</returns>
        public string this[int row, int column]
        {
            get
            {
                if (SelectedSheet == null) return string.Empty;
                Range range = SelectedSheet.Cells[row, column] as Range;
                return (range==null || range.Value == null) ?
                                string.Empty : range.Value.ToString();
            }
            set
            {
                if (SelectedSheet != null)
                    SelectedSheet.Cells[row, column] = value;
            }
        }
        /// <summary>
        /// コンストラクタ。
        /// ファイル名を指定してExcelファイルをオープンします。
        /// </summary>
        /// <param name="path">オープンするExcelファイル</param>
        public ExcelAccessor(string path)
        {
            // エクセルファイルをオープン
            excelApp = new Application();
            excelApp.Visible = false;
            Workbook = excelApp.Workbooks._Open(path, Type.Missing,
                Type.Missing, Type.Missing, Type.Missing, Type.Missing,
                Type.Missing, Type.Missing, Type.Missing, Type.Missing,
                Type.Missing, Type.Missing, Type.Missing);
            // 最初のシートを選択状態にする
            if (Workbook != null && Workbook.Sheets != null
                    && Workbook.Sheets.Count > 0)
                SelectedSheet = Workbook.Sheets[1] as Worksheet;
        }
        /// <summary>
        /// シートを選択します。
        /// </summary>
        /// <param name="sheetName">選択するシート名</param>
        /// <returns>選択されたシート</returns>
        public Worksheet SelectSheet(string sheetName)
        {
            if (Workbook == null || Workbook.Sheets == null) return null;
            foreach (Worksheet sheet in Workbook.Sheets)
            {
                if (sheet.Name == sheetName)
                {
                    sheet.Select(Type.Missing);
                    this.SelectedSheet = sheet;
                    return sheet;
                }
            }
            return null;
        }
        /// <summary>
        /// Excelファイルをクローズします。
        /// </summary>
        /// <param name="save">上書き保存する場合true</param>
        public void Close(bool save)
        {
            SelectedSheet = null;
            if (Workbook != null)
            {
                Workbook.Close(save, Type.Missing, Type.Missing);
                Workbook = null;
            }
            if (excelApp != null)
            {
                excelApp.Workbooks.Close();
                excelApp.Quit();
                excelApp = null;
            }
        }
        #region IDisposable メンバ
        /// <summary>
        /// このアクセッサを破棄します。
        /// </summary>
        public void Dispose()
        {
            Close(false);
        }
        #endregion
    }
}

テスト用に準備したExcelファイルはこんな感じ(↓)。A〜C欄にそれぞれ英語・日本語・数字で適当な値を入れてみました。Test.xlsxという名前をつけてexeファイルと同じディレクトリに入れます。

 それでは、Excelファイルのセルの文字列を取得するテストプログラムを書いてみましょう。ExcelAccessorはDisposableインタフェースを実装したので、using節を使用してクローズし忘れを防止します。「テストシート」という名前のシートを選択してから、インデクサを使用して2次元配列であるかのごとくセルに入力された文字列を取得します。注意しなければならないのは、プログラマーはインデックス0から始まることに慣れていますが、本家のMicrosoft.Office.Interop.Excelでインデックスが1から始まるのに合わせて、ExcelAccessorのインデクサでも1始まりを使用していることです。1始まりが気持ち悪いという人は、ExcelAccessor側で0始まりになるよう調節するといいかもしれません。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.IO;
namespace Yamachan
{
    class Program
    {
        static void Main(string[] args)
        {
            using (var excel 
                = new ExcelAccessor(Directory.GetCurrentDirectory()+"\\Test.xlsx"))
            {
                excel.SelectSheet("テストシート");
                for (int row = 1; row <= 2; row++)
                {
                    for (int column = 1; column <= 3; column++)
                    {
                        Console.WriteLine("["+row+", "+column+"] "+excel[row, column]);
                    }
                }
            }
            Console.ReadLine();
        }
    }
}

 さて、このプログラムの実行結果はこんな感じです(↓)。プログラム最後のConsole.ReadLine()は、テストプログラムが一瞬で終わってしまうのでコマンドプロンプトが閉じないようにしているだけです。この状態から何か入力して(入力しなくても)エンターキーを押せば、ウィンドウが閉じます。どうですか、簡単に各セルに入力された値が文字列として得られました。


 さて次は、このファイルのセルにプログラムから何か文字列を書き出して見ましょう(↓)。今度はちょっと横着して、Mainメソッドのみ。注意すべきは、ExcelAccessorはDispose()メソッドはファイルを上書きしないように閉じる実装にしたので、上書き保存したい場合は明示的にClose()メソッドにtrueを渡してファイルを閉じなければならないことくらいでしょうか。これも、そういう実装が嫌な方は、Dispose()でも上書きする実装にしてもいいかもしれません。

        static void Main(string[] args)
        {
            var excel = new ExcelAccessor(
                Directory.GetCurrentDirectory() + "\\Test.xlsx");
            excel.SelectSheet("テストシート");
            excel[3,4] = "書込み";
            excel.Close(true);
        }

 このテストプログラムを実行すると、Test.xlsxファイルはこんな風に(↓)プログラムから書き出された文字列がセルに入っています。

 自分が扱っているシステムでは、いまだに帳票をExcelファイルで出力したり、データ一括入力をExcelファイルから行なったりしていますので、簡単にExcelファイルを扱えるExcelAccessorクラスは使いまわして重宝しています。ExcelAccessorはセルの値を文字列で読んだり書いたりするというだけのシンプルな機能ですが、例えば、あらかじめフォーマットを作り込んだマスター用Excelファイルをコピーしてそこに帳票データを書き込むとか、アンケートにユーザー答えを入力してもらったExcelファイルをプログラムが読み取って集計したりなど、以外にもこのシンプルな機能だけで十分なケースが多いように思います。

2017年6月14日水曜日

プロジェクトリーダーとプロジェクトマネージャーの違い、あるいは会社にとって死活的に大事なのはどちらか?

プロジェクトリーダーとプロジェクトマネージャーの違い、あるいは会社にとって死活的に大事なのはどちらか?:プロジェクトマジック:オルタナティブ・ブログ:

 今回の話題は、IT系業務におけるプロジェクトリーダーとプロジェクトマネージャーの違いを説明した白川克氏の記事を元に、少し仕事の愚痴も入りますが自分のような電機メーカーの開発現場もIT系と近い問題があるという話題です。少し愚痴っぽいかも??

 まずプロジェクトリーダー(PL)とプロジェクトマネージャー(PM)のイメージを元記事から転載させて頂きます(↓)。当たり前ですが、PLとPMの違いはリーダーとマネージャーの違いなわけですから、前者はプロジェクトを導く立場、後者は管理する立場ということになるでしょう。

 白川氏によれば、日本ではPMがPLよりも役職的に上であることが多いので、「名目上の偉い人≒PM」で「実際に現場を取り仕切る人≒PL」というように見られがちですが、本来のあるべき姿は、PM・PLというのは「仕事内容の違い」であってエラさの違いではありません。しかし自分のところもそうなのですが、古き良き日本企業は「エラい=マネージャー」というのが刷り込まれていますので、実際にはプロジェクトのことなど分からないがエラい人というのをPMというポジションに祭り上げておくということはよくあります。つまりPMとは名前だけの人で何もしない(たまに工程表をチェックして、遅れを取り戻せとゲキを飛ばすだけ)、実際にはPLとされる人がPMとPLを兼ねるというのが実態であることが多いと思います。

 本来の定義におけるPLとPMを見たとき、「よそ者」でも務まるのがPM・内部の人しか務まらないのがPLと言えるかもしれません。古き良き日本企業で、無能だが役職だけエラい人がPMにおさまりいいのも、プロジェクト固有の課題や問題点・解決方法といった部分には入り込まず、全てのプロジェクトでも共通的に必要なPDCA(Plan・Do・Chech・Action)を回すことが仕事です。アメリカなどではPMという仕事それ自体がプロの仕事として認知されていますが、それでもPMは「外から買ってくることができる」と言われるのはそのためです。それに対してPLは、チームをまとめゴールまで導くリーダーですので、経営層や関連部署などの関係者を巻き込んで彼らを納得させ、チームメンバーにやるべきことをやってもらい、次々と起こる問題を乗り越えながら狙い通りのITをつくり上げるのです。つまりPLは使い回しをすることができない、あるプロジェクトで素晴らしい力量を発揮したPLがいるからといって、彼を全く別部署のプロジェクトに引っ張ってきてもうまく力量を発揮させられないのです。それはそうですよね。全く門外漢なプロジェクトにヘッドハンティングされても、利害関係者とのコネクションもなければ狙うべきゴールもイメージできず課題の解決方法も手探りになるはずです。

 したがって、育てるべきはPMではなくPLなんだというのが白川氏の主張です。自分も概ね賛成です。特に日本企業のような無能だがエラいPMは「お飾り」だけですので、実質的にプロジェクトの成否のカギはPLの双肩にかかることになります。ただ、そんな日本企業のお飾りPMであっても、できればその「エラさ」を活用して経営層や関連部署とのネゴ(交渉)に活躍の場を持って欲しいと思っています。白川氏によれば、関連部署のネゴもPLの仕事に割り振られていますが、社内でお飾りPMを立てる場合はその仕事はPMの仕事としたほうがいいと思います(もちろん社外からプロPMを買ってくる場合は違います)。

 ところで、自分のようなメーカー系開発の場合は、白川氏の主戦場であるIT系と違ってソフトウェア開発メンバーは少人数であることが多いので、PLは設計者が兼ねるケースが多いと思います。つまりPLは、設計者とプログラマー数名(外注も含む)の中のリーダーということになります。恐ろしいことに1人プロジェクトというものがあって、PL・設計者・プログラマーを全て1人が兼務ということさえあります。IT系の開発プロジェクトはオートメーション化された最新工場のように役割分担されていますが、自分たちの場合は家内制手工業のように何でも1人でこなしているのが実態です。もちろん開発するプログラム規模が小さいことが多いのでそういうことが可能なのですが、必然的に少人数のプロフェッショナル(その製品のソフトウェア全体をスミからスミまで理解しているような人)が生まれやすい土壌で、彼らは余人をもって代えられない人材となります。リプレースできない人材というのは経営面ではリスクになり、例えばある製品のPLが会社を去ってしまうとその製品の継続すら危ぶまれる事態になりかねません。実は、自分のところでも最近、キーマンだったPLが抜けてしまったある製品(システム)の継続開発ができないので、一から作り直してもらえないかという話が来ています。仮にそうしたところで今度はキーマンが自分になってしまうだけですから、本質的な解決にはならないのですが、経営層としては何かトラブルがあった時にキーマンが社内にいることの安心感を得たいのかもしれません。

 PMは汎用的なマネージャー、PLはプロジェクト特化型のキーマンです。外から買ってくることもできるのがPM、社内でしか育てられないのがPLです。したがって、真っ先に社内で育てるべきなのはPLですが、PLは一朝一夕には育たないことも事実です。さらに、自分たちのようなメーカー系開発の場合は開発人数が少ないがために、PLの重要性はより一層増すように感じています。企業は、社内で育てたPLが他所に行かないよう、囲い込むくらい大切に扱ってほしいものです。