越境スキルの重要性

スキルにおける専門性とは何か?

サーバサイドならサーバサイドを極めるという意味なのだろうか?

もう少しわかやすい表現、「一つの開発言語に閉じているのはヤバイ」ということなのかもしれない。

もちろん、一つの言語を超深堀しているなら、そういう人がいてもいいと思うが、それはともかくとして、イマドキのWebサービスは、さまざまな技術に跨っている。

つまり、スピーディーに話を進めたり、問題解決をしたり、相手を説得したりする時に、さまざまな技術に対する造詣が深いほうが、Web系のエンジニアとしては、専門性が高いと呼べるのではないだろうか?

昔、とある案件で、Strutsを使ったのだが、お客さんの環境で一定時間経つと、MySQLとの通信が切れてしまい、うまく接続できなくなる問題が発生した。

アプリケーション担当は、毎回MySQLには適切に接続しに行っているのに、繋がらないのはおかしい!と主張し、インフラ、ネットワーク担当は、そもそもpingが通っているし、それ以外にも特別な問題は起きてないので、ネットワークの問題ではないと主張した。

リーダーである僕は、Strutsが不慣れだったのもあり、技術的な深掘りができなかった。

これにより、「よくわからない」という状態に陥ったことがある。

おそらく、なんらかしらの理由でコネクションプーリングがタイムアウトしたのだと思う。対症療法的に一定時間でMySQLに接続するコマンドを発行するなどの措置を施したにも関わらず、接続が切れて、繋がらなくなるという問題は解決できなかった。

いずれにせよ、対処としては、「多分、コネクションタイムアウトが問題だろうから、再接続処理を徹底する」ことで、どうにか回避をしたつもりであったが、何故ダメだったのか?何故再発しないのか?という根拠もはっきりせず、対処法としてはスッキリするものではなかったという嫌な思い出がある。

僕自身としても、この案件がServletではなく、僕自身が不慣れなStrutsだったので、何がどうなって、そこに接続しているのかを理解できなかったので、原因追求ができずに、アプリケーションエンジニア任せになってしまったのが問題だった。

(しかもオフショア案件で、彼が開発したわけでもないという2重の悩みが)

こういう責任分界点をまたぐ問題が発生した時に適切に解決する方法はいくつかある。

・ネットワークエンジニアがアプリケーション側に乗り込んで問題を解決する
・その逆に、アプリケーションエンジニアが、ネットワーク担当と話をして問題を解決する。
・リーダーが、双方の問題を見て解決する

などであろう。どれが望ましいかはケースバイケースであるし、どれでなくてはいけない、というのはないとは思う。

ただ、

問題が解決しないと、非常に、気持ちが悪い。

ITには、「なんとなく解決してラッキー」などという問題は存在しない。
その問題には必ず論理的な問題点があり、地雷を踏んでいるのだ。

その論理的な問題を解き明かすのがエンジニアの仕事である。

しかし、問題の複雑さは、自身の専門領域の外にあることも多々あり、1人では解決できないかもしれないということなのだ。それ故に「なんとなく解決」することに慣れきっている人もいる。Windowsをアップデートしたら、たまたま直った、OSやフレームワーク、ライブラリをアップデートしたら偶然回避できた、キャッシュをクリアしたら偶然戻った、などのアバウトな解決法に我々は慣らされてしまっている。

実際に、もしかしたら、その問題もStrutsやJDBC周りの問題だったのかもしれない。

確かに、論理的な問題を追いかけて、追いかけて、最後の最後に持つ疑問が「我々では避けがたいバグなんじゃないか?」という結論になることはある。

でも、本当にそこまで突き詰めて考えているのか?

その際に、とにかく一つだけお願いしたいこと。

目の前の問題に対峙した時に、こういう時に間違っても「自分の担当領域は問題ない。お前らが悪い」と、このことの問題解決に無関心にはなってほしくない。

必ず、どんな時にも「自分が悪いんじゃないか、地雷を踏んでるんじゃないか?」と考える姿勢が重要だ。そしてそのことを論理的に相手にわかるように説明する。その説明の会話を通じて、問題解決のヒントに繋がることは多々ある。それらの姿勢が予期的に問題を発見する体質に繋がる。

それ故に、できるだけ自分の専門分野を超えて、問題解決をする取り組みができると良いとは思う。

先ほどの例で言えば、MySQLに発行されているSQLと、その時間をキャプチャして、タイムアウトとの関係性を時系列で追いかける。複数の役割の人が顔を合わせて、仮説と検証を議論しあい、解決を模索する姿勢だ。

無論、当時のリーダーとしての自分の無力さも痛感する。

10年以上経った今でも、いろんな問題に出くわすたびに、この時のことを思い出す。

決して、お客様に怒られたというわけでもないのだが、ちゃんと解決できていないということに苛立ちを覚える。

そういえば、モバツイをやっている時、Twitter apiの問題でモバツイが調子が悪くなった時には、8割9割ツイッターの問題とわかってはいても、必ず「自分ところのシステムに問題があるんじゃないか?」と原因を確認していた。

実際、api負荷が高くなった時にだけ、発生する問題があったりもするわけで、それによって改善したところもある。

年末対策でつけた「正月モード」がそれだ。紅白歌合戦の時は、アクセスが長時間に渡って集中するので、ずっとサーバを監視し、問題解決方法を追いかけ、年末のユースケースにあわせてデータベースにできるだけアクセスをしない機能をつけた。年末にしか起きない負荷問題を回避するためだった。

それも、紅白だから仕方ないよねてお酒を飲んでいたら、絶対に問題は解決しないし、それで困るのはモバツイのユーザーさん達だったわけだ。

今の仕事でも、スマホアプリとサーバサイド、フロントエンドデザインとサーバサイドデザイン、外部のクラウドサービスと自社のサービス、Webアプリケーションとインフラなど、さまざまなところで、チームとしての責任分界点が存在する。

もう少し視野を広げればマーケティングと開発、CSと開発、など組織における責任分界点も存在する。更に言えば、お客様のビジネスと、我々が維持管理しているシステムとの責任分界点も存在する。その際に互いの領域にも関心を持って、問題が起きたりしていないか?起きた問題をどう解決していくか?を考えなくてはいけない。

そこで、「相手が絶対に間違っている」と思い込んでたが故に初動が遅れ、実は自分たちのバグが引き金だった、というのでは目も当てられない。

いずれにせよ、このような責任分界点をまたいで発生している問題のとばっちりを受けるのは、お客様であるのは間違いないのだから、問題を適切に解決していけるのがチームで取り組むべき重要な仕事ということになる。

そこには、深夜も休日もないのだが、まぁそうは言っても携わっているのは人間であるし、会社員なのだからという部分もあって悩ましい所である。そのうちWebサービスの運用は、AIが自動的に最適な状況を維持するように、サーバ台数を調整するだけでなく、予期的に動作したり、警告を発生するインテリジェントなインフラの上にアプリケーションを作りこむ時代が来るだろうね。きっと。我々はそれにあわせてシステムをデザインするのが仕事になりそう。

たまに少しだけ、Webサービスという、ひたすら流れ続けるデータフローのシステムを維持、改善、し続けるのは人間には難しすぎるのか?、と思う瞬間もなくもない。

ま、それ故に、仕事として頑張る価値があるわけだし、そこにスキルとしての専門性があると信じて、自分を磨いていきましょう。

【PR】ご意見、感想などは是非、mstdn.fmのローカルタイムラインでお聞かせください