「優秀なSEの条件とは？」、このシンプルな問いに含まれるもの

「優秀なSEの条件とは、なんだろう？」
システム開発に関わる会社、もしくは人であれば、一度は考えたことがあるのではないだろうか？
もしくは、仲間と酒を酌み交わしながら、議論にふけった経験がある方もいることと思う。
シンプルな問いではあるが、それゆえに、「優秀なSEの条件とは、なんだろう？」という問いの答えは悩ましい。
筆者が、ある先輩SEから教えられた「優秀なSEの条件」をもとに、この問いを考えてみたい。
 

「客たらし」なSE

筆者は、かつてIBMのグループ企業にいた。
Webアプリケーションの開発を担う、いわゆるLAMP※な会社で、営業でありながら、PM的な役割を担っていた。（LAMPという言い方も、もはや郷愁感が漂うけれども・・・)
それは、女性の先輩SE（仮に、「ひろみ女史」としておこう」）と雑談をしていたときだった。
彼女は、同じSE仲間（仮に、「たなかさん」としておこう」）を褒め始めた。
「たなかさんって、本当に優秀なSEだと思わない？」
僕はプラグラミングのことはよく分からないが、たなかさんは、確かにある部分、ずば抜けたSEだった。
システムの勘所と言うべきか、お客様の勘所と言うべきか・・・
「お客さんが欲しがっているのは、これだよね！」というポイントを抑えるのが、実に巧みなのだ。たなかさんの強みが特に発揮されるのは、要件定義においてである。要件定義をしながら、「でしたらコレコレこういう機能を追加しましょうか？」と提案する。
これが、実に感心するぐらい、お客さんのツボを突く。
だから、お客さんが、良くも悪くも、皆、たなかさんのファンになってしまう。
たなかさんは、「女たらし」ならぬ、「客たらし」なSEだった。
「いや確かに、あの提案力と発想力はすごいと思いますけど・・・。でも、バグが多すぎですよね？」
テストのたびに、バグの多さに辟易していた私は、指摘した。
そう、たなかさんは確かに「客たらし」で優秀なのだけれども、肝心のプログラミングは、バグが多すぎた。コーディングは早いのだが、粗いのだ。
愛嬌はあるけど、SEとしてはどうなの？
そういぶかる私に、ひろみ女史はうなずきながらも、こう続けた。
※LAMP
Linux、Apache、MySQL、そして、Perl、PHP、Pythonに共通する「P」の頭文字を並べたもの。これら、OpenSource系の環境や言語で開発するシステム開発会社を指す。
 

プログラムの中にある「遊び」

「確かに、あのバグの多さは、困ってしまうけど・・・」
たなかさんのバグ対応に、もっとも手を煩わされているのは、ひろみ女史本人だ。
「でも、たなかさんのすごいところは、提案力ではなくて、プログラムに持たせた『遊び』なのよ」
 
「遊び」？
原則として、プログラムは最短経路を目指すべきだと、彼女は言う。
回り道をすれば、プログラム文は長くなる。あくまで一般論ではあるが、長くなればなるほど、処理に時間も掛かるし、バグ発生の可能性だって増えてくる。
だが、最短経路で書いたプログラムには、拡張性がない。
システムというのは、作ったらそのまま・・・、ということはあまりない。何かしら、バージョンアップであったり、機能拡張が行われる。それは、特にビジネススピードの早いWebアプリケーションに関しては顕著だ。
最短経路で書かれたプログラムの場合、例えば機能拡張の際に、最悪プログラムをゼロから書き直さなければならないケースも出てくるのだ。
だから、優秀なSEは、プログラムの中に「遊び」を設けておく。
お客さんを診て、システムを診て、そしてシステムが関与する、ビジネスモデルの将来を予測して、バージョンアップや機能拡張をやりやすいような回り道、すなわち「遊び」の部分を、予め設けておくのが、優秀なSEの素養だと、ひろみ女史は言うのだ。
「たなかさんは、『遊び』の設け方が、絶妙なのよね・・・」
 
SEにとって、バグを出さないということは当たり前のことだ。
いわゆる、「早い、上手い（間違いがない）」というのは、一定のレベルに達したSEとしては当然の素養である。
だが、「遊び」というのは、教育などによって、SEに身に付けさせるのは、なかなか難しい。本人がもともと備えてきたセンスも必要となってくる。
バグの多さに目をつぶったとしても。
ひろみ女史は、たなかさんの「遊び」のセンスを認めていたのだろう。
 

観察力と洞察力

少し話がずれるのだが。
私の父は、ある化学工業系の企業に勤めていた。
父は、文系の出身である。しかも、ずっと営業畑一筋だった。
そんな父が、ある日、工場の所長を任じられた。
工場長になってしばらく経った頃、私は父をからかったことがある。
「化学なんてぜんぜん分からないのに、所長になっちゃって。製造現場のことなんて分からないし、どうせお飾り的な仕事しかできないでしょう？」
父は、苦笑いしながら答えた。
「たぶんな、会社もそう思っていたかもしれないな。
でもなぁ・・・、不思議と分かるんだよな、現場主任らの報告を聞いていると、『あっ、こいつ嘘ついてる！』とか、『なんか怪しいぞ！』ってな。
周りの連中も、驚いているよ」
学生であった当時（しかも、専攻は工業化学だった）、私は、父の言葉を強がりと感じていた。が、たなかさんと仕事を共にするにつれて、父が診ていたものが、私にも分かってきた気がする。
ふたりが備えていたのは、観察力であり洞察力なのだろう。
父は、部下たちを日頃から観察することによって、当人たちが気づかずとも犯した発言や行動の矛盾やごまかしを洞察することができたのだと思う。
一方、たなかさんは、クライアントである企業や、その企業内でカウンターパートナーとなる方々を観察することで、クライアントが求めるであろうシステムの将来像を洞察した。
当たり前だが、ビジネスは人が創るものである。
そして、SEが作り出すものは、ビジネスの一部として利用されるものだ。
だとすれば、SEは、プログラムのコーディングを介して、ビジネスと、それを創る人々を見つめなければならない。
確かに、観察力と洞察力は、優秀なSEが備えるべき条件のひとつであろう。
 

優秀なSEの条件とは？

勘違いしないで欲しいのだが、私は、ここに挙げた、たなかさんのようなSEが最強のSEだとは思わない。
優秀なSEの条件は、置かれた環境によって変わるものだ。
例えば・・・。
ソフトハウスにおいて、たなかさんのような自由気ままなSEは、ある意味危険分子とみなされてしまうかもしれない。良かれと思い、勝手に要件定義書にない機能などを追加されては、会社の信用に関わることもあるかもしれない。
運用保守系のSEとしても向かないだろう。なにせ、バグは出しまくるくせに、お客さんに対し提案ばかりするのだから、「あいつは口ばっかり達者で・・・」と敬遠される可能性もある。
たなかさんの強みが活きたのは、比較的早いサイクルで、ビジネスのアップデートを図らざるを得ない、Webアプリケーションの世界だったからだ。
 
では、あなたの会社であり、あなたのビジネスにおける優秀なSEの条件は、なんだろうか？
この問いに、即答できるシステム開発系企業のSEは、きっと優秀だと思う。
逆に、回答に迷う方、もしくは企業は、少し問題があるかもしれない。
SEに限らないが。
自社の人材に求める素養は、企業のビジョンが反映されるべきだ。
あなたの企業が求める、「優秀なSEの条件」が診えていないのであれば、それはビジョンのブレイクダウンが十分ではないことが原因ではないだろうか。
 
「優秀なSEの条件とは？」
このシンプルな問いには、さまざまな学びと気づきが含まれている。
あなたの企業は、どうだろうか？