隣のエンジニアと話が通じないあなたに
「システムエンジニアの仕事って、どんなことをしてるんですか？」と尋ねられることが本当に多い。もう何年もエンジニアを続けているにもかかわらず、自分はこの質問を受けると適切な回答がうまく見つけられず、返答に窮してしまう。
悩む理由は、自身がどんなエンジニアかという具体的なレベルで答えてよいのか、「エンジニアとは」という一般的なレベルでの回答が期待されているのかが分からないからである。自分がどんな業務に特化したエンジニアなのかということに答えるのは簡単だ。だがそれでは、総体としてのエンジニアの専門性を説明することにはまったくつながらないと考えてしまうのだ。
エンジニアの仕事は現場ごとに全く異なる態様で行われている。あるエンジニアはスマートフォンアプリの企画開発に勤しんでいるし、別のエンジニアは銀行の古くからある取引業務システムのメンテナンスを続けている。またあるエンジニアは経理や給与計算のパッケージを法改正に対応した新しいクラウド型のパッケージへの移行を検討しているし、さらに別のエンジニアは通信が遅いと言う顧客の苦情に対応するため、ネットワーク回線の改修に昼夜問わず駆り出されている。要件定義や基本設計などの「上流工程」と呼ばれるプロセスに立ち会うエンジニアには、システムの知識に加えて、対象となる顧客の業務に精通していることが求められる。銀行のシステムであれば銀行業務、給与のシステムであれば給与計算業務の知識が必要であり、顧客の目線となって次工程を担当するエンジニアに指示を出す。こうした個々のエンジニアごとに専門領域が異なるという事情があるので、たまたまエンジニア同士で会話をする機会があったときですら、仕事の内容について込み入った話がすぐにはできず、もどかしい思いをすることになる。
個々のエンジニアの専門分野は異なる。では、エンジニアと会話する際に共通の知識があるかと考えてみる。多くのエンジニアが入社時に目指す資格として、IPA（情報処理推進機構）が主催する基本情報技術者試験がある。この資格にはコンピュータの基礎からネットワーク、データベース、セキュリティ、開発設計、マネジメント、経営戦略、関連法規に至るまで、どんなエンジニアでも必要とする基礎知識が網羅されている。悲しいことに、この資格は実務ではあまり役に立たないと言われることが多い。基礎知識自体ではなく、あくまでこの知識を土台として、実際に取り扱う機器の細かい知識を取り入れ続けることがエンジニアには要求されているからだ。LPIC、CCNA、ITIL、Oracle DB、SAPなどに代表されるベンダ側の知識がなければ「現場では」往々にして役に立たないのだ。というか、基本情報試験に合格した一般人がいたとして、このレベルの知識を持ち出してきて「ブラックボックステストっていうのをやってるの？」みたいな話をされても、エンジニア側は「まあ、やってるね」くらいしか返しようがない（自分はこの話を知り合いに実際にされたことがあり、「今の案件は自分が設計から実装までやってるので、むしろホワイトボックスでやってますね」といたずらっぽく返したことがあるが、案の定、相手がぽかんとしていたのを覚えている）。試験の知識がそのまま会話のネタになるということはない。もっとも、そのままでは使えないというだけであって、資格の根底には、次に示すようなエンジニアの共通理解が存在する。
エンジニアの共通理解をわかりやすく示しているのは、「機能要件」と「非機能要件」というシステム設計の用語だと思う。機能要件とは、システムが果たすべき本質的な要件のことをいう。正しく金額の計算が行われること、伝票の転記が正常に行われることなど、システムを導入する本来的な目的だ。これに対して、システムが正常に稼働するためのその他あらゆる要件を、非機能要件という。使いやすいこと、時間がかかりすぎないこと、同時に大量のアクセスがあっても落ちないこと、セキュリティが十分であること、障害が発生してもすぐに復旧できることなど、業務の本質以外の部分でも考慮すべきことがある。本来は品質を測る指標だが、この非機能要件は、どんな現場に関わっているエンジニアでも無視することのできない課題だ。個々のエンジニアの専門性が機能要件の実現過程で垣間見ることができるのに対し、全てのエンジニアに共通する専門性は、この非機能要件を検討する場面にこそ現れるといっていい。
例えば、この非機能要件を構成する項目の中に、「保守性」というものがある。そして、エンジニアが保守性を確保するために「同じ処理を書かない」という理念がある。これは現場によって異なるルールなどない、エンジニア一般に通用する原則だ。データベース設計でも「一事実一箇所」と呼ぶ、類似の原則がある。エンジニアはひとつの処理が二箇所以上の場所に繰り返し記載されることを嫌うのだ。将来、その処理に関する修正をしなければならなくなったときに、一つの修正事由に対して、複数の同じ内容の修正箇所が存在することになり、このチェックが非常に面倒なのである。この状態は同時に、修正によるバグの発生が起こりやすいということも意味している。そうならないよう、データベースは正規化という処理を行い、プログラムは共通処理の関数化、類似する処理の差異がある部分をパラメータ化することで上記の原則を達成しようとする。ムダを省くこと、ミスを減らすことは開発の究極目的だ。設計思想という観点では、「例外処理」という用語も覚えておきたい。これは、非機能要件の「使用性」に相当する。例えば、数字を入力するテキストエリアに誤って文字を入力してしまったときに、「数字を入力してください」とエラーメッセージが出てしまったことはないだろうか。ユーザがどんな誤った、あるいは不正な入力を行っても、システムの側が致命的な不具合を起こさず、ユーザに正しく次のアクションを起こしてもらう。そのために、プログラムのテストを行うとき、正しいデータが正しく登録されることと同等かそれ以上に、エラーデータについて正しいエラー処理が行われることについて気を使うのだ。エンジニアの細かな工夫は、このように非機能要件を充足するための細部に現れる。
ここまで話して、展開が当初の予定通りだったかどうかが不安になる。難しく話してしまったので、一般の方向けに改めて話す。冒頭の質問については、エンジニアと話す際には、ぜひ「何を作ろうとしてるんですか？」とか、「どんな課題を解決しようとしてるんですか？」と聞いてほしい。本質としては、彼らはモノづくりをしている者たちであり、あなたの業務を支える裏方の人間なのである。