約1年間SI事業部で働いてみて
丁度前職を退社して今の会社に入社して、およそ1年間SI事業部に所属し約4社フロントエンドエンジニアとしてプロジェクトにジョインさせていただいて感じたこと、学んだこと、良かったこと、悪かったこと諸々を備忘録的にまとめていこうと思います。
(3年や5年選手の方々はもっと多くのことを感じていると思うので、初学者レベルのエンジニアの感想として捉えてもらえたら嬉しいです。)
ざっくり自分について
約1年と半年、イベント企画・制作・運営企業のPR事業部に所属し自社のイベントLPやWordPressを用いたポータルサイトをおよおそ30~40サイトディレクション〜制作・運用保守、デザイン、サーバー運用等々全般を担当してきました。
そこでは基本的に100名前後の社員がいる中でWeb担当は自分のみ、他の社員は問題なく公開されていれば問題ないスタンスで細かい運用方法等についての興味は圧倒的にないスタッフの方が多く当たり前の状況だったので、これ以上自分のステップアップには繋がらないと感じて転職しました。
その為、まずどんなサイト制作やサービス開発、構築、運用等々が業界ではあるのかをまず知りたいと考え、転職段階でSI事業部へのジョインを希望しました。
SIとしてジョインした企業
大手企業、自社サービスを運用している企業、受託制作企業と色々な企業に参加させてもらいました。
その間、次のジョインさせていただく企業が決まるまで突発的に自社の受託案件の運用保守を一時的に参加させてもらったりと、この1年で何だかんだ様々な案件に参加させてもらいました。
担当箇所も新規開発、運用保守、デザインも担当させていただいたり、上流工程からジョインさせていただいて一時的にPMを担当させていただいたり、文字通りプログラミングだけに従事させていただいた案件もありました。
自社の運用保守では、クライアントの方やサーバー企業の方とやりとりさせていただいたりと矢面に立ってコミュニケーションを取る機会もありました。
良かったこと
まず良かったことは文字通り、様々な案件にジョインさせてもらえること。
自社内にだけいたら、受託チームは受託チーム、自社サービスチームは自社サービスチームの案件を基本的に担当するので、開発手法や運用手法もある程度固定化されたものに則ってプログラミングやデザインを担当していくことが往々にして少なくないと思います。
SIとして色々なチームに所属させていただいて担当していくと、それぞれに合った運用方法や開発手法を都度選択していくのでそれぞれどういったメリット・デメリットがあるのか、どういう案件にあうのかなどを考えるきっかけにもなるし感じることができました。
プログラミングひとつとっても、案件によりJSのフレームワークをゴリゴリ使ったり、ejsやpugなどのテンプレートを使用したりとひとくちに『フロントエンド』と言っても様々な手法に触れることができました。
この辺りも、自社内に固定化されてしまうとあまり拡張しづらい部分もあるのではないかなと（個人的に）感じました。
技術的なところで言えば、『一人のプロ』としてジョインさせていただいていたとしても圧倒的にレビューし合えたりすることも企業によってはあるため、技術力向上のチャンスも0ではないと感じました。
もちろん基本的には『一人のプロ』としてジョインするので、レビュー等がなくゴリゴリ開発していくというパターンが多いと思います。
僕は上流工程やデザインも担当させていただけたのもあって、エンジニアリングに直接的に関係ない（と感じる人もいるであろう）箇所についても考えたり、感じるきっかけになりました。
具体的に言えば、『本当にエンドユーザーに届けるために機能改善なのか』『その機能は本当に必要なのか』『このUIは本当にこれで良いのか』『ターゲット層に対してこの画面遷移、処理で良いのか』『この開発ペースで完了することができるのか』等々プログラミングに直接的には関係がなかったりする箇所についても感じたり考えることができたと感じています。
例えば『このコードの改築の影響範囲はどうだろう』とか『このフレームワークは運用保守に最適なのかどうか』などはどのステータスにいても考える切っ掛けにはなると思います。
それはチーム運用や、チームとして何かをしていくには必ず必要な視点だからです。
また、横のつながりは圧倒的に広がります。
普通にイベントに参加することで広がることも多くありますが、SIとしてジョインさせていただくとそのチームメンバーと開発をともにしていくのでそもそも繋がれるというのは大きいです。
そこから飲みに行くような関係になったり、お仕事を頂戴できたりする機会も増えます。
悪かったこと
良いことばかりでもありませんでした。悪かったなと感じることもあります。
まず商談で伺っていた話と実情が違う、というのが大きく影響しました。
商談は、企業側は自社の課題を解決できる人材かどうか、チームの和を乱すような特殊な人間性をしている人ではないか等々を判断していただく場になっています。
ジョインする我々エンジニア側も自分に見合った案件か、やれそうかどうかなどをこの場で判断しその後返答をします。
この時伺っていた内容といざジョインさせていただくとそれ以上に大きな課題を抱えている、もしくはそことは違うフェーズに課題を抱えていらっしゃる企業様も少なくなく、ジョインさせていただいてからそういった課題に直面し早めにチームを離脱される方も少なくなりませんでした。
またそもそも『パートナー契約の人材』に求めるレベル感の違いなどもあり、ハイスペックな人材を求めている為に初期契約時の3ヶ月などで離脱というケースもありました。
そもそも商談のときと実際の現場との乖離は多少やむを得ないなとも感じました。
気にし始めているとキリがないなと。
とは言え、SIとして行ったら行きっぱなしにされてしまいフォローアップがされなさすぎると問題になると感じました。
きっと現場現場でエンジニアリング以外にも課題解決に様々な手法で取り組むことも不可能ではないはずです。
ただ、（僕の場合は）その場で解決に注力するために労力を割きたいのはあくまでエンジニアリングだった点とコンサルティングであったりあまりにも別フェーズに関することで解決に迎えそうだと判断したこともあった為、企業からジョインしているという点もあって契約期間で離脱させていただきました。
本来これがフリーランスであったなら、契約上の問題もあるためぐだぐだ言わずに頑張らないといけなかったり、もっと別軸の要素もあいまってきて簡単に答えは出せないと思います。
また、今回特に企業からSIとしてジョインしていたので余計に感じたことだと思いますが、帰属意識は圧倒的になくなっていきます。
基本的にSIとしてジョインし、各企業に出向させていただいているとよほどなことがない限り基本的に自社オフィスへ戻ることが少なくなっていきます。
するといくらSlack等のコミュニケーションツールで繋がっていたとしても圧倒的に自社の他メンバーとのコミュニケーションを取る機会が減っていきます。その為、自分はどこに所属しているエンジニアなのか等々考えてしまいます。
ある意味いいきっかけではありますが、元々目的があり所属企業に入ったエンジニアからしてみれば辛い現実になりうると感じました。
学んだこと
まずもってエンジニアリングの知見は広がります。
例えば僕はフロントエンドなのでJavaScriptを多く使用しますが、JSの場合圧倒的に一つの処理を実行するのに書き方が様々あるので余計に勉強になります。
特にES6や、ES7等々最新の書き方を追うのもなかなか大変だという人にはとても勉強になるのではと感じました。
また、ReactやVueなど最近流行りのJSフレームワークの記法もGoogle等で検索しても英語の記事が多かったり、なかなか学習がし辛いと思いますが、そういった面も実務と掛け合わせて学ぶことができると感じました。
特にどういった処理がそこでされているのか、例えば単に『〇〇をdispatchする』とか書かれていても、dispatchって何？となる人も少なくないと思います。そういった面も一人でGoogleで調べながらやるよりも圧倒的にスキルアップに繋がります。
いざSPAで開発しようと決まっても、サーバー側はどういった形式で保存するのか、SPAの技術選定は何を基準に選ぶのか、拡張性は問題ないのか、SEOは担保されているのかなど様々な要因がある中で何を決め手にそれを選ぶのかなど案件や企業の状態によっても様々です。
Reactで開発をすると記法のマナーが整っているため、途中から開発にジョインしてもある程度は開発着手までの工数は低く抑えられる印象です。
Vueの場合は型定義等の記法も初期から入っているわけではなかったりある程度の緩みがある中で開発ができるため、できるだけ初期構築段階で開発ルールの設計とドキュメントの作成が必要になってきます。
また拡張性を担保するなら、公式のプラグインで多くの必要パッケージが担保されているVueが向いているケースもあります。
Reactは記法が整っている反面フレームワークではなく、ライブラリという立ち位置な部分があり、一部分への適用などに向いている部分があります。
この辺りは一括でReactで開発を進めるか、もしくはバックエンド側の言語のMVCと絡めてReactを採用して開発をしていくのかという判断が必要になってくるなと感じました。
またチームとしての開発手法や、運用方法、細かいところで言えば使用ツールやドキュメントのまとめ方一つでも様々な手法やツールが存在しているのでそれぞれの特性や使用方法、良いところ悪いところも学べたと感じています。
僕が参加させていただいた案件は、スクラム開発的に機能ごとにチケットを切り開発を進めていきつつ、全体の進行としてはウォーターフォールで進めている案件に参加させていただいてきました。
その中で、チケットの内容がスパイラル開発の拡張的な内容に変更していきつつ走りきった案件もあれば、後半からはメインWBSで管理していきながらチケットの工数メインではなく、納期メインで機能開発を進められるところから進めていった案件もありました。
スクラム開発は本来機能単位でチケットを切り、対応していく為細かくリリースを繰り返す中で修正対応にも柔軟に対応できるように進めていくのが強みになってくる開発手法なので、新規事業開発や大規模なサービス開発など工数管理が明確にやりづらい案件にはやはり向いていないのではないかと感じました。
ウォーターフォールはその進め方が出来たら最高だなと非常に感じましたが、ドキュメントの用意や管理、メンバーのアサイン等々考えると予算が多い案件にしか向かないのか？と感じました。
逆に、人数が少ない時のウォーターフォールはその分一つ一つのフェーズである程度工数が担保されているかエンジニアはエンジニアリングに集中して出されたアウトプットをPMないしリーダー層がドキュメント等仕様としてまとめていく工数がある状態でないと難しいのかなと感じました。
(もう少しうまい回し方している案件でもお仕事してみたいところです。)
ウォーターフォールは本来各工程単位で仕様を確定させていくものになるので、後戻りをしない(スクラム開発は細かく開発とリリースをしていく)のが特徴ですが、ここでトラブルがおきたケースとしてそもそもPMがエンジニア知識や技術がないPMが担当した案件がありました。
そもそもこの仕様がある程度のユースケースを担保できた仕様になっているのか、顧客との共有の中での漏れはないのかなどの見積もりが漏れていたりバックエンド側で実装されたものがフロント側に渡ってきた時に問題ない状態なのかなどの判断するフェーズもなく進んでしまいその最中にも仕様追加が入ってきてしまった為に、本来の工数見積もりを破綻させつつ細かい単位で文字通りのスクラムになりました。
この時、『クライアントが求めている機能』なのか『サービスとして必要とクライアントが感じている機能』なのかの精査をすることなく仕様追加として工数見積もりまで出してきてしまい、納期の変更はかからないので結果的に開発者の首が絞められるという状態に陥ってしまいました。
にもかかわらず、細かい顧客との共有はできずに進んでしまったために最終的に炎上してしまった案件もありました。
何よりサーバーの用意等々顧客との確認箇所の用意が遅れに遅れてしまった点など開発手法の選定以前の要因で炎上してしまっていたとも考えているので力不足さも感じた案件でした。
また、新規事業等の時は往々にして実装イメージが出来ていても細かい部分で実装経験がないであったり、組み合わせた時に問題がないのかどうかが判断出来かねる時も出てくると感じていて、そういった時に予定工数と一部スパイラル化時の工数の管理方法が重要になってくるなと感じました。
開発担当者や開発チームのリーダーがチケットを切らないケースもありましたが、この場合本当に必要なチケットが何なのか、何が仕様として確定していない為に開発が進められないのかなどチケット同士の関連度や、今チケットが誰担当でなにのフェーズで止まっているかなども判断しづらいケースも発生したりとツールと開発手法の組み合わせ方は案件の進捗や見えないタスクの工数による見えているタスクの工数への影響も出てきてしまうと感じました。
受託制作の新規制作の時、100%既存の事例がある技術のみで実装できるとは限らないのがWeb制作です。
類似案件はあっても、個々に課題を感じている箇所が違う為全く同じサービスを作るということがない為、必ずどこかで実装経験がないであったり組み合わせ経験がないといった箇所が出てくると思います。
こういった時はスパイラル開発で設計とプロトタイピングを繰り返すフェーズを一度挟みつつ進めるタイミングも出てくるのかもしれないなと感じました。
ドキュメントに関しても運用保守では、基本的に更新に工数をかけているわけにもいかないケースがあるため、最新のGithub等で管理しているソースを読んでもらい理解してもらうのが一番だと思います。
新規事業開発の初期フェーズの段階では誰もが更新しやすく管理がしやすい箇所で一元管理するのが好ましいと感じました。
Redmine、GithubやwrikeやBacklog等の工数管理ツールなどと併設されているwikiなど様々な箇所で管理する方法が用意されています。
それぞれに適した手法とツールで管理していくのが好ましいです。
これがバラバラになってしまったり、決まったフォーマットに則らずに管理していってしまうと結果的に引き継ぎのフェーズや新規メンバージョインの時にインプットに工数がかかってしまったり、ちゃんとインプットできないまま着手してもらわざるを得ない状況になってしまったりします。
この辺りはもっと知見を貯めていきたいです。
まとめ
企業からSIとして出向する場合は
･ 個人的な目的を裏設定として決める
･ 所属企業のチームとしての目的を明確にする
･ 期間を決める
など何かしら明確に決めたものを引っさげて出向するのが良いのではないかと感じました。
間違いなく旨味はあるし、学びもメリットもあります。
ですが、それを殺してしまわないように抽象的な状態のまま出向しない方がより楽しめるのではないかと感じています。
これからSIで頑張っていこうという方の参考になれば嬉しいです。
この記事が気に入ったらサポートをしてみませんか？