前回はいかに SE が専門職として敷居が低いか説明しましたが、適正、つまり向き不向きがあるのも事実です。今回はどのような人が SE に向いているか触れたいと思います。
向いている人、向いていない人に触れる前に、SE の一般的なイメージに触れておきましょう。SE の一般的なイメージとして以下のようなものが当てはまるのではないでしょうか。
- 内向的で寡黙
- マニアックで何かを突き詰めることを好む（いわゆるオタク体質）
- 世間ずれしている（身だしなみ、流行に疎い）
- 頭の回転が異常に早い
- IT の知見がない人を見下す
ただの自分調べなので正確ではないのですが、一芸に秀でている分、変わり者で近寄り難い、みたいなイメージがあるかもしれません。これらに当てはまる人が実際多いことに間違いはありませんが、傾向として多いというだけで、実際は僕のような凡人が多いのも事実です。僕自身は上記のいずれにも当てはまりません。
これまで語り尽くされてきた、エンジニアあるある、みたいなことをここで言ってもあまり楽しませる自信もないので、ここではシステムエンジニアにどのような人が多いか、ということでなく、システム開発の現場で重宝される人＝向いている人、成果が出づらい人＝逆に向いていない人として説明していきます。
システムエンジニアに向いている人
- 気持ちが外に向いている
- 変化や失敗を恐れない
- 物事の真髄を理解し俯瞰的に捉えられる
- 当事者意識が強い
意外でしたか？一見するとこれらはどの職種でも求められる姿勢だと思いませんか。それぞれ解説します。
気持ちが外に向いている
ゲーム制作会社やサービスの提供元に勤めない限り、SE の仕事は誰かの業務をお手伝いすることにあります。そして娯楽を除き、すべてのシステムの目的は効率化です。まず、依頼者が何に困っていてどのように改善（効率化）したいかを知る必要があります。そのため優秀な SE がシステムを改修する場合、まずそのシステムが何を目的に、どのような背景で導入されたか、普段どのように利用されているか、どのような問題を抱えているか、などをシステム利用者の目線で情報を収集したうえ、理解します。そして現在上がっている要望に対する解決策などを勘案するのですが、これらは相手の立場になって考える必要があります。それが可能なのは相手を理解しようとする心です。相手に無関心ではできません。
これができない SEは（まあ、無数にいるわけですが…）利用者の利便性など考慮できず、要求もされていないような、例えばボタンのフォント（書体）に異常にこだわったり、滅多にないレアケースのために目が痛くなるような複雑なプログラムを書いたりするものです。
そして仕様の確認にやたら時間を使った割に（相互理解に努めないため、やり取りも輻輳しがち）、満足度の低い、最悪利用されないシステムを構築してしまいます。（利用されないシステムは親に見放された子供に似ています。本当に物悲しいものです）
変化や失敗を恐れない
一般的に言われる通り、IT の進歩は日進月歩です。この業界では変化が前提ということです。それを受け入れられない人は茨の道を歩むことになります。また、変化には失敗がつきものです。
巨大な帝国となった GAFAM[1]GAFAM（ガーファム）：アメリカ、ひいては世界に絶大な影響を与える IT 企業 5強。Google、Apple、Facebook、Amazon、Microsoft の略もはじめは数人で起業して、笑われたり、挫折を繰り返しながら現在の地位を築き、文字通り世界を変えました。失敗は成功の母といいますが、これは原則です。失敗しない人生はありません。適度に失敗して上手に成長し続ける人材が求められます。重要なことは、同じく原則である、現状維持は衰退ということをよくよく理解するということです。これは人生そのものと言えるのではないでしょうか。
自分を刷新し続ける人は柔軟で、目的意識或いは達成思考が強く、常に成長を意識し、それを組織に伝搬します。成長する組織には必要不可欠であり、システムの成長に、成長する組織もまた必要です。
物事の真髄を理解し俯瞰的に捉えられる
古い話があります。出典が思い出せないのですが、もしかしたら最近の SE は知らない人も多いかもしれません。
とあるシステムのクライアントが開発チームのフロアを訪ねて、
「この画面を金色にしてくれないか」
と言ったそうです。それを承諾した開発チームは試しに画面を金色にして、後日クライアントへ持っていきました。するとクライアントは
「次は画面を赤くしてくれ」
と言ったそうです。画面を赤くして持ってきた開発チームにクライアントは
「次は青くしてくれ」
と言いました。これを繰り返すうち、一通りの色を試しましたが、クライアントは納得しませんでした。考え込むクライアントと開発チームが沈黙を守っていると、そこに開発チームの責任者が出張から帰ってきてこれまでの経緯を聞きました。責任者は少し席を外して戻ってくると、問題の画面の文字を少し大きくしてクライアントに見せました。クライアントは言いました。
「これでお願いしたい！」
クライアントは画面を見やすくしたかっただけ、ということです。ちょっと極端な話ではありますが、ポイントとして、
- クライアントが自分の要求を理解している（正しく伝えられる）とは限らない。
- 開発者はクライアントの要求を理解することに努める。そのため相手が何を要求するか、何を要求し得るか考え、ときには提案する。
ということです。最終的に業務もシステムもわかる開発責任者がまたたく間に解決しているのが象徴的なお話です。システムの中身だけ知っていてもそれが動きとして正しいかは、エラーとならない限りわかりません。望ましいかどうかに至っては絶対にわかりません。システムがサポートする業務そのものへの理解が不可欠です。優秀な SE はこれが可能です。
そして業務の理解についてはプログラムを書くことに比べれば難しいことではありません。そのうえで（不思議なことに）SE はシステム以外のことは理解したがりません。そこで物事を俯瞰してシステムに適用できる人が重宝されるのです。
当事者意識が強い
別の記事でも言いましたが、最終的に動くモノを作るのはわれわれ SE です。後ろには誰もいません。厳密にはチームで作業するのでまったくサポートがないわけではありませんが、誰かが作ったプログラムを1行1行見聞することができる、充分な時間が与えられる機会は稀です。レビュー[2]レビュー（review）：別の担当者がプログラムの中身を見たり、実際に動作させて問題がないか確認する工程をするにしてもレビュア[3]レビュア（reviewer）：レビューをする担当者のこと。レビューを受ける（＝プログラムを書いた担当者）はレビュイ：reviewie と呼ばれるだって人間なので見落することもあり、そもそも仕様を知らずにレビューすることもあるため、万能ではありません。
最終的にプログラムに責任を持つのはプログラマ、SE 本人です。レビューが完了したらその後幾つかの試験を受け、本番[4]本番環境：実際にサービスを利用者に公開する環境のこと。商用とも言うで稼働することになります。おかしなところは開発の段階で排除しなくてはならないのです。
そして残念なことにプログラムはほんの一文字誤っていても正しく動作しません。真面目な SE はこの重圧に耐えられず、脱落（急に来なくなる）することがありますが、その場合その重圧は別の担当に移行されます。実際、いい加減に作ってバグを仕込むと場合によっては大惨事になりかねません。
どんな状況でも、顔も見たことのない利用者に向けて、品質の悪いものを提供しない、使えるものは親でも使い、納期と品質を守る、この姿勢がどこでも重宝され、それがまた別の仕事を生み出します。利用者が思いもつかなかった斬新なアイディアが生まれるのも当事者意識のなせる技です。当事者意識の尊さは後天的に養いづらいという点にあります。いわゆるサービス精神のようなもの、個性に関わってくるためです。
誤解を恐れずに言ってしまえば、IT 技術と言ってもただのツールです。事業を成功させたいという然るべきマインドが下敷きになって真に活かされるものです。使い方が重要だということです。
IT のリテラシーが全国的に高まる現在で、プログラムが書けるというだけで SE の価値を不動のものとして保つのは難しいと思います。プログラミングスクールも活況な昨今、そしてプログラムの義務教育化が進むと SE のアイデンティティはさらに縮小され、何かしらの変化が余儀なくされていくでしょう。このような背景と現場での感覚として、今後はベースとしてソフトスキルや良質なマインドを携えた SE の需要がさらに高まっていくと考えられます。
おっと、結構長くなっちゃいましたね。向いていない人編はまた後日とします。
脚注
