言われたとおりにやるエンジニアは二流

依頼者から言われた通りのものを作る。と言えば一見問題ないように感じますが、ただ言われたとおりにやるだけでは、それはソフトウェア開発エンジニアとして二流だと思ってます。

仕事の依頼というものは、それ自体が依頼者の本当に欲しい物を示しているのではありません。依頼者が、欲しい物を伝えようとして表現した結果が仕事の依頼なのです。そこには依頼者が表現する際にどうしてもズレや抜け漏れが生じていると考えなければいけません。

だから、依頼を受けたエンジニアとしては、依頼通りのものを作る事を目指すのではなく、依頼を通じて依頼者が本当に欲しがっているものを推理し、依頼をチューンナップしてあげる必要があります。

上記の話は、ソフトウェア開発においてウォーターフォール型開発だと要件定義の段階で実際によく言われる話です。しかし、ウォーターフォール型開発のように、ステップが明確に分かれていない開発が多くなっています。アジャイルや、それに類似した開発手法では、要件定義・設計・実装は明確に分かれておらず、担当者も同じだったりします。僕が関わっているプロジェクトもそうですね。

そうなると、より担当者の判断が求められるようになってきます。ウォーターフォール型開発だったら、要件定義の段階で全ての仕様について依頼者の同意を得てから次のステップへ進むという方法でしょうが、アジャイルや類似した開発手法の場合そうは行きません。そもそも仕様はどんどん変更されるのが前提ですから、担当者自身が判断して実装して実際に動く状態まで作って依頼者に見せてしまえばいいし、それしかないのです。

今後ますます、言われたとおりにやるエンジニアよりも、言われたことを上手に解釈して意図を汲み取り、実装まで行って動く形にして、依頼者を満足させられるエンジニアが評価されていくでしょう。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。

SQLを久々に直接書いてWeb開発者として思ったこと

久々にSQLを直接書きました。とうのは、最近はORマッパーを使うことが多くて、直接SQLを書くことがめっきりなくなっていたからです。しかし今回は既存のコードに手を加える作業をするという状況で、既存のコードがORマッパーなど使用していないコードだったものですから、SQLを直接書くことになりました。

別にDBの専門家ではないので、パフォーマンスのチューニング方法などはあまり詳しくありません。もちろん速度は考慮して書きますが、それは基本的な部分であって、高度なチューニング（例えばDBMSの種類ごとの最適化やストレージエンジンごとの違いの考慮など）はできません。

とは言うものの、そこまで高度なチューニングが求められる場面は、Webアプリケーションにおいて少ないですし、今後も少なくなっていくように思います。基本的な原則（例えば、不要なレコードは取得しない＝WHERE句でなるべく絞り込む、など）に則っていればよいと思います。以前はSQLの方で最適化しなければならなかったようなパターンも、DBMS自身の進化によって高速化している例もありますし。

Web開発者としては、そもそもSQLをチューニングしなければならないようなDB構成を避けるという方向性の方がよいような気もします（既存のシステムだとそうも行きませんが、そこはDBの専門家の出番でしょう）。

ということで、Web開発者の自分としては、SQLについては今後も基本的な原則は学んでいこうと思いますが、DBMSの種類ごとの最適化やストレージエンジンごとの違いの考慮といった事項は、DBの専門家にまかせておこうと思っています。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。

システム構築に必要な「統一性のセンス」

エンジニアとしてITシステムの構築を生業とするにあたっては様々な能力を必要とされますが、中でも重要な能力だと思っているのが「統一性のセンス」ですね。

これは、直接ユーザの目に触れるユーザインターフェース（UI）についても言えることですし、直接ユーザの目に触れないプログラミングやデータベース構造といったものについても当てはまることです。

例えばUIについては、ボタンの配置の方向や順番や色、アイコンの形、語彙表現など様々な要素について統一性を持たせることが、使いやすさに大きく影響します。

プログラミングについても、変数名・クラス名・メソッド名などの命名規則、論理的構造のパターンなどに統一性を持たせることで、バグの低減やメンテナンス性の向上を図ることができます。

システム構築には美的センスが求められる、と言う場合、その多くは「統一性のセンス」を意味しているのです。なぜなら、統一性のあるUIやソースコードは美しいものだからです。芸術作品では「混沌のセンス」も美的センスとしてアリなのでしょうが、システム構築にはありえないですからね。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。

オープンソース時代こそ「コメント力」を

オープンソースとしてソースコードが公開されているソフトウェアを仕事で使ってたりするんですが、その際にソースコードを読み込んで目的に合わせてコードを追加したり改造したりするんですよね。で、何が一番大変かって言うと、そのソースコードを書いた作者の"意図を読み取ること"です。

プログラムの動作自体はソースコードそのものを読めば分かります。ただ、この変数をここで加算して、この関数に引数として渡して・・・といったプログラミング言語の処理自体は分かっても、そのソースコードが"何を目的に書かれているのか"が分からなければ意味がありません。

結局、ある一部分の動作がどういう意味を持つのかを知るために、関連するソースコードがを読み漁り、相当広い範囲を調べてようやく分かったりします。ただ、そこまで時間がかかるのには理由がありまして、ソースコードに"コードの目的・意図を記述した"コメントがほとんど無い場合にそうなるのです。

前にも書きましたが、ソースコードを読めば分かるってのは嘘ですからね。プログラムの機械的動作は確かに分かりますが、コードの目的や意図まで読み取るのは簡単ではありません。もちろんソースコードの関連する部分を含め広い範囲を読めば見えてくるのですが、しかしそれもどうなんでしょうか。

やはり、オープンソース時代であるからこそ、ソースコードを読む人に対する配慮は大切だと思うし、だからこそ、コードの目的や意図を分かりやすく記述できる「コメント力」が大切だと思うんですよね。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。

プログラミング言語のバイリンガル以上を

現在僕が関わっているプロジェクトは1つはRuby、もう1つがPHPをメインの言語として採用しています。自分自身の経験としても、PHPとRubyは得意とする言語なので両方とも言語を使うこと自体に苦労はありません。その他にもJavascriptは両方のプロジェクトで多用していますし、補助的にPythonも少しだけ使っています。あとは汎用言語ではありませんがシェルスクリプトも駆使します。HTML・CSSの知識は言うまでもありません。

実際プロジェクトの開発を進めてて思うんですが、２つ以上の得意な汎用言語を持っておくと色々メリットが有るんですよね。別にRubyとPHPじゃなくてPythonでもC#でもJavaでもPerlでも何でもいいんですけどね。とにかく2つあれば、色々比較ができるわけで、両方の言語を実際に使って開発した体験・経験を比べることによって言語の特徴が体感覚として分かるわけですよ。

例えば片方の言語で慣れたやり方を、もう一方の言語で実装しようとした時にすんなり行かないことがあったら、そこで言語の強みと弱みが分かります。また、そこでもう一方の言語で実装するときの最適解を考えますから、これも力になります。

それに、複数の言語での実装を知っていると、より汎用的なロジックを考えられるようになります。特定の言語に依存したロジックではく、別の言語でも問題なく実装できるようなロジックを考える傾向がつきます。その方がバグも出にくく、品質の工場にも寄与すると考えられますね。

ともあれ、プログラミング言語はバイリンガルになっておくと色々得をします。もちろん2つに留まらず、3つ4つと大いに越したことはありませんが、まずは2つを目指すとよいでしょうね。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。

ボツになるコードを書く勇気

仕様書通りに動くプログラミングをするのが
我々ソフトウェア開発者にとって仕事の基本ですが
ただ言われた通りのものを作るだけじゃ面白くないわけでしてね。
改善提案をしたいわけですよ。

ところが、人間ってのは実際自分の目で見て動作を実感しないことには
口で行っただけでは提案した改善の効果が伝わらなかったりする、
なんてことが多いです。

そういう場合に、たまに僕がやる手段は、
ボツになるかもしれないのを覚悟で改善提案のコードを
書いてしまうことです。そして目の前で実際に動かしてみせるのです。
もちろんボツになったこともありますが、意外に採用してくれる
ことが多いですね。

言われたことだけ、仕様書に書いてあることだけを創っていては
見えてこない物があると思います。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。

内製化はエンジニアにとって良い流れだ

書籍「ソフトを他人に作らせる日本、自分で作る米国」を読みました。タイトルに惹かれて買った本ですが、面白かったです。読みながら思ったことは、やっぱり日本の場合、ソフトウェア開発に対しての評価が低いっていう、認めたくないが厳然たる事実があるってことなんですよね。

ソフトウェア開発を外注にホイホイ投げてしまうのだって、ソフトウェア開発がビジネスでクリティカルな役割を担っているならばありえない選択肢ですし。いや、もし本当にソフトウェア開発がクリティカル「ではない」領域ならば構わないです。しかしやはり、本来は内製すべきソフトウェア開発を安易に外注に投げている場合が多すぎる、と僕の感覚では思います。

プロジェクトのマネジメント手法やソフトウェア開発手法を、ただ輸入して真似してみたところで上手くいかないのも、そもそも内製を前提としている手法なのに、外注に無理やり当てはめているから、という側面もあるでしょう。アジャイルなんて特にそうであって、あれはどう見ても内製を前提としてるようにしか思えないです。

とまあ、なんかネガティブな感じに書いてしまいましたが、近年の内製化の流れは、このへんのソフトウェア開発軽視の価値観が改善されてきたことの１つの表れかもしれないと思ったりします。

ちなみに僕はソフトウェア開発の経験として内製と外注の両方の経験がありますけれども、明らかに内製の方がいい環境だと思いました。内製と外注では、工数・スケジュール・要件・技術仕様・そしてエンジニアへの報酬に至るまで、考え方が全然違ってしまいます。例えば外注を請け負う立場の場合、考え方は「受注・納品」であり、この場合エンジニアへの報酬は単なるコストでしかありません。一方内製の場合には考え方は「投資・回収」です。するとエンジニアへの報酬は投資の一部となります。この辺の考え方の違いについては別の機会にまた書きたいですね。

ともあれ、実感としてはソフトウェア開発の内製はエンジニアにとっても良い環境を生みやすいので、近年の内製化の流れはいい流れだと思っております。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。

次々に出る新技術とどう向き合うか

この記事『「新技術の習得」は麻薬だ 』を読んだんですが、共感するところが多いですね。次々と有象無象の新しい技術が出てきて、まるで「よどみにうかぶうたかた」のようにボコボコと出現しては消えていくわけですが、追いかけまくっていればそれだけで気持よくなってしまうかもしれません。

実際、技術者同士で話をしていると、知識が膨大にあるというだけで表面上は優秀に見えたりするし、相手の知らないことを自分が知っているという状況の優越感は理解はできます。でもそれが実際の仕事につながるかと問われれば、かなり怪しいですね。

僕の考えとしては、「自分が実際に今使っている、あるいはこれから仕事で使う技術」について徹底的に掘り下げて追求し、その過程で関連する新技術があれば吸収していくべきだと思っています。

注意すべきは、新技術の吸収よりも、現在使っている技術の掘り下げのほうが先だということです。実は、実際に仕事で使っているにもかかわらず、深く知っている、あるいは深く知ろうとする人って意外にも少ないです。

もちろん「深く」ってのもやりだしたらキリがないし、無意味な領域まで言ってしまっては仕方ないです。例えばWebアプリケーションの開発が仕事なのに、CPUのアーキテクチャに詳しくなっても、ちょっとそれは深く掘りすぎて反対側に突き抜けてしまった感があります。

でも、例えば自分が使っているフレームワークのソースコードを読んでみるとか、自分が使っている言語の解説本に徹底的に目を通してみるとか、そういう類のことならば少なくとも新技術を追いまくるよりは余程確実に役に立つし、実力の向上につながると思うんですよね。

そうやって、今使っている技術を掘り下げる中で関連する新技術に遭遇したならば、そこで初めて新技術を吸収すればいいと思います。そうすれば、実際の仕事に直結する形で新技術を勉強することになり、より有意義な勉強になるはずです。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。

一億分の一の間違いすら、許されない〜ITエンジニアの生きる世界〜

Facebookに投稿したものですが、せっかくなので、こちらにも載せときます。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

一億分の一の間違いすら、許されない―

プログラムは、書いたとおりに動く。そこには寸分の誤解もなく、その一言一句・一文字に至るまで、書かれたプログラムはそのままコンピュータに解釈される。一文字間違ったら、人間なら「ああ、ここミスしたのね」と判断してくれるが、コンピュータは一文字間違ったらそのまま実行しようとしてエラーになる。

例えば銀行で動くような巨大なシステムともなれば、想像もつかないが、少なくとも全体では数千万行、文字にして数億文字ものプログラムになるだろう。もしかするともっと巨大かもしれない。

しかし、その１文字でも間違いがあれば、システムは正常に動かない。そう、一億分の一の間違いすら、許されない―。プログラミングとは、実際そういうものなのだ。普段何も気にすること無くATMでお金を引き出せるのは、一億分の一の間違いもなく、システムが動いているおかげである。

これは全く大げさな話ではない。確か数年前に世間を騒がした銀行のシステム不具合も、結局直接的な原因となったのは、僅か数文字のプログラムの不備によるものであった。

とはいっても、やはりプログラムは人間の書いた通りに動いただけである。コンピュータが「プログラムはこう書いてあるが、実は別の意図に違いない」などと勝手に解釈することは原理的にありえない。

そして、プログラムの記述に使うプログラミング言語の決まり事もまた、全部人間が決めたものだ。やはりそこにも、解釈にずれが生じる余地はない。つまり、完全に余すところなく、全ての支配権は「こちら」にあるのだ。

ところが、すんなりとプログラムが動くことは、めったにない。何故ならば、完全であるコンピュータは、完全に人間の命令を反映するのだから、人間の不完全さもまた、忠実に完全に再現するからだ。

ITエンジニアは、確かに、物言わず忠実に応答を返すコンピュータ相手の仕事だ。それは、外部の人間から見れば、無味乾燥とした味気のない、まるで砂漠のような世界に見えるかもしれない。

しかし、先に述べたように、コンピュータとは、人間を映す鏡でもある。組み上げられたシステムをよく見れば、意外なほどに、人間の意志や感情が映っているのを見ることができる。

無機質なようでいて、実は人間臭い―。ITエンジニアの生きる世界とは、そういう世界なのだ。

基本的には独学で

先日、とある人の講演を聞いていた時に、どうやって仕事のやり方を覚えたのかという質問が出たんですね。仕事の成果はかなり認めたらている人でしたけれども、全て独学だと言ってました。仕事上使うツールにしても、別に体系だったものを誰かから教えてもらったわけではなく、わからないことを都度調べたり試行錯誤したりして積み上げてきて、使いこなせるようになった、という話でした。

それを聞いていて、ITのスキル一緒だなと思ったんですよ。例えばプログラミングにしても、僕もいま仕事で使っているプログラミング言語に関しては完全に独学ですね。あと開発に使うツール、例えばEclipseみたいな結構複雑なツールにしても同様に、わからないことを都度調べたり試行錯誤したりして積み上げて、まあなんとか仕事で使えるようになった、という感じです。

エンジニアなんてのは特に独学ができることとか、独学で何かを身に付けられることが非常に重要で不可欠だと思います。例えば技術的な問題だって、仕事をしていれば必ず、どこの誰にも応えられないような、独自の問題にぶち当たる時が来ますからね。その時に、自力で解決できる力がどうしても必要です。

コードはコピペだけ、ググって見つからないなら掲示板で質問、そんなエンジニアなんて三流以下でしょう。

独学するというのは自力で解決できる力を付けるという事でもあります。遠慮無く独学で行きましょう。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。

プログラマ３５歳定年説を疑う

よく、プログラマは３５歳が限界なんて言わたりしますよね。僕が最初にそれに大して疑問を持ったのは、この業界に来てまだそんなに経っていない頃に、仕事しながら海外の技術情報にあたるようになった時です。

というのは、日本と違って海外の掲示板やブログなんかだと、自分のリアルな顔写真を出して投稿している人が結構いたりするんですよね。すると、どうみても３５歳以上に見えるプログラマが結構多い。結構年齢がそれなりにいってそうな人が普通に登場するんですよね。これって何なのかな、と考えたのが疑問の切っ掛けです。ようするに、物理的に体力や業務内容的に若い年齢でしか無理ならば、そもそも海外でも若い人しか居ないはずです。でも、全然違う。

要するに、プログラマ３５歳定年説というのは、日本のIT業界の特殊事情によるものでしかないんじゃないかとその時に思ったんです。で、それから色々な職場で仕事をして、転職も２回あって、やっぱり、プログラマ３５歳定年説は本来ならば間違っていると思います。

一番の問題は、「プログラマ」の位置づけかな、と思います。例えば、誰か他の人が隅から隅まで詳細に設計した通りにプログラムを組むだけ、いわば人間の言語を機械語の言語に翻訳するだけ、みたいな仕事だとしたら、３５歳定年説も通用するのかもしれません。でも僕は「プログラマ」が単にそれだけの仕事しかしないという職場は、今後消えていくと思いますね。そういう、設計まで詳細に行うようなプロジェクトは得てして大規模であり、そしてその場合海外にコーディングだけ投げるパータンにどんどん移行しているからです。

ところが、日本の中においても、横断的なスキルが求められる場面が多くなってきていますね。コーディングだけでなく設計もテストもやるし、サーバ構築や場合によっては運用もやる。昨今だと「フルスタックエンジニア」なんて言葉もありますが、それだってメインでプログラミングをしているのであれば、プログラマの一種とみなせるわけですよ。そんな風になってきた時に、やっぱり３５定年っていうのは違うんじゃないかと思うわけです。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。

エンジニアの差は「最後のツメ」に出る

設計書とかプログラミングとか、エンジニアの成果物にはクオリティが求められますけれども、結局のところどこに差が出てくるかというと、いわゆる「最後のツメ」ってやつですよね。

頻度は少ないものの重要なユーザの操作に対するちょっとした仕様の工夫だったり、万が一のための例外処理で最悪の事態を避けるものだったり、ハッキリ目に見えて分かりやすいものでは無いかもしれないですけれど、「何かあった時に違いが分かる」ってやつです。

しかしまあ、そういう「最後のツメ」のクオリティを上げるっていうのは、義務感とかじゃ無理だと思うんですよね。僕は、「こだわり」だと思うんですよ。気になって仕方ないっていう感覚のほうが、正しいと思うんです。

ちなみに、この最後のツメをしつこく追い求めていると、結局１時間で終わるはずだった作業が２時間もかかってしまったりします。しかし、最後のツメを甘いままに作業を終わりにしてしまったら、例えば後になってミスが発覚し、しかもその前提で進めてしまった別の作業の部分も併せて修正を入れるはめになり、結局トータルで４時間かかったりするのですよ。

決して分かり易くないけれど、やっぱりそういう差ってあると思うんですよ。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。

エンジニア以外の人との会話に必要なこと

この動画↓を見て爆笑したんですが、ひとしきり笑って、ちょっと考えたんですよ。

「しわ寄せはいつも技術者に来る」「笑えるどころか胃が痛くなってきた」　エンジニアの苦悩を描いた動画に世界中が共感

エンジニアにとっては明らかに不可能と思える要求が平然とクライアントから突きつけられる、ってことは、結構よくある話なんじゃないかと思います。上の動画だと「７本の赤い線を引く。全ては厳密に直角で、そのうち数本は緑のインクと透明のインクを使う。」という要求です。

・・・何を言ってるんだ！？と叫びたくなりますが、ここで重要なのは、要求を出している側も、それが何を意味しているのか本当は理解していないし、さらにその要求の字面通りのものを欲しがっているもでもない、っていうことですね。

ちなみに上の動画でリアルだなぁと思うのは、途中でエンジニアが「では２本の赤い線を直角に描いて、残りは透明なインクで描く。これでどうか？」と提案して、クライアントも「それで大丈夫」と一旦返す所です。

そう、厳密に言えば、「２本の赤い線を直角に描いて、残りは透明なインクで描く」というのは、一番最初にクライアントが出した要求とは違います。赤い線は７本から２本に減っているし、緑のインクも使わない。でも、クライアントは大丈夫と言っている。要するに、クライアント自身も、自分が欲しがっているものが分かっていない、ということです。

もうそろそろお分かりだと思いますが、今回のタイトルに掲げた「エンジニア以外の人との会話に必要なこと」というのは、スバリ「察する力」です。

会話から、相手が本当は何を欲しているのか汲み取らなくてはいけません。そしてそれを再度エンジニアが言葉にして返すのです。

相手の言うことを言葉通りに受け取ってはいけません。ものごとを可能な限り正確に話すのはエンジニア同士なら当然のことですけれども、それ以外の人は、会話とはなんとなく雰囲気が合っていればOK程度位にしか思っていない、とエンジニアは考えるべきです。別にエンジニア以外の人が適当すぎると責めたいのではなく、そのくらい言葉の前提が違うという意味です。

相手が滅茶苦茶なことを言っていたとしても、本当は何を望んでいるのかを察することが出来れば、それを提案すれば相手は満足してくれるわけですね。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。

プログラミング言語は多く使えたほうがいいのか

当然のことながら、ソフトウェアエンジニアにとって、使えるプログラミング言語というのは武器であり仕事道具であるわけです。だったら使えるプログラミング言語の種類も多ければ多いほどいいのか、というと、僕はそうではないように思います。

１つのプログラミング言語において、ビジネスにおけるあらゆる要求を満たせるように自在にその言語を使いこなして開発ができるレベルに到達するのは、それほど簡単な話ではないと思うのです。要するに１つの言語を極めるにはある程度の経験の量が必要でありその分時間も必要であるわけです。そして、そこまで到達して初めて、その言語は自分の強みと言える状態になれると思うのです。

そして、使える言語の数が多いからといって、その全てが上で述べたような、極めたといえるレベルに到達できるかといえば、そんなことは不可能ですし、その必要もありません。何か１つ、極めたといえるレベルで使える言語があればそれだけでもかなりの強みを発揮できます。結局プログラミング言語の違いというのは自然言語で言う方言のようなものなので、１つの言語でやり方を知っていることは他の言語にも応用が効く場合が多いからです。

とはいえ、１つの言語しか知らないとなると、その言語独特の流儀だったり特性ってものが分かりません。だからある程度使いこなせる言語が２種類は欲しいところです。逆にそれ以上無理に増やそうとする必要性は薄いと思います。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。

プログラミングのプロとアマの違い「例外処理」

えー、僕も仕事でプログラミングをそれなりにやって来ましたけれども、よくプログラミングの初心者向けの解説サイトとか書籍とかを見てますと、プログラミングって結構簡単に見えるんですよね。まあ、その時点でついていけない人もかなり居るとは思いますけれども、人には得意不得意がありますので仕方ないです。僕が言いたいことは、細かい作業が得意なタイプの人からすると結構簡単に見えるってことですよ。

しかしながら、そういった初心者向けの解説サイトとか書籍には、大抵の場合すっぽりと抜け落ちているものがあります。これはサイトの製作者や書籍の著者たちがうっかり屋さんとかドジっ子なのではなくて、「わざと」抜いてある部分があるのです。それはなにかと申しますと、この投稿のタイトルでお分かりだと思いますが「例外処理」です。

つまりですね、そういう初心者向けの解説サイトとか書籍に掲載してあるサンプルコードには、ある目的を最短距離で達成するコードのみが載っているのであり、ユーザが予想外の操作をしてきた時にエラーにならないようにするための、あらゆるパターンを先回りしてケアするためのコード、すなわち例外処理のコードなんぞ載せてはいないのです。

ですが、この例外処理のコードをいかに抜け漏れ無く、エラーを起こしたりクラッシュしたりしないように書けるかが、プロに求められるプログラミングのスキル（の１つ）だったりします。だいたい、ちょっと自分用に動けばいいプログラムとか、クラッシュしても誰も困らない使い捨てのプログラムだけを作るのであれば、こんなにラクなことはないのです。つまり例外処理こそがプログラミングのプロとアマチュアを分ける最大の違いの１つと言うことが出来るでしょう。

これは、プログラムを依頼する側に、「アレとコレができればいいだけなんだから簡単でしょ」とか勘違いする人が後を絶たない理由でもあります。例外処理のことなど全く考えていない連中からすると、実装しなければいけないロジックは実に単純に思えるのです。しかしながら、例外処理があるのと無いのとでは、ロジックの総量は何倍も違うのです。それを理解しないくせして、無茶苦茶な使い方をして動かないとなると「こんなプログラムは使えない」と文句を垂れるんでしょう。そういうもんです。

もちろんプロとして例外処理はきちんとやるんですけれどね。まあ、実際に仕事としてプログラミングをやったことがある人以外では、この部分の大変さを理解してる人は少ないと思います。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。

フルスタックエンジニアって結構よくある話だよね

なんか最近フルスタックエンジニアってキーワードを目にして、なにかと思ったら、「インフラからミドルウェア、モバイル、デザインまで、あるいは設計からプログラミング、デプロイまで、何でもこなせるエンジニア」ということらしい。

ほう、僕の時代が来たか、って思ったんですけど、よく考えて見れば、別にこれって珍しい訳でも何でもなく、例えば比較的小規模のプロジェクトでは、一人のエンジニアが様々な仕事をこなさなければいけないので、自然とフルスタックエンジニアになるんですよね。Web系でしたら、自分でサーバを用意し、ネットワークやOS周りをセットアップし、要件定義・設計・開発・テストを実行し、デプロイまで行う。さらにメンテもする。そんな感じで仕事してれば一通りできるようになりますよ。

逆に言えば、１つの分野（例えばDB設計だったらDB設計だけとか）に依存している人にとっては、今後厳しい時代になるのかな、と思います。皮肉なことにそういうのは大規模プロジェクトに多く、大規模なプロジェクトに多く関わった人ほど自分の専門分野以外のことを何も知らなかったりします。だから大規模プロジェクトの経験イコール良い経験だとは限らないですね。

ということで、僕と同じように中小規模のプロジェクトで何でも屋のようにあらゆる作業を任されてきたフルスタックエンジニアの皆様、いよいよ我々の時代のようですよ？

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。

ソフトウェア開発者には想像力が重要

今進めてるプロジェクトで、開発中のソフトウェアを実際に使う人を何パターンか用意して実際に利用するシーンを書く、ということをやっております。これはシナリオづくりってやつです。利用者像という意味ではペルソナって用語もありますね。まあ、年齢とか家族構成みたいな細かい部分までは考えませんけど、ざっくりおおまかなイメージは作ります。

画面の構成やユーザインタフェースの詳細をこれから作っていくにあたり、どういう人がどういうシーンで、どういう心境で使うのか、といったことを想定するのはソフトウェア設計の初期段階において非常に大事です。この使用シーンを文書化して仕様書の一部に盛り込む手法は業界のベテラン開発者も提唱しており、今回僕もそれに倣って、仕様書の一部としてシナリオを盛り込むことにしたわけです。

さて本題ですけれども、ソフトウェア開発者はプログラミングさえできればいいわけでは勿論ありません。上で述べたように、自分が開発しているソフトウェアがどのような人達にどういうシーンで使われるのか、想像力を駆使しなければ良いソフトウェアが開発できません。

そういえば、昔ながらのウォーターフォール型開発においては、設計部分とプログラミング部分が分離しており、ともすればそれらが別々の人間、あるいは別々の会社で行われることも多々あるように思います。僕自身もそのようなプロジェクトに携わった経験もあります。しかし、今現在は設計もプログラミングもどちらも行う状況にあります。要するに、プログラミングの工程になったら仕様通りに作ればいいとか言う話では全くなく、プログラムの実装中であっても、ユーザビリティを常に考慮して細かい仕様を変更できるし、すべきだということなのです。

このボタンの位置はもっと右にあると押しやすいとか、あるいは後戻りできない決定のボタンだから逆に押し間違い防止のためあえて押しにくい位置にするとか、選択肢の順序を入れ替えて最も選ばれる頻度の高い選択肢を選びやすくするとか、そもそも本来次の画面での入力項目だったが、よく検討してみたらその前の画面で入力できたほうが分かりやすいから移動するとか、もう色々様々ありとあらゆる細か〜い仕様を使い手の視点に立って最適化しなければいけません。だから、想像力が重要なのです。

このような状況は僕自身については今後も続くと思いますし、業界全体としても、設計からプログラミングを同じ人間、同じチームが行う状況はますます多くなっていくでしょう。そうなると、ソフトウェア開発者全てにおいてやはり想像力の重要性はもっと高くなっていくと言うべきでしょう。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。

派遣エンジニアとキャリアパス

僕も昔、派遣エンジニアをやっていたことがありまして。いわゆる特定派遣ってやつですね。どっかの会社の正社員でありながら職場は別の会社で、そっちに毎日通うというやつです。僕自身の現場経験を思い出してみてもこの形態のエンジニアは多く、IT業界にはかなりの人口がいるはずです。

別に派遣エンジニアそのもの自体は悪くもないと思うんですよね。１つの組織にとどまらず様々な現場を経験するのはそれはそれで面白いと思いますし、バリエーション豊富な経験というのはエンジニアとしての財産であり武器になります。

ただし問題は、特にIT業界の構造として年齢の上昇とともに派遣エンジニアの受け入れ先が少なくなるということです。これはIT業界の構造が原因ですね。

派遣エンジニアの仕事が発生する主な場面の１つとして、システム開発を請負う会社がプロジェクトを受注し、そこで自社で足りない人員を募集するというものがあります。その際に人員募集の情報をエンジニアを擁する会社に流して、条件に合うエンジニアを派遣してもらうわけですね。派遣されたエンジニアは、受け入れ先企業ではチームリーダーの下に就くわけですが、プロジェクトのチームリーダは受け入れ先企業の正社員である場合が多いです。そしてその際に、チームリーダーより年齢の高い派遣エンジニアがいると気まずいだろうと受け入れ先企業は考えるんですね（僕自身はそんなのどうでもいいと思いますが）。だから、条件として明記してなくても、年齢の高いエンジニアは敬遠される傾向があります。

また、派遣エンジニアは炎上したプロジェクトに増員要員として現場に集められるケースが多々あります。そういったプロジェクトはスケジュールが既にかなり伸びてしまっており、赤字の危機（もしくは既に赤字状態）にあります。ということは追加費用はなるべく抑えたいわけです。だから、集める派遣エンジニアも安く済ませたいわけで、すると単価の低い若いエンジニアが選ばれてしまいます。（それで実際大丈夫なのかというと全く違いますが。）

このような事情があるいせいで、派遣エンジニアは年齢が上がると仕事が少なくなるんですね。

僕がIT業界に飛び込んだ時はこういう業界構造を理解してませんでしたし、最初に入った会社がエンジニア派遣で主に儲けていることも分かっていませんでした。だいたい求人情報には「エンジニア派遣やってます」とは書いてません。一般派遣と違って正社員ですし、求人情報見ても区別はつきません。ある程度業界経験積めば分かりますけどね。

それでも最初の切っ掛けをつかませてくれたという意味で派遣エンジニアは大きな意味がありましたし、業界の構造も知ることが出来ました。最初のステップとしてはアリだと思ってます。

ただ、今派遣エンジニアの人は、将来のキャリアパスを見据えて次のステップは早めに考えておくべきとは思います。ある程度経験を積んだら、例えば独立してフリーのエンジニア（個人事業主）になるとか、派遣エンジニアではないビジネスを自社でしている会社に転職するとかですね。ちなみにエンジニア派遣会社の営業になる人もいますが、オススメできません。（ここで書くと長くなるんで別の機会に。）

本当は、業界全体がもっと変化して年齢の高い派遣エンジニアも積極的に受け入れられるようになっていくのがベストだと思います。実際、様々な現場で経験を積んだエンジニアは頼りになりますよ。チームリーダより年齢が高いからと避けるのはもったいないし、高い報酬を出すだけの価値はあります。

しかしいかんせん、業界が変化を待ってたら先に自分が食えなくなるかもしれませんから、やっぱり対策を打つしかありません。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうそ。

エンジニアの大切な要素「しつこさ」について

ITエンジニアに必要な知識なんて無限にあるわけですよ。ある物事についてあらゆる知識を持っている人を「生き字引」なんて言ったりしますけれども、ことITエンジニアの世界においては「生き字引」ってあまり価値ないんですよね。何故かというと１つの理由は必要な知識はネットにあるので覚えておく必要がない、もう１つの理由は新しい技術が次々に生まれるので、古い知識は凄まじいスピードで役に立たなくなるということです。（だからといって知識の蓄積に意味が無いと言っているわけでは勿論ありません。）

さて、いくら勉強しても尽きることのない知識の広大な海の中で僕らエンジニアは成果を出していかなければならないのですが、その際大切になってくる要素の一つが「しつこさ」であると僕は考えてます。

結局日々仕事に取り組む中で目の前に現れてくる問題というのは、自分にとって未知の問題であるわけです。そもそもIT関係のプロジェクトというのは今まで無かったものを実現したり、新たな仕組みを構築したりするわけで、その意味でルーチンワークにはなり得ないんですね。それがこの仕事の面白いところであり、同時に難しいところでもあります。ともあれ、仕事の性質上、ぶち当たる問題は未知の問題であるというのは納得頂けると思います。

だから問題に取り組む時は常に自分の持たない知識を調べ、試行錯誤を重ねなければなりません。ところが、ここで分かれ道があります。

例えば、あるシステム開発プロジェクトで開発を進めるうちに、ある機能の実現について問題にぶち当たったとします。エンジニアとしては、諦めてそれは技術的に不可能ということもできます。しかし、もっと調べたり考えればもしかしたら実現可能かもしれません。

じゃあ、実現可能な方法を発見できる、あるいは考え出せるかどうかは何で決まるのか。知識？経験？いえ、上で述べたように、過去の知識や経験はすぐに陳腐化する業界です。多少はアドバンテージになっても、決定的な差にはなりません。

だからこそ、僕は「しつこさ」が重要だと思ってるんですよ。結局のところ、問題にぶち当たったら僕らエンジニアはほとんど同じスタートラインに立つわけです。過去の知識や経験はほんの数歩のリードくらいにしかなりません。その状況において、問題を解決できるかどうかというのは、やっぱり諦めの悪い人間、すなわち問題が解決するまでしつこく粘れるかどうかで決まるんじゃなかと思います。

ITエンジニアにとっての本当の「経験」とは、問題のぶち当たった時の「しつこさ」を獲得すること、粘リ方を覚えることなんじゃないかとさえ思えるんですよね。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうそ。

エンジニアって勉強家だよね

僕は社会人１年目はITとは別の世界いたし、エンジニアですらない文系職だったから、エンジニアが他の仕事とどう違うのか、ある程度実体験から言える部分がある。その１つは、エンジニアって勉強家が多い職種ってことだ。

別に他の職種を悪く言うつもりはないし、エンジニアよりももっと勉強をしている職種も沢山あることは承知してる。ただ、それでも日々技術について新しい知識を吸収したり、より仕事でパフォーマンスを発揮するにはどうすればいいか学んだり、そういったことをエンジニアは当たり前にしているのをみると、やっぱり勉強家だなって感じるんだよね。

実はこれって、エンジニアの世界では当たり前でも、他の仕事では当たり前ではなかったりするんだ。エンジニアがなぜ勉強家なのか、その理由は次のようなことが考えられる。

まず、そもそも勉強し続けないと仕事にならないこと。次々と新技術が登場し、それら新技術を使えることを求められるから、勉強し続けないと仕事自体がなくなる可能性がある。職場以外の時間でも仕事に関する専門書を読んだりする人は結構多い。

次に、転職の多い業界であること。スキルを磨けばより良い職場に移れるチャンスもあるから、それがモチベーションになりうる。たぶんすべての職種の中でもトップクラスに転職の多い業界だろうし、転職市場からの求人情報も「◯◯のスキルを持つエンジニア募集！」なんて感じで日々流れてくるので、実際転職するかどうかは別にしてもスキルアップに必然的に意識が向くようになる。

そして、エンジニアの仕事自体が好きな人が多いこと。あくまで傾向だけれども、例えばシステム設計やプログラミングといった仕事に、全く興味がなくて就く人は少ない。残念だが世間から見たブラックなイメージもあるから（実際は職場による差が激しく、超絶ブラックもあれば普通もあるのだが）、わざわざ選ぶ人は少なくとも面白そうだと思ってこの業界に入る人が多い。でもって楽しく仕事している人は多いと思う。だからこそ進んで勉強するんだな。

結局何が言いたいのかといえば、勉強家のエンジニアは誇りを持っていいということなんだ。いやほんとに。そうやって自分がすごいと思っておけば、日々の勉強がもっと楽しくなるかもね（笑）

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうそ。