みなさんこんにちは。
私は プレイド のエンジニアの大平(おおひら) (@Victoria_Peak_) と申します。 7年勤めた野村総合研究所を辞め、2018/07〜現在まで 株式会社プレイド で勤務しています。
日々の活動内容(プログラミング・SaaS/SIer・ロードバイク・減量など)をつぶやいたりしておりますので、本エントリを読んで興味を持たれた方は、twitterでフォロー、リプライ、メッセージなどをいただければと思います。
基本すぐに回答します。
今回は下記の本ブログのメインストリームである「SIer/年収1000万を手放した私」シリーズをお休みして、スピンオフとして執筆します。
0.エントリ執筆のきっかけは twitter
今回のテーマで執筆しようとしたきっかけは、twitter上のこんなやり取りがきっかけでした。
全然話と関係ないけど、懐かしいワードたちです、今もやりますけど
— Kaz_Shio / SIerと自社開発 エンジニアのリアル：デジタル人材の探究 (@Victoria_Peak_) 2020年3月29日
私は、SIer の SE から webエンジニア に転職して一年半が経過しました。
このやりとりをきっかけに、自分の経歴を見直してみたところ、最近の業務でSIer時代の経験が役に立つことが多いことに気づきました。
SIerからwebエンジニアを目指している方、普段情報を頂いているお二方に協力できるならばと今回エントリを執筆するに至りました。
今回ご協力頂いたのはこちらのお二方です。
「SIer/年収1000万を手放した私」エントリをお読みいただき、実際にお会いして体験談をインタビュー頂いた炭山水さん
twitter.com
お会いしたことはないですが、以前よりやりとりをさせていただいていたモロー（毛呂 淳一朗）さん
お二人と話していく中で、参考となるような私の体験談がみつかりましたのでそれらを語りたいと思います。
この質問に沿って今回のエントリは下記の構成で執筆しています。
1: SIer時代の会社環境や業務内容、強みとは
2: 障害対応という花形
今回は障害対応をベースにSIerで培ってきたノウハウやスキルをエンジニアリングと掛け合わせてどのように業務に活かしているのか、なぜ私は障害対応をエンジニアの花形というのかをベースに綴っていきたいと思います。
更にSIerからwebエンジニアに転職した後、どのようなキャリアや業務を歩んでいるかは、世間的にも体験談が貴重だと認識しています。
これからwebエンジニアになろうとしている方の参考にもなればと思います。
- 何故webエンジニアへレーンチェンジしたか
本エントリで初めて私の記事を読む方がいらっしゃると思いますので、転職の経緯などは下記エントリをお読みください。
www.taihey-blog.com
- 苦しんだ後の実り
転職後、この1年10ヶ月webエンジニアとして実装をひたすら続けてきました。
実装自体は苦ではなかったのですが、プログラミングスクール出たくらいでは業務に相当する技術レベルまで身につかず、あまりのできなさに自分を責めてしまいました。
本当に辛かった。
人生で一番つらい時期だったかもしれません。
つぶれかけた事もありましたが、そのおかげで成長もしっかり感じています。
やっとここにきて苦労の実りができてきたのです。(↓エントリ参照)
www.taihey-blog.com
www.taihey-blog.com
苦しい時期を抜け得た実り。
それはコードをかけるようになった上で実現できることが、NRI時代の経験も大いに助けになりシナジーを生んでいます。まずはそのNRI時代の話をしていきたいと思います。
1：SIer時代の会社環境や業務内容、強みとは
- SIer 時代の会社環境を整理する
私が新卒から7年、どのような環境でどのようなスキルを身に着けてきたのか。
SIer/業務システムの前提条件から書きたいと思います。
オーダーメイドということと、SaaSということ
SIerは基本受託スタイルです。
作るのは基本的にお客さんのシステム(お客さんに資産性がある)で、システムの種類としては業務系が多くなります。
あまり詳しくはないのですが、1990年代〜00年代は、システムを新規でオーダーメイドして作ることがメインとなっていました。
そこから10年も20年も社会インフラとして現在もいろいろな社会のコア業務を支えることができています。
ただオーダーメイドは今の時代にはあってきていないと感じていて、最近はSaaSに置き換わってきていますが、本題から外れるのでそこはまた別で語ることにします。
このように業務系システムは少なくとも長く使われることを前提にしています。
ウォーターフォール/ビッグバンリリースということ、求められる高品質、納期は絶対。
もう一つ。
SIerの開発方式のメインはウォーターフォールとビッグバンリリースです。数十人から数百人を動員して数年後に一気にリリースしてきました。
まさに巨大建造物のようです。
業務は基本変わらないので、巨大建造物システムは設計や要件が肝となります。
数年前の設計や要件から基本的にそこから変わることはありません。
1990年代に作られたシステムはリニューアルを繰り返しながらも基本的には保守運用に支えられて稼働しています。
私は、ここがNRIの賢さだと思っています。
お客さんの業務は証券・金融や産業、流通などなど、関係者やフローが複雑な業務であるため、それを自体を理解するにも専門知識がいります。
その複雑な業務のオーダーメイドをオーダーメイドで構築するため、難易度が高いです。
さらに関わるお客さんは数百人を超えるケースもあるので（会社の基幹システムなのだから会社の全員がかかわるのは当たり前）さらに難易度があがります。
難易度は高いですが、ここを一度理解し、システムを構築できた会社だけがシステム構築や改修をメインで担当することができる(= お客さんと長い付き合いができる)のです。
参入障壁がかなり高いですが、社会を支えている企業が多いため、システム構築で実現する価値も莫大です。
社員として中にいても、NRIの中の方はとても優秀なメンバーが多いと感じました。複雑な業務の理解力とシステムのPM推進力、それが業務システムを支えているのだと思っています。
求められる高品質
複雑性の高い基幹系システムに求められるのは高い品質が必須です。
今思い返してみると、web業界から見てもめちゃくちゃ高いです。
業務はもちろん止めらません。密接に絡まった業務をほぼ止めずにシステムリリースし、運用を開始するのです。
プロジェクトの指標として作成される目標は、かなり難しいのですが、新規機能追加レベルであれば障害0を目指すこともよくありました。ほぼ障害0が前提です。
ここにはお客さん側の事情もあります。
QCD(品質・コスト・納期)のバランスを考えなければいけないのです。
一番きついのは納期ですが、法律改正への対応や、予算の関係でほぼXデーが固定になってしまうことです。
先輩方や、自分の経験をもってもかなり苦労した経験があります。
ここまでお話したように高複雑性/高難易度/大規模/高品質/絶対納期であるため、やり遂げるには高いコミットメントや業界への深い業務知識が必要ですし、顧客間の調整や内部外部のマネジメント力も必要になります。
金融の大規模システムをつくるということ
ここまでで業務基幹システムいかに難易度が高いかは理解していただけたかと思います。
さらに私は品質の厳しい金融系のプロジェクトが長かったため、求められるものが他の業界よりも一段高かったと思います。
例えば、新卒は流通、産業系の部署に配属されたのですが、在庫管理のシステムなどが多く、運用でカバー（=システムと業務が密接に関わっていない）のでまだ多少のバッファがあり、融通がききました。
ただ金融の場合は、エラーの一つやバグ一つで(桁ズレとか)物によってはかなり大騒ぎになります。
バーストエラーなどはもってのほかです。
このように業界や業務内容のクリティカルさ(お金なんてまさにそうですよね)と使われるシステムの密結合度によって違ってきますので、求められる品質も変わってくるのです。
- そんな環境の中での若手時代の仕事
保守でも高い品質を求められる
若手はド新規よりも既にあるシステムの保守運用や新規機能追加くらいまで、すでに機構ができた上での開発になります。
たまに大規模リニューアルや、基盤更改、会社間システム統合プロジェクトの「お祭り」にアサインされることもあるのですが、それも新規と保守がフェーズごとに別れていて、並行で動き続けます。
やはり保守は切っても切り離せないのです。
お客さんの複雑で専門性の高い業務システムを作ったのだから、これを改修しようとすると、誰でもできるわけではありません。
業務内容の理解や品質の担保など保守でも高い難易度が求められます。
障害もエラーも基本的に起こしてはいけません。
品質の高いシステムとお金
そのため、この高難易度のシステムを運用していくにあたって、長くお付き合いとなるのでSIerとして利益が多く出始めるのは運用のほうだったりする(運用でペイする)ケースも多くあります。
はじめは赤字をある程度出しても案件を取ったりするのです。
お客さんとしてもお客さん自身のビジネスを支えるシステムのため、長く使うのは当たり前で、そのシステムを動かし続けることによってお客さんも儲かる仕組みになっています。
ただシステムや業務難易度が高いので保守もレベルが高い対応を求められ、アホもできません。
みなさんが苦しむのはまさにここなのですが。。
辛いかもしれませんがその苦労がシステムの利益を支えています。
治すにもたくさんお金がかかります。
数行治すのにも品質を保つために対象機能の今まで起きた障害のすべてを起こさないようにテストを行いますので人手やパワーもかかります。
でもお客さんは障害をほぼ起こさずに品質高く改修をしたいので高いお金を出すのです。
同時にヘタなミスをするとめちゃくちゃ怒られます。私も何度もお客さんや上司に迷惑をかけました。
2：障害対応という花形
- web業界/自社開発でも保守運用は一緒
ここまでである程度私のSIer時代の会社環境や高品質大規模システムに関わってきた経験が見えてきたかと思います。
では保守運用活動にフォーカスしながらweb業界での保守活動について見てみましょう。
炭山水さんのツイートをお借りすると保守系の作業はこんなカテゴリができます。
- 監視 - 障害対応★ - 自動化できてないとこの運用 - 保守開発
現職の自社開発でも、SIer時代と変わらずこれらも泥臭くやります。
毎日監視でアラートを検知してトリアージしますし、障害時には社内エンジニアがわらわらと slack 上に集まって対応します。
機能を担当する人やオーナーにはシステムが大変な場合は電話などでアラートが通知されるようになりますし、深夜に対応することもあります。
自動化できない箇所は日々 esa やサポートサイトにアップデートしますし、機能開発でもβ版をリリースして実績を増やし、パブリックの v1 リリース後には安定稼働までのチューニング、ユースケースによって発生するバグの対応などの保守開発(弊社では「磨く」という)をしばらく行います。
今回は私の直近の役職（インシデントマネージャー）と直結するため、例として障害対応について細かく書きたいと思います。
- 障害対応フローノウハウをweb業界でも転用する
障害が起きたときは検知→影響調査→原因特定→復旧作業→根本対応→是正→並行で報告を行います。
下記の図のように結局はお客さんへの報告を密に行わなければいけません。
図に書くとこんな感じ↓です。
こちらはインシデントマネージャーを始める際に私のノウハウをweb業界向けに整理し直したものです。
この図の説明は長くなってしまいますので割愛します。
SIer時代担当していたシステムは銀行系・金融系が多かったので、これを分単位、時間単位で数日行います。
大きい障害であれば数週間単位で行います。
自分がメインで担当していたシステムであればすべての指示出しと内部/顧客の調整・報告を行います。
システムの理解、業務への影響、役員レベルから担当への調整、パートナーさんへの指示、実行、報告、影響調査などなど。。。
web業界用にアレンジはしましたが、やっている考え方自体はほとんど変わりません。
「正しい情報を正しく集めて統制すること」これだけです。
SIerでの経験がこのまま今でも活きています。
- 実装経験と幅広い知識が必要
ここまで書くと結局webエンジニアになっても実装できないのではないか、と思われるかもしれません。
ただ、この仕事にはコードを書く経験とビジネス/PM経験すべてがあるからこそ、かなりのスピード感でできる仕事だと思っています。(ちなみに自動化の開発も私が行っています。)
だからこそポジションが取れるのです。
私もこの1年半コードを書きまくり、KARTE を理解し、アーキテクチャを理解し、コードを理解し、開発フローを経験し、データ構造を理解することができたためにこのような付加価値が産めるのです。
必要な経験としては下記が挙げられます。
- 障害の内容や仕様、クリティカル度合いを的確に把握するプロダクト仕様、アーキテクチャやシステム理解 - エンジニアが何を考えどうやって進めようとしているかのエンジニアカルチャーの理解 - 障害時にビジネスサイドの情報統制ができるPM力 - 組織や人、情報の動きの判断基準を決め、整理するコンサル力 - お客さんの肌感や期待値を想像し、説明や報告、情報伝達方法を考えることができるビジネスセンス - 障害の内容をわかりやすくビジネスサイド向けに説明する翻訳力
幅広いですね。特にビジネスサイドとエンジニアのコミュニケーションや情報統制などは片方の経験だけだと難しいと思います。
障害に対して的確な指示、情報統制がとれて数十人にも及ぶ社内・関係者含め、滑らかに収束まで遂行していく感覚は、達成感と自分が成長したことを感じさせてくれます。
司令塔のようにエンジニア、ビジネス問わず幅広い知識が必要だし、自分がプレイヤーとしても実績がないといけません。
そうです、ビジネスを支える障害対応は花形です。
- 私が見出したのはビジネスとエンジニアのハブ、というポジション
情報を正しく伝えるには、最終的に顧客に事象や対策を伝えるのはビジネスサイドですから、エンジニア用語だけで説明しても正しく伝わりません。
そのため、ビジネスサイドとお客さんが理解できる内容に翻訳、整理が必要となります。
例えば、もしビジネス側経験だけであれば、システムで起きている正しい情報を集められない(理解まで時間がかかる)し、エンジニア経験だけであれば、ビジネスの期待値や顧客への伝え方を誤ってしまうこともあると思います。
翻訳できるハブになるにはビジネス・エンジニア両方の経験が必要なのです。
私はビジネスと実装経験を両方積むことで独自のポジション「ビジネスとエンジニアのハブ」を取れていると感じています。
最後に
今回のエントリは、質問をきっかけにして、障害対応にフォーカスし、SIer時代のスキルをどうweb業界でも適用させることができるか、について書いてきました。
次回は自社開発とSIerの経験から見えてきた、それぞれのビジネス構造の違いと、自分をどのようにフィットさせることで昇華させていくのかを綴っていきたいと思います。
P.S.
日々の活動の記録、転職やその他仕事についてご興味があれば下記またはフォローをよろしくお願いします。
※2020/05/02追記 弊社CPO柴山さんからコメントもらいましたので共有します。】FBより引用
「Startupでも、攻め(change)を支えているのは障害(error)とその期待値と契約を どうバランスしつつ解くのかってとこでそれが何よりも大事なんだと思うんだけど、 その花形感は伝わりづらい。 でも、もうここで勝負は決まってるんじゃないかっていうくらい大事。 そして解く問題が異常にむずいのでここをやれる人は全然いない。」
経営者目線からだと、障害対応は大事なのはわかっているど、考える範囲や経験が幅広く必要になる、本当に不足している人材像なんだと思います。
開発でも何でも、スピードが生命線であるスタートアップの、足枷を潰していく守護神のような仕事なのだとこのコメントから改めて思います。
twitter.com
www.wantedly.com
