ここでは、編集部の独断と偏愛によって選んだコラムをテーマ別に紹介する。今回のテーマは「質のよいソースコード」について。

　「質のよいコード」とはどのようなものか、これは多くのプログラマが議論してきている話題だ。「質のよいコードは可読性が高い」と主張するコラムを筆頭に、「ソースコードの質」について語るコラムニストの意見を見ていこう。

プログラマよ、これからの「可読性」について議論しよう

　まずは、『気難しいプログラマ』の玄米茶氏による、「コードの質の向上」に関する意見を紹介しよう。

　技術の発達によって、これからはソフトウェアの寿命が延びていく。今後は、よりソースコードの「保守性」と「拡張性」が重要になってくると、玄米茶氏は語る。

　これまでは、プログラムは正しく動けばよかった。重視されるのはきちんと動くかどうかであり、それがどんなにひどいスパゲッティコードであろうと美しいコードであろうと、問題にはならない。「非常に洗練されたコードは、バグのないプログラムに負ける」と、玄米茶氏は指摘する。

　だが、複数のプログラマが1つのコードを修正する機会が増えると、ソースコードの質によって保守性に雲泥の差が出てくる。玄米茶氏は、「いまこそ、コードの質の向上について議論すべきだ」と主張する。

　われわれは実行モジュールを作っているのではない。ソースコードを作っているのだ。

　プログラマ自らが、コードの洗練性や進化を渇望せずして、一体誰がそれを望むのか？

　では、「洗練されたコード」とはどのようなものか。玄米茶氏は「可読性」を重視しているという。「プログラマがコードの可読性にもっと気を使うことで、ソフトウェアの長期保守性が格段に上がるだろう」――玄米茶氏はこのように提言している。

気難しいプログラマ: ソースコードの質

「可読性」は、人それぞれで違う属人的な指標

　一方、コードについて議論する際に「可読性」といった指標はあまり用いない方がいいのでは、という意見もある。『地方からの戯言』のAhf氏は、「可読性」という指標のあいまいさについて考察している。

　「可読性」や「保守性」は、人それぞれによって判断基準が異なる、属人的な指標である――Ahf氏はこう指摘する。例えば、ある人はコメントが少ない方が「読みやすい」と思い、別の人はコメントによる説明があった方が「読みやすい」と感じるだろう。どの意見も間違ってはいない。

　このように、読みやすさや保守性は、エンジニアの経験や考え方、使用言語によってさまざまに変わる。「可読性は属人的な指標であるということを理解したうえで、可読性以外の指標を用いて議論を続けるのが建設的では」と、Ahf氏は提言している。

地方からの戯言: ソースコードの可読性や保守性

物覚えが悪いから、分かりやすいコードを書く

　『アジアのソフトウエア開発現場にて』を執筆する山本保男氏は、シンガポールで開発を行っているエンジニアだ。山本氏は、「分かりやすいコード」を書く理由について、ユニークな視点から考察している。

　山本氏は、「分かりやすいコードを書くのは1週間後の自分のため」と語る。自称「恐ろしいほど物覚えが悪い」山本氏は、1週間前に自分が書いたコードの中身を覚えていられない。そのため、「なぜ自分はこのコードを書いたのだろう……」と未来の自分が悩まなくても済むように、日々分かりやすいコードを書くように心がけているという。

　また、山本氏は「バグがないコードと可読性のあるコードは違う」と主張する。きれいなコードは、リファクタリングを繰り返すことによって生まれる。シンガポールの現場では、プログラマの書くコードにある程度バグがあってもそれほど問題にはされないという。その代わり、リファクタリングやテストを繰り返してバグをつぶしていく。

　「きれいなコードについてチームの方針が徹底していれば、コードは誰が読んでもある程度は分かるし、対処もできる」と山本氏は語る。

アジアのソフトウエア開発現場にて: 分かりやすいコード

　ここでは、編集部の独断と偏愛によって選んだコラムをテーマ別に紹介していく。今回のテーマは「リーダーの視点」。

　リーダーにとって必要なものとは何か。リーダーが持つべき視点とはどのようなものか。エンジニアを束ねるリーダーに求められるものについてのコラムをピックアップした。

かつて「気難しいプログラマ」だったリーダーたちへ

　『気難しいプログラマ』を執筆する玄米茶氏は、自身が「気難しいプログラマ」でありながら、同時に「気難しいプログラマを束ねるリーダー」でもある。両方の視点を持つ筆者なりに、リーダーはプログラマとどう接するべきかを述べている。例えば、

• 不具合があったときだけプログラマに話し掛けるようなリーダーにはならない
• 軽々しく「バグ」という言葉を使わない
• 話し掛けるタイミングに注意する。コーディングに集中しているときは話し掛けない
• コミュニケーション＝飲み会、と考えない
• ミスを頭ごなしにしからず、自らフォローを買って出る
• 依頼に反論されたら、「そうせざるを得ない理由」を正直に話す
• 仕様変更に抵抗されたら、プログラマの感じている「嫌な予感」に耳を傾ける

などである。

　「プログラマは時として、リーダーが思いも寄らなかったことを口にする。でも、そういったことを含めてプログラマと接することを面白がらなければ、真のリーダーとはいえない」――筆者はそうまとめている。かつてプログラマだった経験を持つリーダーであるならば、きっとこの言葉が理解できるはずだ。

気難しいプログラマ:
9. 自分の価値観が揺るがされる

●連載「気難しいプログラマとの人間関係に必要ないくつかのポイント」インデックス

1. はじめに
2. 不具合の話しかしない、嫌な奴
3. バグと不具合の違い
4. あなたの問いかけに反応が悪いとき
5. わりと嫌われる飲み会への誘い
6. 説教してはいけません
7. あなたの依頼に反論するとき
8. 奇妙な態度で仕様変更に抵抗するとき
9. 自分の価値観が揺るがされる

リーダーに求められること、いくつできていますか？

　エムズ・ネット・スクエアの講師陣が執筆する『新任リーダー明日香のマネージャへの道』では、中堅IT企業にて若手リーダーとなった主人公、明日香の奮闘を通じて、リーダーに求められる姿勢や視点を解説している。

　毎回、テーマに沿ってストーリーが進み、最後にチェック項目がまとめられている。いくつか例を挙げよう。

• メンバーが仕事の状況を定期的にメールや文書で報告する仕組みがありますか？
• 面談時はメンバーに話をさせるように意識していますか？
• リーダーから積極的にコミュニケーションをとっていますか？
• 担当者が不在時にバックアップ体制がとれるようになっていますか？
• スキルの育成を計画的に行っていますか？
• リーダーとして部署のビジョン（理想像）を策定していますか？
• メンバーにビジョンを伝える機会をつくる努力をしていますか？
• メンバーの状況に関心をもっていますか？
• モチベーションが下がっているときに、どうしたらモチベーションが上がるかを考えていますか？

　どれも言葉にしてみると当たり前のように思えるが、実践できるかは別問題である。日々の行動を振り返り、リーダーとして実践できているかどうかを確認してみよう。

新任リーダー明日香のマネージャへの道:
第4話：リーダーの想いをメンバーに伝えよう！

●『新任リーダー明日香のマネージャへの道』インデックス

1. プロローグ：昼食後のひととき～ランチルームにて
2. 明日香リーダーになる
3. リーダーはメンバーの状況を理解しよう
4. コミュニケーションの活発なチームにしよう！（上）
5. コミュニケーションの活発なチームにしよう！（下）
6. 個人商店の集まりをチームにしよう！
7. リーダーの想いをメンバーに伝えよう！
8. “運用部門の若手メンバーの疲弊”の巻～モチベーションを上げるには（上）
9. “運用部門の若手メンバーの疲弊”の巻～モチベーションを上げるには（下）

リーダーの条件

　北海道で働くエンジニアのAhf氏は、リーダーという立場について「メンバーが自主的に活動する環境づくり」「メンバーそれぞれに合った作業内容の割り振り」「メンバーに合わせた努力目標の設定」など、難しい仕事が多く、大変なポジションであると語る。だが、同時に「自分が整えた環境でメンバーが精力的に活動できたら、それは非常にうれしいことではないか」とも付け加える。

　コラムでAhf氏は特に「メンバー内で技術レベルにばらつきが存在した場合、どこに基準をおくか」という難しい問題について考察している。この問題に限らず、リーダーには、1人のメンバーとして働いていたときとは異なる視点が求められる。「視点を変えてみることで新たな楽しみを感じることができると思う」とAhf氏はまとめている。

地方からの戯言:
チームを率いて

　テストエンジニアの第3バイオリン氏は、ソフトウェアテスト・ワークショップ「WACATE」に参加した際、グループワークでチームリーダー役を引き受けた。「リーダーの条件」について考える第3バイオリン氏に対し、グループの1人は次のように発言する。

　「リーダーは最終的な責任を取るのが仕事です。それさえできれば、メンバーにはあれこれいわなくても指示ひとつ出して『あとは任せた！』でOK、ということです」

　メンバーに任せられることは任せて、メンバーだけではどうにもならないことがあったときには素早くフォローする。それが理想のリーダー像ではないか、というのが第3バイオリン氏の考えだ。

　もちろん、メンバーに任せるためには、メンバー全員がチームの目的を共有している必要がある。それを示すのもまた、リーダーの役目だ。

オブリガート ～感謝されるテストエンジニアになる～:
「WACATE 2010 夏」参加レポート（その4）――リーダーの条件

こんなリーダーはイヤだ！

　最後に「反面教師」の例も挙げておこう。ギャルプログラマの森姫氏は、「ある日リーダーが会社に来なくなった」という恐ろしい体験を告白している。

　多くの仕事を抱えたまま失踪したリーダー。残されたメンバーでは分からなかったり、権限がなかったりする業務が山積していたため、プロジェクトはストップし、顧客は激怒した。

　「1人で何もかも抱えこむんじゃない！」と森姫氏は語る。リーダーが仕事を抱え、しかもそれが属人化してしまうという事態は避けるべきであろう。

恋愛感情で仕事はできるか？:
リーダーが来なくなった日

　『30過ぎで5社目でした。』を執筆するエンジニアのけいいちっく氏は、上に立つものとして「それはいかがなものか」と思った発言を紹介している。

　プロジェクトマネージャとしてアサインされた上司が、顧客と納期について話している際、「任せてください、ベンダをギュウギュウ絞りますから」と発言。けいいちっく氏は「この人は下請けや部下をこのようにしか見てないのか……」と残念に思ったという。

　リーダーは、下にいる者の気持ちを考えて発言してほしい。せめて邪魔をしないでほしいし、余計なことをいってやる気を削がないでほしい――そうけいいちっく氏はまとめている。

　あなたはこうした「反面教師」なリーダーになっていないだろうか。自分がメンバーだったころのことを思い出して、「イヤなリーダー」にならないよう気を付けよう。

30過ぎで5社目でした。:
頼むから黙ってて―上に立つ者（＝リーダー）の品格―

　ここでは、編集部の独断と偏愛によって選んだコラムをテーマ別に紹介していく。今回のテーマは「リーダーとプログラマの人間関係」。

　不機嫌なプログラマ、話し掛けると反応が悪いプログラマがいる。しかし、彼らには彼らなりの理由があるのだ。「プログラマはコミュニケーション能力が不足している」と一蹴せず、彼らとの関係をよりよくするための考え方を紹介しよう。

なぜプログラマは話し掛けると反応が悪いのか

　リーダー「ねえ、ちょっといい？」

　プログラマ「……え、……何ですか？」

　こんな光景を見たことがある人は少なくないかもしれない。なぜ、話し掛けるとプログラマの反応が悪いのか。『気難しいプログラマ』を執筆する玄米茶氏は「集中しているときに話し掛けられれば、不機嫌になるのは当然」と、理由を説明している。

　プログラミングは、非常に集中力を使う作業だ。頭の中でロジックを組んでいるときに話し掛けられると、集中力がぶっつりと途切れてしまう。下手すれば、「脳内コーディング」を最初からやり直し……なんてことにもなりかねない。玄米茶氏はプログラマの集中力が途切れることは、「エクセルで作った資料を保存せずに終了してしまった」ことと同じぐらいストレスが溜まると説明している。

　しかし、チームで開発している以上、話し掛けないわけにはいかない。リーダーはいつ話し掛ければいいのだろうか。玄米茶氏は「タイミングを見ること」が重要だと説いている。プログラマが休憩を入れるタイミングを見計らって話し掛けるとよいだろう。例えば、煙草休憩のとき、席を立つときや席に戻るときなどだ。

気難しいプログラマ: 4. あなたの問いかけに反応が悪いとき

　玄米茶氏は「プログラマの不機嫌を『コミュニケーション能力不足』という一言で片付けないでほしい」と訴える。ほか、玄米茶氏は「不具合の話ばかりしない」「説教は禁物」など、プログラマとの人間関係を改善するためのTipsを紹介している。プログラマとの人間関係に悩むリーダーはぜひ参考にしてほしい。

1. はじめに
2. 不具合の話しかしない、嫌な奴
3. バグと不具合の違い
4. あなたの問いかけに反応が悪いとき
5. わりと嫌われる飲み会への誘い
6. 説教してはいけません

プログラマ側の意見「集中が切れると生産性が下がる」

　玄米茶氏の主張について「まさにその通り！」と語るのは、『プログラマで、生きている』のひでみ氏だ。ひでみ氏は、キャリア20年超のベテランプログラマである。プログラマ目線で「なぜ話し掛けられると反応が悪くなるのか」について説明している。

　ひでみ氏は、「脳内でコーディングをしている最中に話し掛けられると軽いパニック状態になり、動きが止まってしまう」という。結果として不機嫌な対応になってしまうことがしばしばある。

　そんなとき、リーダーの反応には大きく分けて2種類あったという。1つは「人に話し掛けられたら話に集中しろ！ それでも社会人か！」というタイプ。もう1つは「プログラマとしてちゃんと働いてくれるなら、多少の不都合には目をつぶる」というタイプ。

　ひでみ氏としては後者、自分が集中してコーディングしているときには待っていてくれるリーダーの方が一緒に仕事をしやすかったようだ。リーダーが話し掛けてくる場合は「いつも待っていてくれるリーダーが話し掛けるなんて、よほどのことなんだろう」と思い、最優先で話を聞くようになったという。

　「社会人としてきちんと対応すること」と「プログラマとして生産性を向上させること」を両立させることはなかなか難しいと、ひでみ氏は語る。集中すれば生産性は上がるが、話を聞きにくくなる。いつでも話を聞くようにすると、生産性が落ちる。どちらも必要なことなので、うまくバランスを取ることが重要なのだが、それがなかなか難しい。

プログラマで、生きている: 反応の悪いプログラマのいいわけ

親密なコミュニケーションが生産性を上げる

　一方、「コミュニケーションがプログラマの生産性を上げる」という意見もある。『下流から見たIT業界』の後藤和彦氏は、「プログラミングはコミュニケーションだ」と主張する。

　後藤氏は、「プログラマが同僚と話をしたりミーティングで話し合う」のが理想的なプログラミングであると語る。話をしている間に、プログラマは情報交換を行い、意見をすり合わせる。結果的に、チーム内の生産性が上がるという。

　リーダーの役割は「気軽で親密なコミュニケーションができる環境」を整えることだ。皆が黙々と作業して話し掛けづらいと、チーム全体の生産性は向上しない。

下流から見たIT業界: プログラミングはコミュニケーションだ

　後藤氏の意見は、玄米茶氏やひでみ氏の意見と必ずしもぶつからない。玄米茶氏も「不具合のときだけプログラマに話し掛けるのはやめよう」と提言している。大事なのは、リーダーとプログラマ、お互いへの気遣いではないだろうか。リーダーもプログラマも、自分とチーム両方のパフォーマンスを向上させるためにお互い意見をすり合わせることが大事なのかもしれない。

　ここでは、編集部の独断と偏愛によって選んだコラムをテーマ別に紹介していく。今回のテーマは「仕事や勉強を『楽しむ』」。

　仕事も勉強も、せっかくなら楽しみたいもの。エンジニアライフのコラムの中から、「楽しむこと」にまつわるコラムをピックアップした。

エンジニアの4つの楽しみ

　＠IT自分戦略研究所で『仕事を楽しめ！ エンジニアの不死身力』という新連載を始めたITコーチの竹内義晴氏は、自身がエンジニアだったころの仕事の楽しみを4つ挙げている。

1. 個人の力量が評価される喜び
2. 技術力を身につけていくことの楽しみ
3. 顧客と直接、接することの楽しみ
4. チームで作ることの楽しみ

エンジニアライフ クロストーク: IT業界に入って楽しかったこと

　連載では、「好きな仕事を楽しむ」ためのヒントを書いていくという竹内氏。ぜひ期待してほしい。

エンジニアライフ クロストーク: 連載が始まりました！ 「仕事を楽しめ！ エンジニアの不死身力」

つまらないプロジェクトはハックして楽しめ！

　『プロトタイプ開発の日々』のかるたや氏は、「仕事を楽しむための3つの心得」を紹介している。かるたや氏はマクシム・ゴーリキーの「仕事が楽しみなら人生は極楽だ。仕事が義務なら人生は地獄だ」という言葉を引用し、「同じ仕事をするなら、楽しまなければ損」だと説く。

　かるたや氏の提唱する「3つの心得」は下記の通り。

1. 未経験の作業に取り組むべし
2. 自分の作業を効率化すべし
3. 他人のプログラムを丸裸にすべし

　「つまらないプロジェクトは、義務感で取り組むより、『プロジェクト自体をハックしてやる』という気持ちで臨んだ方が楽しい」とかるたや氏は語る。残念なことに「つまらないプロジェクト」にアサインされてしまったというエンジニアの方は、「3つの心得」を実践してみてはいかがだろうか。

プロトタイプ開発の日々: 仕事を楽しむための3つの心得

仕事を楽しむため、若いうちに実力をつけるべし

　『明日への希望、エンジニアのひとりごと』の大久保仁氏は、新入社員研修の講師を務めた際、大切だと思ったことを「5カ条」にまとめている。この中に「仕事を楽しむこと」にまつわる項目が含まれている。

　新人のうちに、仕事の中で実力をつけていくことが、後々のエンジニア人生に大きく影響する。人生の中でとても長い「社会人としての時間」を楽しく過ごせるかは、若いころの地道な努力の積み重ねがあってこそだ、と大久保氏は主張する。

　新人教育に携わる機会があれば、スキルだけでなく、「努力することで仕事を楽しめるようになる」ということを教えてあげると良いだろう。

明日への希望、エンジニアのひとりごと: 新入社員がやってきた2009 ～講師としての5カ条～

学ぶことは、楽しいことだ

　仕事だけではなく、勉強も楽しみたい。学生時代の勉強を思い返すと「つらかった」という人が多いかもしれないが、勉強とは本質的に楽しいものである。

　英語を勉強している『It’s Party Time!』のあずK氏は、「楽しもうとする力」を身に付けたい、と語る。あずK氏は直近で仕事に英語が必要となっているわけではない。それにもかかわらず、英語の勉強が継続しているのは、単純に「楽しいから」だという。

　仕事も勉強も、「楽しい」ならモチベーションが上がり、続けられる。英語学習以外にも「楽しもうとする力」を発揮したい、というのが現在のあずK氏の考えだ。

It’s Party Time!: TOEIC 600点への道 2009番外編：「僕が英語を学ぶ理由」

　『オブリガート ～感謝されるテストエンジニアになる～』の第3バイオリン氏は、「知るを楽しむ」という姿勢を大切にしている。たとえそれが仕事には関係のない雑学であったとしても、「好奇心を持って調べ、新しいことを知る」というプロセスが楽しければ、それでいいではないか。それに、もしかすると、いつか仕事に役立つかもしれない。

　ITの世界は、どんどん新しい技術が生まれていく。好奇心を持って、「知るを楽しむ」姿勢は、エンジニアにとって不可欠な才能ではないだろうか。

オブリガート ～感謝されるテストエンジニアになる～: 好奇心は仕事の合間に食べるお菓子みたいなもの

　仕事を楽しみ、勉強を楽しむ。「そんなにうまくはいかない」と思わず、「楽しんでみよう」という姿勢を忘れないでほしい。あなたは、いまの仕事や勉強を、楽しんでいますか？

　ここでは、編集部の独断と偏愛によって選んだコラムをテーマ別に紹介していく。今回のテーマは「転職活動」。

　はてなブックマークの開発者として知られる伊藤直也さんがグリーに転職したり、MySQLのコンサルタントとして有名な松信嘉範さんがディー・エヌ・エーに転職したりと、ここ数日、IT業界では転職に関するニュースが相次いだ。ITエンジニアにとって、転職は他人事ではない。エンジニアライフのコラムの中から、転職活動にまつわるコラムをピックアップした。

チャンスの神様には前髪しかない

　プログラマのkwappa氏は、「チャンスの神様には前髪しかない」と語る。不況下でその「前髪」をつかむために、kwappa氏は下記の3点に注意したという。

1. 転職する理由を明確にすること
2. 書類／面接で落ちても落ち込まないこと
3. 内定をもらってから退職交渉すること

Wife Hacks ～仕事と家族とコミュニティと～: 転職に必要な神様

　また、家庭を持っているITエンジニアの場合、パートナーの理解を得ることも重要だ。「Wife Hacks」をコラムのテーマに掲げるkwappa氏は、「もう1人の神様＝wife」に納得してもらえるよう、説明する必要があると主張する。

　さらにkwappa氏は別のコラムで、職務経歴書の書き方についても言及している。

　まだまだ転職者にとっては厳しい状況の昨今、企業の人事部には大量の職務経歴書が届く。そのため、「採用担当者の興味を引きつける職務経歴書」を書く必要がある。「志望動機と自己PRあわせて3行」ではマズイのである。

　kwappa氏は特に重要なポイントとして下記の3点を挙げている。ぜひ参考にしてほしい。

1. 写真を貼付する（イケメンでなくとも可）
2. 自己PRを書く（「困難をどうやって乗り越えた」など具体的な事例があるとよい）
3. 課外活動を書く（コミュニティ活動、ブログやTwitter、GitHubのアカウントなど）

Wife Hacks ～仕事と家族とコミュニティと～:
書類審査で落とされない「職務経歴書の書き方」

転職と恋愛、転職と結婚

　転職を2回経験しているというエンジニアの佐藤正明氏は、転職活動を恋愛に例えつつ、よい交際をするためのコツをまとめている。

1. 転職エージェントとのつきあい方（恋のキューピットとの付き合い方）
2. 選考で落とされた！（振られた！）
3. 転職する理由（付き合いたい理由）
4. 面接（デート）
5. 退職の意志表明（お別れ）
6. 新しい職場で（付き合いの始まり）

　特に興味深いのが面接（デート）における心構えだ。佐藤氏は「お付き合いする前のデートは自分をアピールすることも大事ですが、相手を知るということも大変重要」と語る。転職における面接は、相互理解の場であることを忘れてはならない。

Are You Sure?:
恋愛と転職活動～運命の会社に出会うために～

　キャリアコンサルタントの山内宗和氏は、「安定志向」が企業から嫌がられる理由について、転職を結婚に例えて解説している。

　近年は大手企業であっても、安定志向の求職者は嫌われる傾向にあるという。なぜなら、「安定を求める＝いろいろ与えてくれる環境だと思っている」ということだからだ。結婚の場合と同じだ。「あなたの家や給料をあてにしている」といわれるより、「結婚後も一緒に頑張って生活の基盤を作っていこう」といわれた方がうれしいのではないだろうか。

身近な事象に置き換えて転職（キャリア構築）を考えるコラム:
なぜ「安定志向」は企業から嫌がられるのか？

実録・転職活動記

　最後に、あるコラムニストの体験を元にした「転職活動記」を紹介しよう。逆転仕事術氏は全4回にわたって「逆転転職」という連載を公開している。

　この連載では、転職活動を始める前に「会社を辞めます」と宣言してしまった主人公、安原テンマが、転職エージェントとの面談の中で「自分の転職理由」を明確化し、面接に挑む姿を描写している。もちろん、転職活動の内容は人それぞれだが、雰囲気をつかむための参考はなるはずだ。

ワーク×ライフ・エンジニアリング:
『逆転転職』第1話：はじめての転職

　バックナンバーは下記の通り。

• 第1話：はじめての転職
• 第2話：逆転エージェント
• 第3話：逆転最終面接
• 第4話：逆転第2の人生

　IT業界の転職市場は、徐々にではあるが回復してきている。自身のキャリアビジョンを描いたとき、転職が必要だと感じたならば、これらのコラムを参考に、悔いのない転職活動に取り組んでほしい。

■関連リンク

IT業界 転職市場最前線 インデックス − ＠IT自分戦略研究所

エンジニアのための転職マニュアル インデックス − ＠IT自分戦略研究所

　ここでは、編集部の独断と偏愛によって選んだコラムをテーマ別に紹介していく。今回のテーマは「メンタルヘルスケア」。

　ITエンジニアは、何かとストレスが多い仕事だ。だからこそ、「心の調子」には気を配りたい。「心の病」の予防法や対処法、普段から使えるメンタルヘルスのTipsを紹介する。

「逃げるしかない」――仕事を愛していたのに仕事を辞めたエンジニア

　まずは、心が病んだエンジニアの物語を紹介しよう。元エンジニアX氏の『デスマーチで嫁（い）き遅れました』は、元エンジニアX氏＝老婆がかつてエンジニアだったころの思い出を語る物語である。

　「……長い長い間、エンジニアをやってたんだ」と、元エンジニアX氏は語り出す。エンジニアだったころは、仕事が大好きだったという。何度もデスマーチを経験したにもかかわらず、お客さんに喜んでもらえるのがうれしくて、仕事に全力を注いだ。だが、つかの幸せは、部下の提案を反逆とみなす上司の登場によって終わりを迎える。

　「考えるな！ 本なんか読むな！」「生意気なことをするな」――上司は怒鳴る。自分の思い通りに動かない人間に対して、男はむき出しの敵意を向けた。さらに、仕事が佳境に入っているときに「残業は21時まで。休日出勤は禁止」という命令を出した。ありえないスケジュールのために仕事の効率は落ち、上司は日々暴力的な言葉を投げつけてくる。元エンジニアX氏は心を病み、ついには「逃げるしかない」というところまで追い詰められる。

デスマーチで嫁（い）き遅れました: うらみ・ます

　物語は全10回。ぜひ、初回「忘れない日々」から読んでみてほしい。

心の調子を崩した元プログラマ

　もう1つ、心の調子を崩した元プログラマの物語を紹介しよう。テストエンジニアの第3バイオリン氏は、かつてプログラマだった。そのころの話を、『冬の終わり』という小説にまとめている。

　第3バイオリン氏は、学生時代の専攻を生かしてプログラマになった。新人のころは必死になってコーディングを覚えた。だが、3年目にもなると、「プログラマは自分にあまり向いていない」ということに気が付いてしまう。自分がどうなりたいのかが分からない、やりたいことが見つからない――第3バイオリン氏は次第にふさぎ込むようになる。

　このままではいけないと思い、第3バイオリン氏は病院に行き、薬をもらった。「現代型うつ」について、第3バイオリン氏は下記の症状を挙げている。

1. 20代～30代の若年層に多い
2. 自分ではなく他人を責める
3. 自分の趣味、好きなことはできるが、嫌いなことや苦手なことはやる気にならない
4. 自覚症状がある。自分から病院に行きたがる
5. ストレス耐性が低い。自傷行為に走ることもある

オブリガート ～感謝されるテストエンジニアになる～:
小説 冬の終わり 「目を覚ませと呼ぶ声が聞こえ」

　やがて第3バイオリン氏は、音楽とテストエンジニアという新しい仕事を得て、「冬の終わり＝再生」に向かっていく。連載は全5回。バックナンバーは下記のとおり。

• 第1話：おしゃべりはやめて、お静かに
• 第2話：わたしの心は血の海に漂う
• 第3話：わたしのため息、わたしの涙
• 第4話：目を覚ませと呼ぶ声が聞こえ
• 最終話：退け、もの悲しき影よ

心の病を予防するために必要なのは「メリハリ」と「余暇」

　2つの物語から分かるように、エンジニアはさまざまな理由で心の調子を崩すことがある。まずは「予防法」から考えよう。

　『エンジニアの年輪』の山﨑靖之氏は、「心の病」を予防する手段として「メリハリをつけた働き方をする」ことと「余暇を上手に使う」ことを推奨している。

　特に忙しくなると、疲れがたまって心の調子を崩しがちになる。山崎氏は「平日に徹夜したら休日はしっかり休む」など、「やるときはやり、やらないときはやらない」とはっきりさせることによって、慢性的な疲労を緩和できるのではと、提案している。

　また、余暇を上手に使うことが重要だ。余暇では「疲れた身体を休める」「心をリフレッシュさせる」「楽しむ」ことを心掛けるとよい。

　「能力を十分に発揮するためには、心身ともに健全な状態を作ることが重要だ。そのためには定期的な休養を取り、余暇を上手に使って自分をリセットすることが必要」と、山崎氏は語る。

エンジニアの年輪: 余暇を上手に作ることの重要性

うつ病1歩手前で、逆転サバイバル！

　いくら自分が予防していても、それだけでは十分ではない。なぜならストレスや心労は、仕事環境やチームメンバーなどの「外的要因」によるところも大きいからである。

　『紅一点！ 生産管理ガテン系SE☆』のSARA氏は、上司の暴言に耐えかねて、心療内科に通っていた。だが、上司は態度を改善する気配がまるでない。「これではうつ病になってしまう」と危機感を感じたSARA氏は、上司の「権力に弱い」性格をうまく利用した。保健所に相談し、部長と課長を味方にして見事、異動を果たしたのである。

　「1日は40時間ではないし、設計ミスはプログラマのせいではない。悩んでいる人に『あなたは悪くない』と伝えたい」と、SARA氏は主張する。SARA氏のサバイバル意識と行動力に、見習うところは多い。

紅一点！ 生産管理ガテン系SE☆:
第7回　うつの手前で逆転！ 縦社会サバイバル

　バックナンバーはこちら。

• とにかく「うつ」だけは避けたい
• 状況改善 but 解決はしていない
• うつの手前で逆転！ 縦社会サバイバル

メンタルヘルスケアのTipsまとめ

　最後に、「メンタルヘルスの理論と実践」を日々行っているエンジニアのアドバイスを聞こう。

　『It’s Party Time!』のあずK氏は、「自分はメンタルが弱い人間だ」と語る。かつては、愚痴をいう、かんしゃくを起こす、八つ当たりする、自分をとにかく責めてしまうなど、うまく感情をコントロールできなかったという。あずK氏は自分の弱さを認めたうえで、その弱さと上手に付き合う方法＝セルフケア方法を学んできた。

　ここに、あずK氏が学んできたメンタルヘルス方法をまとめて紹介しよう。

●マインドフルネス瞑想でメンタルヘルスケア

　不安感がいつもある人向け。「失敗したらどうしよう……」といった不安を軽減するためには、マインドフルネスという考え方が有効だ。不安に対して、余計な思考を挟まない方法だ。マインドフルネスには、7つの基本姿勢がある。

1. 判断しない
2. 忍耐強くなる
3. 初心を忘れない
4. 自分を信じる
5. 努力しない
6. 受け入れる
7. とらわれない

●笑ってメンタルヘルスケア

　イライラしがちな人向け。嫌なことがあったときに、つい「むっ」とした顔をしてしまうことがある。だが、嫌なことがあったときにあえて「笑う」と、自分のイライラが軽減できる。あずK氏は、いつでも笑っている先輩から、このことを学んだという。

●アサーティブな生活でメンタルヘルスケア

　コミュニケーション不全で悩んでいる人向け。コミュニケーションの形には、3パターンある。「アグレッシブ（攻撃的）」「ノンアサーティブ（非自己主張的）」「アサーティブ（自己主張的）」だ。この中で、「相手を立てつつも、自分の意見を伝えるアサーティブ・コミュニケーション」を取ると、コミュニケーションがうまくいくという。

●ABC理論でメンタルヘルスケア

　感情を上手にコントロールしたい向け。「ABC理論」とは、「A：Activating event（起こっている出来事）」「B：Belief（信念）」「C：Consequence（結果）」の頭文字を取ったものである。イライラの原因となる、「～せねばならない」「～するべきだ」という信念や考え方を変えようとする方法である。

●ストロークの法則でメンタルヘルスケア

　人とよりよいコミュニケーションを取りたい人向け。ストロークとは、「他者に対する自分の表現」のことだ。「ストロークの法則」とは、「人はみんなOKである」という精神のもと、人に対して「プラスの表現」を行うようにしていく考え方である。

It’s Party Time!: メンタルの弱さを自覚する人の心得

　ここでは、編集部の独断と偏愛によって選んだコラムをテーマ別に紹介していく。今回のテーマは「文章力」。

　ITエンジニアに求められるスキルとして必ず上がってくる「文章を書くスキル」。エンジニアになぜ文章力が求められるのか、どう文章力を磨けばいいか、どんな場面で生かせるかを紹介しよう。

「何をいいたいの、この人は……」と思われないエンジニアになる

　まずは、文章を書くスキルが必要な理由から。『ワーク×ライフ・エンジニアリング』の逆転仕事術氏は、「プラスアルファで獲得したい16のスキル」の1つとして、「文章力」を挙げている。

　なぜ、エンジニアに文章力が必要なのか。その理由はシンプルだ。「エンジニアは、文章を書くことが多い仕事だから」。見積もり依頼や作業依頼のメールはもちろんのこと、議事録、報告書、提案書に納品書など、エンジニアが文章化しなければならないものは多い。

　ほかの人が書いた文章を読むときは「この人は何をいいたいのか……」と戸惑うか、「この人の文章はなんて分かりやすいんだ！」と感動するかのどちらかであることが多い。どうせなら「分かりやすい文章を書く人」と思われたいところだ。

ワーク×ライフ・エンジニアリング:
プラスアルファで獲得したい16のスキル（9）～（12）

　ちなみに、逆転仕事術氏が紹介している「プラスアルファで獲得したい16のスキル」は、下記のとおり。

• 「業務知識力」「翻訳力」「余裕力」「地頭力」
• 「残業力」「信頼力」「会計力」「提案力」
• 「収集力」「分析力」「執着力」「文章力」
• 「育成力」「ヨイショ力」「独立力」「気遣力」

「インプット→吸収→アウトプット」のサイクルを回す

　では、具体的にどうやって文章力を身に付ければいいのだろうか。文章力を身に付けるには、「書き続ける」ことが必要だ。テイクウェーブの竹内義晴氏は、「勉強して情報をインプットした分、文章でアウトプットする」勉強法を推奨している。

　勉強には、以下の3つのプロセスがある。

• 情報を集める「インプット」
• 文章を起こす上での言語化や思考の整理「吸収」
• ブログやメルマガなどに書く「アウトプット」

　勉強というと、ついインプットが多くなりがちだ。しかし、竹内氏によれば、勉強したものをきちんと文章化してアウトプットすることが新しいインプットにつながるのだという。「インプット→吸収→アウトプット」というサイクルを回すことによって、効率的な勉強ができる、と竹内氏は主張する。

　「勉強になるアウトプット方法」として、竹内氏は以下のポイントを紹介している。

1. 誰かに役立つ文章であること
2. 文句や不満・批判ではないこと
3. 格好つけないこと
4. コピペしないこと

エンジニアライフ クロストーク:
わたしの勉強法（3）アウトプットが次のインプットを生む

何を書けばいいか分からないなら、まずはとりあえず書く、書く、書く

　次は、一風変わった文章力アップ方法を紹介しよう。『フリーなスキル』のはがねのつるぎ氏が紹介するのは「自動筆記」と「文章模写」という方法だ。

　「文章を書く力は筋肉に似ている」と、はがね氏は主張する。ある程度まで鍛錬したとしても、使っていないとすぐに力が落ちる。力を維持するためには、ある程度のメンテナンスが必要だ。

　そこで、はがね氏は「自動筆記」を試した。きちんとした文章を書こうと考えず、とにかく文章を書くのである。

　つれづれなるまま。気の向くまま。おもむくまま。文章を書いている。書けない。文章を書けないというテーマで文章を書いている。なんという矛盾。書いて いるじゃないか。そういえば、自動書記をやるのもひさしぶりだ。ながらくやっていない。こうゆう基本をおろそかに、しているから、文章が書けないなんて事 態が発生するのだ。まったく、ふだんからちゃんとやっておかないといけないね。まだまだレベル低いのに、文豪気取りで気分の乗っているときにしか書かない なんて100年はやいわ。

　もう1つ、はがね氏が挑戦したのが「文章模写」。プロが書いた文章を書き出すことによって、文章の「流れ」を体得できるという。

　竹内氏とはがね氏が紹介しているのはどちらも「文章を書く」方法だが、その目的は異なっている。「インプットしたものをアウトプット」することは「頭を使う」。一方、「自動筆記」は頭を使うことではなく「書く行為そのもの」に注目している。どちらも、文章力を上げるためには有効な手法だ。自分に合った方法を試してみるとよいだろう。

フリーなスキル: ぶん。ぶん。ぶん。

文章力を上げる4つのノウハウ

　文章を書き続けることが文章力アップの基本だが、やはりプロの「ノウハウ」は知っておきたい。研修講師を勤めるひろぶみ氏は、文章力を上げるためのポイントを4つ紹介している。

• ペルソナ法：読み手（ペルソナ）の人柄や要求を具体的に想像したうえで、ペルソナを説得できるような文章を書く方法
• パラグラフ法：文章を段落（パラグラフ）に分け、文章全体の論理を構築する方法
• スペクトル法：未知のものから来る情報（スペクトル）を、自分の経験や仮説と照らし合わせて検証し、文章に落とし込む方法
• レビュー法：自分が書いた文章を、第三者になったつもりでレビューする方法

　文章術の教科書として、ひろぶみ氏は木下是雄氏の『理科系の作文技術』を紹介している。こちらも併せて参照してほしい。

エンジニア能力開発あれこれ:
ビジネス文書の基本（酒場の会話）

エンジニア能力開発あれこれ:
続・ビジネス文書の基本（河岸を変えた酒場の会話）

情報処理技術者試験にも、文章力は必要！

　最後に、文章力の活用方法を紹介しよう。『システムオーディタ川辺の資格取得とキャリアアップ』のシステムオーディタ川辺氏は、資格試験のときに文章力が役立つと語る。

　例えば、情報処理技術者試験。論文試験に合格するためには、必要な知識を記憶することと同時に「効率よく書く」ことが必要だ。

　川辺氏は、「合計2900字を2時間（7200秒）で記述する。よって、7200秒÷2900字＝2.5秒/1字で記述することが必要」など、論文の必勝方法を紹介している。日々文章を書くことに慣れていれば、論文試験はずっと合格しやすくなるかもしれない。

システムオーディタ川辺の資格取得とキャリアアップ:
新情報処理試験に勝つ（2）

■関連リンク

誰にでも伝わるSEのための文章術 インデックス − ＠IT自分戦略研究所

ITエンジニアにも必要な国語力 インデックス − ＠IT自分戦略研究所

　ここでは、編集部の独断と偏愛によって選んだコラムをテーマ別に紹介していく。今回のテーマは「学生」だ。

　誰もがかつては学生だった。エンジニアの中には、学生のころITに興味を持ち、エンジニアを志した人は少なくないだろう。また、「学生時代に戻りたい」と考えている人もいることと思う。エンジニアライフでコラムニストとして活躍している現役学生の本音、社会人を経て学生に戻ったエンジニアたちの本音をまとめてみた。

高校最初の仕事は、パソコンクラブの立ち上げだった

　まずは、現役学生のコラムニストを紹介しよう。『システムエンジニアを目指して』のサトにゃん氏は、コラムタイトルが示すとおり、システムエンジニアを目指して現在さまざまな活動を行っている、意欲的な現役高校生だ。

　彼の活動範囲は非常に幅広い。まず、高校でのパソコンクラブの立ち上げだ。中学生のころから「高校に入ったらパソコンクラブに入部するんだ」と夢見ていたサトにゃん氏。だが悲しいかな、入学した高校には、パソコンクラブがなかったという。

　だが、サトにゃん氏はめげなかった。「クラブがないなら、自分で作ればいいじゃないか！」と思い立ったのである。高校入学して早々、サトにゃん氏はクラブ設立のために奔走した。「備品も予算も何もない状態から何かを作ることは非常に苦労したけれど、どうにかクラブができた」と、サトにゃん氏は振り返る。

　現在、サトにゃん氏はパソコンクラブの部長として試行錯誤しているようだ。また、非営利団体アスクウェアを設立するなど、システムエンジニアを目指して日々奮闘している。

システムエンジニアを目指して:
自分の手で何かを作り上げる（高校クラブ奮闘日誌1）

IT技術よ、加速せよ！ 現役高校生が考えるIT技術

　もう1人、学生コラムニストを紹介しよう。『加速し続ける未来派IT技術』のLotus氏は、日々IT技術やプログラミングについて勉強している高校生である。

　Lotus氏が興味を持っているのは、サーバやネットワークセキュリティ、プログラミングなど。コラムでは、クラウドコンピューティングや分散技術など、IT技術についての意見を寄せている。また、2009年にはアジア最大級のエレクトロニクス総合展「CEATEC JAPAN　2009」に、学校の代表として参加したようだ。Lotus氏は、イベントの詳細なフォトレポートを執筆している。

加速し続ける未来派IT技術:
アジア最大級のエレクトロニクス総合展に行ってきました！

社会人になってからでも「学生」はできる

　続いて、一度社会人になってから「学生」になったコラムニストを紹介しよう。『アーキテクトを目指して （元）社会人大学院生の挑戦』の阿部聡氏は、SEの仕事と社会人大学院への通学を両立させている。

　阿部氏が社会人大学院を志した理由は、「実務だけのスキルアップに限界を感じたため」だった。現在、阿部氏はSI企業でSEとして働いている。日々の仕事でプロジェクトに関する知識は身に付くが、体系的な知識はなかなかつかみにくい。自身のスキルアップのため、阿部氏は社会人大学院の門戸を叩いた。

　社会人と学生の両立は、なかなか大変なようだ。ほぼすべての講義で、レポートや演習課題が出されるため、日々の時間調整が重要事項となる。また、阿部氏によれば「頭の切り替え」もポイントになるようだ。働いている間は「仕事をこなす」モードだが、学生モードになるときは「初心に返って学ぶ」意識にチェンジする必要がある。これが非常に大変で、なんと「終電間近まで仕事をしていたときより大変だった」というから驚きだ。

　ほかにも、阿部氏は社会人大学院で学ぶ際の心得や、仕事との両立について、興味深いコラムを寄せている。

アーキテクトを目指して （元）社会人大学院生の挑戦:
難しいのは気持ちのシフトチェンジ

平成世代の学生に、どうやってJavaを教えよう？

　自分が「学生」という身分にならなければ、学生と触れ合う機会が得られないわけではない。『二足のわらじ－さすらいエンジニア教壇に立つ－』のまっつん氏は、SOHOでWebシステム開発をしながら、専門学校で講師として働いている。

　まっつん氏は、情報系専門学校で学生に向けてJavaの基礎を教えている。学生は皆、平成生まれ。物心がついたときにはWindowsが普及していた世代だ。いくら専門学校に来ているぐらいITに興味があるとはいえ、DOSコマンドを使ったことがある学生は圧倒的に少ないだろう。そういう学生に、どうやって上手にJavaを教えればいいのだろうか。

　そこでまっつん氏は、講義方法に工夫をこらした。「座学」「実技」と講義を分け、実技では「ゲームのようなもの」を作成することにしたのである。CUIに馴染みがない学生に「CUIって面白い！」と思ってもらうためにはこの方法が有効だった、とまっつん氏は振り返る。工夫が功を奏し、講義は無事に成功したようだ。

　世代が離れていても、ITに関する興味は共通するものがある。まっつん氏のエピソードは、そんなことを物語っているように思える。

二足のわらじ－さすらいエンジニア教壇に立つ－:
SOHOをしながら講師をする

　ここでは、編集部の独断と偏愛によって選んだコラムをテーマ別に紹介していく。今回のテーマは「チームで働く」。

　エンジニアは多くの場合、チームで働くことになる。チームの在り方や、チームリーダーに求められることなど、「チーム」にまつわるコラムを紹介しよう。

チームプレイの本質

　「エースプログラマ」が集まっても、プロジェクトが失敗する確率は、普通に人数を集めたプロジェクトとそれほど変わらないのでは――『地方からの戯言』のAhf氏はそう主張する。

　開発プロジェクトは個々の能力も去ることながら、チーム全体で目標に向かい一丸となって作業を行えるか、という点が特に重要である。当然、リーダーの良し悪しはプロジェクトの成否に大きな影響を与える。

　ただし、チームで働くとき、リーダーだけが気をつければいい、というわけではない。「チームとして結果を出すためには、どうしたらいいか」という問いは、メンバー全員が意識すべきではないか、とAhf氏は語る。

地方からの戯言: 人が集まってもチームにはならない

　『Are You Sure?』の佐藤正明氏も、個人の働き方とチームでの働き方の違いについて言及している。佐藤氏は、「サッカーにおけるチームプレイ」の考え方が、仕事にも適用できるのではないかと語る。

　サッカーにはフォワードやミッドフィルダーなどの「ポジション」が存在する。なぜポジションがあるのか。佐藤氏は「『チームとして有機的に機能する』ために、役割を決めておく必要があるから」だと解説している。このとき、チームの目的は「試合に勝つこと」である。

　「複数の人間が同じ目的に向かって、有機的に機能する」。これはサッカーでもビジネスでも同様だ。自分の役割だけをこなしていればよい、とか、自分さえ目立てばよい、というようなプレーヤーがいると、チームとしては不完全で、目的を達成することは難しくなる。

Are You Sure?: サッカーは社会の縮図～チームプレイの本質～

リーダーの条件

　続いて、チームで働く際に重要となる「リーダー」について、3つのコラムを紹介しよう。『オブリガート ～感謝されるテストエンジニアになる～』の第3バイオリン氏は、テストエンジニア向けのワークショップ「WACATE」に参加した際、グループワークでチームリーダー役を担当した。

　リーダーに求められるものとは何かについて、第3バイオリン氏はグループワークのメンバーと話し合った。あるベテランのメンバーは、次のように話したという。

　「リーダーは最終的な責任を取るのが仕事です」

　「チームの目的」をメンバー全員に示し、あとはメンバーに任せられることは任せる。そして、メンバーだけではどうにもならないことがあったときに素早くフォローし、責任を取る。それが優れたリーダーの姿なのではないか、と第3バイオリン氏はまとめている。

オブリガート ～感謝されるテストエンジニアになる～: 「WACATE 2010 夏」参加レポート（その4）――リーダーの条件

　『新任リーダー明日香のマネージャへの道』は、チームリーダーになったばかりの主人公「明日香」の奮闘をもとに、リーダーに必要な心得を解説している。「リーダーはメンバーの状況を理解しよう」「リーダーから積極的にコミュニケーションをとろう」といった具合である。

新任リーダー明日香のマネージャへの道: “明日香リーダーになる”の巻～第1話（上）

　「困ったリーダー」も世の中には存在する。『恋愛感情で仕事はできるか？』の森姫氏は、「リーダー失踪」という事件に遭遇したときのことをコラムに書いている。

　過酷な仕事を一身に背負い、それでも笑顔で働くリーダー。そんなリーダーが、ある日突然、会社に来なくなった。連絡も取れない。リーダーしかアクセスできない進ちょく表や、リーダーしか分からない仕事があったせいで、業務は完全にストップしてしまった。

　このとき、森姫氏は「1人で責任を負うことの危険性」を感じたという。「自分にしかできないこと」を背負いすぎてはいけない。「この仕事がほかの人にもできるように」と、常に自分のバックアップを作るべきなのだ。

恋愛感情で仕事はできるか？: リーダーが来なくなった日

メンバーのスキルの差をどう埋めるか

　最後に、チームにおける「業務」と「メンバー育成」の兼ね合いについて。これは、非常に難しい問題である。新人やスキルの低いメンバーをプロジェクトに参加させ、実践形式で育成したくても、それによってプロジェクトのパフォーマンスを落とすわけにはいかないからだ。

　Ahf氏は「メンバー内で技術レベルにばらつきが存在した場合、どこに基準をおくか」という問題について、「最低ラインに合わせるのは、エンジニアリングのプロとして避けねばならない」と主張する。だが一方で、「あまりにも高すぎるレベルに合わせるのも、同様によくない結果しか生み出さない」とも語る。どうバランスを取り、パフォーマンスを最大化しつつ、スキルの低いメンバーを育成するか。リーダーの手腕が問われるところだ。

地方からの戯言: チームを率いて

　永和システムマネジメント コンサルティングセンターの天野勝氏は、『システム開発に関わる人をイキイキさせるヒント』で、アジャイル開発のチームにおけるメンバーのスキルについて言及している。

　アジャイル開発は、チームで要件定義からテストまでを担当するという特徴がある。だが、最初から全工程のスキルがそろったメンバーでチームを構成するのは難しい。アジャイル開発には育成のループが組み込まれてはいるものの、いきなり成長するわけではないので、限界がある。

　天野氏の結論は、「ソフトウェア開発の基礎知識（要件定義から、テストや運用まで）」をきちんと学ぶことが重要、というものだ。当たり前のように聞こえるかもしれないが、チームで働く以上、基本的なスキルは習得済みであるべきなのだ。

システム開発に関わる人をイキイキさせるヒント: 人材育成、講師の視点から（3）

　ここでは、編集部の独断と偏愛によって選んだコラムをテーマ別に紹介していく。今回のテーマは「エンジニアと資格取得」だ。

　IT業界には、さまざまな資格がある。多くのエンジニアが、資格取得のために勉強していることだろう。

　エンジニアはなぜ資格を取るのか？ 資格取得にはどんなメリット・デメリットがあるのか？ 資格を取って、どんな自分になりたいのか？ 「資格」にまつわるさまざまな意見を紹介しよう。

資格取得はメリットがある。だけどコストのこと、考えてる？

　そもそも、エンジニアとして働くうえで、資格は必要なのだろうか？ この問いに対して、『Wife Hacks ～仕事と家族とコミュニティと～』のkwappa氏は「資格は取れるものなら取っておきたい」と答える。

　資格取得にはメリットがある。「最低限のスキルがある」という指標になるし、「資格取得」という目標は勉強を始めるきっかけとして有効だ。

　だからといって、「力の限りを尽くして資格をどんどん取ろう！」と安易に考えてはいけない。なぜなら、資格取得には時間や労力といった「コスト」がかかるからだ。kwappa氏は「資格は足の裏の飯粒のようなものだ」と語る。

取らねば気持ちが悪いが、さりとて取ったところで飯は食えないとの意味である。なんと言いえて妙なる洒落ではないか。

足の裏の飯粒

　資格や知識は邪魔にはならない。何かを知っていれば、きっとどこかで役に立つだろう。しかし、気持ちが向くままに新しい技術や資格に注力すると、コストとのバランスがうまく取れなくなってしまう。資格取得においては、「資格がもたらしてくれるメリット」と「コスト」のバランス感覚が重要なのである。

Wife Hacks ～仕事と家族とコミュニティと～:
「懐刀」と「足の裏の飯粒」

難関資格を1つ取るか、それとも主な資格をいくつも取るか？

　資格取得のためには、資格のメリットとコストのバランスを取ることが大事だ。当然のことながら、上位資格になればなるほど、取得が難しい。時間や労力を、どう配分すればいいのだろうか？

　フリーエンジニアのはがねのつるぎ氏は、ORACLE MASTER Goldを取得した。次に待ち受けるのは、最難関といわれる最上位資格のORACLE MASTER Platinum。

　ここで、はがね氏は2つの道を考えた。まず、「難易度の高い資格を1つ取得する道」。そして、「難易度の低い資格をいくつか取得する道」だ。はがね氏が選択したのは、後者の道だった。

　難関資格を取るためには、莫大なコストがかかる。「そのコストをいくつかの資格に振り分ければ、主だった資格は制覇できるかもしれない」と、はがね氏は考えた。時間や労力は有限だ。これらをどううまく配分するかを考えておきたい。

フリーなスキル:
資格い頭を丸くする ～資格取得で迷っているアナタへ

資格＝免許という制度にしてみては？

　次に、資格が持つマイナス面について掘り下げよう。「資格は、実力を反映したものではない」「資格を持っていても、仕事ができない人間はたくさんいる」――こう考えたことがあるエンジニアは、決して少なくないことだろう。『地方からの戯言』のAhf氏は、「IT資格は免許制のようにしてはどうか」と提案している。

　経験や勤続年数が多ければ、ある一定のスキルは身に付く。資格も同様に、持っていればある程度のスキルがあるという「目安」にはなる。しかし、資格がそのまま実力を表していることにはならない。エンジニアのように、技術力によって生産性が大きく変わる職種であれば、なおさらだ。

　ここに、IT業界とエンジニアのジレンマがある。技術力もプロダクトも、どちらも可視化しにくい。だから、資格は「技術や経験を表すもの」の1つとして扱われてしまう。

　資格そのものは、使いようによっては有用である。例えば「この作業をするためにはこの資格が必要」という使い方をしてはどうか、というのがAhf氏のアイデアだ。「この資格を持っている人は、詳細設計を担当できる」「この資格で扱える仕事の範囲はここまで」というように明確化するのだ。

　運用するためにはかなり高いハードルがあるが、うまくいけばIT業界全体の健全化につながるかもしれないと、Ahf氏は考えている。

地方からの戯言: 資格と免許

なぜわたしは資格を取らないのか

　「昔は資格を取得していたけれど、最近は全然……」という人の意見に耳を傾けよう。『若人視点』の早川勇太氏は、「なぜ資格を取らなくなったか」について紹介している。

　早川氏は、学生時代にはよく資格を取得していた。実務経験がない学生が実力を示すために、資格は有用だったからだ。だが、社会人になると状況が変わる。資格が、学生時代ほど評価されなくなるのだ。

　せっかく資格を取っても、あまり評価されない。一緒に資格を取得しようとする仲間もいない。早川氏は、これらが「資格取得への意欲がなくなった」原因だと語る。

　「だが、一番の“死角”は気の持ちようかもしれない」。早川氏はこう語る。資格を取らない理由はいくらでも考えられる。しかし、結局のところ、一番の原因は「自分が資格を取りたいと思うかどうか」なのだ。

若人視点: 資格の死角

資格取得のモチベーションを上げる3原則

　資格取得は、個人のモチベーションに大きく左右される。初めは頑張っていても、何度も落ちたり仕事が忙しくなったりして、勉強へのモチベーションが下がることはままあることだ。では、どうやれば「資格」へのモチベーションを維持できるのか？ 『It’s Party Time!』のあずK氏が考案した、モチベーションの保ち方を紹介しよう。

　早川氏と同様に、あずK氏も「資格が評価されないとモチベーションを維持しにくい」と指摘する。「わたしはこの資格を取ります！」と周囲に宣言するだけでもずい分モチベーションが上がると、あずK氏は語る。

　また、往々にしてあるのが「資格取得が目的になってしまうこと」。「資格を取得して、自分はどんな人間になりたいのか」ということをイメージすることも、非常に重要だ。

　最後に、あずK氏による「楽しく資格勉強するための3原則」を紹介しよう。

• 仕事に直結している
• 評価してくれる（褒めてくれる）人が周囲にいる
• 資格取得後の自分がどうなっているかをイメージする

It’s Party Time!:
資格試験に対してモチベーションを保つコツ

テストエンジニアが応用情報技術者試験を取りたい理由

　最後に、『オブリガート ～感謝されるテストエンジニアになる～』の第3バイオリン氏が語る「資格取得の目的」を紹介しよう。

　第3バイオリン氏はテストエンジニアだが、「応用情報技術者試験」の合格を目指している。なぜ、評価部門のエンジニアが開発系の資格を取ろうとするのだろうか。「開発部門の人と対等に渡り合うためには、応用情報技術者試験ぐらいの知識が必要だと考えた」――第3バイオリン氏はこう語る。

　もちろん、資格を取得したからといって、すぐに開発部門の人と対等に話せるわけではない。しかし、歩み寄りたいという姿勢は見せることができるのではないか。第3バイオリン氏は、「資格を取得したい目的」「なりたい自分の姿」をきちんと見据えて勉強している。その姿は、これから資格取得をしようと思う人にとって、参考になるだろう。

オブリガート ～感謝されるテストエンジニアになる～:
テストエンジニアのキャリアを考える（その1）――資格