Contents
システムエンジニアの条件
10年以上SEを仕事としてきたが、多様な役割がある中でSEの条件は以下の3つに集約されると考えている。
- 調査
- 設計
- 提案
この3つのどれか一つ欠けると、SEとしてイマイチな人材になってしまう。
SE を目指されている方は、これからのキャリアでこの３点が磨かれるようなポジションをプランニングされることをお勧めしたい。
各要素についての紹介と、なぜその3つなのかを解説する。
調査能力
SEは、日々システムトラブルと相対する。プログラムのバグ、ミドルウェアの不具合、ハードウェア障害。
これらは様々なテスト手法で炙り出されるだけでなく、時に予測不可能な挙動を持って唐突にエンジニアを襲う。
自身の、チームの生産物であり、守るべき資産であるシステムが発した異常からは、おおよそ逃げる事ができない。
事象に関する調査は、その第一段階のアプローチであり、この深さが深いほど正確な判断材料となる。
解決への糸口だけでなく、原因が判明すればそれが人為的なものか、製品の抱えた問題であるのか、あるいは製品やプログラムの組み合わせによって生じた問題か、が明らかになる。
その問題を取り除くためのより良い、「設計」は何であるか。また、解決するためのアクションを「提案」する材料たり得るかは、この調査という行為によって導かれる。
基本にして最も重要なSEの能力だ。
設計能力
Infrastructure as Artという思想を提唱していて、インフラシステムは芸術的な美が必要と考えている。
システムは最終的に「運用」と呼ばれるフェーズに入る。システムが完成し、実用されている状況を指し、開発した側はそのシステム日々監視し、サービス提供に問題が生じていない事や、問題の予兆がないかのチェック、障害発生時にはその解消を行う。
運用を意識せずシステムを設計する人物や組織が稀に見受けられる。理由も明らかで、システム開発プロジェクト全体を通して、開発期間が長い場合、「運用」の開始は1年後であったりと少し未来なのだ。
今まさにシステムを構築しているエンジニアは、今目の前のタスクをこなす事に必死で、1年先を考えているかと言えばそうでない事も充分あり得る。
システムが完成すれさえすれば良い、と言う思考に陥ってしまうこともある。事実、運用と言うフェーズに開発者がフルで関わることは少ない。インフラの場合尚更その傾向が強く、先を考えずに不完全に作り上げてしまうことの要因の一つだ。
設計とはデザインを示す。一般的なシステム稼働期間は5年間。
5年も間、維持可能な普遍性をデザインし、システムに与えることを設計と呼ぶ。
100年、200年と受け継がれた絵画や彫刻の様な芸術品とは規模が違えど、ひとつの芸術として情熱を傾けるには、十分な運用期間だ。
提案能力
システムエンジニアに必要な能力の3つめは、提案する力だ。
仕事としてシステム構築を前に進めるためには、考えた内容を提案として伝える必要がある。
例えば、設計内容を練って、提案する。その設計内容にはどのようなメリットデメリットがあるか、それだけではなく、自分はなぜその設計内容を是としたのかを言語化し提案するのだ。
また、トラブル発生時にも提案する。例えば、調査の結果、原因はまだ不明で、回避策もあるとする。その時、システムを取り巻く他チームの状況を把握し、回避策をいつまでに行い、元々のスケジュールを変更し、根本原因を継続的に調査すべきだ。
と言った、提案をしなければ前に進まない。
ここで、多くの場合、誰かが決めてくれるはずだ、という思考が働く。他人任せにすることで、自分は与えられた作業だけすれば良いという考えに陥ることが多い。
システムエンジニアはコンピュータを操作することが多いがために、コンピュータと仕事をしていると錯覚しがちだ。
内にこもって仕事をしているようなエンジニアも多い。設計書を書き、コードを書き、バグ票を書き、テストを繰り返しているうちに、自分はコンピュータと仕事をしていると錯覚する。
コンピュータはツールであり、成果物である。
現実には、人と仕事をしている、ということを忘れてはならない。
身に付けた技術を利己的に発揮することも悪くない。しかし利他的に発揮できればなお良いエンジニアになるだろう。
苦労して身に付けた技術から得た知恵を、チーム全体を前に進めるために、提案という形式で伝えられることは、システムエンジニアとして最も重要な要素の一つだと考える。
なぜこの3つか
この3つ以外にもエンジニアの必要な条件はある。技術力であったり、自己学習する力、論理的思考能力などだ。
結果的にそれらのスキルといったものはSEになった時点で自然と磨かれていくのだが、条件として挙げたこの3点はマインドセットとして自己啓発のなかで取り入れていくものだ。
調査に対する傾倒性
これは仕事に関する問題解決の意識の高さによって優劣が発生する。
人によっては、調べて欲しいと頼んでも、調査を進めてくれないエンジニアもいる。調べたようで、サポートセンターに問い合わせただけであるとか、エラーメッセージが出ていました、という連絡だけで返してくるエンジニアもいる。
それは自分の仕事ではない、と言いたげな態度で。
なんのために仕事をしているのか、は人それぞれである。しかし、システムエンジニアであるからには、成果物はシステムであるべきで、システムが安定しなければその仕事の意味すら揺るがす可能性がある。
システムの安定を目指す同じチームメイトとして、調査に腰が重いというエンジニアは、同じエンジニアとして、距離を取らざるを得ない一因になる。
設計に関する美意識
先にあげた設計美とも、芸術家とも言える意識は、性格的に思考が向かない場合もあると考える。
要件定義されたものから設計していくわけであるが、部分的にアート思考の考え方を取り入れる。独創的で例のないアイデアが、それまでの形骸化したシステム設計に色を持たせるということはよくあることだ。
もちろん独りよがりの芸術がではいけない。調和の中で、改善すべき点があるならば、部分的に目を引くポイントとして取り入れるとよりよい設計となる。
誰も作ったことのないハードウェア構成の設計や、仮想化技術の新機能を絡めた設計内容の解説、システムトラブル時の改修内容など、独自に完結するドキュメントなどで効果を発揮する。
提案できない技術者
初級者であれば提案することが出来ないというのは自然でもあるが、問題は、初級者であっても、こうしたらどうか、といった類の提案は可能な点である。
専門的な技術を学ぶ過程で様々な関連技術に枝分かれして学びを深めるが、他の分野の技術の優れた点を、学習過程によって取り入れながら改善していくことは良い学習方法である。
尚且つ、実践的であり、例えばVMware社の仮想化技術の考え方を、Oracle VMの設計技術に応用することが出来る。仮想ネットワーク構成のパラメータなど、類似の構成にしても良い。
同じように、他ベンダーの類似製品同士の違いを学ぶことで、製品ごとの優劣があるポイントを把握しながら技術力を高めることが出来る。
これらの情報は充分に提案力になるのだ。
なぜこの設計なのか、なぜこの仕様なのかを考える際には、初級者ならではの考え方でも充分通用する。仕組みさえ知っていれば、条件を変えていくという提案は、パズルゲームと同じだ。
提案ができず、ただレールに従って速度を変更するだけでは、いつかレールが外れかけていても急停止する事はできない。
システムエンジニアとして、システムが危険に陥る可能性を未然に防いでこそ冥利である。
システムエンジニアを目指すかたへ
調べることが出来て、設計できて、提案できることが条件であると述べた。もちろん、何か一つが欠けていたらシステムエンジニアではないというつもりは無い。これらのどれかひとつに秀でていても良いし、どうしてもこの点が弱いといったポイントがあっても良い。
チームとして補うことが出来ればそれは問題ないし、プロジェクトでシステム開発を行うのはそういった理由があるからだ。
しかし、これら3つの重要な要素を理解しておく事は必要だ。提案は、上司にやってもらう、とか、設計は先輩エンジニアにやってもらう、など相互に補完し合う考えは社会として望ましい形態である。
自分ができる事は何か、を考えてみると良い。例えば、調査のためのログ収集や整理、メッセージの抽出や事例の整理など、できる内容は多くあるはずで、それもまたトレーニングである。
この記事が、自分が苦手なアクションを認識し、他者に協力を仰ぐコミュニケーションの一助として頂ければありがたい。
