SIer時代に学んで今でも役に立っていること、Web系の会社に入ってから考えを改めたこと

こんにちは、株式会社fluctで fluctSSPの広告配信に関わっている坂本です。

私はfluctでは新しい広告(PMP, NativeAd)の追加をしたこともありましたが、ここ1年半くらいは自分で追加した広告機能や既存機能のサポートエンジニアとして働いています。
(インフラの保守・運用は専門部署があるのでおまかせしています)

経歴

SIer(金融・ECサイト開発等)のピラミッド構造で開発に従事していた6年
Web系の会社(VOYAGE GROUPとは別会社)にてSESとして仕事をしていた4年(ここ終わりでVOYAGE GROUPに転職)
Web系の会社(VOYAGE GROUP/fluct)にて正社員として2年半~現在に至る

今の自分の行動指針はSIer時代に培われたものがほとんどですが、Web系の会社に入って考えを改めたものもあるので、自分のスキルの棚卸しを兼ねてそれを整理してみます。(サポートエンジニアに限った話ではなく、いちエンジニアとして心がけているものです)

現SIerの方が転職する際のお役に立つかもしれませんので、自分が転職した時のことも少し書いてみます。

おそらく殆どの人にとっては当たり前すぎることしか書いてないと思います。
技術的な話を期待されている方、ゴメンナサイ。

経歴
Web系会社に入ってからSIer時代の経験が役に立っていると思うこと
Web系の会社に入ってから考えを改めたこと
- 1. バージョンアップへの追随を怠らないこと
- 2. 小さく・早くはじめるために、さくっと作る
おまけ1 : SIerからWeb系に転職しようと思った時にどう動いたか？
おまけ2 : SIerから今の会社に転職して良かったこと、微妙だと思っていること

Web系会社に入ってからSIer時代の経験が役に立っていると思うこと

1. 自分が関わっているサービスを使っている人と綿密なコミュニケーションをとること

　幾つか理由があるので箇条書きにします。

理由１. 使う人(社内・社外問わず)がどう使っているのか？を把握するため。
ヒアリングをして分かる話だけではなく、問い合わせや小さな障害対応などを通じて業務理解・ユースケースをどれだけ深めるか。という二つの軸で情報を集めることが大事だと考え行動しています。どちらかだけでは機能改修の時に、微妙な結果(※)になったことが過去にあったためです。
- 微妙な事例１ : 社内向け画面の改修時にユーザ部門の意見を取りまとめてしまったがゆえにニュアンスがぼやけてしまいユーザ部門の実業務と乖離してしまった
- 微妙な事例２ : 保守対応時にユーザの意見をそのまま聞いてしまい、ツギハギだらけの機能になってメンテナンスしづらくなった
また、こまめにコミュニケーションをとっていると分からない言葉が出てきた時に都度確認できるので、DDD界隈でよく話題に上がる「ユビキタス言語の整理(辞書化)」を自然に進めていくことになると考えています。
Backlogなどを使いノウハウや問い合わせ内容を貯めていければ同じ問い合わせは減らすことも出来ます。
理由２. 相談しやすい関係性を構築するため
誰もが思っていると思いますがエンジニアと非エンジニアの間には壁ができやすいものです。自分が過去に関わって壁を放置したプロジェクトはうまくいっているものは無かったです。
「管理画面の余り使わない画面の使い方がわからない」みたいな比較的影響度が小さいことがわかっている問い合わせだったとしても、積極的に関わりに行くことで「この人には相談してもいいんだ。」という気持ちになってもらい、アラート検知システムに引っかからない何かがあった時に迅速に情報をあげてもらえるような関係性を保つことが重要。(検知システムが無くていいとかザルでいいという意味ではありません。)
では、その時にどう振る舞えばいいのか？というのは以下にまとまっています。特に5. 常に機嫌よくいる。(≒聞きやすい雰囲気を作る)が一番大事だと思っています。が、忙しいとすぐに崩れてしまうので注意が必要（自戒を込めて...）。

techlog.voyagegroup.com
理由３.普段の小さなお問い合わせに対応することで、障害対応のスキル/ドメイン知識を少しずつ身につける
- 影響範囲の特定
- 調査力
- 一次対応(ビジネス上システムが適切にに動くためのパッチ)の立案
- 根本対応の立案と補償等の影響
- サービスとしての危険度の判断力(ドメイン知識)

2. 全体像を図示して関係者間の認識齟齬を少なくすること

SIer時代、新しい部署や会社に入った時に担当するシステムの概要図すらなくて概要を把握するのが大変だったという経験があったことから、自分で色々書くようにしています。
私は文章ではなく図示することの方が好きです。理由は図のほうが情報量が多く誤解を招かないためです。
自分で書いてみて、以下の価値があるのではないかと考えています。
(存在する事自体の価値と、自分が書く過程において生まれる価値の二種類)

機能追加のときに関係者全員で同意をとるのに理解してもらいやすくなります
他のエンジニアにコードレビューしてもらう時に概要把握してもらいやすくなります
プロジェクトに参入してきた誰かに説明するときに使うことで人に説明するコストが下がります。(自分が思い出すコストも下がります)
書くことで、俯瞰的な視点でサービスを捉えやすくなり、障害対応時の影響範囲の確定や、計画・見積もりが正確になると考えています

注意点

細かく書きすぎないこと。
細かすぎるとコードとドキュメントの乖離問題につながるので、私は以下で十分だと思っています。(これらでもメンテナンスしないとすぐに乖離していくので常に更新するようにしています)

業務フロー図(プロセス図)
ユースケース図
ER図 <= エンジニア向け

fluctでは新卒・中途に関わらず新しくエンジニアが入ってきた時、「エンジニアクルーラリー」という
`機能毎の説明を一番詳しい人がリレー形式で行い、システム全体の理解を深めてもらう` という取り組み( 全体概要 -> 管理画面 -> 配信 -> バッチ -> インフラ ... と説明)をしていて、自分が説明する際にこの取組で書いた図を使うようにしています。

3. 自分が作ったものを見届ける(サービスクローズに立ち会う)こと。

SIer時代に追加開発するチームと保守するチームが違っていることが多く、追加開発するチームの品質が一向に上がらないことがありました。
保守チームにいた自分がその当時の先輩に「どうして追加開発チームの品質が良くならないのか？」と質問したときの答えが「自分で作ったものを見届けないエンジニアは成長しづらい。」と言うものでした。
新規開発だけしている人は運用時のPDCAに参加するのが難しいので、自分の作るものの品質を改善する機会を失っていることになります。
私は保守運用側の立場なので、開発だけをやって離れてしまったエンジニアにこんな改修があったよ。ということをなるべく伝えるようにしています。そのエンジニアが次の開発を行う時に頭の片隅においてもらえるように。
Web系の会社では比較的スクラップ・アンド・ビルドが多いのでその機会には恵まれているのではないかと思います。
使われなくなった機能のコードを消すことが `尊い` と言われますが、その機能が何故使われなくなったのか？まできちんとふりかえるとより効果があるのでは？と私は思っています。
fluctに入ってからは中々見届けることが出来ていないのですが、若い子たちにそういう動きを取ってもらいたいと思っているので、促すようにしています。

Web系の会社に入ってから考えを改めたこと

1. バージョンアップへの追随を怠らないこと

コアシステムのバージョンアップでも社内向け管理画面でも、テスト/監視系/リリースフローが充実していれば同じように積極的に動くべきだと思います(メジャーバージョンアップについては検討の必要あり)。
SIer時代は最初に作った時のバージョンで塩漬けにする事が多く、塩漬けにしたことで後々辛くなることが多かったのでこの点は考え方を改めました。

具体的には以下参考。

techlog.voyagegroup.com

2. 小さく・早くはじめるために、さくっと作る

「どうすれば、新しい広告(サービス)をユーザに提供できるのか？」をビジネスサイドの人間と一緒に考え、「最初は手数を減らしてでもとりあえず動くものを作れるか？」を考えること。
SIer時代はどうしても「納品」という概念があったので(チームが別なことが多い)納品後のことまでセットで自分で調整するのは難しかったのであまり意識していなかったのですが、
全て自分でやらないといけないWeb系ではリリース時に必要最低限なものだけを作って後は機能追加でカバーするということを最初はうまく切り分ける事ができていませんでした。
今は少しずつ出来るようになってきているかなと思っています。

おまけ1 : SIerからWeb系に転職しようと思った時にどう動いたか？

転職エージェントさんに相談した上で、自分の強みが何か？を考えてアピールするようにしてみました。
(転職しようと思ったのは2014年6月、実際に転職したのは2015年2月のことです)

VOYAGE GROUPではない広告配信している会社に合計で4年程SESとして仕事をしていたので広告配信の業務知識があった(SESの前に少しやっていたのも併せると5年弱の経験があった) => そこを押してみようと考えた。
SIer時代に10Projectほど追加開発・保守をバランス良く経験して、このプロジェクトが何故、成功・失敗したのか？を色々見る事ができた。
そこから汎化できるようになっていた(当時の上司から、「失敗したときだけではなく、うまく行ったときにもきちんとふりかえりを行い、うまく行った理由も考えるといい」と言われ、それを自分の中に積み重ねることが出来ていたので自分の中で汎化できていたのではないかと思っています)
私は「XX(言語、インフラ等)がやりたい <<<< 使ってくれる人の声を聞いて仕事がしたい(裁量権をもって仕事がしたい)」と普段から考えています。
保守・運用っぽいことをやりたがるエンジニアは少ないのでそこもアピールしてみました。

おまけ2 : SIerから今の会社に転職して良かったこと、微妙だと思っていること

良かったこと

自分と同じような考え方を持っている人と一緒に仕事ができること
エンジニアにかかわらず若くて優秀な社員が多い
が、運用経験値は多いとはいえないので彼らをサポートするという自分の立ち位置を見つけることが出来た。(若い子たちからすると口うるさいおっさんだと思ってるだろうけど...)
正しい(≒やりたい)と思ったことを実行に移すのが比較的容易
VOYAGE GROUPはかなりハードルが低い方だと思う。特にfluctはVOYAGE GROUPの中でも低く、Rustが本番サービスで動いていたりします。
勉強会に行った時に、取引のある同業種のエンジニアさんたちと交流が取りやすい(SES時代にはビジネス的な話をするのは難しかった)。
VOYAGE GROUPに猛者がいっぱいいるので、お話する(あるいは誰かと誰かが話しているのを聞く)たびにいろんな刺激を受ける事ができる。
(猛者 : 機械学習に強い人、言語の最新動向に精通してる人、@t_wada (※)等々) ※ @t_wadaはVOYAGE GROUP内のfluctを含む幾つかの子会社に週に一度ずつ来ていただいています
事務方が素晴らしい。(改善要望を出すと早いと当日中に改善されたりする)