エンジニアは泥臭い
自分の肩書きがプログラマなのかシステムエンジニアなのか何なのか分かんないけど、ともかく自分は主に受託案件でどこぞの企業のシステムを設計開発したり保守改修をしたり、ということでお金をいただいている。この仕事を始めて10年近く経とうとしているが、ようやく理解したというか、諦めがついたというか、受け入れた事実が、システム開発はちっともシステマチックではないということだ。
プログラムは基本的に、正確なアウトプットを求められる。「1」を入力されたら「2」を返す、という動作は毎回確実でないといけない。そのためには「要件定義」や「設計」という工程を通じて、システム化したい内容を厳格に言語化し、人の手でやっていた時のような「曖昧さ」をなくすことに心血を注ぐことになる。プログラムは「いい塩梅で」「周りの状況を見て」「臨機応変に」結果を変える、などということは (今のところ) 無理だし、システム化したいという要望は基本的にそうした「手作業で発生していたゆらぎ」をなくすために行われるので、正確に条件やしきい値を定義することになる。
しかし、そんなシステムを利用するのは「曖昧な人間」であり、曖昧な人間は機械にも「臨機応変な対応」を求めてくるものだ。「私が担当する時はこういう風に処理していたから、システム化された後もこんな風にしてほしい」といったワガママを、複数の人が申し出てきて、よく聞くと双方がやっていることに矛盾がある。結局はシステム化するにあたって何らかのルールを規定して「人」の方を正さないといけないのだけど、こんな子守りみたいなこともシステムエンジニアが顧客折衝としてやるべき仕事なのだろうかと。
システムを新規開発する、何か機能を追加する、というのは、エンジニアがやる仕事の中では実はさほど難しいことではない。どれだけソースコードが汚かろうとシステムが複雑だろうと、「動けばいい」だけであれば、とりあえず作ってしまうことは出来る。図工が苦手な人でも、木の棒と釘を組み合わせれば、とりあえず座れる椅子を作ることはできる、というイメージに近い。
もっと難しいのは、一度作ったシステムが正常に動き続けるように面倒を見る、運用保守、障害対応というフェーズだ。一見正常に動いているシステムだが、内部ではメモリ管理にバグを抱えており、数週間動かしているとメモリリークでシステムが強制終了してしまうーだとか、登録されたデータの件数が増えたことで動作がメチャクチャ遅くなったーとか、使っているミドルウェアに脆弱性が見つかったのでバージョンアップしないといけなくなったが、バージョンアップすると特定の API に依存しているプログラムが動かなくなるので周辺のソースコードの改修も必要だーとか、まぁ色んなことがある。
そして、そうした不具合にいち早く気付いて迅速に修復できるような監視・通知の仕組みを設けたり、もしくはシステム自身に自動復旧させる仕組みを作るのは相当難しい。いわゆる「非機能要件」というカテゴリの話で、どこまでやれば OK かという基準が設けづらいのだ。さらに、時間経過で周りの状況が変化すると、当初計画していた内容が「誤り」扱いになってしまうようなこともある。「何もしてないのに壊れた」というのは、こういう場面では言えたりする。ｗ
システムのどんな些細な変化にも気付けた方が良いのかというと、そうでもない。監視する「人間」のコストが増大するし、監視の仕組みを入れるために様々なツールを導入したりして月々の運用コストもかかる。「絶対に通信が途絶えてはいけないのだ」なんつって専用回線を引くとする？大地震で海底の光ファイバーケーブルがちぎれるリスクまで考慮すべきか？金さえかければ「何があっても止まらないシステム」を作れる…とも言い切れないのに、ちょっとした「やりたいこと」にも青天井なコストがかかるのが運用設計だったりする。
素人でもとりあえず角張った椅子は作れたが、その耐久性はどうなのか。床を傷つけないだろうか、長時間座りやすいか、持ち運びはしやすいか、万が一壊れた時に、座ろうとした人が怪我するような壊れ方ではなく、より安全に故障する (クルマのクラッシャブル構造のような概念) とか、故障したらランプでお知らせするみたいな親切設計があると良いよね、なんつって考え始めると、「座れるものを作る」という「機能要件」よりも考えることが多く、実現にはお金がかかり、正解もないワケである。
目の前のことだけではなく将来を見据えて、正確で、安全で、修正変更がしやすいモノを作ることが望ましい。そういうモノを作れる専門家として発注を受けてるワケだし、自分としてもできればそういう優秀で手のかからないシステムを作りたい。保守コストがかからないシステムは顧客も低予算で済んで嬉しいだろうが、実際に保守作業をするエンジニアの負担も減るので、目指すべき姿ではある。
だが、そういうのはまぁ難しい。日本は特に資格がなくてもエンジニアになれるし、「プロジェクトマネージャです」なんて肩書きがあるからといって、全員が国家資格である「プロジェクトマネージャ試験」を持っているワケでもない。大抵の会社は、本人の要領の良さと経験に基づく漠然としたスキルを上手く対外的にアピールできた人が昇格してプロジェクトマネージャを名乗ったりしているに過ぎない。実力がないワケではないが、その程度には大きなバラつきがあるし、その人の「流儀」でもって仕事をしているケースが大半だろう。体系的なスキルを有しているワケでもなく、プロジェクトマネージャ同士が同じ資格を持っているから共通言語をもって話せる、というワケでもない。そのあたり、欧米のエンジニアと比べると、押し並べてスキルが低いのがニホンノエスイーだと思う。
だから結局「アイツとはソリが合う・合わない」で仕事の出来が変わる部分が大きい。性格や考え方が似ていたり、長年一緒にやってきたようなメンツだとツーカーでやり取りできるが、違う流儀を持つメンバが入ってくると全然思いどおりに仕事が進まなかったり、メンバの寄せ集め方が悪いと新規開発案件の立ち上げも失敗しやすい。「コンウェイの法則」みたいなモノで、そのシステムに携わる人達の関係性が、そのシステムの毛色を出しやすい。
目指すべき本当の姿は、そうした属人性をなくし、誰がやっても同じ結果を出せるモノを作るのがシステム開発なのだが、
- 専門家としての共通言語を持たないので、考え方が異なる人間同士の「我のぶつかり合い」になるし
- 技術水準が低いので余裕がなく、目の前のタスク消化で精一杯だから、将来性がない保守困難なシステムを生み出すし
- 低レベルな連中が我流で作ったシステムはそもそも使いにくくて最初から顧客満足度が低いし
- (顧客側もシステム化というモノを分かっていないから、自分を主体に考えてしまってシステム屋からすると見当違いな指摘や不満が溜まるし)
…という感じで、まぁ思いどおりになどならない。
一応、IPA だとか、色んな団体が「標準ガイド」みたいなモノを作っていたりはするので、システム屋として全社的に「ウチはこの標準ガイドに従って作ろう！」と社員教育することは、不可能ではないかもしれない。社員教育用の子会社を持っているような、大きな会社だと比較的社内での共通言語が出来上がっているケースはある。
しかし、それでも顧客の思惑はコチラではコントロールできない。
- 「標準ガイドだか何だか知らないがウチにはそういうの必要ない (まぁ、ハイ、そうですか…)」
- 「コスト優先でこの機能は省くが、同等程度の仕組みは実現してほしい (何を言っているんだ？)」
- 「それよりも何か流行りのドッカー？とかいうやつ使って技術アピールしたい (遅すぎ知らなさすぎ)」
技術的な専門領域を知らないために、こうした顧客の思惑が生まれること自体は仕方がないと思う。半分くらいは懇切丁寧に解説・交渉することで、おかしな方向に行きそうなシステムを軌道修正できるかもしれない。しかし大概は「お金の問題で」「部署間や子会社との都合でどうしても」「ウチの社長が認めてくれないんです…」なんていう理由から、「標準ガイド」や「ベストプラクティス」から外れた苦労を強いられることが多い。
そういったポイントは結局現場の人間が独自に考えることになり、そこで発揮されるオリジナリティはイコール技術的負債になるのだ。皆必死にその場しのぎで対策を考えて、「あー微妙だなー扱いづらいなー」と思いながら、それが承認され、おいそれと変更できなくなる。「自分達で考えて作ったもの」には大抵考慮漏れがあり、それが根幹を揺るがす問題に繋がり、リリース直前のテストで発覚して大炎上するか、リリース直後に本番障害で気付いて徹夜の火消し作業になるか、といった感じだ。
…誰が悪いんだろう。何が変われば改善するんだろう。
一人のエンジニアができそうなこと。あらゆる方面を勉強し、多くのスキルを身に着けること。顧客の状況を把握し、顧客に丁寧に説明ができるようになること。
会社組織としてできそうなこと。社内にノウハウを貯め、ナレッジを漏れなく発揮できるようにドキュメントのテンプレートやチェックリストなんかをこしらえて全社的に教育して底上げしていく。
できれば顧客にやってほしいこと。世間一般的な「システム化」の流れを知ること。パソコンは「思いどおりに動く魔法」ではないと理解すること。アジャイルとかスクラムとか目新しいバズワードに騙されないこと。ああいうのは年収1,000万以上の海外の超優秀エンジニア集団が提唱している限定的な話なので真に受けないこと。
…なんつって考えてみるけど、まー世の中そう簡単には変わらないよね。仕事を一生懸命やりたい人もいれば、仕事なんか仕方なくやっている人もいる。どこにも「完璧に物事をマスターしている人間」なんていないのでどこかしら不完全なモノになるのだし、「完璧なシステム」もどうやったって作れない。
僕はずっと「皆が俺と同じように考えて同じように動いてくれたらいいのに」という思いが強い方だったと思う。基準が自分自身でなくとも、多くの人間の思想やアウトプットを統一したい、という欲求がずっとあった。というか今もある。「みんな違ってみんないい」なんて全く思えない。「みんな違ってメッチャ嫌」である。
だけど、実際は「みんな同じ人間」なんかではなく、「みんな違う人間」なのだ。それぞれの事情でそれぞれ大枠は正しく、一部は間違っている。意図的か無意識かによらず、白黒ハッキリつかないグレーゾーンも多い。「他人が変わってくれればいいのに」と思っている自分自身の思想も変えられない。
こういう、ワケの分からない「人間」という生き物を相手にしているのがシステムエンジニアなのだ。何だかいつも似たようなモノを作っている気がするのに、毎回異なるワケの分からないトラブルに巻き込まれ、意思疎通が図れない相手と会話 (？) をし、システマチックでもないプログラマブルでもない、原始的で非効率で手作業満載の不確実な仕事を繰り返す。いつまで経っても体系的な仕組みが構築できない。誰も現状に課題意識を持っていないように感じるが、自分一人では変えられない規模の物事が絡んでいて次第に諦める。今日も昨日と同じ作業を同じ時間かけて行う。「もっと分かりやすく」と指摘してくる上司の書く文章は日本語が含まれていること以外一つも理解できない。失敗が目に見えているのに誰もそれを回避しようとせず、自分が声を上げても状況は変わらず、全員が一丸となって火の中に飛び込んでいく。
バッカじゃねえのと思う俺も、次第に色んなことを諦め始めた。社内の身内も、顧客も、世の中も、俺自身も、何にも変わらないし、どうなってもいいや、と。もっとちゃんとした業界だと思っていたし、ちゃんとするべきだと思ってたんだけど、そうじゃないんだ。土建屋に失礼な表現で恐縮だが、「IT 土方」という表現がいわんとしているのは、東南アジアかどこかの法規制もへったくれもないような建造物を勝手に建てて勝手に増改築しているような、物凄く暫定的で間に合わせの仕事スタイルを指しているのかな、と思った。長く住めるかとか、雨漏りしないかとか、そんなことおかまいなし。とりあえず今屋根が欲しいから拾ってきたトタンを貼りました、そんな考え方に近い気がしてきた。
個人的にキチンとしたいなという思いはあるけど、そう思う自分自身を含めて、人間というモノがそもそもそんなキチンとはしていないのだ。自分がキチンとしたいのは顧客のためではなく、自分がスッキリしたいがためだろう。そりゃあ人を動かせなくて当たり前だ。他人の気持ちなんかマジでどうでもいいけど、俺の気分は害さないようにお前ら気を付けろよ、というクソ矛盾。生きづらいなーーってその原因は俺にあるのでは？
ともかく、誰かをどうにかすればとか、コレを一つ直せば万事解決とか、そんな「銀の弾丸」はない。システマチックなシステム開発なんて最初から不可能な話だったのだ。なのにそういう風に働きたいと思っていた俺が間違っていた。どこまでも泥臭くてイビツだし、属人性はなくならなくて保守しづらいし、課題は解決しない、こんな仕事をずっと繰り返していくモノなんだと思うようになった。
…そうなんだけどさ、それは分かったんだけど、それをずっと続けるのって物凄くストレスだなー。もうエンジニアでいたくないや。ココから先は考え中。ｗ
