とある元SEの思考を探る

ひょんなことからとあるICT企業ではたらくことになったなんちゃって元SEがしたためるブログ。主に、政治・経済・社会問題・日常の出来事について発信していきます。お読みいただけたら、感動にむせび泣くほど嬉しいです。よろしくお願いします。

スポンサードリンク

早稲アカのキャッチコピーに見る危うさ

「天才はいない」

女優、芦田愛菜さんを起用した早稲田アカデミーの広告のキャッチコピーだ。

 

私は、「天才はいる」と考えている。

身近なところから、報道でしか知らない人まで、天才を見てきた。

 

天才の定義とは何か。常人ではなし得ないことをなし得る人のことだと定義したい。

では常人とは何か、という定義に関しては明確にしないが、少し具体的な例を挙げてみたい。

 

例えば、オリンピックで金メダルを獲得できる人はごくわずかだ。この世の中の大多数は、オリンピックで金メダルをとることができない。私は、オリンピックで金メダルを取ることができるような人は天才だと思う。

もし、オリンピックで金メダルをとった人が天才でないと仮定するならば、私のような常人でもオリンピックで金メダルをとることができることを意味する。つまり、誰でもとれることになる。しかし、オリンピックの金メダルの数は決まっているから、誰でもオリンピックの金メダルを獲得することはできない。したがって、オリンピックで気メダルをとることができる人は天才である。

そもそも、一度冷静になって考えてみよう。誰もが皆できるのであれば、それに対して価値はあるのだろうか。多くの人がなし得ないから皆賞賛するのであって、天才と讃えるのである。価値があるのである。

私は多くの人ができないことを達成してしまう人を天才と呼びたい。

 

結論から言うと、「天才」の定義とは何かという問題に落ち着くのだが、ここでは上記のような定義で話を進めたい。

 

少し、私が見てきた天才を挙げて見たいと思う。

身近な例だが、高校3年生の時のとある河合塾の模試。物理の問題で、高校ではまだ習っていない分野の大問が出題された。電磁気学か何かだったように思う。私は、まだ習っておらず分からないので、解くのを諦めた。しかし、同級生は、なんと6〜7割解いてしまったのだ。同じ物理の授業を受けてきたにもかかわらず、その同級生もまだ習っていないにもかかわらず解けてしまうのだ。

話を聞くと、「ここはこうに決まってるじゃん」と言う。物理は、過去の偉人たちが見つけた法則を元に問題をとく。つまり、その同級生は、その法則を考えて解いてしまったのである。確かに、模試の問題なので、何もないところから法則を見つけるよりは、簡単かもしれない。しかし、翻って考えてみれば、アインシュタインであれ、ファラデーであれ、ボルツマンであれ、過去の偉人たちは物理法則を実験的あるいは理論的に導き出したわけである。だからこそ、後世にまで語り継がれる天才なのである。

この世の中の誰もが努力をすればアインシュタインになれると言うのであれば、冒頭の学習塾はその証明をしてほしい。

 

私がキャッチコピーをつくるならば、「天才はいる。しかしあなたは天才ではない。」あたりだろうか。

なぜなら、本当の天才ならば、こんな広告には微塵も見向きもしないからだ。この広告に少しでもピンときた人は天才ではない。

天才はいると言うことを認めた上で、天才ではない自分はどのようにこの世の中を生きていくかという方がよほど現実的で建設的ではないだろうか。

 

私は、自分ができる精一杯の努力をしても勝てないと思う人に何度も出会ってきた。勉強しかり、スポーツしかりである。その絶望たるや底はなく、沈んで沈んで沈みきって、浮かび上がってこなくてもいいと何度思ったことだろうか。

それでも私がこうして生きていられるのは、もし自分がこの世界で生きられないのならば、自分と同じような境遇の大多数の常人も生きられないと言うことを意味する。それはつまり、人類が種として繁栄できないこと意味する。現実は、人類はこうして男性35億、女性35億(概算)いて、繁栄していると言っていい数値であろうから、自分のような常人でも息を吸って良いことなのだろう。

こうして、自分の能力では到底追いつけない天才に出会い、絶望を見ながらも粘り強く生活していく。これこそが、天才ではない私あるいは私たちの取るべき戦略なのではないだろうか。

 

改めて考えてみよう。メダリストが金メダルを取って賞賛されるのは、そして、アインシュタイン相対性理論を発表してノーベル賞を与えられるのは、我々のような常人に成し遂げられなかったことを成し遂げたからである。

だからこそ常人には、価値があるのである。メダリストは多くの人に感動を与える。科学者は発明で生活を豊かにする。常人はその恩恵に被るだけだ。多くの人は世の中をわずかにしか豊かにしない。天才たちの功績で割ったら0になることもあるかもしれない。それでも、皆生きているのである。何の役にも立たない自分が生きているのである。私は、それだけで価値のあることだと思う。少なくともそう思わないとやっていけない世の中である。

 

「天才はいない。だからあなたも努力すればできる!」という言葉にどれだけの人が苦しめられてきただろうか。「諦めなければ夢は叶う」といったメダリストもいた。そんな成功者たちの言葉の呪縛から常人は解き放たれるべきだ。

 

あなたは天才ではない。

 

でもあなたには価値があるのだ。

私が思う「尊敬」できるエンジニアについて考えてみました

尊敬できるエンジニアはどういうエンジニアかを考えてみました。

私は、エンジニアの判断する上で、知識・スキル・人間性という3つの軸で判断することが多いです。

 

しばしば、知識とスキルの違いが曖昧になりますが、私が思う「ある技術に対して知識がある」とは、「ある技術を使って動くものを作れる」ということを意味します。経験を積めば、様々な技術に触れる機会が多くなるでしょうから、それだけ知識は増えます。概ね、知識とは経験に比例するものだと考えています。

一方、スキルとは、知識を前提として、より良い設計でアプリケーションを作れる度合いだと思っています。例えば、Railsで言えば、controllerにゴリゴリ業務ロジックを書いて動くものを作ることはできます。しかし、より良い設計という観点から言うと、業務ロジックはなるべくmodel側に寄せて、controllerの役割とmodelの役割を明確にし、複雑な業務ロジックをmodelの単体テストで担保できるようにするのがベターと言われています。もっと良い設計があるかもしれませんが、controllerに業務ロジックを書くエンジニアとmodelに委譲するエンジニアであれば、後者の方がスキルのあるエンジニアと言えると思います。

人間性とは、一緒に働こうと思うかどうかです。例えば、同じ会社に勤めていても、頭ごなしにあれやれこれやれ、このようにやれと言ってくる人とは一緒に働きたいと思わないでしょう。一方、「こんなことがやりたいんだけど、手伝って欲しい。。何かいいアイデアはないかな。一緒に考えて欲しい。」と言われるほうが、(少なくとも私にとっては)気分良く仕事ができます。人間性に関しては、個々人に大きく影響するので、私が働きたいと思う人が他の人とって違うかもしれませんので、個人差があるところだと思います。

 

そして、私にとって、尊敬できるかどうかは、「スキル」と「人間性」に大きく依っているのではないかと最近思い始めました。知識が豊富でも保守・運用性のことを考慮せずとりあえず動くものを作るというのは職業エンジニアとして失格だと思います。より良い設計というのは、保守・運用性の高いというのもその要素の一つに挙げられます。

「動くものを作る」というのは、勉強すればできることです。スキルも、勉強すれば向上することですが、動くものを作れたということに満足してしまう場合は、おざなりになってしまうところです。一歩高みを目指すエンジニアにとっては、動くだけに満足せず、どうすれば他の人でも保守しやすいコードになるか、自分以外でも読みやすいコードになるかというのを考えるのは、プロフェッショナルとして尊敬できる点でしょう。

 

ここで、もう一度スキルについて深掘りをしてみたいと思います。

現場では、とにかく早くリリースすることを求められることが多々あります。そのような状況では品質がないがしろにされる場合があります。スキルのあるエンジニアは、それでも、できる限り品質の担保に努めます。つまり、ここのテストコードは今は書く余裕がないけれども、テストがしやすいように、メソッドを少し細かく分け、役割を明確にしておこうとか、ビューに関係のあるコードだからモデルではなくプレゼンテーション層に入れようなど、そうした設計です。フレームワークやライブラリを作るのならともかく、わかりにくいメタプログラミングを多用しないといったことも大事かもしれません。if文を何度もネストしなければならない状態になったら、何かが間違っているかもと思って少し立ち止まって設計を見直すということもするでしょう。

そうした様々な設計を考慮しその上でかつ、超速ですべてのメリットデメリットを考慮してその時点での最適な設計を瞬時に導き出す。さらにその過程も何らかの形で素早く後世に伝えれるようにする。この速度もスキルのあるエンジニアと言えると思います。

本当にスキルのあるエンジニアなら、テストをも求められる短納期で書き切るでしょう。

 

知識は時間をかければ誰しもなんとかなると思います(動くものは作れる)。

しかし、スキルに関しては頭の回転の速さも求められるところです(私にはムリ…)。だからこそ、スキルがあるエンジニアを私は尊敬したくなるのだと思います。

人間性についても、一緒に働きたいかというのも重要な要素です。高慢な態度の人はやはり苦手です。

だから、私は、知識よりも「スキル」と「人間性」が大事だと思います。経験の少ないエンジニアは知識が少ないのはある意味やむを得ません。あらゆる言語に精通して、インフラもフロントエンドも詳しくなるなんていうのは1年で身につけるのはムリだからです。しかし、その中でも常に向上心を持ち、周りのことを考えてコードを書く。これを地道に継続できるエンジニアはたとえ知識が少なくても尊敬できます。

 

今回も、自分への戒めの意味を込めて、もっともっと自分を磨いていきたいという思いを込めて、書かせていただきました。

ここまで読んでいただき、ありがとうございました。

 

関連記事

smartenergy.hateblo.jp

エンジニアがもつべきは「思いやり」ではないだろうか

最近、常々思うことがあります。

Webエンジニアに必要なのは、思いやりなのではないだろうかと。

 

エンジニアはつねに改善するように常日頃から心がけることが必要な職業です。だからこそ、エクストリームプログラミングスクラムといった手法が考案され、実行されているのだと思います。

スクラムのふりかえりには、KPTといってよかったこと(Keep)、問題点(Problem)、改善したいこと(Try)を振り返ります。社会人1年目が習うPDCAサイクルを回すといったことに近い事象でしょう。

その中で、今日は、思いやりにかかわるWebエンジニアがやるべき3つのことを述べたいと思います。

 

1.テスト

エンジニアはテストを書きます。これは、昨今は当たり前となっていることです。「テスト書いてないとかお前それ@t_wadaの前でも言えんの」などと言われるこのご時世。テストのないシステムは、自ら破滅へ向かいたいのかと言わんばかりの自殺行為とも言えます。

しかし、中には様々な事情をつけて、テストを書きたがらないエンジニアもいます。その理由は様々です。「リリース優先で時間がなかった」「動作確認しているからテストはいらない」などやらない理由はたくさん出てきます。

私は、テストは必ず必要なものだと思います。いちばんの大きな理由は、このシステムが自分の手から離れたとき、後から参画するエンジニアの開発効率に大きく影響するからです。

テストは、いわば仕様書といって過言ではありません。後から参画するエンジニアは業務要件がわかりません。ソースコードを読んだり、業務がわかるエンジニア、サポート、経理等々に聞いて要件を理解していきます。その大きな手がかりとなるのがテストです。不具合があって初めてコードを見るということは良くあります。その時にそのケースが事前に考慮されていたものなのか、意図したものなのかということは、理解する上で、そして修正する上で大きな手がかりとなります。意図しているのであれば、そもそもの実装が間違っていたということですし、意図していないのであれば単純に考慮漏れということもありうるでしょう。それを開発した前にいたエンジニアがどこまで考慮したかを知ることは、当時の開発の様子を把握する上で非常に貴重な資料となるのです。

それだけではありません。多くのソフトウェアは、常に修正が繰り返されます。後から参画したエンジニアは自分がした修正が既存の仕様を破壊していないかに常に気を配らなければなりません。自信を持てなければ、開発なんてできませんし、破壊しないようにするために冗長なコードが多数生み出されることもあります。そうすると、保守性が著しく低下し、同じ内容の修正をしなければいけない箇所が複数存在して不具合の温床となります。後世のエンジニアが自信をもって機能開発するためにも、テストは必ず必要なものなのです。

テストに関して、必要性を2つほど述べました。まだ他にもあると思いますが、一旦ここまでにして、この2つに共通することは何かを考えてみます。

それは「思いやり」です。最初に作った人がいなくても、後から入ってきたエンジニアは、テストによって仕様が理解でき自信を持って開発ができます。会うかどうかわからない人に思いを馳せ、テストを書くのです。

なぜソフトウェアを開発するのでしょうか?それは、ユーザーに価値を提供するためでしょうか?私は、違うと思います。いっときだけ価値を提供すれば良いのではありません。ソフトウェアによって、ユーザーに価値を継続して提供し続けるのです。いっときであれば、なにもシステム化する必要などないのです。ユーザーに価値を提供し続ける。これが、経営陣も望むことでしょうし、ユーザーが望むことでしょう。それこそが私の思う思いやりです。

 

2つ目は、コードの品質です。

私が仕事で使っているRuby on Railsであれば、Rails newと同時に行うことの一つにGemfileにrubocopを入れ、.rubocop.ymlを置くということがあります。rubocopは、コードの静的解析をしてくれ、コードに改善すべき点があれば、指摘してくれます。また、CodeClimateというサービスを使ってソースコードの品質を評価してくれるサービスもあります。こうしたツールを使うことで、テストコードと同様に不具合の芽を摘むことができます。品質が良いコードというのは、保守・運用性に優れたコードであるとも言えます。

こうしたツールを利用することは、技術的負債を後世になるべく残さないようにという意図が明確になります。ソースコードは生まれた瞬間から多かれ少なかれ技術的負債となります。それをなるべく軽減しようとする意識は、後から参画したエンジニアからみれば、とてもありがたいものと言えます。

例えば、100行ぐらいあるメソッド(関数)と遭遇したらどう思うでしょうか?

1行に1000文字ぐらい書かれていたらどうでしょうか?

if文が10回ネストされたコードを見たらどう思いますでしょうか?

それを見た瞬間にまともなエンジニアならば拒絶反応を起こすと思います。これを書いた人は、これを読んだ人がどう感じるかを考えなかったのだろうかと思ってしまいます。

上記に挙げたツールでは、こうしたとんでもないコードに対して警告を発してくれます。静的な解析であるにせよ、警告は、統計的に不具合が起こりやすかったり、保守・運用性の観点から一般的に許容されない箇所に対して行われます。

後世のエンジニアが読んで拒絶反応を起こさないようなコードをを書くためにも、品質を向上させるためのツールの利用は、リポジトリを作成した直後から利用する必要があるでしょう。これも思いやりがあれば、自然と行うことでしょう。

 

3つ目は、コードレビューです。

信じられないことに、世の中には、コードレビューなしでリリースされるコードがまだまだあります。

第一に言いたいのは、エンジニアはコードレビューなしでリリースしても良いと絶対に思ってはいけないということです。エンジニアとはそういう職業ではありません。人間は間違える生き物です。それは古今東西当てはまる真理です。

そうした前提に立てば、その間違いをいかに最小限に留めてリリースをするためには、コードレビューは不可欠です。前述のテストコードを書くことや解析ツールを利用することも間違いを未然に防ぐための方法の一つですが、コードレビューも同様です。静的解析では発見できないミスや業務知識が必要とする箇所などは、レビューによって発見しえます。

そして、コードレビューにおいてもう一つ重要なのが共有です。システムは1人で作るものではありません。自分のプライベートなプロジェクトである場合を除き、システムは複数で作り上げるものです。コードレビューをすることで、知識の共有することができます。

エンジニアの中には、1人で作り、他の人に共有しない人がいます。いわゆる属人化です。これはエンジニアに限った話ではないかもしれませんが、仕事を他人に教えず自分しかできないようにして自分の存在意義を高めようとする人は一定数います。そうした属人化は、百害あって一利なしです。もし、1人しかできない仕事だとしたら、その人がいなくなったらどうなるでしょうか?その業務が滞ってしまいます。それは会社にとっては大きなリスクでしかありません。そして、そのような社員はそうしたリスクを考慮しないという点でプロとは言えません。プロフェッショナルは常に様々な状況に対応できるように準備をします。その一つが業務知識の共有であり、エンジニアにとってはコードレビューがその形態の一つです。

人は突然いなくなります。交通事故かもしれません。急に病に侵される場合もあるでしょう。身内の突然な不幸で、1週間出社できないということもあるでしょう。本人が健康でも、他のことで仕事に打ち込めない場合は十分に考えられるのです。

共有ができていれば、仕事ができる状態であっても、他のタスクで手一杯で、他のメンバーの方が余裕があるのであれば、その人に任せることも可能になり、より柔軟なチームを作ることができます。

これも全て「思いやり」があれば容易に想像ができることです。会社への思いやり、経営者への思いやり、突然任されることになるかもしれないまだ見ぬあなたへの思いやり。

 

エンジニアは、すべからく「思いやり」を持つべきだと私は思います。

それがエンジニアとしての矜持なのではないでしょうか。

自分への自戒も込めて。

 

本日も、ここまでお読みいただき、ありがとうございました。