術後、2～3日してから痛みが取れはじめ、入院とはいえ、久しぶりに暇な時間をすごしました。目を使えないのでラジオを聞いたり、音楽を聞いたり、おいしくない病院食を楽しみにしたり、考えごとをしたり、結果的にはいいリフレッシュになりました。そして、あの苦痛の手術を受けてから4日後に、無事退院できました。
【退院後】
退院後は前職の職場にすぐに仕事復帰し、残タスクなどをこなし、術後から2週間たった頃に目から糸が出てきて、3週間後には現職の職場に転職するという、精神的にも体力的にも少々しんどい思いをしました。その後の経過も問題なく、目に異変もなく過ごせています。また、目の充血や腫れが取れるのには約1カ月ほどかかりました。
【網膜剥離の誤解】
網膜剥離という病名自体は有名ですが、誤解している方が多いなと感じることがたびたびありました。そのため、よく受けた質問をまとめたいと思います（ただし、わたしは医者ではありませんので、ちゃんと知りたい方はお医者さんに直接聞かれることをお勧めします）。
・「ボクサー以外でもなるのか？」
外傷性が原因の場合、ボクシングのように眼球に衝撃を受けやすい格闘技などもなる可能性があります。わたしのように、サッカーが原因のケースも存在し、野球やテニスでもボールが当たったことによりなる可能性があるようです（もちろん、完治すれば復帰が可能です）。
・「職業病なのか？」
「開発中にPCをずっと眺めていて、目を酷使するからなるのか？」 とよく聞かれましたが、目の酷使で発症するということはなく、ましては開発者がなりやすいということはありません。
・「失明するのか？」
放置しておくと、失明する可能性があります。網膜剥離は剥がれた分（例：上がはがれると下が）だけ症状としては視野が欠損しますので、視野が狭く感じたりする場合は疑いがあるので検査をおすすめします。
・「痛みはあるのか？」
剥離自体に痛みはありません。
・「視力は戻るのか？」
剥離が進んだ状態にもよるそうですが、発見と処置が早ければ早いほど戻りやすくなると言われています。
・「再発の可能性はあるのか？」
再発の可能性はあるので術後も半年から1年毎に定期検査を行う必要があります。わたしはこれを怠ったせいで左目の発見が遅くなりました……。
・「コンタクトは使用できるのか？」
問題なく使用できます。
・「レーシックは受けられるのか？」
病院にもよりますが術後半年や、1年以上経っていれば問題なく受けられるようですが、わたしにはもう受ける度胸はありません。
【まとめ】
網膜剥離は適切な手術を施せば、9割以上が治ると言われています。また、わたしのようにすぐに仕事に復帰できますし、普段の生活に支障が出るようなことはありません、精神的にはまた強くなった気もします。
最後に、当コラムで同じ診断を受けた方が、少しでも手術と入院への不安を和らげたらと思います。
]]>さて、網膜剥離ですが、進行性のあるものと、進行が止まるものがあります。私の場合はだいぶ前に発症し、たまたま進行がとまっていたため、自覚症状がなかったようです(右目の時は進行性があったため、即入院、即手術でした)。
20年前は1カ月の入院だったのですが、今では1週間ほどで退院できるとのことで技術の進歩を実感しました。また、仕事は退院後2～3日後であれば復帰できるだろうということでした。
診断の翌日、当時の職場にできるだけ早く手術を受けるため、有給消化をスライドしてもらい、内定先にもエージェントを通して現状を伝えました。また、紹介された病院でそれから1週間後に入院と手術が決定しました。
【手術直前】
入院した翌日に手術を受けることになりました。手術は、子供の場合は全身麻酔、成人の場合は部分麻酔になります。目の手術は基本的に痛くないと言われていますが、その中でも網膜剥離は痛い部類に入ります。
手術の当日、多少不安はあったものの、自分自身で右目の手術が成功し、問題なく見えている経験をしているため、比較的リラックスして手術を迎えました。手術室に入る直前にはふたたび余裕でつぶやいています。
このあと、看護士さんに怒られたあげく、iPhoneを取り上げられ、想像をはるかに超えた恐怖の手術を迎えることになります。
【手術】
まず、麻酔の注射を受けます。先生からは「痛いですが我慢してください」と言われ、医者はだいたい大げさだとたかをくくっていたところ、目の下に注射を刺され、味わったことのない激痛が走りました。この時点で、さっきまでの余裕はありません。
続いて、手術中は部分麻酔なので、意識もあり、先生が自分の目を触ったりしていることはわかる程度の視力がありました。そのため、目にバックルを縫いつけたり、穴をふさぐために人工的に凍傷を起こしたりなど、手術のすべての工程が分かります。
凍傷を起こすためのマシンが調子が悪く「再起動してみようか？」といった【困ったときには再起動】が医療の現場でも行われていたり、大学病院で手術を受けたため、研修医とのやりとりも長く感じます。
先生「ここに穴が空いている、見てみなさい」
研修医「良く見えません」
先生「ここだよ、よく見てみなさい」
といった手術を早く終わらせて欲しいと思っている患者としては、いじめるためにわざとやってるんじゃないかと勘ぐってしまうほど、精神的に追い込まれた時間でした。
【手術後】
手術の時間は1時間半程度でしたが、目をえぐられていますから放心状態です。車椅子に乗せられ、ベッドについて横になっていると麻酔が切れはじめ、眼の奥のほうから鈍痛を感じるようになりました。痛み止めはもらうものの、この痛みは2～3日続くことになります。
つづく
]]>エンジニアは特に目を使う仕事なので仕事を続けられるのか？ など、より不安に考えてしまうかもしれません。当記事で少しでも不安を和らげていただけると幸いです。
【レーシックの検査】
それは、約3年勤めた会社へ退職の旨を告げ、新天地への期待と不安を募らせていた矢先に発覚した出来事でした。メガネを掛けるのがだんだんおっくうになり、転職を機に、流行りのレーシックを受けようか迷っていたところ、たまたま応募していたレーシックのモニターに当選し、無料で受けられるいうこともあっていい年してだいぶ浮かれていました。
実際にレーシックの検査を受けたときにはのんきにこうつぶやいています。
このつぶやき後、いくつか検査を受けて先生に告げられる衝撃的な宣告のことを思い出すと、恥ずかしくて目も当てられません。
検査のあと先生に「網膜剥離なので、レーシックの前に網膜剥離を根治してください」と告げられました。
【網膜剥離って？】
網膜剥離とは、ボクサーがなりやすく、そしてキャプテン翼のロベルト本郷がそれを原因に引退を決意したあの網膜剥離です。
もともと、わたしは小学生の頃に外傷性の網膜剥離で手術の経験があり、一瞬そのことかと考えたのですが、よくよく聞いてみると手術を受けた右目ではなく、正常だと思っていた左目で網膜剥離が発症していました。
20年以上前に受けた手術と1カ月の入院の記憶が蘇るなか、当時の職場と内定先にこのことを伝えなければと考えながら、病院をあとにしました。
つづく
]]>初めは苦痛？ でしたが、だんだんと肩肘を張らずに読めるようになりました。仕事にかかわる技術系の本から自己啓発やビジネス系へ手を伸ばし、いまでは古典や小説にまで手を伸ばせるようになりました。
いままで読んだ本は、何かしらの影響をわたしに与えているのですが、その中でいくつか紹介していきたいと思います。
【達人プログラマー】
技術系の本で影響を受けた本はたくさんあるのですが、その中でもわたしのエンジニアとしてのキャリアの積み方にまで影響を与えた本です。
エンジニアであれば、技術の進歩の早さや多様さに圧倒され、何をどう勉強すればいいのかという焦燥感に駆られることと思いますが、この本には学習方法に関して1つの指針が書かれています。筆者は、以下のようなポートフォリオを考えるべきであると言っています。
やや古い書籍ではありますが、技術的（思想的）にもDRY原則（Don't Repeat Yourselfの略で「繰り返しを避ける」というソフトウェア設計上の原則）やメタプログラミングなど、非常に興味深いセンテンスが多く、自分自身のソフトウェアを設計する思想に大変影響を与えています。
【人を動かす】
ご存じの方も多いと思いますが、この本は「自己啓発の元祖」と呼ばれています。出版されてから約70年経ったいまも読まれいているのは、人間の本質をついているからだと思います。簡単に紹介すると、以下のような構成になっています。
初めて手にしたのは、チームのリーダーを任されてチームメンバーや後輩にどうやって接していけばいいかを模索していたときでした。一番、わたしに影響を与えたのは、以下の「人を動かす3原則」でした。
現在も十分にできているか？ というと疑問ですが、当時一通りの仕事を覚え、人の面倒を見るという新しい役割を与えられ、なかなか自分の思うように仕事を振ることができず、「自分でやった方が早い」「人には任せられない」と考えて勝手に忙しくなっていたころに読み、目から鱗が落ちる思いでした。姉妹本の「道は開ける」もお勧めです。
【ビジョナリーカンパニー1＆2】
こちらも大変有名な本です。時代を超えて生存する企業とそうではない企業との違いを指摘し、「ビジョナリーカンパニーとは、基本理念を持って成長する企業である」と書いています。
ベンチャー企業に勤めているわたしにとっては勇気の出る本です。目先の売り上げに振り回されたり、自分の仕事が何の役に立つのか分からないときなどに理念を持って動くことの正しさを思い出すために、いまでも頻繁に読み返します。
【中国古典の知恵に学ぶ 菜根譚】
中国の古典の1つで、400年ほど前に書かれた処世訓です。
「菜根譚」とは、
「人よく菜根を咬みえば、すなわち百事なすべし」（堅い菜根を噛みしめるように、苦しい境遇に耐えることができれば、人は多くのことを成し遂げることができる）
という言葉に由来します。
エンジニアはついつい仕事に追われがちなことが多いですが、バランスをもって生きていく大切さが分かる本であり、プライベートでも仕事でも自分の判断基準となってくれる本の1つです。
本書には原著から220項目が選び出されていますが、その中から1つだけ紹介します。
「苦労もし、ゆとりも持つ」
あまりに暇すぎると、どうでもいい雑念が頭をよぎるものだ。逆に、あまりに忙しすぎると、今度は自分の本心を見つめる余裕がなくなり、自分を見失ってしまう。心身の苦労はあったほうがいいのである。しかし、一方で、風流を楽しむ心のゆとりも持ち合わせていなければならない。
本書自体は優しく訳されていますので、興味のあるかたは原著もお勧めします。
【ワンピース】
週刊少年ジャンプで連載中の、大人気漫画です。ジャンプの3大キーワードである「友情・努力・勝利」の全てが詰まった漫画で、もちろんストーリー自体や複雑に張られた伏線はもちろん、各キャラクターに与えられた役割、各キャラクター自身がお互いを尊重して自分の役割をまっとうする姿が魅力的です。
ベンチャーにいるわたしにとって、とても参考になる組織(海賊団ですが……)なのです。会社を大きくしていくうえで、こうでありたいと思う組織の1つです。
]]>転職をしたいと考える理由は何であれ、今の仕事を続けるよりも新天地で働きたいという欲望が勝っているからこそ、転職活動は頑張れるものです。しかし、書類選考で落とされたり、面接で落とされたりすれば、恋人に振られた時のような絶望感に苛まれることもあります。
逆に転職活動を通して学ぶことも多く、新しい自分の可能性を見いだすことも可能です。
また、恋愛と転職活動はよく似ているといわれます。言葉は悪いですが、今の彼女に飽きて新しい彼女を見つけようという感じでしょうか。
そこで今回はわたしの経験を踏まえ、転職活動を恋愛にたとえながら、わたしなりの転職活動(恋愛？)のコツをいくつか紹介したいと思います。
1．転職エージェントとのつきあい方(恋のキューピットとのつきあい方)
恋愛にたとえるならば、エージェントは恋のキューピットです。恋のキューピッドは意中の相手と仲良くなるために上手く使うことが必要です。
ビジネスモデルの構造上、転職エージェントの存在には賛否両論がありますが、よいエージェントと出会えれば心強いことは確かです。
自分がどれだけ業界内で価値があるのか、自分では知ることができなかった今後のキャリアの可能性など有益なアドバイスをもらえます。
また、普通の応募であれば、応募した会社から返ってくるのは選考結果のみですが、エージェント経由での応募の場合は選考のフィードバックがもらえることが多く、より客観的な自分への評価を得ることができます。
メリットばかりを言いましたが、エージェントは「あなたを転職させることによって」利益を得ていますので、自分を経由した会社から内定を貰えればあなたにその会社を薦めます。
この行為自体に良い、悪いはなく、ビジネスモデルの都合上、率先して薦めるのは当たり前の行動です(もちろんあなたのキャリアをちゃんと考えてくれて他社を薦めるエージェントも存在します)。
したがって、最終的に決めるのは自分であることを肝に銘じる必要があり、エージェントに振り回されるのではなく、上手に使うぐらいの気持ちでつきあう方がうまくいくのではないかと思います。
2．選考で落とされた！(振られた！)
これまで、どんな人でも一度や二度、恋人に振られたり、恋が叶わなかったりした経験はあるのではないでしょうか？
同様に転職でもよほど優秀な方でない限り選考で落とされることは普通にあります。自分が否定されたような気分になってしまい、落ち込む場合もあるかもしれません。
精神論になってしまいますが、恋愛と一緒で転職活動中はいちいち落ち込んでいたら、きりがなく次に力を注ぎ込むべきです。
書類選考で落ちたのであれば、履歴書や職務経歴書を見直し、自分がやってきたことが伝わるように修正をするべきです。
面接で落ちたのであれば、自分の応対に問題はなかったかどうかを考察し、次の面接では同じような過ちを起こさないように注意をしなければいけません。
「縁がなかった」と前向きにとらえ、前向きに次の行動へ移すことが大事だと思います。
3．転職する理由(付き合いたい理由)
わたしの偏った感覚かもしれませんが、恋人がいるにもかかわらず、別な人を好きになる場合は付き合っている恋人とは別な魅力を持っていることが多くありませんか？
そして、転職理由の基本は「今の会社で実現できないことを、転職先で実現する」です。
しかし、転職の理由として「人間関係」、「給料が安い」というようなオーソドックスで世間的には後ろ向きと捉えられる理由は、応募先には言いづらいものです。
わたしはたとえ、そういった理由でも自分に、肉体的にも精神的にも害があるのであれば正当な理由だと考えていますが、後ろ向きな理由をどう伝えたらいいのかよく悩みました。
エージェントを使っていれば、すべてを伝えた方がエージェント自身が動きやすく、暗にそういう理由をうまく伝えてくれることがあります。
自分で伝える場合には、例えば「給料が安い」となぜ考えるのかを感情に流されず冷静に突き詰めて考えれば、それを伝えるべきかそうでないかは判断が可能です。
応募先の会社には、「また同じ理由で辞めないか？ 」と考えさせないことを念頭においてうまく伝えれば、あのとき言っておけば良かったなどの後悔はなくなります。
4．面接(デート)
お付き合いする前のデートは自分をアピールすることも大事ですが、相手を知るということも大変重要です。
転職における面接も会社側からみた選考という視点ではなく、相互理解の場です。
たった2、3回程度の話し合いで自分の人となりを見てもらい、相手の社風や求められることを理解しなければいけません。
だからそこに駆け引きは必要なく、いかに正直に自分のことを伝え、相手にも正直に状況を伝えてもらうべきだと思います。
完璧な人間が存在しないように、完璧でない人間が作った会社が完璧であるはずがありません。自分のアピールだけで終わらずに、相手の会社を知ることを忘れずに面接に臨むことが必要です。
5．退職の意志表明(お別れ)
恋愛で別れは告げられる側より告げる側のほうが辛いと言われますが、転職活動でも一番心苦しいのは退職の意志を伝えることではないでしょうか？
お世話になった先輩、一緒に仕事した同期、可愛い後輩のことを思い浮かべるとなかなか伝えづらいもので、今日伝えよう、明日伝えようとなかなか伝えられないこともありました。
心ない人から裏切り者だとか言われることもありますが、自分で決めたことですので、いちいち気にせずに堂々と感謝を忘れずに退職の意志を伝えることが大事だと思います。
6．新しい職場で(つきあいの始まり)
新しい恋人と付き合うにあたり、付き合う前は気にならなかったようなことが目についたり、意見の食い違いなどは必ず出てきます。
新しい職場でまず気をつけなければいけないのは、今まで自分がやってきた仕事のやり方を押し付けたり、押し通したりしないことです。
新しい職場には新しい職場のやり方があり、それをまずは尊重すべきです。尊重した上で、明らかに非効率的であったり、よいやり方がある場合に慎重に提案や改善を行いましょう。
また、中途採用で入ったことを意識しなければいけません。新卒採用はポテンシャルのみで採用を行いますが、中途採用というのはあくまで即戦力として期待されています。
自分が現状何を期待されているのか、将来的に何を期待されているのかをしっかりと理解した上で、即戦力としてのアウトプットを出しつつ、中途採用としての新しい風を社内に吹き込むぐらいの意気込みを持つことが大事かと思います。
【最後に】
恋愛は付き合ってからのほうが本当の始まりであるように、転職が成功したかどうかは転職先が決まった時点で分かるものではなく、転職先でいかに自分のやりたいことを実現し、十二分に力発揮できたかどうかにかかっていることを忘れないようにしましょう。
]]>頭と体が連動してくれるぎりぎりの年齢的になりつつあることもあり、今しかできないという焦燥感のもと、部活並みのサイクルでやっています。
週5回はやりすぎにしても、エンジニアは体を動かさない仕事ですので、週に2、3回は運動をする時間をもうけた方がよいというのがわたしの持論です。
ただ、運動をする効果や、習慣化するための仕組みを作る話は、blogや雑誌でもさんざん取り上げられているかと思います。
そこで今回は、わたしの好きなサッカーとビジネスにおけるチームプレイの共通点や、スポーツを通して学べるチームマネージメントを語りたいと思います。
【エンジョイ志向と競技志向】
フットサルやサッカーでチームを作る場合、たいていエンジョイ志向と競技志向のプレーヤー間で摩擦が生じます。
おおざっぱに説明すると、エンジョイ志向とは競技そのものを楽しむことを目的とし、競技志向とは試合に勝つことを目的とします。
互いの競技や勝利に対する温度差やチームとしてのベクトルがバラバラであるために摩擦が生じるのですが、ビジネスでも同じように仕事に対する温度差や、チーム内のベクトルがそろっていないと失敗するのは目に見えています。
こういった温度差やベクトルはいったんチームを組んだあとに改善するのは難しく、最初からチームとしての方向性を決める必要があります。
【チームプレイと個人プレイ】
チームスポーツであるサッカーにはポジションがあります。
なぜポジションがあるかといえば、「チームとして有機的に機能する」ために役割を決めておく必要があるからで、チームの目的は試合に勝つことです。
「複数の人間が同じ目的（試合に勝つ）に向かって、有機的に機能する」
これは「試合に勝つ」という目的を「プロジェクトや会社の成功」という言葉に置き換えるだけで、ビジネスにおけるチームマネジメントにも簡単に適用できます。
サッカーにしろ、ビジネスにしろ、各々に与えられたポジションをこなすことは大前提です。
しかし、ビジネスもサッカーも想定外のことは必ず起きます。
想定外のことが起きた時に、自分の役割だけをこなしていればよい、自分さえ目立てばよいというようなプレーヤーがいると、チームとしては不完全で、目的を達成することは難しくなります。
例えば、サッカーの試合も、ビジネスでも必ずピンチやチャンスが訪れます。FWでもピンチであればディフェンスをするし、チャンスであればDFも攻撃に参加します。
これは本来与えられた役割から外れた役割であっても、試合の状況を観察し、チームとして目的を達するために一番何をしなければいけないのかを、各々が判断をして生まれるプレーです。
プロジェクト内で「自分の仕事ではない」「言われてないからやらない」「言われたことしかしない」「自分は悪くない」というようなスタッフがいませんか？
そういったスタッフは大抵チームやプロジェクト全体を考えていない、考えられないスタッフです。プロのサッカー選手であれば、よほどの選手でない限り、試合に出られないかクビになってしまいます。
サッカー選手でないにしろ、対価をもらっている以上はプロであることは間違いないのですから、ビジネス上でも「今何をしなければいけないか」という意識を持つ必要はあると思います。
【コミュニケーション】
結局のところ、チームを成長、成熟させるためにはコミュニケーションをいかにとるか、ミスコミュニケーションをいかに減らすかにかかっています。
この場合は、議論をする、対話するという意味だけでなく、もう少し広い意味でのコミュニケーションになります。
サッカーの場合では、右利きの選手であれば右足で扱いやすいところへパスする、味方が得意なプレーをしやすいようにフォローをするというようなことを心がけますが、こういったプレーは、仕事上で相手を思いやってとる行動と非常によく似ています。
【サッカーは社会の縮図】
サッカーもプロジェクトも様々なバックグラウンドをもった人間が集まり、1つの目的に向かって行動をするという意味では、チームマネージメント、コミュニケーションの取り方などと、本質的には変わりはないと思っています。
サッカーバカの極論としては、サッカーで良いチームプレーができる人間はビジネスでも良い仕事ができるのだろうなと思いますし、逆もまたしかりです。
チームがうまく機能しているサッカーは美しいです。ビジネスでも同じように美しい仕事をしたいですね。
※最後に。本当にサッカーバカですので、都合が合えばお誘いいただいたフットサル、サッカーにはたいてい参加します。お声をかけてください。
]]>わたしが社会人としてデビューしたのは2000年で、就職氷河期と言われる世代になります。入社式で、社長が働くにあたって5つのメッセージがあると言って、結局、4つしかメッセージがなかったのを聞いて、「この会社大丈夫か」と不安になった覚えがあります。
入社した会社は典型的なSIerで、非常に仕事ができる人が何人か存在し、その人達を中心に新人や、2～3年目の若手がくっついていくというような会社でした。8割の社員は客先に常駐し、懇親会のたびに初めて会う先輩がたくさんいました。
入社後しばらくは、研修と勉強でかなり退屈な日々を過ごしていました。
1カ月ほどたち、会社の先輩2人がわたしより先に常駐していたところに、学生時代にJavaの経験がある（実際のところはありません……できる人のレポートをコピーしてました）という理由と、わたしの他に誰も立候補しなかったため、先輩達のおまけでわたしも常駐することになりました。
わたしの転機はこの常駐先でした。
【はじめての常駐】
当時のわたしのスキルはほぼないに等しく、ブラインドタッチができる程度でした。
サーバ、Linux、データベース、CSVなど、ミーティングで飛び交う単語はすべて分かりません。とりあえず、知ってる顔をしてメモってあとで調べる、というような毎日でした。
研修中は2人で1台という状況だったにもかかわらず、常駐先では開発環境として2台パソコンが与えられました。
「なぜ、パソコン2台がもいるの？」という状態でしたが、あとでサーバ用とクライアント用ということを理解し、「サーバって何？」から始まって、LinuxのインストールからWebサーバの構築まで、試行錯誤しつつ環境作りをしていました。
このときに「Try and Error」の癖がつきました。
当然、仕事をこなしていくのに、会社という場だけでスキルを磨くのでは追いつかないため、必然的に家でも勉強しなければ仕事ができない状態に。家でもパソコンに触れる機会が増えました。
OSといえばWindowsとUNIXしか知らなかったわたしがLinuxにはまり、毎日のようにいろんなディストリビューションをインストールしていました（当時好きだったディストリビューションはKondaraです）。
また、常駐先にいたエンジニアの方達は、本の買い方が豪快でした。
元来わたしは本嫌いでしたし、技術書は一般の書籍に比べると高く、購入するのをためらいがちでした。しかし、自分より技術のある人たちが本を買って勉強しているという事実を目の当たりにしたという焦りもあって、できるだけ読んでみたいと思った本は何も考えずに買うようにしていました。結果的には技術書に限らず、本を読んで知識を得て、自分なりの答えを見いだすという癖がつきました。
現在のわたしのエンジニアとしてのスキルは、この2つの癖のおかげだと思います。
こうして、わたしはたまたまこういった出会いや機会に恵まれ、エンジニアとしてなんとか生きてこれていますが、常駐先で1年間議事録しか書いていない、ずっと待機状態で勉強やたまのテストに借り出されていた、というような同期がいました。エンジニアとして採用されたのにもかかわらず、開発の経験をしないうちに嫌気がさして辞めていく同期もいました。
もちろん、会社の状態や景気にも関係することなのですが、IT業界で働いている人たちの多くが認識しているSIerの由々しき実態の1つだと思います。
（議事録を書くことやテストがエンジニアの仕事ではないという意味ではありません。それしかやらせてもらえないような会社が存在する、そういう実態を放置している会社が存在するという意味です）
【SIerで働く新人に向けて】
わたしは最初の会社に3年間所属しました。その中でもいいキャリアを積んでいる先輩、同期、後輩を見ていていくつか共通点があると感じていました。
その共通点を紹介したいと思います。
●なるべく目立つ
周りに顔と名前を覚えてもらわなければ、何も始まりません。さらに現実として、SIerはできる人のところにしかいい仕事は集まりません。
まずはできる人を探し出し、顔と名前を覚えてもらいましょう。
●よきメンターやロールモデルを見つける
社内でも社外でも構いません。目標とする人物を見つけることは、自分を客観視できるようになります。
●頭で考える前にやってみる
新人は何もできなくて当たり前です。頭でいくら考えてもなにもアウトプットは出てきません。
実際に手を動かしてみて初めて、やる気や興味がわくことのほうが多いです。
●技術で遊ぶ癖をつける
仕事上の技術だけでは補えないことがあります。なによりも遊ぶことで発見できるアイディアも多々あります。
●自分への投資を惜しまない
目の前の仕事はできて当たり前です。将来くる仕事をこなすためには投資が必要です。
●2～3年はワーク・ライフ・アンバランスで働く
プライベートをなくせとまでは言いませんが、 若いうちはがむしゃらに働く時期があっても良いと思いますし、この時期にエンジニアとして基礎体力をつける必要があります。
●顧客に成長させてもらう
顧客とは自分にとっての顧客です。つまり、社内の上司、先輩、実際のお客様、エンドユーザー、すべて当てはまります。
自分の顧客が自分に対して何を要求してるのかを把握し、その要求に答えることを念頭に置きながら、少しずつでもいいから良い意味で期待を裏切って成長していきましょう。
●背中で仕事をする
エンジニアは世間が考えているよりも泥臭い仕事が多く、自ら先頭に立って仕事をしなければいけないときがあります。
根性論になってしまいますが、そういったときにプロジェクトのスタッフがついてくるかは、背中で仕事をできるかどうかにかかっています。
SIerも様々なのですべてが当てはまるかどうかは分かりません。ただ、貴重な時期を無駄に過ごさないための予防策だと思って参考にしてもらえればと思います。
]]>エンジニアを10年もやっていると、それなりに経験が蓄積され、若いころであれば調べないと判断できないようなことも、培った経験で判断ができてしまうことが増えてきます。
しかし、そのような経験を過信してしまい、物事に対して先入観を持つことにより、間違った判断をしてしまうことがあります。
と判断していませんか？
「前にやったことがあるけどダメだった」
「アプリケーション側でエラーが起きるわけない、データベース側の問題だ！」
こんなセリフを吐いて思考停止していませんか？
【思考停止エンジニア】
わたしは経験だけで話をするエンジニアの言うことは信用ができません。
エンジニアの技術力はITのアンテナを張って体系的に学んだり、好奇心で学ぶ技術（勉強することによって得る技術力）と仕事で経験を積んで学ぶ技術（経験することによって得る技術力）という2つの側面によって成り立っているとわたしは考えています。
どちらかが大事ということではなく、両者をバランスよく保つことで、エンジニアはうまくスキルアップしていかなければならないのですが、後者の「経験による技術力」がたびたび、エンジニアを思考停止に陥らせます。
例えば、プログラミング言語はバージョンアップします。バージョンアップされれば、便利なAPIの追加や機能追加があります。
前のバージョンでは10行書かなければいけなかったものが1行ですんだり、自前で実装しないといけなかったものが標準化されることもあるでしょう。
極端な話、バージョンアップという事実を知らなければ、経験による技術力だけで判断することになり、「工数がかかる」「技術的に不可能だ」という判断に陥ってしまう可能性があります。
また、わたしはトラブル時にその道のエキスパートと呼ばれている人から、結果的には思い込みによる見当違いなアドバイスを受け、疑問を感じていながらも、エキスパートが言うんだから問題ないと思い込み、確認せずに業務を遂行したために痛い目に遭ってしまったこともあります。
このように、思考停止は伝染していくのです。
【エンジニアが心がけてみて欲しいこと】
エンジニアにとって経験は非常に大事ですし、技術の根本的な部分は、よほどの技術革新がない限り今後のキャリアを支えるスキルになります。
ただし、過去の経験を過信しすぎたり、自分のスキルに対して謙虚な気持ちがないと、それが先入観になり、冷静に考えれば解決できるような単純な間違えを起こす可能性があります。経験にかかわらず、先入観を持っていないか？ と問い続けましょう。
また、経験を積めば会議の場で発言したり、スタッフにアドバイスをする機会は多くなります。経験年数や実績は、自分が思っているよりもその「発言」に重みを持たせます。
若いころ、先輩やベテランエンジニアからのアドバイスは何も考えずに「そういうものなんだ」と受け入れていませんでしたか？
それを考えると、間違った発言やあやふやな発言はできなくなるのではないでしょうか？
「あの人がそう言っていた」からそうしたんだ、って言われないようにしましょう。
【こんなエンジニアと接するには？】
わたしは、非エンジニアの意見はエンジニアの先入観が入っていないため、エンジニアにとって貴重な意見であると考えています（中にはメチャクチャな意見を言う人もいますが……）。
若いエンジニアならともかく、ある程度経験を積んだエンジニアに対して意見を言うことは、しんどいと思うことがあるかもしれません（理屈っぽいし、意見を言われて条件反射的に怒るエンジニアもいますし……）。
エンジニアの発言に対して理解できない、先入観にとらわれていないかなど、疑問を感じた場合は、トヨタの改善活動のように「なぜなぜ5回」の精神で、なぜそういった考えや結論に至ったのかを聞いてみましょう。
]]> もちろん、面と向かって言われた方がいいに決まってますよね。
【なんでもメールで済ますエンジニア】
同じ社内にいるのに、というか目の前にいるのに、なんでもメールで済ますエンジニアはいませんか？
以前、トラブルを起こしてしまったエンジニアへ進言した際、たまたまわたしの勘が当たりトラブルが解決したことがありました。
その後、
「ありがとうございました。助かりました」
というメールがきました。
わたしと彼は同じフロアどころか、同じ島にいるにもかかわらずです……。
わたし自身は同じチームとして皆で解決したトラブルですから、別に感謝してほしいなんて思っていないし、こういったことはチームで仕事をしている以上お互い様だと思っています。と、建前はそうですが……実際、感謝されるというのは嬉しいものですよね。
そのときは「あれ、俺、目の前にいるよ……」と思うと同時に、「本当に感謝してるの？」と思ってしまいました。
このケースような御礼の言葉だけでなく、謝罪の言葉も直接もしくは電話で改めて伝えるなどの行動は「誠意」を伝えるためにも必要な行動だと思いませんか？
いくらメールが便利でも「誠意」や「思い」はメールだけでは伝わりません。
【エンジニアが心がけてみて欲しいこと】
エンジニアにはシャイな方が多く、こういった行動が恥ずかしいなどといういいわけをする方がいるかもしれません。
エンジニアである前に社会人であることを思い出してください。メールは書いて送るだけなので楽です。楽なだけに怠慢に過ぎません。
また、エンジニアは仕事が出来ればそれ以外のことはある程度許されると思っていたら大間違いです。よほどの天才エンジニアでない限り、そんな特権はありません。
人と接する場合には最低限のマナーが必要なのは理解はしていると思います。よりよい信頼関係を築くためには、小さい行動が大きく影響することを認識し、自分の行動を改めてみることが必要です。
【こんなエンジニアと接するには？】
今回はメールを取り上げましたが、実際に社会人としてのマナーが欠けているエンジニアは存在します。
新人ならともかく、何年も社会人を経験しているエンジニアにこういったことを注意すべきかどうか、悩ましいですね。
わたしの場合、会社や本人のためを思い本当に直して欲しいケースでは、注意ではなく「なぜメールだけで済ますのか？」と、エンジニアのいいわけを聞きます。
よほどひどいエンジニアでないかぎり、頭では分かっているのに行動できていないだけなので、行動することにより得られる結果と行動しないことによる結果の違いを教えてあげると、自分の誤りに気づいてくれるかもしれません。
つづく
]]>「大丈夫です」
というセリフを一番信用していません。
たいていの場合、「大丈夫」ではないんです……。
【大丈夫病エンジニア】
バグを修正するたびに「これで大丈夫」としか報告しないエンジニアはいませんか？
毎週の進捗報告で「大丈夫」としか報告しないエンジニアやプロジェクトマネージャはいませんか？
極論すると、「大丈夫」だらけのプロジェクトはおそらく火の玉プロジェクトの前兆です。
私自身、他人に迷惑をかけたくない、仕事ができないと思われたくない、何とかできると勘違いしているなど、あまり大丈夫ではないのについつい見栄を張って「大丈夫」と報告し、あとあと自分自身が痛い目に遭い、もちろん関係者に多大な迷惑をかけたことがありました。
また、あってはならないことですが、現場はまったくもって危険な状態であるという雰囲気なのにも関わらず、現場の空気を読めていないのか、顧客の手前「大丈夫ではない」という報告ができないのか、プロジェクトマネージャでさえも「大丈夫」と報告をしている悲惨なプロジェクトに遭遇したこともあります。
根拠のない「大丈夫」ほど信用できないものはありません。
エンジニアも人間ですから、「臭いものに蓋をする」というごまかし行動に傾いてしまうこともあるかもしれません。
しかし、勇気をもって、大丈夫ではないことをしっかりと関係者と共有しなければ、最初は小さなほつれだったものが徐々にプロジェクト全体へ影響を与え、火の玉プロジェクトへ発展していくのではないでしょうか。
【エンジニアが心がけてみて欲しいこと】
初心に返り、社会人になって最初に教育される「ほうれんそう（報告・連絡・相談）」を思い出してみてください。
何をもってそう報告しているのか、判断しているのかをしっかりと自分自身で再確認し、自分がどこまでリスクを考えているのかを明らかにすることが基本です。
報告する相手がテクノロジに疎い人物だった場合、エンジニアは報告してもどうせ理解できないだろうという傲慢な考えについつい陥りがちです。
しかし、最終的に困るのは自分自身であることを自覚し、自分がどう伝えるかではなく、相手がどうとらえるかという観点で、報告を行うことをおすすめます。
【こんなエンジニアと接するには？】
私自身、「大丈夫」という言葉を信用できないと思ったのは、自分が報告される側になったときでした。
それまで、自分なりに報告をしていたつもりでいましたが、まだまだ足りなかったんだと痛感した覚えがあります。
「立場が人を作る」といいます。私も実感したとおり、一番効果があると思います。
また、少々手荒い方法として、あえてほったらかしにして、火が回らない程度に失敗させるのも個人的には効果があると思います。
あわせて矢面にたって責任も取ってあげると、エンジニアからの信頼度も上がり一石二鳥です。
つづく
]]>そういった非現実的な思いがエンジニアを狂わすのでしょうか。バグが発生すれば、「きっと自分のせいじゃない！」、自分が出したバグであることが判明すれば、「すぐに直さなければ！」、お客様に「トラブル発生！」と迫られると、「早急に原因を特定します！」と反応してしまうことはありませんか？
【余裕のないエンジニア】
私が大規模なプロジェクトに関わったとき、開発チームとは別に20名程度のテストチームが組まれたことがありました。SIerではテストの役割を当てられるのは新人や2年目などの社員で構成されることが多く、チームの立ち上がりに時間がかかりながらも、若いだけあって高いモチベーションを保ちつつ、テストチームとしてかなり有機的に機能していきました。
やがて、彼らはゲーム感覚でバグを発見するようになり、バグを見つけるとガッツポーズまで出るようになっていました。この話は私にとっては笑い話なのですが、なかにはそのガッツポーズ見て、激怒した開発者がいました。
たしかに開発者にとって、バグを発見されたときの心境は気持ちのいいものでありません。それが致命的ものであれば逃げたくなることもあるでしょう。
ガッツポーズの是非はおいておきますが、理解しなきゃいけないのは仕事とはいえ、彼らは他人が作ったプログラムのテストを行い、バグを「見つけてくれた」のです。本来なら本番運用で発生する前にテストの段階で見つかったことを感謝すべきでしょう。
また、本番運用後にお客様のビジネスに影響する、もしくはエンドーユーザーに影響するようなトラブルが起きた場合、早急な対応を迫られることがあります。
シビアな状況だからこそ、冷静になるべきなのに焦って不適切な対処を行い、2次災害を起こしてしまうこともあるでしょう。
【エンジニアが心がけてみて欲しいこと】
何か問題が発生したとき、
「私のせいじゃない」
と宣言してしまったものの、深く調べているうちに、やはり自分が原因であることが判明してしまうことがあります。一番恥ずかしいですよね。バグや問題が発生したときには、自分が関係しているか否かに関わらず、客観的に間違いがないかどうかを疑いましょう。
また、バグを出してしまったことに対して、過敏に反応し、過剰に落ち込まないこと。開発を行っている限り、バグはつきものです。大袈裟ですが、バグとうまくつきあうことが大切です。
本番運用後でのトラブルの場合、お客様からの強いクレームに押されて我を失い、「原因を突き止め、早く直さなければ！」という心境に陥ることがあります。
原因を突き止めることも大事ですが、起きてしまったことはしょうがないと腹を括り、運用回避は可能なのか？ ビジネスにインパクトはあるのか？ など多方面から分析し、今すぐにシステムを直さなくても回避できる対処方法がないかどうかを探ることから考えましょう。
どうしてもプログラムを直さなければいけない場合、プログラムに手を入れることに対するリスクがあることをお客様やチーム内で共有を図り、関係者全員のコンセンサスを取る必要があります。「自分だけ」の判断で解決しようとせず、チームはもちろん、お客様も巻き込むことをお勧めします。
私の経験上、トラブル対応などイレギュラーな仕事を冷静かつ適切に行うと、普通に仕事をするよりも、お客様の信頼度はよりアップすることがあります。ピンチはチャンスとよく言いますが、まさにそうであることが多いかもしれません。
【こんなエンジニアと接するには？】
いつもは頼りがいがあるのにトラブルが発生すると頼りなくなるエンジニア。要はガラスのハートなのです。
バグを憎んで人を憎まず、できるだけ人を責めないようにしてください。普通の感覚を持ったエンジニアであれば、自分が引き起こしてしまったことは十分自覚しています。
もし、お客様の矢面に立つ立場であるならば、率先して開発者をかばってください。ITの仕事はスマートそうに見えて実際は泥臭い仕事。マネージャや上司は背中を見せることにより、開発者の信頼を得るものだと思います。
ITに限らず人は、納期や、上司の目、お客様の目など、何かしらのプレッシャーを感じながら仕事をしています。中には周りから見たら理解できないような（余計な？）プレッシャーを感じている人もいることを理解しつつ、不必要なプレッシャーを感じないようなチームや会社を作ることが必要なのだと思います。
つづく
]]>「間違っていそうだけど、仕様書に書いてあるし、このままいくか」
「こっちの仕様の方が良さそうだけど、面倒だから仕様書どおりにいこう」
こんな感じでとりあえず作ってはみたものの、ユーザーや営業から
「何でこんな作りになってるの？」
と言われついつい出てしまう言葉……
「仕様書にそう書いてあったから」
【言われたことしかやらないエンジニア】
頼む側と頼まれる側、設計側と製造側などの立場があるとはいえ、こういったやりとりはできるだけなくしたいですよね。
わたしは、作ることは自己表現の場であると勘違いをして、昔は言われたこと（仕様書に書かれていること）以外までやってしまって、よくやり過ぎだと怒られたことがあります。
わたしはこのことは全く後悔はしてないのですが、反省はしました。冷静に考えればそれは自分が使うものでもないし、自分のシステムではないからです。自社製品、自社サービスであれば許されるかもしれませんが、SIerであるならばお客様が欲するものを作るのが基本です。
かといって、仕様書が明らかに間違っている場合や、どう考えてもおかしい場合が多々あります。エンジニアがたくさんバグを出すように、仕様書や要件をまとめる人、ビジネスプランを練る人も同じ人間ですから、同じように仕様バグを出すことはあるでしょう。
間違っていることを認識しつつも、仕様書に書いてあるとおりに実装してしまうのは、誰も幸せになれません。いずれ直さなくてはいけないのですから。
【エンジニアが心がけてみて欲しいこと】
このようなエンジニアが生まれる原因の1つとして、SEとプログラマというわたしからしてみれば妙な役割分担がはびこっていることもあげられます。ものを作るにあたって役割分担などは関係なく、良いものは良い、悪いものは悪いと指摘する必要があると考えます。
今作っているシステムが最終的に誰がどのように使うのかを一度考えてみてください。考えた上で、お客さんや関係者に指摘や提案をしてみてください。
言葉は悪いですが、エンジニアは作らされる側に立つことが多く、良かれと思って指摘したことも、理不尽なお客さんから余計なことをするなとか言われる可能性があるかもしれません。しかし、いいものを作るためならこういった行動は必要だと思います。
【こんなエンジニアと接するには？】
わたしの感覚では、こういったエンジニアは間違いに気づいていることや、ヒアリングしてみるとちゃんとした意見を持ってることが多く、逆に気づいてない場合は「すぐ直します！」という、本当に何も考えてないような言葉が返ってきます。
前者の場合はある程度の仕様を決める権限を与えるとよいでしょう。また、エンジニアは日頃はおとなしく、しゃべる場が与えられると饒舌になるので、もの申してもいいんだという雰囲気作りが必要かと思います。
後者の場合は、何も考えてないぶん基本的に素直ですので、率直に仕様や要件にもバグが潜んでいるということを教えた上で、考えることを促すといいかもしれません。
つづく
]]>エンジニアのイメージを壊すべく作られたキャッチコピーっぽく、わたしが目指すエンジニア像の1つになっています（ググってみたら7万5000件ヒットしたので、結構な数のエンジニアが目指してるのではないでしょうか）。
このカテゴリでは、わたしが歩んできた生活の中での実体験や、出会ってきたエンジニアを観察した中で、エンジニアの誤解（エンジニアとのコミュニケーションの取り方）をわたしなりに説いていきたいと思います。
【傲慢、無愛想にみえてしまうエンジニア】
当たり前ですが、エンジニアは技術に詳しいです。
詳しいことに自信を持つことにはまったく問題ないと思いますが、それが悪い方向で表に出てしまう場合があります。
お客さんとのミーティング、営業との打ち合わせ、新人の指導時など、
「そんなことも知らないの？」
このセリフ口に出さないまでも心の中で呟いてしまうことありませんか？ 心の中で呟くまでなら、きっとギリギリセーフです。これが傲慢、無愛想にみえてしまうエンジニアだと
「勉強しなおしてこい」
「ググれ」
「そんなんじゃ作れない」
などのぶっきらぼうなセリフが出てきます（新人の指導時などはあえてそうしたほうがよい場合もありますが）。
【エンジニアが心がけてみて欲しいこと】
ここで僕が一番よくないと思うケースは、相手が技術を知らないということを受け入れていないケースです。言いかえると、自分と相手が違うことを受け入れてない場合です。
そういう思考回路に陥ってしまう前に、それぞれの立場を尊重し、自分に与えられた役割をもう一度見つめ直し、相手と接する必要があるのではないか？ と思います。
いったんそれを受け入れると相手との接し方が自然に変わっていきます。
俗に言う「Yes, and」の精神です。また、相手が技術を知らないと説明をするのが面倒ということもあります。しかし、説明する能力もまた非常に大事なスキルです。
技術を知ってる人と知らない人の数を比べたら、単純に技術を知らない人のほうが多いですし、必然的に非技術者に説明をする機会のほうが多いでしょう。ドキュメントを書く、仕様書を書くというのもまさに説明するスキルがなければ書けません。
ここは自分のスキルを磨くチャンスと思って、相手に分かりやすい説明をすることを心がけてみてください。
【こんなエンジニアと接するには？】
無愛想なセリフを吐かれると誰だってムッとします……が、ここではぐっとこらえてください。
こういうケースの場合、我慢してエンジニアへいろいろ聞いて（技術的なキーワードを並べられるとより効果があります）、誘導すると、べらべら～と気持ちよく解決策の提案や詳細な説明をしてくれる可能性があります。ぜひ試してみてください。
つづく
]]>本コラムでは、ITエンジニアの1人として、仕事やプライベートを通じて日々思うことを綴っていきます。
自分の成長の場の1つとしてご意見などいただければと思います。
【綴っていきたいこと】
-ライフハック-
3～4年前からライフハックという言葉が（特にIT系エンジニアの間で）使われ始めました。
わたしもちょうど社会人として5年目、6年目ぐらいの時期で、仕事のやり方について悩むことが多くなってきたときに出合った言葉です。
俗にいうライフハックは個人の生活や仕事の効率化ですが、わたしはもう少し大きい範囲でのライフハックを考えていきたいと思います。
例えば、技術の分からないお客さんに合わせた仕事の仕方、逆に技術の分かるお客さんに合わせた仕事の仕方。大人数での仕事の仕方、宇宙人みたいに何考えているか分からない上司との仕事の仕方など、失敗談も含め、自分なりに模索したものを紹介します。
-エンジニアの誤解-
エンジニアって気難しいとか、とっつきにくいとかよく耳にします。実際に寡黙な人や、独特な雰囲気を持っている方の割合は多いかもしれません。
でも仲良くなると面白い人ばかりです。きっとエンジニアだっていろんな人とコミュニケーションを取りたい！ と思っている人も多いはず……。
だいぶ勝手な思い込みかもしれませんが、＠IT自体はエンジニアをターゲットにしたメディアである、ということを踏まえて、エンジニア視点から、エンジニア側から歩み寄った方がいいかも、ということを紹介していきます。
-技術-
一応エンジニアなので、技術動向も個人的な解釈で紹介や感想を書いていきたいと思います。
今、興味があることはAndroid、iPhone、自然言語処理、Ruby on Rails、分散処理などです。
特にiPhoneはミーハーな気持ちで購入後、やはりiPhone用アプリを開発してみたいという好奇心で、この前発表された新MacBook（頑張ればWindowsでも開発ができるみたいですが）の購入を考えています。
-エンジニアとトラブルとプライベート-
エンジニアにとって、トラブルは特別な日によくおきます。特別な日に起きているから、記憶により残りやすいのかもしれません。
彼女との大事なデート中、旅行で楽しんでいるとき、カラオケで気持ちよく歌っているとき、会社やお客さんからの電話……楽しい瞬間からどん底に突き落とされます。
ネタ的な要素もありますが、わたしの経験談や友人の話など、笑い話として紹介していきたいと思います。
【おわりに】
コラムを書かせていただくにあたって、1～2週間に1コラムを目標にします。
よろしくおねがいします。
]]>