2013年もそろそろ飲み納め。みなさん忘年会活動の状況はいかがでしょうか。
先日、生まれて初めて「高級ワイン」と呼ばれる部類のワインを飲む機会があり、僕自身はとてもお酒にも恵まれた1年だったと感じています。

さて、今回はワインの話ではないのですが、一つの見解として共有したいテーマがあったので、コラムを執筆しました。2013年の振り返りなどは、また別途執筆したいと思います。

さて、データ分析に基づく経営という観点では、欧米に比べて、日本は5年は遅れていると言われています。これは実際の肌感覚としてもある程度正しいと思いますし、これからどうやってキャッチアップしていくのかは、事業・IT戦略上の大きな論点の一つと考えています。

一方で、ビッグデータを始め、データアナリティクスの分野に関しての取組も進んできたと感じる反面、自分自身が統計の知識を深め、事例に通じるほど、データだけに頼った意志決定は正直難しいと感じてもいます。

従来より、データが蓄積され分析の手法が確立されたことで、データから得られるインサイトは格段に増えているのですが、今後さらに顧客の動向を知るためには「観察」がもっとも重要な要素の一つになるのではないでしょうか。

観察の方法には、ビッグデータの解析、キャンペーン分析、アンケートなどなど、色々とありますが、場を作り出すことで観察を深耕する（参考2）のような取組が、今後の差別化要素になりそうです。ここに多様なデータ収集の仕組みを加えることで、インサイトをより定量的な裏付けを持って識別することが可能になってくる。

デジタル化に向けた一つの視野として、今後も論考を深めていきたい領域です。

◆参考1：エスノグラフィーとは
http://itpro.nikkeibp.co.jp/article/Keyword/20100204/344197/

◆参考2：ステートファーム社の「Next Door」というコミュニティ
http://insightxinside.com/?p=3283

→デザインコンサルティングで有名なIDEOが手がけた案件。保険会社にとっては、顧客インサイトの発見、ブランディング向上の双方で効果のある取組だと思います。僕のクライアントにも提案していきたいですね。

　今回のコラムでは、成長を加速するためにインプットをいかに得ていくか、について考えてみたいと思います。

◆成長の糧を得よ

　人間が成長するためには、アウトプットを増やす工夫が必要不可欠、というのが僕の持論です。また、良いアウトプットをたくさん生み出すためには、論文や書籍を執筆する場合のように、山のようなインプットが必要となることもしばしばです。どうせなら、栄養価が高くて“おいしい糧”が欲しいですよね。

◆それじゃ、糧って何だろうか？

　資料や書籍を読み漁るであるとか、よく知っている人から話を聞くであるとか、いろいろなやり方はありそうです。ここは、コンサルタントらしく少し整理してみましょう。

　個人的には、成長の速度を大きく左右するのは、「経験」だろうと考えています。石の上にも3年と言いますが、それなりの時間をかけて物事に取り組むことは、それ自体が価値あることと捉えられており、その理由が経験の蓄積なのかな、と。

　経験にも2種類あって、自分の経験と他人の経験に大きく分けられます。基本的には、自分が直接得られる経験の機会と量は時間に比例するので、他人の経験（図中（3）（4））をうまく吸収することが、成長の近道になりそうです。

　ちなみに、僕の最近のブームは、（3）領域です。特に、歴史から学ぶことがとても多いなぁと、いまさらながら歴史の授業をちゃんと受けておけば良かった、と後悔しています（笑）。そのように感じたのは、昨年から開催している読書会のおかげです。

　歴史に関連した書籍をテーマとしているのですが、回を重ねるうちに、思考の幅というかパターンを認識する力がついてきたような気がします。すでに結果の出ている出来事の集合を俯瞰的に眺めることができるため、パターンを抽出しやすいのかもしれないですね。

◆だがしかし……感度には個体差がある    

　さて、整理したのは良いものの、やっぱり人によって「感度」は異なるもの。よく気づいて成長が早い人もいれば、なかなかステップアップできない人もいるものです。せっかくの経験なので、できれば一度でたくさん吸収したいですよね。

　個人的な経験ですが、気づきが浅い人は思考が浅い場合が多く、試しに対応策やアプローチを聞いてみても、あまり考えていない人が多いように思います。下記のように、いくつか段階もあるかと思います。

• レベル1⇒まったく回答できず沈黙
• レベル2⇒対応策らしきものをバラバラと挙げるものの「それって誰がどうやって、どんなスケジュールでやるの？　優先度は？」と聞くと沈黙
• レベル3⇒上記はクリアしたものの、「なぜ、そのやり方でうまくいくと考えているの？」に回答できない

　レベル3まできちんとクリアできると、「あ、よく考えてるな」と感心するレベル。自分もそうありたいものです。

◆学びのアンテナはどうやったら伸びるのか？

　例えば、環境を強制的に変えるのも、1つの手かもしれません。アンテナの高い友人を作ることで、自分自身も高められるということは、経験のある人も多いのではないでしょうか。でもそんなに種類の違う人と、いきなり友人になることもできないわけで、結局、特効薬はないんですよね。

　1つ言えることは、向上心や好奇心を大事にし、かつモチベーションを失わないような環境を上手く作り出して、継続的に取り組む必要があるということ。

　いきなり感度が上がることはなく、長い取り組みではあるものの、感性は人生を豊かにするはず。年に数ミリでも、天に向かってアンテナを伸ばしていきましょう。

　ここで、格言でも……。

　　『人生は過ぎていく、問題はどう過ぎるかだ』（by レオナルド・ダ・ヴィンチ）

　……はて？

　よくよく考えてみると、目標設定はキャリア開発において極めて重要な割合を占めている一方で、真面目に取り組む人が少ないのではないかと感じ、今回の題材に選定しました。

　みなさんは仕事における目標設定をどのように実施していますか？　というか、やっていますか？

◆目標設定って、面倒くさい？

　多くの企業では、日々の仕事に追われてしまい、公式に目標を設定するという機会が少ないのではないでしょうか。これは僕の勝手な想像ではありますが、他業種・他社の友人と会話していると、そんなふうな印象を感じています。

　もちろん、インフォーマル（非公式）なメンタリングというか、会話の機会というのは存在するでしょう。ランチ、飲み会、仕事中のちょっとした会話など、さまざまな場面を活用していると思います。ただし、そういう思いつきかつ断片的な対話では、全体感を網羅した目標設定が難しいため、偏った目標ばかり設定してしまい、昇進や成長に必要な目標が設定されない、なんてことになりがちです。

　例えば、開発スキル向上ばかりを設定してしまい、リーダーとしてのスキル強化が疎かになってしまったり、プロジェクトや周囲の人の都合に振り回されて、キャリア構築に悩んでしまう、であるとか。

　さらに言えば、面と向かって目標設定なんて畏まらなくても……なんて感じている上司・先輩方もいるかもしれないですね。

　僕自身は、目標設定というのはキャリア育成に役立つという漠然としたうれしさがあるだけではなく、プロジェクトにおいて自身の活動をコントロールするための重要な取り組みだと認識しており、面倒くさいどころか、けっこうな時間を割いています。

　また、目標設定を通じた対話による副次的な効果もあります。経験上、マネージャとのコミュニケーションが良好になり、仕事自体がやりやすくなることが多いのです。それだけでも、取り組む価値はあると思いますので、忙しいエンジニアの皆さんにもぜひトライしていただければ。

　参考までに、エンジニア時代の僕のエピソードを紹介しましょう。

　プロジェクト参画時の目標設定ミーティングで、「ホスト上のプログラミング、アセンブラやCOBOLにも興味がある」と伝えていたところ、思わぬ開発メンバー不足に陥った際に、「サトマモくん、やってみる？」とチャレンジの機会を与えてもらうことができました。小さな開発ではありましたが、無事にやり遂げ、プラスアルファの貢献となりました。

　その手のエピソードは他にもたくさんあるのですが、いずれもきちんと希望を伝えていたからこそチャンスがめぐってきたというのは間違いありません。

　一方で、目標設定をしなかったプロジェクトでは、やりたいことと振られる仕事、期待する仕事のフィット感、納得感が少なく、モチベーションが上がらない……その結果、良いパフォーマンスが出せなかった、ということもあります。これは一概に目標設定が原因とは言えないのですが、けっこう大きな影響があったのでは、と個人的には感じています。

◆プロジェクト型ワークの弊害

　長く職場や役割が固定されている場合には、上司や先輩も長い付き合いとなり、ある程度長い目で育成・評価することが可能です。

　しかしながら、エンジニアやコンサルタントの方々は、プロジェクトが変われば環境がガラっと変わり、チームもリセットという場合が多いと思います。こういうプロジェクト先の上司はジョブ・マネージャ、というように呼ばれ、会社の部署の上司とは異なるものの育成や評価に対して大きな役割を負うことにます。よくある話ですが、クライアント先で仕事をする僕らにとっては、自社部署がバーチャル組織のように感じることも、多々あるでしょう。会社側からすれば、そんな職場環境のなかで、どのように社員の帰属意識を醸成するか、という課題と常時対峙することになります。

　一方で、従業員サイドでは中長期に渡る継続的な教育・評価が受けられないため、キャリア育成や自己実現に取り組みにくい、というのが多くの企業・現場が抱える頭の痛い問題の一つでしょう。

◆評価制度に目標設定を組み込む

　これらの問題に特効薬はないものの、評価制度にプロジェクト毎の目標設定を組み込むことで、緩和を試みている企業もあります。

　僕は米国系の外資企業しか職場経験がないのですが、アメリカでは地理的に離れた場所で仕事をすることも多いためか、プロジェクト参画時に新しい上長と目標設定について話し合う場が制度として規定されていたりします。もちろん、自己表現・自己主張がはっきりしていて、評価についてシビアという文化も影響しているのでしょう。

　さて、では目標設定してみましょう、となった際に「モジュール設計からテストまでを独力で完了できるようになる」、「XXXという資格を10月までに取得する」といった具体的な目標を策定する前に、ちょっと考えておくべきことがあります。それは何かというと、前提と期待の理解です。確認すべきは主に下記の3点だと考えています。

• プロジェクト背景・文脈
• 自分が果たすべき、もしくは期待される役割・ゴール
• 自分自身のキャリアプランと役割をどのように結びつける、バランスするか

　まず第一に、プロジェクトの置かれている状況を正確に把握します。火を噴いているところなのか、進捗は順調だけど他に問題があるのか、何が困り事、制約、前提なのか…などなど。プロジェクトの文脈によって、設定できる・すべき目標も当然変わってくるからです。

　次に、プロジェクトの背景・状況から、上司が自分に期待する働きを正しく理解しましょう。ここがずれていたり、期待を無視してしまっては、上司から見るとまったく使えない部下になってしまいます。この期待値は最低現クリアするハードルとして、目標設定に組み込まれるべきなのです。

　3点目に、そんな背景や期待を受けて、自分が達成したい目標やキャリアプランと、どのように整合をとるかを考えます。ここが一番の調整どころで、研修プランややりたい仕事などをとことん話し合いましょう。

　ここまでやってから、細かい目標をターゲットを明確にして設定していくことが理想的ではないかと考えています。加えて言うと、目標設定といえば、気をつけるべきはSMARTという観点ですね。測定可能、というのは特に大事です。

◆まとめ

　このような取り組みを実施することで、自分は何がしたいのか、いま何をすべきなのかを考える機会が生まれるため、プロジェクトでの貢献や自身のキャリア開発の観点からも、非常に効果的な取り組みといえるのではないでしょうか。会社で制度化されていなくても、是非参考にしていただければと思います。

　また、双方向の取り組みですので、上司・先輩方の協力も必須！　リーダー、マネージャの皆さんにも、部下の育成に積極的に取り組んでいただきたいと願っています。

　最近、秋の夜長を過ごしつつ、スタンフォード大学卒業式でのスティーブ・ジョブズ氏のスピーチを繰り返し聞いています。英語の勉強……ではなく、2010年後半をどう過ごそうか、ジョブズ氏に元気づけられながら見直し中です。

　「Stay hungry, stay foolish.」

　そうありたいものですね。

　……すいません、この話題は何の前振りでもありません（笑）

　さて、今日の本題に入ります。

◆思考停止してないですか？

　「便利な言葉だけ使って、思考停止してはいけない」

　職場の先輩と話していて、出てきた名言。とても反省したので、手帳にメモしたくらいです。

　このとき話題になっていたのが、サーバ統合にともない、成果物やプロセスを標準化して、開発工数を削減！ というお題。

　一見、「おーすごい、そうだよね！」と思うのだが……何をどこまでアセット化するのか？ 削減てどんだけできるの？ などなど、ツッコミどころはたくさんあるよね、という指摘。先輩としては現実性があるかも分からないものに対して、風呂敷を広げすぎるのはどうなの、というコメントだったのですが、これは考えさせられました。

　その内容にではなく、自分の短絡的な思考を。

　「徹底的に再利用できるようアセット化するのが大事」とかいってる自分は、そこまで考えていたかなと反省した次第です。

◆その意見に具体性はありますか？

　謳っていることは間違いではなくとも、そこに分析と確固たる仮説がないのであれば、「良さそうだね」の域を出ていかず、単なる空想に過ぎなくなってしまう。これは要件定義でもそうだし、提案の時にも大いに陥りそうな罠です。

　要件定義で機能・非機能要件を定義する際にも、このあたりは口を酸っぱくして注意されるところですよね。あいまいな言葉を使わずに、できる限り測定可能な（定量的な）ものさしで要件を定義すること。例えば、エンド・トゥ・エンドのトランザクション時間は2秒以内でなければならない、であるとか。

　いずれにせよ、具体案を伴わない提案では人は動いてくれないし、そんな設計ではシステムも動かないわけです。エンジニアたるもの、実現性については誰よりも深慮すべきでしょう。

　このエピソードから、1つの書籍を思い出しました。「ライトついてますか？」という問題発見の本です。往々にして、問題を解決するよりも問題を定義することが重要であり、もっとも誤ってはいけないポイントだ、と本書では述べられています。解決すべき問題を示すことはとても難しいもので、解決する必要のない問題であれば、たいてい山ほど出てくるわけです。

　では、課題を解決するフェーズになると、ことはすんなり進むのでしょうか。解決策の中にも罠が潜んでいます。

　「ライトが消えているから暗い」→「ライトをつける」

　とても簡単で分かりやすい解決策です。しかし、ライトが消えているのは電球が切れてしまったからではないんでしょうか？ 問題は正しく捉えているかもしれませんが、解決策へ至る道が短絡的で、効果のある策を導けていないということはないでしょうか？ 考え出すと、日ごろ身の回りで起きていることのような気がします。

• サーバが乱立し、運用管理コストがかかって仕方ない→サーバ数を削減してTCOを削減しましょう！
• 新商品の売り上げが上がらず、利益も出ない→コストを削減して、利益を捻出しつつ、PRを強化しましょう！

　“→”の間には、データや事実に基づく分析があるはずで、それが解決策の正しさを担保するはずです。上記例のレベルでは、なんかフワフワしていて、とてもじゃないが受け入れられる意見ではありません。検証のない提言は絵空事だと思われても仕方ないですよね。

　結局は、短絡的な解決策に飛びつくのではなく、「？」を加えて思考を充分に働かすべきだということです。どんなときも考えることをサボってはいけないという、大きな反省でした。

◆思考するところとしないところ

　思考停止は悪だ、というテンポでここまで進めてきましたが、停止しても良い場面もあります。例えば、同じような仕事をするのに、改めて進め方を考えるとか、ドキュメントをそろえるだとか。そういった下準備だったり、一度は試行錯誤して確立した手順を再度構築するのに、頭と時間を使うのはもったいないですよね。そういった類のものを再利用できるように整えておくのはやはり大事なことでしょう。

　問題は再利用＝そのまま使える、という錯覚です。当然、世の中の仕事はそれほど単純なものではなく、明らかなルーチンワークでないかぎり、頭を使ってとりこぼしを防ぐのは当たり前。そこを省くことが再利用の目的ではないので、意図を取り違えないように注意したい。

　余分なことで疲れないように、思考休止もうまいこと取り入れていけると、バランスも良くなりそうですね。

◆教訓は振り返ることが大事

　反省を忘れないために、自分手帳の振り返り名言集にこう付け加えたいと思います。

　「頭動かしてますか？」

　皆さんも思考停止にはご注意を。

　書かなくてはなーと思いつつ、最近悩める時期でもあり、なかなか気の利いたコラムが書けそうにない、と筆から遠ざかってしまっていました。

　しかし、9月はエンジニアライフの大イベントもあるわけなので、少しは活動しておかないと！ というプレッシャーもあり（笑）、肩の力を抜いて徒然に執筆してみようかと思います。

■ワインとメインフレームの共通点？

　いきなりですが、みなさんお酒はお好きですか？

　わたしはお酒大好きで何でも飲むんですけど、ワインを飲むことが多いです。先日は近くの酒屋さんの試飲会で、昼から試飲しすぎていい感じになってました（笑）。

　それはさておき。

　先日、ちょうど弊社の新メインフレームの社内セミナーに参加して話を聞いているうちに、ふと考えました。

　メインフレームもワインも昔からあるものだけど、時代に合わせての変化や、機能や品質そのものの進化を伴いながら、ここまでやってきているんだなぁ、と。

　ちょうど、試飲会でも最近のワイン醸造家の取り組みをお話しいただいたのもあるかと思います。

　例えば、オーガニック栽培の方法でも、醸造家の方々ごとに色々な工夫があって、今もよりよい物を求め続けているわけです。改良や進化をしていくのは当たり前、と思うかもしれませんが、そこには歴史が長い分だけの伝統の重み、過去を引き継いでいかなければならない難しさがあります。

　日本の伝統芸能だと歌舞伎もすごいですよね。海外へも進出していますし。これも伝統や過去を大事にしつつも、新たな表現の場を求めてのチャレンジでしょう。

　これらと同じかどうかは分かりませんが、IBMのSystem zも既存のアプリケーション資産という伝統を抱えつつ、それでも新しいステージを狙っていく意欲はすごいな、と感心した次第です。こちらは宣伝です（笑）

　http://www-06.ibm.com/jp/press/2010/07/2301.html

　新しい革新的なシステムやアプリケーションに惹かれる面も当然ありますが、エンタープライズシステムの大半はすでに基本的な基盤機能を有している現状で、今後はインフラをどう扱うようになっていくんだろうか、と考えます。

　パブリッククラウドで外出しするという手も当然あるでしょう。しかし、逆に内製化プライベートクラウドにして自社内でITガバナンスを確立するという方向もありそうな気もします。

　企業ごとにIT戦略はそれぞれだし、抱えているシステム資産やミッションクリティカル度合いも違いますし、一概には言えない話ですが（ミッションクリティカルって言葉は、どうにも言いにくいですね）。

　とはいえ、銀行の基幹システムをアマゾンのクラウドに乗っけるわけにもいきませんからね……。トランザクション量や規模を考えると、ほんとに安いのか、とか。日本国民が1日くらいATM止まっても別にいいよ、と言ってくれれば、もうちょっとハードルは下がるかもしれませんが……まあ、そんなわけはないでしょう。

　Twitterみたいに「I'm sorry」って出しておけば良いのであれば、いいんですけどね（笑）。

　改めて考えるまでもなく、求められているものの違いは大きいと感じます。

■終わりに

　どんな分野の製品、あるいはサービスでも、「常に革新と向かい合って生きていかなければいけない」というのは、何とも大変なことだと、しみじみと感じた今日この頃です。

※1：技術用語だと「transparent」とかよく出てきますね。

　会計や簿記も同じで、会社の経済状況や取引を表すための言語なのです。知っている人には当たり前かもしれませんが、自分が実感できるようになると、感じ方も違います。そういう意味で実際に勉強して、体感できたことはとても有益でした。

　では、言語として簿記を知っていると、何が嬉しいのでしょうか？ 会社の経済状況が分かる、財務諸表が読める、などさまざまに言われていますが、個人的に一番大きいのは、「会社の行動の意味が分かる」ということじゃないかと感じています。

　残業すると収益が減ってしまう、というのは容易に想像もできますが、資産管理を考えてみましょう。弊社でもそろそろ半期の棚卸しがあるようですが、会社資産のPCのカウントなどが実施されます。ここでもし、「ありません」、「不明です」となるとどうなるでしょうか。こういうものは、棚卸し損として計上されて、損益計算書（P/L）では棚卸減耗費とか損失として明示されることになりそうです。

　（きちんと確認していないので、弊社の会計処理と実際は異なるかもしれません）

　損失が発生するとどうなるか？ 当然、収益が減ることになります。収益が減るとどうなるか。1株当たり当期純利益（Earnings Per Share）が低下します。EPSはどれだけ儲かっているか、の視点であり、投資家からみれば、投資するか否かを検討する材料の1つです。となると、このPCが行方不明になるインパクトって、思ったよりも重大じゃありませんか？

　そんなことが財務諸表や勘定と結びついて理解できるようになり、企業活動に対する理解は深まります。自分の会社の状況を知っておくというのも、いまのご時世ではとても重要ですよね。

　以上は社会人なら誰でも共通に得られるメリットですが、エンジニアにとって、わざわざ会計の勉強をする意義はなんなのか？ という部分をもう少し考えていきます。

■役割によって、会計知識の重要性や意味は異なります

　毎日ひたすらプログラムを書いているエンジニアにとって、会社の財務諸表や日々の取引の勘定はどれだけ大事でしょうか？ 確かに自分の会社が幸先不安かどうかを知る、というのは雇用問題として大事でしょう。景気のいい会社に転職するための判断材料にもなるかもしれません。これはメリットとして考えられそうです。

　メインの仕事を業務要件の取りまとめにしているような、SEやITコンサルタントにとっては、顧客の業務がビジネス上どんなインパクトがあるのかをきちんと理解して、提案や機能設計をしていくことが極めて重要です。当然、分野にもよるわけですが、会計はＩＴとの相性が非常によく、SAPのERPを始め、さまざまなアプリケーションが会計処理を扱っています。これらを語るのに、最低限の会計の知識は必要になるに違いありません。やはり知っておくにこしたことはないでしょう。ただし、必須かというと、担当している業務にもよるので、一概には言えません。

　プロジェクトマネージャ（PM）から見るとどうでしょうか？ PMはプロジェクトから利益を出すのが指名の1つなので、少なくとも、プロジェクトの損益については理解して損を減らすように気をつけているでしょう。PMが直接仕訳をするわけではないですが、自分が買った備品や契約、チームメンバーの人件費がどのように会社で処理されているかを知っておくと、自分の仕事をよく知ることにもつながります。数年前の工事会計基準の導入はPMさんにとっては、提案や見積もりを作る際の考慮事項だったはずです。個人的な感覚では、日商簿記2級程度の知識があると、かなり自信が持てるのではないかと思います。

　こうやってみると、いろいろな役割がある中で、知ってて損になるということはなさそうです。新しい知識を得るわけですから、そもそも損があるわけではないですが……。というわけで、役に立ちそうなので、みんな勉強しましょう！！！

　と、言いたいわけではありません（笑）。

　実は、ここでもう1点考えたのが、業務外の勉強をするのはいいが、「何に役立つのか、役立てるのか」を明確にすることが大事ということ。これは社会人の学習として、基本的なことだと思います。新しいことを勉強するのは楽しいことです。だけど、時間も当然食います。時間を投資するだけの意義を見つけておかないと、挫折するか、せっかく勉強しても実践的に身につける機会がない、なんてことになってしまい、もったいないと思うのです。

　これは資格マニアにならないように、自分へ向けたメッセージでもあったりします（笑）。

■それで、会計はお金になりますか？

　最後に、勉強をしてエンジニアとして儲かるか、という点について考察したいと思います。モチベーション向上の一観点として。

　結論から言えば、大して儲からないでしょう。

　前述した内容のとおり、ＩＴ屋としての活動はシステムを作ることです。機能として会計処理を理解する必要はあるかもしれませんが、たまたま会計システムでも作っていない限りは、直接的に業務に役立つことはないでしょう。それならば、開発手法や新しい技術、プロジェクト管理手法を勉強した方が価値がありそうです。

　一方、昨今話題のIFRS（国際会計基準）の適用であるとか、IT企業として儲かる点は常にあるように思います。これに乗っかっていこう！ ということで、会計を勉強するというのであれば、それもいいかもしれません。ただし通常、会計基準の変更なんてＩＴエンジニアの手に負えるものではないので、会計士やコンサルタントに業務要件を定義してもらった後に入って、システム構築をする、というのが現実的な進め方ではないかな、と思いますが。

■おわりに

　やはり業務に役立てるという意味では、一部の会計システム担当者を除き、モチベーションは上げにくいような気がします。なので、効果の上がる勉強を先にやった方が良いでしょう。

　以上。

　って、そんな結論にしてしまうと、勉強中の自分のモチベーションが著しく低下してしまいそうですが（笑）。

　他にもエンジニアの方でＩＴ以外の勉強されている方がいらっしゃれば、コメント、ご意見いただけると幸いです。よろしくお願いします。

　気付けば4月。世間は新学期、入社式など春らしいイベントが目白押しですね。IBMでも、Spring Kickoff（入社式）が開催され、初々しい新入社員の方々の姿が見られました。どんな後輩が入ってきたのか楽しみです。

　自分がワクワクしながら入社式に参加したのは、気付けば、4年前。5年目社員というと、新入社員から見ると、ずいぶん先輩になってしまいますね。果たして、5年前にイメージしていた先輩像になれているのか、ちょっと疑問ですが……。

　さて、3月の時事争論で、「新人／部下の教育」について、というお題をいただいたので、遅ればせながらちょっと考えてみたいと思います。

　今までの記事には、自分自身が受けてきた教育や育成に関する内容が多いので、自分が教育する立場だとしたらどうするか、どうしたいかをお話しします。実際には、後輩の面倒を見るという機会は少ないため、想像の部分が多くなってしまうかもしれませんが、ご了承を。

【以前に書いた教育関連コラム】

若手ホスト担当エンジニアがスキルを伸ばすための5カ条

メインフレームとの出合い

■いまどきの新人ってどんな人たち？

　まず、「新人」とひと区切りになっているとアプローチが難しいので、分類してみましょう。新人といっても、新卒入社／中途入社の大きく2つに分けることができますが、今回は「新卒入社の人」を対象に考えていきます。

　私見ですが、昨今の新卒入社の方には、いくつかパターンがあると考えています。すでにITに強い人もいれば、頭が良くてコミュニケーションに長けている人、などなど。仕事に関連する能力として、ITスキルと社会常識（コミュニケーションを含む）のあるなしを軸に、以下の図の4タイプに分類してみました。この分類をもとに、それぞれのタイプごとで指導方法を考えてみたいと思います。

（1）ITスキルらしきものはあるが、付き合いにくいエンジニアタイプ

　いわゆるエンジニアっぽい人です。実際のプログラミング能力などに長けており、その辺の先輩よりもすでにコードは書けてしまいます。指導する側の能力を上回ったスキルを持っていて、技術的な指導が困難な場合すらあります。そのような時は、切磋琢磨して自分のスキルを伸ばすというのもアリかもしれません。

　彼らに必要なのは、社会人として一般的なマナーだったり、挨拶、お客様との話し方などの練習でしょう。先輩としては、特にこのへんに注意して指導してあげるのがよさそうです。

（2）ITスキルも理解力もある秀才タイプ

　ちょうどわたしの後輩がそうなのですが、勉強家でスキルも吸収が早いし、マナーやコミュニケーションもそつなくこなします。正直、あまり指導することがないです。日々の業務やアドバイスで充分に戦力になっていくタイプです。彼らのモチベーションが高く保たれるように、刺激を与えたり、相談に乗ってあげることが重要と思います。

（3）ITスキルはまだないけど、頭の良い伸びしろタイプ

　いわゆる文系エンジニアのタイプです。最初こそ、ITに関する知識や技術がないため苦労しますが、何年かすると追いついてきます。彼らは基礎的なコンピュータの知識がないため、業務で使う技術の背景や基礎の部分を補強してあげるのが、先を考えたときに有効ではないでしょうか。けっこうエンジニアでJavaは書けるけど、コンピュータそのものの仕組みは知らなかったりする人が多いですが、こういう基本を知っていると仕事の上でも役立つことがたくさんあります。基礎がしっかりしていると、適応力もついて、変化の早いIT業界で働いていくにも役立つと思います。

（4）ITスキルがない上に、社会人としてのマナー・常識に欠ける学生気分タイプ

　たまにいると思いますが、ちょっと頭を抱えたくなる学生気分な新人さんです。幸い、こういうタイプの人に出会ったことはないのですが、こんな後輩がやってきたら、もうつきっきりでたたき込んでいくしかないかもしれません。ポイントなのは、さじを投げないことでしょう。大変身したときの感動はものすごいでしょうし。

■結論：最後はやる気でしょ

　いろいろと考え考え書いてみましたが、結論は「やる気が大事」かと。いくら指導したところで、やる気がなければ身につかないし、育てる側もやる気を喪失してしまいます。別にどんなタイプだろうがなんでもいいのです。一生懸命にやってくれれば、生きていく術は自然と身につきます。

　そう考えると、先輩として本当に必要なのは、後輩のやる気を持続させること。いろいろな方法があります――たまには飲みに連れて行ってあげるとか、自分が頑張る背中を見せるとか、褒めてあげる、取り返しのつかない失敗はしないようにフォローしてあげるとか。　

　以上、5年目社員として、後輩の面倒を見るときには考えてあげたいポイントでした。
　
　この手の指導はみんな頭を悩ませる部分だと思います。いろいろとコメント・アドバイスいただけると幸いです。

　いきなりですが、わたしはかなりの面倒くさがり屋です。自分が面倒くさいと思ったことは、本当にやりたくない人だったりします。

　初対面はなぜかA型に間違えられたりしますが、実際、適当でおおざっぱな典型的（？）なO型なのです。

　さて、今回は要件定義書をまとめていて、そんなものぐさな筆者が考えたことを、つらつらと書きたいと思います。

●ドキュメント作成、正直めんどいです

　みなさんのプロジェクトでは、ドキュメントは標準化されているでしょうか？

　システム構築という仕事は、実に半分以上の時間をドキュメンテーションに使うことが多いわけですが、いくら標準化されていても、時間はかかるし、フォーマットの乱れもなかなかなくならないし、苦労されていることかと想像します。

　文章が大量になればなるほど、標準化レビューにも時間がかかりますし、場合によってはアルバイトを雇って、大量処理！ なんて場合もあります。

　ものすごい手間がかかりますよね。

　もっとプログラム作ったり、設計考えたり、お客様と話をする時間に充てたいものです。

　そもそも、なぜこんなに修正作業が必要になるのでしょうか？

　以下のような項目が思いつきました。

• 日本語能力が足りない
• 標準化を理解していない
• 標準化を知ってはいるけど、実施していない（適当に書いている）

　ああ、自分の胸が痛いですね……。

　さて、標準化で見落とされやすい点として、筆者が着目したいのは、「読者のスキルレベル設定」。

　実は、見た目は簡単に標準化できますが、文章内容についての標準化は定性的で難しいためか、あまりやっていないケースが多いのではないでしょうか？

　こういう場合、レビューや提出前になって、「これじゃお客様が分からないね」とかいう話になったりも。

　そもそも、お客様にもいろいろな技術レベルの方がいるので、どこをターゲットにするかによって、内容のかみ砕き方も変わってきます。

　分かっている人に、懇切丁寧なドキュメントを出すのは、作る側も時間の無駄だし、読む方も「こんなんは分かってるよ……」と余分な時間をとることになります。

　そのへんの嗅覚を標準化する人達（プロジェクト・マネージャやチーム・リーダーでしょうか）には、ぜひとも身につけていただきたいですね。あ、もちろん、自分も勉強します、ハイ。

　開発手法にペルソナ法という仮想の登場人物を定義して、ユーザビリティ等を検討していく手法がありますが、プレゼンやドキュメント作りでもこういう考え方は有効かもしれませんね。

　結局、ニュアンスの部分は勘というかセンスを磨くのが、最大の効率化への道かもしれません（それが一番難しいのですが）。

　閑話休題。

　ちょっと視点を変えて、こーんな校正作業の手間をグっと減らす工夫というのは、どうでしょうか？

　正直、システム開発の非効率さのある程度の部分を、ドキュメンテーションが占めていると思います。

　なんで、本質的には同じようなことを書いているのに、お客様ごとに、ドキュメントのスタイルを調整して、いちいち時間をかけて標準化しなくてはいけないんでしょうか？（スペシャルな部分は、都度作らないといけないのは承知ですが）

　見た目の問題がけっこう大きいんじゃないでしょうか？

　となると、システムエンジニアである我々は、お客様のシステムを開発することも大事ですが、ドキュメントの属人化を払拭する共通インフラを開発するというのに目を向けても、面白いかもしれませんね？

　ちなみに、ソースコードを解析して、メタデータを作成し、XML化して、XMLから文章を自動生成するような製品はいくつか見たことがあります。

　こういうツールも使いやすさやXML ⇒ ドキュメントの変換ルールを簡単に作れるようになると、基礎ドキュメントは全社統一で、お客様に合わせて見た目だけ加工する、なんてことができると思うんですけどね。

　それをツール上で実施して、変更や修正のトレーサビリティ（追跡可能性）を確保していくのが、正しい姿。そういうツールがあれば、もうMicrosoft Officeも要らないですし（極端ですが）。

　みんな、もっと面倒くさがり屋になって、世の中を働きやすくしませんか？（笑）

　実は上記の話は、昨年に社内検討会のテーマにしたネタなのですが、みんな思いは同じものの、よくよく考えてみると実現もある程度難しそうだし、そもそもペイしないのではないか（自社で開発しても元が取れない）、なんていう議論になりました。

　もし、こんな先進的なツールを利用している方がいらっしゃるようでしたら、ぜひコメントください！

　徒然なるままに書きましたが、以上です。

　次回は、社内での技術論文を書いた時に思ったことなど、つらつらと書いてみたいと思います。

　それでは！

　今年は月に2本はコラムを書くぞ！ と息巻いたエンジニアライフですが、さっそくノルマを達成できなくなりつつあります（笑）。

　いやいや、せっかく立てた目標なんだから、頑張ります！！

　というわけで、新年最初のコラムです。ご一読いただければ幸いです。

■ホストシステム担当の若手を取り巻く状況

　前々回のコラムにて、筆者の初プロジェクトアサインの頃の様子を紹介しました。あれから何年か経って、何が大変だったのか思い返してみると、以下のような点を思いつきます。

1. 言葉が分からない
2. 仕組みが分からない（コンピュータの基礎）
3. 先輩との知識・経験差が大きい
4. 今まで得たITの無力感

（1）言葉が分からない

　何より、まずはこれが一番大変でした。用語がPCやインターネットの世界と異なるところも多く、何を言っているのか分かりません。この「言っていることすら理解できない」という状況は、かなり精神的に辛いものがあります。

　海外に放り出されるとこんな感じなんでしょうか。まあ、プロジェクトで日常会話に困ることはないので、ちょっと違うかとは思いますが。

（2)仕組みが分からない

　これは自分がいけないのですが、WebとかJavaのやっていることは分かっても、OSレベルのシステムの動作が分かっていなかったため、メインフレームがどんな風に動いているのか、どのような構成要素があるのか、という全体像のイメージを掴むことができませんでした。

　極端に言えば、今やっている作業の目的や、これをやることでシステムにどういう影響があるのか、ということがさっぱり分かりませんでした。これがもかなり大きなストレスでしたね……。

　このへんって、単純なアプリケーションを作ったくらいでは、意識できない領域で、プロとアマチュアの違いが大きく出てくるところなのかもしれません。

（3）先輩との知識・経験差が大きい

　これはある意味では良いところでもありますし、悪いところでもあります。

　そもそも、メインフレームの担当者だと、若手の先輩という方はほとんどいませんでした。筆者の参加したプロジェクトでも、良く分かっている先輩が10歳年上で、10年間バリバリ運用やってました！ みたいな人だったので、オペレーション技術から知識や経験まで、本当に天と地ほどの差があるわけです。差が大きいことで、自分が勉強しても全然役に立たないのではないか？ という悩みを持ったりします。

　しかし、逆に捉えると、それだけ知っている人ばかりが周りにいるので、うまく知恵を分けてもらって、スキルをつけるチャンスに恵まれているともいえますね。

　LinuxやIAサーバ（Windows）のように、通常触れられるものではないため、この開いている差は、なかなか埋まりません。

（そろそろ筆者もSE4年目終わりに差し掛かっていますが、個人的な運用スキルの差は、永遠に縮まらないかと、なかば諦め気味なのが正直なところだったりします。）

（4）今まで得たITの無力感

　これは表現が大げさですが、つまり、IT世代として「ITけっこう分かってますよ」という顔で入社してきたため、まったく知識が通じない状況はプライドもずたずたになり、けっこうきついわけです。

　筆者は豆粒並みのプライドはあったものの、比較的早めにお手上げして、「全然分からないもの」としてメインフレームに接し始めたため、実はそれほどのストレスはなかったように記憶しています。

　逆に、WebだとかTCP/IPなどオープン系と呼ばれる知識はある程度持っていたため、両者を対比することで、メインフレームの特徴をよく捉えることができたのではないかと感じています。

　とはいえ、直接的には歯が立たないという意味で、「無力感」という提示でいきたいと思います。

　こんなことを踏まえつつ、「それじゃ、若手エンジニアがメインフレームと共存するためには、どうしたらいいの？」と考えてみた結果を、次にまとめてみます。

■若手ホスト担当エンジニアがスキルを伸ばすための5カ条

第1条：素直に先輩に教えを請う！！

　とりあえず、経験も知識も上なので歯が立ちません。まずは、謙虚になって素直に教えを請いましょう。

　極端な話、「自分で考えろ！！」と言われても、技術的な問題は早めにギブアップしてください。何が分からないのかも分からないんだから、悩んでも答えは出ません。自分で考えられるようになるのは、もう少し経験を積んでからで良いです。

　メインフレームに関連する対応は失敗するとクリティカルなものになることも肝に銘じて、慎重に行動しましょう。自分もそうでしたが、勘違いと思い込みで、事態を悪化させるリスクがあります。

　また、分かりもしないくせに偉そうな文句ばかり言うのもダメです。スキルがない自分を認めて謙虚になることから始めましょう。

　とはいえ、教えて君になっていいわけではありません。分からなかったことはすぐに資料で確認します。そのときは理解できなくても凹む必要はありませんので、必ず情報を入れてください。しばらく経って、きっと理解に繋がる助けになります。

　また、アドバイスを受ける際に気をつけるのは、「本質を理解する」ということです。仕組みや背景を理解する、と言っても良いかと思います。

　コードやJCLの書き方でも、端末でのオペレーションでも「なぜ、このやり方がよいのか」「先輩のどんな経験が活きているのか」ということを考えたり、聞いたりしていきましょう。きっと成長のスピードに雲泥の差が出ると思いますよ。

　そう考えると、素直＝鵜呑みは違います。この、「なぜ？」というところは明確にして、納得した上で素直に教えに従うようにしましょう。

第2条：論理的に考える

　製品知識やスキルなどは分からなくて当然ですが、システム運用や会議でのディスカッション、プロジェクトの進め方など、頭で考えれば勝負できるところは、どんどん意見を出しましょう。

　決して、先輩がいるからと任せてはいけません。技術力がつくには時間がかかりますが、論理的思考力やディスカッションは、できる人なら早い段階で先輩たちと勝負できる領域だと思います。

　「こいつ、アホではないんだな」と思ってもらいましょう（笑）

第3条：メインフレームに好奇心を持つ

　あまりに分からないからって嫌いにならないでください（笑）。

　嫌いになってしまうと、思考もシャットダウンされて、スキルもつかず、どんどん悪循環になってしまいます。

　筆者の例ではないですが、「もう分からん！」 ⇒ 「一体、こいつは何なんだ？」というように、自分の好奇心を意識的に向けてあげることが大切だと思います。

　そうなってくると、知らないことや不思議なことがどんどん出てきて、だんだん楽しくなってきます。

　無邪気に知識を吸収していくことが、その後の成長に、ものすごく大きな影響を与えるんじゃないでしょうか。

第4条：おじさんと仲良くなる

　おじさんなんていうと失礼かもしれませんが、諸先輩方、ご容赦ください。

　これは経験豊富でスキルも高い、かなり年上の先輩方に気に入られて、成長を助けてもらおうということです。どこの現場を回ってみても、メインフレームの関係者は40代以上の場合が多いのではないでしょうか。

　大学新卒の人から見たら、自分のお父さんくらいの人と一緒に仕事をするわけで、おじさんウケするというのは、かなりのメリットがあると思われます（笑）。

　年長者への礼儀ということもありますが、やはり現場のおじさん方は「バカは嫌い」なんだと思います。分からないのに知ろうともしない人や、自分の頭で考えていない人には、やや冷たい雰囲気がなきにしもあらず（筆者の経験では、ですが）。

　そういう方々にきちんと指導してもらうには、甘えているだけではなく、第二条で書いたように「ちゃんとやろうとしている」という意欲を感じてもらうことは、最低条件です。でも、これは分野によらず、何事もそうですよね。

　一回認めてもらえると、面倒見たがりな諸先輩方は、あれやこれやと小技や濃ゆい技術を、これでもかと与えてくれたりします。

　こういう口伝的な暗黙知を得るのも、成長という観点ではとても大切ですよね。

第5条：先輩の知らないスキルで対抗する

　これは特に、年の離れた諸先輩方に対して、です。

　幸いなことに、IBMのメインフレームはオープン対応など進化しており、Linuxが使えたりと、必要なスキルの幅が非常に広がってきています。

　というわけで、昔からのメインフレーム担当者の方々は、最近のオープン系の技術（LinuxやTCP/IP、Webなど）には、それほど詳しくないことも多々ありますので、そういう部分こそ、若手が頑張れば貢献できるところです！

　後は、日々登場する新しいソフトウェアなんかも、当然、知識のある人が少ないところなので、知っていると重宝されると思います。

　ブルーオーシャンを狙う……ではないですが、カバーされていない領域を進んで勉強するのも、とても大事なことだと思います。

　書いていて感じたのですが、やっぱりこれもメインフレームの世界に限った話ではありませんね。

■終わりに

　スキルを伸ばす5カ条、いかがだったでしょうか？

　共感していただけるところ、反論したいところなど、いろいろとあるかと思いますので、ぜひコメントいただきたいです。

　新人と思っていたのも束の間、筆者もエンジニアとして今年で5年目になります。

　エンジニアとしては、正直まだまだですが、もはや新人とも言えない立場ですよね。そろそろ、今日の5カ条での成長は厳しいところです。

　なので、もう一歩成長していくには、また新しい観点も追加していく必要があります。

　最近、その中の1つは、「後輩に自身の経験を伝える」「後輩を育てること」かな、と感じています。

　徐々にプロジェクトや部門でも、自分よりも若い人と仕事をするようになってきますが、そうなると、必然的に立場の近い自分が面倒を見ることになるわけです。

　そういうときに、今回のコラムで書いたことや、自分が経験してきたことを伝えて、少しでも後輩の成長の糧にしていってもらえたら、先輩としても嬉しいですよね。

　そんなふうに、後輩を成長させる先輩として、自身も成長しつつ、新たな5カ条を探していきたいと思います。

　まだ数回しかコラムも書けぬまま、今年が終わろうとしています。1年は早いもので、8月にコラムを書き始めたものの、他のコラムニストさんの面白くて勢いのあるコラムに圧倒されています。定期的に文章を書き続けるというのは、なかなか難しいことを思い知りました……。

　そんな反省もありつつ、年末ですので＠ITでの活動と、今年のエンジニアとしての1年を簡単に振り返ってみます。しばらくお付き合いください。

■今年の＠IT活動

　さて、思い返してみると、いきなり＠ITからメールが届いたのが、ちょうど5月くらいだったと記憶しています。「運動で変わるシゴトとカラダ」という特集を組むので取材に協力してくれないか、という依頼に、面食らいながらも承諾したのを覚えています。

　そして、取材の中でコラムを書くことも興味があると話したところ、エンジニアライフを勧めてもらったのが、このコラムを立ち上げたきっかけでした。

　今読み返してみると、やや誇張気味なところもあり、恥ずかしい限り。しかも、全然アスリートの体になってないし……。ブレイクダンスもそんなには上達してないし……。これは、きちんと読み返して、来年の肉体改造計画を立てたいと思います。

最終回　運動を長く無理なく続けるコツ

　とはいえ、やはり取材から半年経った今でも、自分にとって運動の重要性は変わっていません。頭もスッキリすると思いますし、ストレスを溜めない秘訣かな、と。エンジニアの皆さんも健康な体を手に入れつつ、困難ながらも楽しいエンジニアライフを満喫しましょう♪

　（※ちなみに、よく聞かれるのですが、掲載していただいたスケジュールは2008年で一番多忙だった時期のもので、最近はもっと平和な日々を送っています）

　さて、肝心のコラムというと、今回の投稿を入れて4件。内容もさることながら、ちょっと低調でした。反省。

　普段、いろいろと思うことはあるのですが、公開するコラムにまでネタを昇華できず、筆が進んでいないというか…。来年はもっと…24本くらいは書きます！（月2本ペース）

　という風に宣言して、自分を追い込むタイプです（笑）。来年は頑張るぞ～。

■ITエンジニアとして

　今年はいくつかプロジェクトを移動したり、掛け持ちしたりと、去年までのドップリぶりとは打って変わって慌ただしい1年でした。

　いくつか個人的なキーワードを出すとすると、こんな感じでしょうか。

• プロジェクトチームとアカウントチーム
• システムアーキテクチャの重要性

　いわゆるお客様付きのエンジニアという立場を体験したのですが、今までのプロジェクトベースの働き方とはまた違った経験ができました。本当にお客様と一緒になって、日々の業務や運用をサポートするのは、プロジェクトを進めていくのとはまた異なった知識や振る舞いが必要になってきます。この辺は、自分よりも読者のみなさんのほうがよくご存じだと思いますが、詳細はまた気が向いたときにコラムにしていきたいところです。

　あと、いろいろなシステムを見ていると、根幹にある基本的な考え方の重要さを、今まで以上にヒシヒシと感じたり。こういうのをアーキテクチャと呼ぶわけですが、今後複雑化していくシステムの面倒を見るためには、アーキテクチャを確立することが、本当に重要になってくると再認識しています。このへんも、やっぱりコラムで書いてみたいネタの1つではあります。

　仮想化したりクラウドにするのはいいんですが、やっぱり根幹のシステムってどんどん複雑になっていってしまっていますよね。やはり、みんなで早めに手を打っていかないといけない部分かな、と思います。

　また、昨今のIT業界の流れを見ていて、自分が感じているキーワードもいくつかあります。

• セキュリティの強化
• SOA（Service Oriented Architecture）の浸透
• オフショア開発の浸透

　やはり、システム統合や連携が進んできているというのは間違いなく、企業間接続において、セキュリティがきちんとしていないところとは繋げたくない！ とか、繋げやすくするためにはSOAで疎結合化しないと……ということが進んできていると、ひしひしと感じます。

　去年はちょっと向こう側で動き始めているな～という感触だったのですが、そろそろコンセプトも浸透して、動き出していますね。

　あと、オフショア開発っていうやつですね。

　これはもうけっこう日本のエンジニアにはインパクト大きいです。本当に最近はちょっとした開発はアジアの方々にお願いすることも多く、こちらも浸透してきています。各社でノウハウが溜まって、実働に移ってきている段階なんだと思います。もっと頑張らないと、おマンマ食い上げになりそうです……あわわわわ。

　また、会社の外に目を向けてみると、やはり不況のなかでも、日進月歩で技術は進歩しています。

　例えば、自分も年末に買ったiPhoneやAndroidなど、モバイル用技術・デバイスの発達も一気に加速してきていますね。これは、かなりライフスタイルも変えるくらいのインパクトがあるんじゃないかと感じています。iPhoneアプリの開発案件とかもきっと多いんだろうと思いますし。来年以降もGoogle携帯など、こちらの発展も止まるところはなさそうです。

　エンタープライズで閉じていた世界でも、この加速的な変化によって、企業システムや業務への影響もあるし、Webの世界を通じたエンタープライズとコンシューマー世界の融合は、より緊密なものになっていくと感じています。

　あと、IT業界といえば、「クラウド」というキーワードが存在感を増してきました。

　Amazon ECをはじめとして、企業システム基盤をクラウド化する「エンタープライズクラウド（プライベートクラウド）」など、弊社としても注力している分野でもあります。

　これに付随して、KVM(Key Value Store）を用いたプログラミングモデルは、リレーショナルデータベースの世界にも一石を投じているように感じます。このへんは、エンジニアであれば押さえておく必要がありそうですよね。自分もまだまだ勉強できていませんが……。

　あと、金融業界もサブプライムローンの影響が収束し始め、ガバナンス確保のための手を打ち始めていますが、少なからず、金融業界で働く自分のようなエンジニアにも影響がありますので、こちらも仕事柄、目が離せません。

　なんか、あれもこれもやらなくちゃいけないわけですが、これがITエンジニアの醍醐味なのかな、と楽しんでやっていこうかなと思っています。

　やっぱり、これだけのことを勉強しながら仕事をやっていくことを求められるITエンジニアっていうのは、面白い職業ですね。

　（念のため注釈ですが、以上はすべて、個人的なコメントなので、ご理解のほどよろしくお願いします）

■2009年総括

　いろいろと振り返ってみましたが、まとめてみると、一歩を踏み出せた貴重な年でした。何よりも、こうして年初に立てた目標通りにコラムを書かせていただけているわけですし。

　あまり考えすぎずに、まずは筆慣らしという位置づけで、良かったのではないでしょうか。小さな一歩ではありますが、こういうちょっとしたことに喜びを感じながら、2010年も活動していきたいと思います。

　あと、コラムニストさんともコメントやTwitterなどなど、いろいろな場を通じて価値観の交換をしていけるといいな～と。

　最後に、コラムネタ探しではないですが、ベンダSEに聞いてみたいＸＸなどあれば、良かったらコメントください！

　面白く膨らますことができるかは別としても、機会を見つけてコラムにしていきたいと思っています。

　不況が吹き荒れたIT業界でしたが、来年も好奇心を持って、楽しく逞しく頑張っていきましょう！

　みなさんも良い新年をお迎えください。

　若きメインフレーマーには参考になればと思うし、ベテランの方々にも昔をちょこっと思い出していただけるのではないでしょうか。

　それでは、しばらくの間お付き合いください。

■「メインフレームって単語くらいは知ってるんじゃないかな」

　こちらは今でもよく覚えているセリフです。

　研修を無事に卒業し、初めてのプロジェクト先が決まった頃、

　「サトマモさんは、どれくらいメインフレームのスキルがあるんですか？」

という、プロジェクト先のアドバイザーである先輩の質問に、当時の所属長がこのように答えていました……。かく言うわたしも、隣で頷いていたわけですが……。

　まずそもそも、驚くべきことかもしれませんが、わたしの入社した2006年の新人研修には、System z（IBMのメインフレームシステムの製品名です。IBMにはもう1種類のホストシステムがあるので区別のため、以降はSystem zと記載します）について、実際に触れるようなコースは、一切含まれていませんでした。

　かろうじて名前を知っていたのは、製品に関するコースがあり、一通りのハードウェアとソフトウェアの特徴について学ぶ機会があったからです。

　しかし、所詮は簡単な営業資料を読んだだけであり、System zに関するわたしの知識は、その時点で以下のようなものでした。

• とにかく信頼性が高い（Zeroダウンのzなので）
• でも、値段も高い（詳しくはいくらか分からない）
• 最新テクノロジーの塊

　……ええ、本当に適当なイメージしかなく、今書いていて恥ずかしいです。

　とにもかくにも、JavaでWebアプリを作ったり、ソリューション提案の研修ばかりやっていた新人が、ぽ～んっとSystem zの世界に放り込まれたのです。

　昨今の弊社新人には、こういうケースの人がけっこうかもしれないので、現場のベテランの方々はご容赦ください……。

■調べても調べても分からない単語を調べ続ける日々

　プロジェクトアサイン当初は、インフラの基本設計が終わり、ちょうど詳細設計の途中でした。データセンターを新たに構築するプロジェクトだったため、結構大がかりです。まず手始めに、と言わんばかりに、300ページあまりの基本設計書をドスンと渡されました。

　基本設計書というのは、その名の通り、プロジェクトのマスタースケジュールだとか、基本的な設計コンセプト、移行計画、技術要素の検討内容等について述べているものです。

　読み始めたは良いものの、当たり前ですが、System zに関連した用語がすっかり分かりません。どうしようもないので、とりあえず、分からない単語は片っ端からノートへメモすることにしました。

　インターネット世代の若者であるわたしは、ご明察の通り、拾った単語をGoogle検索へ突っ込みました。世界のGoogleやWikipediaのおかげで、たいていの分からないこともとりあえず調べられる世の中ですよね。

　しかしながら。

　System zに関する情報って、インターネットにはあまり落ちてないんです。もちろん、探すとたまに見つかるんですが、期待しているような分かりやすい、ドンピシャリな資料はほとんど出てこないのが現状です。

　お客様先にいて、インターネットくらいが唯一の情報源だったわたしにとっては、死活問題でした。

　そもそも、System zのマニュアルなどはすべてインターネットに公開されているので、それを読めばよいのですが、単語も分からない新人に、いきなりマニュアルはいささかレベルが高かったのも事実です。

　結局、会社に戻った際に、自習用の資料などを集めてもっていきましたが、結局、単語を調べたたり資料を読んでみたところで、机上の空論というか、全然イメージができず、理解するにはほど遠い状態で、1カ月が過ぎていきました。

　社内にはクラスルームの研修もあるので、行っても良かったのですが、アドバイザーの先輩曰く、

　「研修行くよりも現場の方が勉強になると思うし、行かなくていいんじゃない？」

　とのこと。なので、構築作業が始まるまでは詳細設計書のレビューに参加したり、資料の手直しを手伝う日々を過ごしました。

　今のわたしなら、研修に行って全体像を掴んでから、作業へ参加するところですが、ホストインフラの現場って、こういう根性論のような現場主義があったりするのも、また事実ですね。当然、このような方法が重要な面もあります。個人的には、新人の間に現場であれこれトライできて、良い経験だったと思っています。

■データセンターにてSystem z 構築開始

　年が明けた2007年。データセンターへSystem zが導入され、構築作業が開始されました。

　導入セットアップが終わった日、データセンターでの初電源オンをしたことを、未だに昨日のことのように覚えています。

　System zは常時稼働していることがほとんどですし、本当に電源までオフにすることは滅多にありません。そう考えると貴重な電源オンの瞬間でした。

　さて、実際の構築作業とはいっても、さすがに何して良いか分からない戦力外なため、最初は端末用パソコンのセットアップがお仕事です。

　これはこれで、マウスが使えないとか、いろいろと細かいトラブルがあったのですが、本編とは関係ないので割愛しましょう……。

　構築作業は進み、ついにSystem zの初回起動です。z用語では、システムを起動することをIPL（Initial Program Loading）と呼びます。システムを起動するための殻である区画を設定していくのですが、この辺の作業は、もうひたすら眺めているわけです。ひたすらメモを取りつつ。

　システムに触れていると、正確にメモを取ることが大事なことが良くあります。特に、データセンターではセキュリティ要件で、外部とのネットワークも遮断されていたり、そもそもエラーメッセージも保存できない状況があるからです。

　また、書くことで自分の勉強にもなります。ちょっと後で勉強してから見直してみると、あの事象はこういうことだったのか…と合点がいくことも良くあります。

　初回起動後もカスタマイズをしていく過程で、手順をメモしたり、エラーが発生してはエラーメッセージをメモしたり、ひたすらメモっていました。メモしたことは帰ってから、資料やマニュアルと突き合わせて、その都度「なるほど」と理解していきました。

　いわゆる、「何が分からないのかが分からない」という強烈な体験をした3カ月間でした。

■初めてのトラブル発生！

　構築作業も少しずつ進んで2ヶ月ほど経った頃。開発環境の構築という、新たな作業が始まりました。

　インフラ基盤の作業項目としては、開発環境を整備するというのは重要なことで、実施するテストに対して、必要なシステム資源（CPU能力、メモリ、ディスクなど）を見積って、準備していきます。今回の構築に関しては、そこまで詳細な見積もりはせずに、既存の開発環境をコピーして作成するというものでした。

　相変わらず、話を聞いても訳が分からないところは多々ありつつも、雰囲気を見ていると、うまくいきそうだなぁと楽観視していたのです。

　立ち上げ初日。データセンターで作ってきた手順通り作業を進めていきます。コピーしたシステムデータを使ってIPL。起動のログがコンソールという端末用パソコンへ出力されます。流れるのが早くて全部は読めないんですけどね。

　そのまま、無事に起動するかと思いきや……。真っ赤なエラーメッセージが出てきました！！

　構築チームのメンバー全員がビックリして、マニュアルをひっくり返し、コマンドを打ち込むのですが、いっこうにエラーは解消されず……。仕方なくシステムを停止します。ちなみに、わたしはひたすら実施したコマンドやメッセージをメモです。議事録同様、メモ取りも新人の仕事ですね。

　原因が分からず、みんなで頭を悩ませました。開発環境構築のスケジュールもあるため、失敗しましたとただ帰るわけにもいきません。

　プロジェクトのメンバーにも相談しながら、試行錯誤して、気づけばとっくに深夜になっていました。

　まだ開発環境だったので、お客様の業務には全く影響がなかったことは幸いだったのですが、大きなトラブルはこれが初めてということもあり、昨日のことのように鮮明に覚えています。

　これが噂に聞く、システムエンジニアの仕事なんだな、と感じた日でもあります。

■最初の3カ月を終えて……

　データセンターで四苦八苦した3カ月では、自分のスキル不足を痛感すると同時に、メインフレームの取っつきにくさも理解した時期だったと思います。

　見たことのない機械、見たことのない端末、見たことのない機能……。パソコンが当たり前だからこそ、余計に違うことが難しく感じてしまうのかもしれません。コンピューター＝パソコンの世界で育ったわたしたちには、その異質さは受け入れにくい巨大な存在であるとすら思うわけです。

　それでも、「コンピューターは何故動くのか」ということと、トコトン向き合えるメインフレームの世界は、エンジニアとして非常に有意義な勉強場所でもあり、ぜひ一度は触れてみて欲しい世界だと感じています。

　このときの体験から、現在は社内コミュニティで、若手System z担当の技術者がメインフレームのスキルを効率よく身につけていくためには、どんな工夫が必要か、ということを検討する活動に参加しています。少しでも取っつきにくさを少なくして、メインフレームを楽しいと感じてもらいたいんです。経験をその後にどう活かすのか、ということも大切なことですよね。

　メインフレームの技術は今もどんどん進化しており、System zではLinuxまで稼働することができます。お客様のシステムに対する要件が厳しくなればなるほど、信頼性に優れたメインフレームの出番はあり、当分はなくならないでしょう。

　そう考えると、メインフレームと今のエンジニアがどのように接していくべきか、昔を大事にしながらも、今はどうするべきか？ という温故知新の視点が必要だろう……というのが、このコラムのタイトルに込めた意味でした。

　特に締まりもなく、長々と書き綴ってしまいましたが、いかがだったでしょうか？

　メインフレーム担当でない方も、新人の頃は色々と苦労されたと思います。もし、このコラムで思い出すことなどがあれば、ぜひコメントください✏

　プライベートでやや混沌とした日々を送っておりましたので、気分転換に『時事争論』の話題に乗っかってみることにします。

■就活生からの『ITエンジニアの仕事についての質問』

○ワークライフバランスについて：
＞仕事（残業）と私生活の両立はうまくいっているか、うまくいく方法

　最初から難しい質問です……。わたし自身はうまくいっている方だと思いますが、そもそも「うまくいく」というのは何でしょう、というのを考えてみると良いのかもしれません。

　学生の頃は、やりたいこと全部をやる時間があったかもしれません。しかし、就職して仕事をするようになると、どうしたって学生時代と同じような時間の使い方はできません。

　私生活の両立が「今まで通り好きなことに時間を使えるか？」ということであれば、これは100％不可能だと思います。

　わたしの場合は、まずは社会人として私生活の在り方を変えていったことが、バランスをうまくとれているポイントでしょうか。

　仕事や勉強で必要な時間と自分の本当にやりたいことの時間のバランスを見極めて、状況に応じて対応するのが大切だと思います。

　そりゃー時には朝から晩まで仕事をしなくてはいけない時もあります。特に新人にはスキルもないし、人一倍物事に時間がかかるのだから、これは覚悟しないといけません。

　しかし、バランス感覚が身について、仕事もこなれてくると、残業しなくてはいけない時間が減ったり、コントロールできるようになってくるので、私生活との両立は夢ではありません。

○デスマーチ・プロジェクトについて：
＞経験はあるか、どれくらいの頻度であるのか、経験談など

　幸い、デスマーチまで達する経験はありませんが、かなりスケジュールがきつかったことは何度もあります。

　わたしは3年間同じプロジェクトに参加していましたが、年に3、4回ピークがありました。その時期は終電あるいは深夜まで……ということもありました。

　なかには無理をして倒れてしまう人もいたりするのですが、傾向としては、悩みすぎたり、仕事を抱えてしまう真面目な人が多いですね。わたしのようにおおざっぱだと、ちょっと疲れるくらいで何とか乗り越えられます。

　デスマーチなプロジェクトに参加した友人の話では、そういうプロジェクトになると、忙しいのにみんなの士気が低くなっており、だらだらと夜中まで開発し続けている……とか、そんな噂は聞いたことがあります。

　でも、業界的にはだんだんとそういう無茶なプロジェクトは減ってきているようです。

○ブラック企業について：
＞ブラック企業に在籍していたことがあるか、周りや自分の経験談、ブラック企業の見分け方など

　これは分かりません。少なくとも、2ちゃんねるの情報を鵜呑みにするようなことはないようにしたほうが良いですね。

　人事の方と話した時にオーラで感じ取ったり、業界誌のようなものの批評にも目を通してみるといいのではないでしょうか？ あと、現場の人にも会ってみることをお勧めします。

○学生時代に学んだこと（プログラミングやロジック）は役に立つか

　全部役に立ちます。ただし、直接的には役立たないこともありますので、その際に凹まないようにしましょう。

　わたしの場合がまさにそうなのですが、学生時代や研修で勉強した知識は、メインフレームという世界では直接使えるものはほとんどありませんでした。

　しかし、言語やロジックの知識やコンピューターの扱いは、ITに共通するものですので、仕事をしていると役立つことを実感できると思います。

○学生時代に「これをやっておけばなあ」と思ったこと

　これもよく聞かれますが、外資系に就職してしまったわたしとしては、もっと英語を真面目に勉強しておけば良かったかなぁと感じています。

　でも、個人的には学生時代は大いに楽しんで、人生経験やネットワークを広げたりと、伸び伸び過ごした方が社会に出てからも楽しくやっていけると思いますね。多少スタートは遅れても、やる気さえあれば何とかなります。

○人と話すのが苦手な自分でも、エンジニアをやれるか

　話すのが嫌い、というのだと大変ですが、苦手なくらいは問題ないと思います。

　真摯な気持ちというのは必ず伝わるものですし、ロジックや技術をしっかりと身につけておけば、コメンテーターのようにペラペラ話す必要はありません。

　資料を上手く作るとか、コミュニケーションをフォローする手段もたくさんありますし、同僚や先輩に助けてもらうのだって、恥ずかしいことではありませんので。

■回答してみて感想

　こうしてみると、自分が就職活動時に気になっていたことがほとんど出てこず、自分がいかに適当な就職活動をしていたのかと反省しました……。

　来年も新卒採用は非常に厳しいとの見通しですが、ぜひとも頑張ってもらいたいものです。わたしの弟も来年就職活動なのですが、幸運を祈るのみ……という感じですね。

　デスマーチやワークライフバランスなど、IT業界で出てきそうなキーワードがあるものの、読み返してみると、ITエンジニアだけに限った話ではないと思います。

　個人的には「IT業界だから飛び抜けて忙しい」ということはないと思いますので、尻込みせずに飛び込んできて欲しいと思います！ 頑張ってください！

　みなさん、はじめまして。

　この度、エンジニアライフにコラムを掲載させていただくことになりましたサトマモと申します。このペンネームは、後輩がわたしのことをこう呼んでいるので。

　「温故知新とエンジニアの地位確立を目指して」

という大それたタイトルを付けてしまったことに、やや後悔しているのですが、日々の現場で思うことや今後のIT業界について、エンジニアとしてどう成長していこうか、など自分事たっぷりに書き綴っていきたいと思いますので、ご気軽にコメントいただければ幸いです。

　簡単に経歴を紹介します。

　2006年に日本IBMに入社し、今年で4年目のITエンジニアです。

　最初のプロジェクトは金融機関の基幹系システム構築ということで、メインフレーム、いわゆる“ホスト”と呼ばれているシステムの構築に携わりました。

　2年半に渡るプロジェクトを無事に終え、現在は新たなお客様先で、同様に基幹システムの構築・運用サポートの業務を担当しています。

　業務で直接携わることも少ないのですが、ITアーキテクチャやアプリケーション・アーキテクチャなどにも興味を持っています。

■なぜコラムを書こうと思ったのか？

　さて、そもそも、なぜコラムを書き始めようと思ったのかというか、以下のような想いがあります。

• ITの現場で感じることを共有したい
• ベンダのエンジニアとしての視点も提供したい
• 普段の業務を離れて、エンジニアの方々と交流したい
• 物を書くという活動も進めたい

　それぞれ、簡単に説明します。

１.ITの現場で感じることを共有したい

　他のコラムニストの方々もたくさん書かれていますが、やはり現場でのコミュニケーションやシチュエーションで疑問に感じたり、時としては憤りを感じたりということも多々あります。

　社内で愚痴っていても発展性がありませんので、コラムとして何かしらの形に残すことで、皆さんとディスカッションするネタになったり、新たな知見が得られると良いなと考えています。

2.ベンダのエンジニアとしての視点も提供したい

　近年、ITエンジニアのスキルなどについては、なんとなく世の中にも伝わり始めてきたように感じます。しかし、ベンダのシステムエンジニアの仕事というのは、いまいちよく理解されていないのではないでしょうか。

　フリーランスの方やスキル指向のエンジニアの方々とは、やはりちょっと異なるサラリーマンとしての一面があります。

　ベンダのSEに対して、「エンジニアなのにスキルが低くて話にならない」と思われる方も多いと思いますが、確かにそういう場合も多々あるのだと思います。

　ただし、これも一概にスキルがない＝悪いこと、ではなくて、やはり仕事が違うんだと思っています。とはいえ、実はITスキルもものすごく求められるという……かなり厳しい立場にありますので、その辺もわたしの視点から論じていきたいと思います。このネタは賛否両論ありそうで、楽しみですね。

3.普段の業務を離れて、エンジニアの方々と交流したい

　たまに社外のセミナーや勉強会にうかがうと、やはり立場も視点も異なる方々とお話をする機会が多く、非常に刺激を受けます。色んなビジネスや技術や考え方があり、自分の視野が閉鎖的にならないように、歯止めをかけてくれていると感じています。そういう交流の一端でも、この場で得られれば幸いです。ベンダのシステムエンジニアはあまりこういう場には出てこないですよね。それもそれで、どうなんだというところですが……。

4.物を書くという活動も進めたい

　個人的に物を書く、ということは嫌いではありません（中毒というほど好きでもありませんが）。せっかくなので、世に触れるところで文章を書いて、自分の作文能力に磨きをかけて行きたいという想いです。好き＝得意ではないので、見苦しいものもあるかと思いますが、ご容赦ください。

　いろいろと書き散らかしましたが、エンジニアライフの熱い諸先輩方の仲間入りできるよう、熱いコラム執筆を頑張っていきたいと思います。

　今後どうぞよろしくお願いします。