今回は、慢性的に多忙になりがちなITエンジニアの「仕事と余暇」について話をします。　

　最近では、社会全体的に「心の病」が増加している傾向にあります。　ここで「心の病」と言っているのは、うつ病、パニック障害などを指しています。わたし自身は医療に関しては素人であり、この手の専門知識も豊富とは言えませんが、メディアや自分の知りうる環境でも以前よりも増加していると実感しています。　

　現代病という言葉では片付けることができない深刻な問題ではないでしょうか。20年ほど前と比較して世の中全体に余裕がないのがその一因ではないか、と個人的に考えています。　

　前述のとおり、わたし自身は医療の専門家でもありませんので、「心の病」にならない方法やなってしまった後の対処などを書くことはできません。　しかし、日頃の仕事のやり方などで、なるべく健全な状態を維持することで、うつ病などになりにくい方法があるのではないかと思います。

■仕事と余暇を切り替える

　わたしが日頃の仕事のやり方で大事だと考えていることは、仕事と余暇の切り替えです。　

　これは、単にうつ病防止ということではなく、仕事の効率アップにも繋がると考えています。　何より健康が一番大事なことで、心と体が健全な状態を維持できれば、仕事も捗りますよね。

　今回のコラムを執筆するにあたって、うつ病に関する情報を少し調べてみましたが、2005年にWebに掲載された情報で、“うつ病の増加は、IT業界から始まった”との記事がありました。　この業界に身をおく立場として、この記事内容に少なからずショックを受けました。　

　特にITエンジニアは、

• 長時間労働
• 納期のプレッシャー
• プロジェクト内の限られたメンバーとの閉ざされた世界
• 作業場所が自社以外（顧客先など）

といった労働環境の下、行き詰まり感を増徴し、自らの心を壊してしまうのではないかと考えます。

　では、このような状況に陥りやすいIT エンジニアとして、どのような対策があるのでしょうか。実際に開発プロジェクトの終盤では、休日返上や深夜の対応など、どうしても厳しい労働環境になりがちです。　

　そうならないように、わたし自身は、「やる時と抜く時のメリハリをつける働き方をする」と心がけて実施してきました。　もちろん厳しい時には、無理をせざるを得ないこともありましたが、“メリハリをつける”ということを常に考えて仕事をしてきました。例えばですが、平日は徹夜をしてでも休日は休みを取る、というような考え方です。　もちろん自分だけの判断でそれが叶わないことも多いので難しい問題ではありますが。

　もう1つは、余暇を上手に使うということです。

　多忙な状況の中、せっかく作った余暇ですので大事に使うようにします。わたしが考える余暇の過ごし方として、以下のことを心がけています。

• 疲れた身体を休める
• 心をリフレッシュさせる
• 楽しむ

○疲れた身体を休める

　まずは疲労を癒すことを優先します。　疲労には身体的なもの、精神的なものがありますが、十分休養をして溜まった疲労を取り除くことが重要です。　疲れていては何もできませんので。

○心をリフレッシュさせる

　仕事のことを忘れる努力をします。わたしの場合はきれいさっぱり忘れることができます（笑）。方法はその人によって異なると思いますが、例えば、趣味（スポーツ、読書、映画鑑賞など）に没頭するとか、何もせずに自然の中で、ボーっとするなど、方法は何でもいいと思います。　

　重要なのは仕事を忘れることです。仕事を忘れることは、なかなか難しいと思いますが、休日に空いた短い時間を使って仕事をしても大して捗らないと自分に言い聞かせ、潔くあきらめることも大事です。わたしの場合は、スポーツが好きなので、休日にはよく身体を動かしています。　ITエンジニアは、長時間座ったままでの労働が多くなりがちで、心身の疲労のバランスを崩すことも多いので、たまには身体を動かして、心身の疲労のバランスを取ってみるのもいいことだと思います。スポーツなどによる肉体疲労の後は、思った以上によく眠れるものです。　

　また、スポーツをしている間は、仕事は頭から忘れ去ることができるので、心のリフレッシュをすることができます。

○楽しむ

　最後に、余暇を十分楽しむことです。自分の趣味などに貴重な時間を使って楽しむことで、また新たに仕事への意欲が沸いてきます。

　今回は、技術と離れた話題となりましたが、要するに自分の能力を十分に発揮するためには、心身ともに健全な状態を作ることが重要であり、そのためには定期的な休養を取り、そこでできた余暇をいかに上手に使って自分をリセットできるかが大事であるということについて書いてみました。厳しい環境の中で働いているITエンジニアの皆様、身体に気をつけて仕事をしてください。

　第3回、第4回は、技術的な話題をしましたが、今回はエンジニアに必要なコミュニケーション能力についてふれてみましょう。

　ソフトウェア開発に関わるエンジニアといっても、皆さまざまな環境で働いており、その立場によって必要とするコミュニケーション能力は異なると思います。自身の置かれている立場や環境によっては、他人とのコミュニケーションがあまり必要と感じていない方もいらっしゃるでしょうし、また、エンジニアの中にはコミュニケーションを得意としていない方もいらっしゃるかと思います。

　しかし、わたしは仕事をしていく上で非常に重要な能力としてとらえています。このように言っているわたし自身も、若い頃は人とのコミュニケーションはそれほど得意ではありませんでした。今のわたしを知る方には信じ難いことかもしれませんが、あまり話しをしなかった部類であったと記憶しています。現在では、あまり話し過ぎないように自分自身で注意をしていないと、ついつい話し過ぎる傾向にあり、話し過ぎてから反省をしていることも多々あります。　

　人とのコミュニケーションは、一方的に話すのではなく、会話のキャッチボールであり、むしろ相手の思いを聞き出す事が重要です。前述のとおり、わたし自身は、人とのコミュニケーションがあまり得意ではなかったのですが、その後も特にコミュニケーション能力向上に関する専門教育を受けたことはありません。しかし、現在では、特に他人とのコミュニケーションで困ることはありませんし、どちらかといえば他人との会話は好きなほうです。

　その理由はSE（システムエンジニア）やPM（プロジェクト管理者）という仕事を通して、人とのコミュニケーションの重要性を思い知らされ、その能力をなんとか身に着けなければと考え、努力したからだと思います。　エンジニアには高い技術力が備わっている必要がありますが、その高い技術力を活かすためにも、コミュニケーション能力は重要です。

　以降にエンジニアがコミュニケーション力を高めるために考えるべきことをいくつか紹介しますが、けっしてコミュニケーションのテクニックではありません。　

　エンジニアとして、企業のお客様と仕事を進める上で重要な事柄をわたしの経験からまとめたものです。また、今回は“関係構築”、“システムづくり”に焦点をあてていますが、他にもさまざまな局面があり、各局面ごとに順調に仕事を進めるための心構えとコミュニケーションの方法は存在していると考えます。

1．信頼関係を築くため

　人との関係は健全な信頼関係の上に成り立つもので、ビジネスでも同様です。立場を問わず企業の代表として相手企業の代表と会話をしていることを忘れてはなりません。　

　また、困難な仕事を乗り越えるためには、相手企業の担当者との信頼関係はなくてはならないものです。システム開発のプロジェクトを完遂させるまでには、幾多の困難と直面しますが、それらは、作り手企業の努力だけで解決できる問題だけではありません。発注者側企業の協力が有ってこそ乗り越えられる問題も多くあります。そのような局面での協力依頼などは、担当者同士の信頼関係の有無が大きくものをいいます。

　しかし、勘違いをしないでほしいのは、ここでいう担当者同士の関係とは、癒着するということではありませんし、飲み友達になることでもありません。お互いにビジネスマンとして信頼しあう関係を構築することです。では、具体的にどのように信頼関係を築いていくのか、わたしが心がけていることを以下にあげます。

●相手に礼を尽くし協力的である

• お客様である相手には礼儀正しい言動をする
• お互いに企業の代表として仕事を進めている立場ということを忘れない
• 自分が対峙している担当者の企業内での成功とは何かを考えた言動をする（相手の企業内での立場を理解する努力）
• Win-Winの関係を大事にする

●誠実である

• 約束を守り、正直な対応をする
• 問題発生時には早い段階で報告する

●信念を持つ

• 常に意見が一致しない場合もあります。しかし、相手企業の成功につながると思う提案は、多少の逆風には負けず、理解を得られるまで説得する努力をすることも大切です。
• 相手企業の見解に一貫性に掛けている部分がある場合には、その矛盾点を見過ごさず、勇気を持って指摘して改善に努めるように働きかけることが重要です。

　上記の項目は、コミュニケーションをとるためのテクニックというよりも“姿勢”になります。信頼関係を築く上で小手先のテクニックは通用しません。自分自身の取組み姿勢がにじみ出てくるものですから、相手の正面に立って正々堂々とぶつかっていくしかないと思います。

2．正しいソフトウェア・システムを構築するため

　1．は、主に人と人との感情の繋がり（信頼関係）における姿勢についてでしたが、2．はシステム構築におけるコミュニケーションになりますので、コミュニケーションの主体は感情から理論に移ります。　

　この領域においては、当然のことですが、ドキュメントやモデルによって情報の確認を取る手法が中心となり、記述された内容について齟齬が存在していないか判断することが多くなります。　しかし、すべての情報をドキュメントやモデルで網羅できないことがありますので、それを補完する上でその他のコミュニケーションが重要となります。顧客企業が求めるシステムを正確に構築するために必要なコミュニケーションの観点は以下になります。

●要求を正しく引き出す

　段階的に要求を整理することが重要です。ヒアリング → ドキュメント化 → レビューを繰り返して、相互に正しい理解を進めていくことになりますが、その順序や手順を誤ると、無駄に時間を費やすことになりかねません。　

　要求とは何の理由もなしに湧き出てくるものではありません。その裏側には、その要求発生の原因があるはずです。例えば、何らかの問題を抱えており、その課題を解決するための要求事項であったりします。また、その問題にも根本的な原因があり、要求項目の表面だけを見てもその本質を理解できない場合が多くあります。よって、原則的には、“川上から川下”へと段階的に要求事項を整理しながら纏め上げていくことが要求を正しく引き出し、整理する方法となります。　要求事項を整理していく大まかな流れは、以下のとおりです。

• 問題を分析し正しく理解する
• ユーザーニーズを理解する
• 課題解決のためのシステム化範囲を決定する
• システムの詳細化を進める

図1．要求管理の流れ
参考：「Managing Software Requirements A Unified Approach」　DeanLeffingwell/Don Widrig著

　このような基本的な流れを意識しながら相手とコミュニケーションをとることで、大きく論点を外すことなく、ミーティングの場をコントロールするのに役立ちます。

●抽象度と粒度

　要件のヒアリングをする際に、ユーザーはさまざまな事柄を1度に提示してくる場合がありますが、抽象度と粒度の観点から要求事項を的確に整理する必要があります。

　何らかの課題を解決することがシステム化の目的であり、漠然とした問題提起から、詳細なシステム定義に落とし込むには、前述のとおり段階を経て情報の整理をする必要があります。ここでいう粒度とは、ユーザーニーズを言っているのか、システム化において必須となるシステム要件を言っているのかなど、どのレベルについて話しをしているのかを聞き分けることです。　

　また、コミュニケーションをとる上で重要なのが抽象度です。相手が話している内容が、どのぐらいの抽象度なのかを的確に判断する力が重要になります。お互いに異なる抽象度の話をしても会話は噛み合いません。例えば、業務処理における一般的なルールなどは、抽象度が高い話であり、特定業務における処理手続きは、抽象度が低くより具体的な話になります。それぞれ抽象度が異なりますので、どちらについて議論をしているのか正しく理解できていないと会話は噛み合わず、適切な提案もできなくなってしまいます。これは、よりシステム的な議論でも同様のことが言えますので、重要な考え方だと思います。

●誰の要求なのかを追及する

　オーナー不在の要求事項があった場合には、そもそも誰が望んでいる要件なのかを聞いてみるとよいでしょう。もし、会話をしている相手が把握していなかった場合は、その件について認識している人に聞いてみる努力をする必要があります。

上記のような場面に出くわした場合は、システム要件を議論する場に、すべての利害関係者が揃っていない懸念があるからです。

●曖昧さを排除したコミュニケーション

　基本は文章、表、図、モデル化したドキュメントを介してお互いに齟齬が発生しないように努めることでできる限り曖昧さを排除します。　

　しかし、ドキュメントで全ての情報を漏れなく伝えることが可能なわけではありません。記述してある内容が正しくとも、読み手の理解が誤っている場合や、その逆の場合などがあり、最後は人が正しく理解しているかが焦点となります。　

　最終的な相互理解は、レビューの場で相互に正しい理解をしていることを確認するしか方法はありません。わたしが気をつけて実施していることは、重要な事を確認する時に、相手側が“Yes”or”No“ で返事ができないように問いかけ、実現したいことをなるべく相手の言葉で話してもらうようにすることです。　

　例えば、”～の要件はこれで正しいですね？“ という聞き方をした場合、相手は、”はい、正しいです“（または”いいえ“）と回答しますよね。この場合危険なのは、肯定された場合であり、後々、やはりこの要件は誤っていたと前言を翻すことを数多く経験しています。このケースの問題は、相手がこちらからの説明を100％正しく理解せずに”Yes“の回答をしてしまったことです。　

　このような場面では、”～の要件について最終確認をしたいので、要件の概要についてお聞かせくださいますか？“のように問い掛けるよう心がけています。このような場合、相手にひたすら話をさせるのも失礼になりますので、所々、こちらからも問いかけをして、会話を進めていくように努めますが、重要な事は相手の言葉で話していただくことです。これは、自分自身の思い込みによって誤った業務処理の理解や、それに伴うシステム設計段階での齟齬を少しでもなくすようにするためです。

3．最後に

　今回はエンジニアが身に付けたいコミュニケーションについてをテーマとし、企業ユーザーのシステム構築に関わるSEの視点で書いてみました。　

　この他にも、お客様やプロジェクトのメンバーと健全な関係を維持するためのコミュニケーションの秘訣はたくさんあると思います。また折を見てご紹介できればと考えております。

　最近では、学生時代になんらかのプログラミング言語を習得してから社会人になることも珍しくないですが、入社時にプログラミング言語の知識を持ち合わせていない場合もあるでしょう。入社時点でのプログラミング能力は若干の差があるとしても、ソフトウェア・エンジニアを職とした人たちが最初に習得すべき課題は、プログラミング技術だと考えます。

　プログラミング言語の基本的な仕様を習得し、簡単なプログラムを作成するようになるまでには、さほど多くの時間をかけずに実現が可能です。プログラミング技術を磨くには、多くのプログラムを開発することと、他人が書いたプログラムを読み、その意図を理解することが一番だと思います。他人が書いた賢いコードやきれいなコードを読むことで、自分にはない発想を学び、上手に自分のものにしていくことが重要です。

　このように、ある程度経験を積むことで、1人でプログラムを作成できるように成長したエンジニアの次の課題は、ソフトウェア設計です。

　わたしが社会人として最初の会社に入社した時代は、ソフトウェア設計とプログラミングを分業していましたので、プログラミングを習得してから設計者へと“格上げ”されていきました。最近では、設計と実装を明確に分離せずに進める傾向にあり、これは、オブジェクト指向設計やAgile開発が浸透してきている影響だと思います。

　ソフトウェアは、プログラマがある種の設計をしながら作成されていくものだと考えますので、わたしもこのアプローチは正しいと思います。しかし、ソフトウェア・エンジニアとして成長していく過程において、一度に多くのことを習得することは困難であり、段階を経て一人前になることが一般的です。その前提に立つと、プログラミング ⇒ 設計の順序で、エンジニアとしての腕を磨いていくことは効果的な方法だと思います。

■ プログラマが備えるべき設計スキル

　プログラムを開発する際、設計上で気をつけたいポイント。

1. モジュール（クラスなど）の凝集度が高く、疎結合であること
2. 重複する機能が点在していないこと（コピー＆ペーストをしていないか）
3. テスタブルであること

● 凝集度と結合度

　凝集度とは、クラスなどが単一の機能で構成されているかの尺度です。

　必ずしも単一機能で構成されている必要はありませんが、機能の凝集度が高いほうが、機能に対する実装単位が単純化され、より理解しやすい構造になります。また、特定機能に対する変更が発生した際に、他の機能に対する影響度を最小限に留めることが可能です。

　一方、結合度において重要なことは、呼び出す側と呼び出される側の関係は弱いほうが良く、情報の受け渡しが疎結合の状態を目指して設計することです。

　疎結合の状態とは、コンポーネント同士の依存関係が弱く、柔軟にそれぞれのコンポーネントを交換、変更することができ、一方へデータまたはデータの構造体を渡すことにより、目的とする結果を得るという関係です。

　このような関係だと、データを受け取ったプログラムが内部でどのような処理をしているかを意識する必要がなく、呼び出す側は、いわゆるブラックボックスとして考えればよいわけです。よって、呼び出されるプログラムに何らかの変更が生じても、2つのプログラム間のインターフェースに変更がなければ、呼び出し側のプログラムは、特に変更を意識する必要がありません。

　逆にコンポーネント同士が密な関係を密結合といい、呼び出し側から、呼び出される側が保有している情報を直接変更するような場合や、その逆の場合があります。密結合は、動作は高速ですが、それぞれの変更がそれぞれのプログラムに大きな影響を与える可能性があり、変更容易性を低下させることになります。

● 重複の防止

　同一のソースコードを、複数に点在させてはならないという基本的な考え方です。

　実装言語の仕様によって実現方法は異なりますが、共通的な機能は一箇所にまとめることが望ましいです。同一のコードが複数箇所に存在した場合、変更の対応に手間がかかることはいうまでもありません。プログラミングしている時に、一連のソースコードをコピー＆ペーストしたくなったら要注意です。

● テストが容易

　開発したプログラムのテストが、容易に実施可能であることが重要です。

　上記の凝集度、結合度が理想的に守られているプログラムは、テスト容易性が高いといえるでしょう。　

　凝集度が高ければ、より小さな機能単位でテストが可能であり、結合度が低い（疎結合）プログラムでは、プログラム単体でのテストが容易になります。このような構造で設計されたプログラムは、テストの自動化も容易となり、開発効率向上と品質向上へつながります。　

■ そのほか、設計上で注意したいこと

　ソフトウェアの設計といっても、その抽象度のレベルは様々です。

　通常、最初から詳細なソフトウェア設計をするわけではなく、抽象度の高いところから段階的に詳細化（低い抽象度）していきます。前述の設計上で気をつけたいポイントは、プログラミングレベルの抽象度の低いレベルでの注意点です。ソフトウェアは、多くの場合、膨大な数のクラス（モジュールなど）が連携しあって動作するものです。一般的には、最小単位のかたまり（例えばクラス）を一定の目的で束ねて集約（例えばサブシステム）し、さらにそれらを複数束ねて集約（例えばパッケージ）するといったように階層化された構造になります（図-1）。

　クラス群を構造化していく上での設計上の注意点は、以下になります。

1. サブシステム間インターフェイス設計
2. 隠蔽性
3. 依存関係

● サブシステム間のインターフェース設計

　ここでいうサブシステムとは、UML(Unified Modeling Language)でいうサブシステム（<<Subsystem>>）を示しています。

　具体的には複数のクラス群から構成されており、ひとつ以上のインターフェースを公開し、その内容については公開していないという特徴があります。クラス群は、関連性の高い一定の目的を達成するための集合体です。サブシステムが公開するインターフェースは、そのサブシステムが実現すべき機能を考慮し、将来の拡張も踏まえた設計とすることが重要です。　

● サブシステムの隠蔽性

　上記のように、サブシステムはその内容を公開しないという特徴がありますが、これは被利用者からの独立性を保つために重要な概念です。よって、サブシステムを構成するクラス群は、それらが保有する要素の可視性に注意して設計することが重要です。サブシステム外から、サブシステム内の要素を直接、参照・操作できない可視性とすることで、隠蔽性が保持されます。

● 依存関係

　レイヤーを跨（また）ぐ依存関係が存在する場合、自分と同じレイヤーか、もしくはより抽象度の高いレイヤーへの依存を許可するような設計が必要になります。自分より抽象度が低いレイヤーへの依存や循環依存（互いに依存しあっている）関係を回避する設計にする必要があります。

■ 最後に

　今回のテーマでは、プログラムの実装に近いフェーズでの設計における原則的なポイントを紹介しましたが、現実の設計＆実装では、全てが原則通りにはいかない場合があります。

　現実的な解決策として、部分的に冗長な設計をする場合があります。ここで重要なことは、原則を遵守する部分と、冗長な設計をする部分をどのように決定するのか、その判断の基準にあると考えます。しかし、その答えを導く方法は、場面ごとに適切な判断を下すしかありません。適切な判断を導き出すには、経験を重ねていくしかないのかもしれません。

　システム構築の現場で予期せぬトラブルに出くわすことがよくあります。そのような局面で重要となるのは、目の前で発生している障害の原因を、正確に迅速に突き止めることです。

　システムトラブルは発生しないに越したことはないのですが、若いうちに様々な局面で問題解析能力を磨いておくと、将来、大変役に立ちます。

■まずは問題を正しく切り分ける

　システムのトラブルといっても様々なケースがあります。

　例えば、自らが開発したソフトウェアを組み合わせて構築したシステムである場合や、商用製品など自らが開発をしていないソフトウェアを組合わせて構築したシステムの場合などがあります。また、システムはソフトウェアのみで動作することはできませんので、サーバ、ストレージ、ネットワーク機器など様々なハードウェアと組み合わせて機能するものです。そのため、トラブルが発生した場合に厄介なのが、一体どこで障害が発生しているのかが判り辛いケースです。

　このような場合に重要になるのは、問題の切り分け能力です。問題の切り分けとは、障害の原因が、ハードウェアにあるのか、ソフトウェアにあるのか、論理的な判断により障害の原因箇所を少しずつ狭めていき、最終的な原因特定まで導き出すことです。

　これには経験と知識が必要ですが、意識して訓練することは可能でしょう。障害の事象を見ただけで、誰もがすぐに原因の特定ができるようなケースもありますが、多くの場合は、すぐに原因の特定には至らず、いくつかの調査を経て、原因の特定につながるのではないでしょうか。

　障害の原因を調査するうえでのアプローチ方法としては、システム全体をいくつかの意味のある単位に分類し、分類した単位（コンポーネント）ごとに障害の事象と照らし合せて、障害の原因となる可能性の有無を論理的に立証することをお勧めします。また、ソフトウェアに限らず、サーバ、ネットワーク関連のハードウェアも同様に、分類した単位ごとに当該箇所が障害原因となり得るかを検証することが非常に大切です。

　こうした論理的な立証のための調査や検証には、地道な活動を要しますが、障害原因になり得ることを証明する検証をするのか、障害原因になり得ないことを証明する検証をするのか、どちらが検証し易いかといった視点が重要になります。システムトラブルは原因の特定に時間が掛かるケースもありますが、このように1つ1つ確実に障害原因となり得る範囲を狭めていけば、最終的には原因を特定できる可能性は高まるでしょう。

■最近、ダンプ解析をしている人が減少している

　これは15年ほど前のことになりますが、メインフレーム・システムの構築現場で育ったわたしにとって、UNIX環境での開発者たちがアプリケーションの障害発生時にダンプ解析（*）をあまりしていないことに非常に驚いた経験があります。

　わたしが見てきた範囲に限りますが、業務システムを開発している技術者の中で、コアダンプの解析を正確にできる人材は少なかったように感じました。しかし、ダンプの解析を正確にできなければ、深い問題に直面した時、障害原因の特定はできないように思えます。

　ダンプ解析をするには、それなりの知識が必要であり、解析作業にも時間を要しますが、ダンプ解析をすると障害原因の特定の可能性は確実に上がります。なぜなら、障害が発生した時のメモリーの状態がそのまま残っているため、表面的には見え辛いことがダンプ解析をすることで明らかになるからです。皆さんも、ダンプ解析ができる先輩SEが周りにいたら、積極的にその技術を習っておくことをお勧めします。

　システムトラブルに対する対処として、上手に問題の切り分けをし、障害原因の特定をすることと、障害原因が局所化した場合は、より深い調査能力を有することが重要です。日々の仕事の中でも問題解析の意識を持つことによって、このような技術を向上させることができると思います。　

（*）ダンプ解析：プログラムが占有するメモリーの情報を16進形式で出力したもの

　私自身、SE業務を中心にIT業界に関わってきております。その結果、企業向けのシステム構築という視点からの話が中心になってしまいますが、できる限り広い視点で自らの反省も踏まえて書いてみます。

■ どんな仕事に就くかは分からない

　前回のコラムでは「IT業界の仕事は面白い！」と言いましたが、これは働く人の気持ちによるところが大きいと考えます。IT企業に入社すれば、常に興味を持てる仕事に従事できる、とは限らないからです。

　私の場合は、某メーカー企業のシステム事業部門に配属されていたので、多くの人が企業向けのシステム構築に関わるSE業務またはプログラマという仕事をしていました。しかし、私は大多数の人々とは一線を画す仕事に就いていました。それは、SE部門を支援する役割を担う部門の仕事です。

　企業内部の話になりますので、あまり詳細に仕事の内容を書くことは差し控えたいと思いますが、概要レベルで説明します。SE部門が企業向けにシステム構築をすると、他の企業システムでも流用可能なソフトウェア資産が少なからず残るものです。私が所属していた部門は、そのような再利用可能ソフトウェア資産を管理する役割を果たしていました。

　その当時の私の主な仕事内容は、膨大な数の再利用可能ソフトウェア資産を管理するシステムの開発と、そのソフトウェア資産の機能の確認でした。当時の私は他部門に配属された同期入社のSE達が羨ましくて仕方なく、そのことで悩んでいました。彼らは企業向けのシステム構築を担当するSE部門で仕事をしており、自分よりも高尚な仕事をしているように見えたからです。

　しかし、私と同じ部門で働く先輩社員にその悩みを相談したとき、私の考えは一変しました。その先輩のアドバイスはこうです。

　“現場のSE部門で学べることも多いが、今の部門でしか学べないことは非常に多い。あなたは、自分の足元の宝を見ずに、人の宝を羨んでいるだけではないか”

　この言葉の意味を理解したとき、自分が恥ずかしく思えました。その後は、自分の担当業務から何かを学び取ろうとする強い意識が出てくるようになり、今まで気づかなかった多くのことに気づくようになりました。具体的には、再利用可能なソフトウェア資産の機能を確認する課程で、OSやミドルウェアに対する多くの知識が身についていくことでした。

　実際に、SE部門に配属された同期社員と話をする機会があり、その差を感じることができました。彼らは、毎日のようにプログラム開発やテストに明け暮れており、それ以外のことを考える時間がない生活を送っているようでした。よって、自社のOSや製品についての知識については、よく知らないといった状況であったのです。

　私と同期入社SEのどちらが良いのかはわかりません。重要なのは、自分が与えられた環境でより多くのことを学び取ろうという姿勢です。そのように取り組むと仕事も楽しくなってくるものです。

■ システム構築という仕事

　企業システムを構築する仕事は、非常に多くの知識・スキルを要する仕事です。

• プログラム開発
• ソフトウェア設計
• 要件定義
• 業務分析
• 業務知識
• プロジェクト管理
• ソフトウェアテスト
• ハードウェア
• OS・ミドルウェア
• ネットワーク構築

　大雑把に挙げても上記のように多岐に渡る知識やスキルが必要です。上記を1人の人間がすべてカバーするわけではないのですが、全体を俯瞰（ふかん）する立場になろうとすると、多くの分野の知識が必要となります。特定の技術領域に特化したスペシャリストの道もありますが、企業システムを構築するといった視点で取り組むエンジニアは、より広い範囲の技術知識が必要ということです。

■ どんなスキルを磨けばよいのか？

　より多くの、幅広いスキルを身につける必要があります。しかし、全ての分野でスペシャリストになることは不可能なので、まずは、自分の得意な分野でのスキルを磨き、そこから徐々に広げていくことが重要です。

　私の場合は、ソフトウェア開発を中心に徐々に関連スキルを広げるようにしてきました。ただし、前述のとおり最初から深くプログラミングに関わる仕事をしていたわけではなく、ミドルウェアなどの関連知識を業務から学んだ後、SE部門への配置転換を経て、プログラム開発やソフトウェア設計を学んでいきました。

　私の主観ですが、プログラミング言語というのは、それほど難しいものではなく、ルールさえ覚えれば小学生でもプログラムを作成することは可能なものであると考えます。重要なのはソフトウェアの設計やアーキテクチャであり、それをいかに学び取るかが肝要と考えます。

　また、同様に重要なのがソフトウェア・テストです。最近はテストができない職業プログラマをよく見かけます。さらに大きな視点で見ると、企業で営まれている業務をシステム化するには、業務を分析するスキルとそこからシステム化すべき要件を定義するスキルも重要です。また業務要件が正しくシステムに反映させるためのソフトウェア開発方法論や、それに則ったプロジェクト管理のスキルが必要になります。

　これだけ多くのスキルが必要なので、焦ってもすぐに結果が出るものではありません。1つ1つ、しっかり技術を積み上げていくことが重要です。　

■最後に

　IT業界に入ってまだ日が浅い若手エンジニアの皆さん、いま自分が従事している業務には、何かしら学べる事があるはずです。学び取る意識があればそこから何かが見えてきます。そして今後、自分の中心に据える技術領域を見つけてください。その技術を中心に、今後の経験の中から様々なスキルを積上げていくことでエンジニアとしての厚みが出てくると思います。

　しっかりとした土台には、立派な建造物を築くことができます。技術の蓄積も同様でしょう。

　“エンジニアとして、どのように年齢を重ねていくことが望ましいのか？”と立派なサブタイトルを付けてしまいましたが、わたし自身がすでに40代半ばと歳をとってしまっているので、もしかしたら、わたしの後悔を綴るコラムになってしまうかもしれませんが、コラムを読んでいただく若いエンジニアの方々に、少しでもお役に立てる内容を書いていければと考えています。

　わたしは、社会人になって以来ずっとソフトウェア開発の技術者として働いてきましたが、現在では、執行役員とCTOという役割を仰せつかっており、日夜奮闘をしています。

　ずっと一技術者として働いてきたと思っていたのですが、ふと気がつくと、企業を経営する側の立場になっていました。実際、技術の現場からは少し遠のいてしまっています。できる限り若いエンジニアと接点を持ち、いろいろな話をしようと努力をしていますが、思うように時間がとれず苦しんでいるというのが現状です。

　このコラムでは、エンジニアの生活や思いが年齢とともに変化していく様を、わたしの経験や後悔を通じて綴っていきたいと思っています。

■ 技術者には、様々な可能性がある、だから楽しい！

　時代の変化とともにソフトウェア技術者のあり方も変わってきていると思います。変化したというよりも、バリエーションが増えたと表現した方が正しいのかもしれません。

　それは、ITを取り巻く環境の変化によって、職業としてITに関わる技術者の職種が増えたということなのだと思います。

　わたしがこの仕事についた頃は、インターネットなんてものはなく、ソフトウェアエンジニアといえば、「企業システムの開発」「OSやミドルウェアの開発」「業務パッケージの開発」など、大別するとこのようなことをする職種のこと、だったと思います。しかし、インターネットの普及やモバイルデバイスの技術的進展を見れば分かるとおり、ITはどんどん進化しています。こういった背景から、ソフトウェアエンジニアなどIT関連の技術職の幅は広がってきています。

　現在は、職業の選択の幅という視点から、ITに関わる技術者にとって、プログラムを開発する以外にも、Webコンテンツ開発など多種多様な職種を選択できる環境があり、将来の可能性が広がったということにもなるでしょう。また、技術者として、どのような役割を目指していけるかをみてみると、「生涯一プログラマ」のような職人を目指したり、ソフトウェア開発を通じて専門業務知識を習得し、コンサルタントになることや、ITに特化した技術でコンサルタントになれるという可能性もあります。さらに、プロジェクトマネージャやIT企業の経営層になるなど、SEという1つの職種から、様々な職種（役割）に転身できるのも、IT業界で働く技術者の面白味であるとわたし自身が感じています。　

■ 自分は何になりたいの？

　しかし、社会人1年目に、現在の40歳半ばの自分の姿が想像できたはずもなく、その頃のわたしは、自分が何になりたいのかもよく理解をしていなかった気がします。

　今までを振り返ってみると、現在に至るまでいろいろと回り道をしてきていると感じることがあります。

　わたしがこのコラムでお伝えしたいことは、人は誰でも歳をとっていくものですが、年齢とともに人間として、技術者として確実に成長していくことが重要であるということです。時の経過とともに、自然と成長していければよいのですが、それは容易なことではなく、1つ間違えると年齢による衰えだけは確実に進むけれど、年輪や熟練といった、年とともに深まっていく経験や人間味、風格のようなものを醸し出せないといったことになる可能性があります。それでは寂しいですよね。

　こう書いている自分にその年輪があるのか疑問を感じつつ、わたし自身の若い頃を思い出しながら、年代ごとに、どんなことを考えながら過ごしていくことが望ましいのかについて書いてみましょう。

　偉そうに書いていますが、わたしが社会に出たばかりの頃は失敗の連続でした。自分が何になりたいのかさえ明確に認識もせず、日々仕事に追われていたと記憶しています。

　さて、長い前置きはさておき、今回は新人エンジニアの頃にさかのぼり、その年代のエンジニアの取組みについての話を書いてみます。

■ 若い頃の苦労は買ってでもしろ！

　実は、わたしがこの職業に就いたことに明確な理由はありませんでした。

　ただ、なんとなくシステムエンジニア（以下、SE）という職業が“格好いいかな”と思ったぐらいでした。SEという職業の詳細までは、あまり理解していませんでした。プログラミング言語を使ってのプログラミングは多少なりともできたものの、“SEとは、おそらくソフトウェアづくりに関わる仕事なのだろう”と漠然と考えている程度でした。

　新入社員当初は、某メーカーのSEとして従事していました。実際は、メーカー企業の社員ではなかったのですが、入社直後に資本関係のあるメーカー企業へ出向となり、それ以降約7年間、そのメーカー企業でSEとして働いていました。技術者としての教育などは、このメーカー企業に大変お世話になりました。

　この時期において、わたしの記憶に一番残っていることは、“若い頃の苦労は買ってでもしろ”です。

　わたしが好きで買った苦労ではなかったのですが、結果的には、ここでの苦労が現在のわたしの基礎を作ったといっても過言ではありません。単に苦労をすればよいという意味ではなく、若い時には短期間に集中的に多くの技術を学ぶことが重要という意味です。

　前述したとおり、あまり明確な目標も抱いていなかったわたしにとって、この頃の日々の課題は、とにかく多くの技術を身につけることでした。

　そして、当時の最大の苦労は、何しろ労働時間が長かったことです。おそらく入社してから3年間は、普通の人の2倍近くの時間を働いていたのではないかと思えるほどでした。

　しかし、今振り返ると、この3年間で技術的に、かなり成長したのではないかと思います。最初の3年という、技術者としての基礎を作る大切な時期に多くのことを学べたことが良かったのでしょう。

　最近のIT業界は、よく“3K”と言われていますが、状況は当時も同じです。正にそれを絵に描いたような状態でした。しかし、そんな厳しい環境の中で耐えることができたのは、指導してくれた先輩社員に恵まれたからだと思います。先輩社員には技術だけではなく、エンジニアとしての志を教えていただきました。精神論ではありますが、当時、教えていただいた志は現在でもわたしの支えになっています。

　「入社直後の技術者の取組みとして重要なこと」は2つ、

• 時間を惜しまず多くの技術（特に基礎的な）を学ぶことに貪欲になる
• エンジニアは、“こうあるべき”を自分なりに考えてみる

　であると思います。

　2つ目の“こうあるべき”は、自分の中でなかなか定まるものではありませんが、真剣に考えてみることが大事だと思います。わたし自身も同期や年齢の近い先輩と、よくこの話題で議論しました。

　深く考えることなくこの業界に飛び込んだわたしでしたが、このような厳しいながらも同志に恵まれた職場環境を過ごしたことで、情熱を持って仕事をする魂が芽生えるまでに多くの時間はかかりませんでした。