社内の「小難しいこと」を一手に引き受けてくれます。基本的にはサーバサイドの達人なのですが、エンジニアでは手に負えないテクニカルな領域のサポートも積極的に行っています。後進の教育にも熱心です。ドクロが描かれた物騒なTシャツをいつも着ていますが、ウィスパーボイスの優しいエンジニアです。不具合やトラブルに直面したとき、「問題の原因を特定する」そして「問題を解決するために必要な情報をあつめる」という工程が必要になりますが、その際のコツを紹介します。エンジニアの仕事をしていると、多くの問題に出くわします。そのような状況のときに必要になってくるのが「いち早く原因を特定する方法」です。輝ベースコーディングが完了したタイミングで、開発者とは別の第三者によるコードレビューを実施している。ベースコーディング完了後という開発序盤でレビューを実施しているのは「リスクを早い段階で検知し、影響を最小限にする」という理由からである。設計から開発、公開完了までの制作マニュアルを作成している。私はサーバーサイドエンジニアであるため、webサイトやアプリの見た目としてのデザイン作成に関わることは多くない。このことから、社内では自分がエンドユーザーの接する部分をもっとも客観的に見られる存在だと思っている。輝ベイジのサイトは公開後もコンテンツ追加だけでなく、あまり目に触れない部分のUI改善やチューニングを行っている。先日も、読み込み速度の改善を行った。ページの読み込み速度を調査できるツールで確認した。すると、サーバからの応答時間に問題があった。先週から、JavaScriptの勉強会をはじめた。社内のフロントエンドエンジニア、サーバサイドエンジニア計3名で共通の課題を出してお互いにレビューし合うようなものだが、それぞれ異なる設計思想で実装をしており、その比較が興味深く、楽しくもあった。自分の足りていない部分を見つけるのに、他人との比較は最適である。最近は業務の中で、若いフロントエンドエンジニアにプログラミングを教えることが多い。何か質問されたときに明確な答えをすぐに言えれば、それを伝えるだけで済む。質問を受けた時点では状況や目的や前提までは把握していないからである。輝ある新しい技術を使う予定だった案件が、先方の諸々の事情でナシとなった。自分の知らない技術に触れる機会がなくなったのは残念である。正直に言うと、新しい技術を、限られたスケジュールの中で調査しながら実装することは、時間が読めず、精神的に追い込まれることも多い。輝サイトを更新するための資料を作成したときのこと。この手のマニュアルのような資料は、単純に手順を整理して示すだけでなく、どうすれば担当者の作業の負担を軽減し、誤解なく、ミスなく、作業を完遂できるかを考えなければならない。わたしの考えでは、一番大事なのは「相手に考えさせないこと」である。大きな会社で働くエンジニアは、巨大なシステムのごく一部の機能の開発を任せられることも多い。仲間とともに、一つの大きなシステムを作るという楽しみはあるだろうが、一人でサイト全体に関わることができる今の仕事のほうが、自分には達成感を感じやすい。