開発以外のプロセスが、開発での考え方を変えてくれた。アプリ特化型エンジニアから転身したITコンサルタントの独白

転職を決めたのは、開発以外のプロセスに携わりたかったから

新卒で入社した会社は、SAPという基幹パッケージシステムを取り扱っている会社でした。導入よりも保守の追加開発が多く、要件定義から開発までを担当していました。

20代半ば、友人との会話の中でWeb系への憧れが生まれ、Web系のSIerに転職。エンジニアとして、ECサイトやWebアプリケーション等の開発を行いました。当時は、フロントとバックエンドが完全に分離している現場が多く、開発環境や本番環境などの環境構築も、専門のインフラ担当者がいました。そのため、アプリの要件調整、開発、テスト……と、アプリ特化のエンジニアとして働いていました。

イントリックスの現チームメイトが聞いたらギョッとするかもしれませんが、GA（Google Analytics）という言葉は「聞いたことがある」程度にしか知りませんでした。「DockerやLaravelはわかるけれど、CMS？PIM？DAM？？」と、今では当たり前に使っている用語も、なじみのない単語でした。

転職の直接のきっかけとなったのは、前職で最後に携わった案件です。たまたま、機能改善の提案や新規企画を討議する会議に出席する機会が何度かありました。その経験が私に、「アプリ開発以前から、開発に至るまでのプロセスに関わってみたい」という風に思わせ、転職の決断に至りました。

変わったのは、これまで何度も繰り返してきたフェーズでの考え方

イントリックスでは、複数案件に並行して参画することも少なくありませんが、私が初めて担当したプロジェクトは、大規模なWebサイトのリニューアルだったため、入社後の２年間、メインのプロジェクトは一つでした。チーム体制は、私の後ろにシニアコンサルタントとCTOが控えてくださっていて、とても心強かったです。

私の仕事は、要件定義の前段階にある、要件定義のための計画フェーズから始まりました。前述した通り、私はプロセスに興味があって転職したので、顧客ニーズをヒアリングしながら進行していく過程が、とても新鮮でワクワクしました。

ITコンサルタントの立場で考える主たることというのは、例えば

• ・非機能要件をどうするか
• ・リニューアル後のシステム全体像を考えたときに、CMSはどれを選定したらよいか
• ・検索機能はどのように実現するか
• ・製品情報はどこから取得するか

こういった内容になるのですが、プロセスに携わると、

• ・既存ユーザー向けなのか、新規ユーザー向けなのか
• ・既存ユーザーの年齢層はどれくらいか
• ・販売している製品の使用環境はどのようなものなのか
• ・ユーザーはどんなタイミングで問い合わせたくなるのか
• ・バラ売りをしたいか、ライン売りをしたいか
• ・どういう切り口で製品を選ぶ人が多いのか

こういった話まで聞けるようになります。最初はそれを単純に「おもしろいな」と思っていたのですが、後々、「仕様がブレなかったのは、このおかげか」と気が付きました。

興味深く思いながら参加していた議論は、実は仕様の根幹に関わる非常に重要なものでした。

経験してきた分野でこそ、学びが多かった

意外だったのは、今まで自分が開発者として何度も関わってきた「要件定義からリリースまでのフェーズ」でこそ、学びが多かったことです。

特に自分の中で大きく変わったのは、データに対する意識です。エンジニアとして働いている時、データベースに入れる情報はある意味フラットでした。型は何か、数値型か、整数なのか、小数点は？マイナスは？何桁なのか？必須なのか。データベースを構築する上で、形式が整ってさえいれば、それ以上のことをあまり想像しなくてもよかったわけです。

例えば導入事例の紹介ページを作る場合、顧客から掲載許可を得る必要があるのですが、素材収集が困難だと、「任意項目」とする必要が出てきます。ただし、ページ全体の構成要素を考えたとき、「任意項目」が占める割合が多過ぎると、ページの内容の品質が保てなくなってしまいます。

CMSの入力画面の設計は、こうした「必須項目」を前提に考えられるべきであり、最終的にデータベースに反映されているのだということを知りました。エンジニアとしてテストをしていた時は、適当なフリー画像を用いたり、「テストテスト……」と文字列を入力するだけだったので、背景にある事情を知ることができたのは、とても良い学びとなりました。

他にも、PIMの導入に関しても似たようなケースがありました。ベテランのシニアメンバーが、お客様に対し「データ整備はとても大変だ」と何度も強調していたのを横で聞きながら、「それほどのデータ量でもないのに、何がそんなに大変なのだろう」と、私自身よくわかっていませんでした。その時はまだ、「適当にテストデータを入力していた感覚」が抜けていなかったのだと思います。

Webに掲載できるようなフォーマット的にも、見た目的にも、統一された製品の写真を用意したり、Web表示を考えた適切な文章量の商品PRを考えたりするのは、大変な作業。今考えれば当たり前のことですし、今まで開発してきたWebアプリでも当然、そういった作業が発生していたはずですが、「当時の私の立ち位置では、色々なことが見えていなかったのだな」と気づきました。

こうした「気づき」が、プロジェクトを進める中で何度かあり、その度に、自分と違う職種の考えに触れられたことで、少しずつ自分の視野が広がるのを 感じました。

また、もともとアプリケーションエンジニアだった私は、すでに構築されたインフラ上で開発を行うことが多かったため、公開サーバでどういう要素がインフラ構築の要件になるのか、あまり知りませんでした。自分で勉強用にサーバを立てることはありましたが、公開するわけではないので、とりあえず動くようにするために設定をいじるくらいでした。

イントリックスに入ってから、システムを企画し、公開サイトとしてリリースまで携わる過程での知識不足を実感するようになり、案件でもAWSを使っているところが多かったので、インフラの勉強がてらAWSの資格を取得しました。AWSのサービスに特化した資格ではありますが、なんとなく知るだけだったDRやパフォーマンス、スケーリングなどについて改めて学習する良い機会となりました。

ITコンサルタントで活きた、エンジニアの経験

前職の経験が活きたなと思うこともあります。一つは、マネジメント自体の経験はありませんでしたが、開発工程を知っていたため、ベンダーマネジメントがやりやすかったということ。しかしそれ以上に活かせたのは、開発をしたことがあるという経験でした。

もちろん、エンジニアとして参画したわけではないので、コーディングはしていませんが、要件を詰めていく際に、100%ではないものの「こういう風に実装するのではないか」と想定ができる。そうすると、「大丈夫かな？」と思った時に、リスクや実現難易度をベンダーの方に確認したり、外部システム連携でグレーゾーンに落ちそうな部分や、曖昧な部分の切分けにも、対応することができました。

エンジニア時代よりも、自分の技術が役立つ場所を探すようになった

つい先日、プロジェクトが無事完了したので、それに合わせて自分の2年間を振り返ってみました。システム企画から実現までの全工程に携わりましたが、正直な話、企画したものを構築するというのは、こんなにも大変なのかと実感しました。

どんな場所でも、新天地では新たな学びがあるとは思うのですが、戦略立案から構築・運用まで、すべてのプロセスにおいて三位一体の視点で取り組むイントリックスだからこそ、多様な職種の人と関わることができ、今まで意識することもなかった分野にまで興味を持てたのだと思います。また、だからこそ自分の技術が役に立つこともあると思えました。それはプロジェクトを推進する上でもそうですが、社内の作業改善という意味でもそう感じます。

変な話、エンジニア時代よりも「自分の技術が他者の仕事にも役立てる部分があるのではないか」というのを、よく考えるようになりました。SIerにいたときは、仕事でコーディングする以外にそれをどう活かしていいかわかりませんでした。周囲の人もみんなできることなので、仕事以外ででしゃばるタイミングもなかったです（笑）。今なら他の職種の仕事でプログラムを書いて自動化して、負荷を下げることなんかもできるのでは？と思うこともあります。

さまざまな人々と関わりながら、自分の技術を活かせるシーンを積極的に模索しています。