こんにちは。グループ経営ソリューション事業部の圷(あくつ)と申します。
2021年に「技術職」として入社し、一貫して会計パッケージの導入チームで仕事をしています。
具体的には、「Tagetik」という経営管理ソフトウェアの導入プロジェクトに入っています。
皆さんは「ITエンジニア」と聞くと、パソコンに向かってコードを書いている人を思い浮かべるかもしれません。
実はコードを書かないシステムエンジニア（SE）も多く存在します。私自身も日ごろの業務でプログラミングをする時間は非常に少ないです。(ゼロではないですが。)
本記事では、主に就活生の皆さん向けに、私自身の経験から「プログラミングを行わないシステムエンジニア」の仕事内容とその魅力についてお伝えします。
"パッケージ"とは？
先ほど、「会計パッケージの導入チーム」で仕事をしていると書きましたが、そもそも「パッケージってなんだよ」と思われたことでしょう。IT業界では「パッケージ」という言葉がよく使われます。パッケージと呼んでいるのは「パッケージソフトウェア」の略で、特定の業務や目的に合わせて事前に開発され、複数の機能があらかじめ備わっているソフトウェアのことを指します。電通総研の主要製品である「POSITIVE」や「STRAVIS」もパッケージの一種です。
この中で重要なのが「事前に開発され」「あらかじめ備わっている」という部分です。すなわち、機能の大部分は導入の際に自分で実装する必要がないということです。企業の業務の中である程度共通化できる部分を前もって開発しておくことで、顧客に導入する際のコスト・期間を大幅に短縮することができます。
パッケージの"導入"とは？
ここまでパッケージと呼ばれる製品について説明してきましたが、今度は「導入」に関わる部分を説明します。
パッケージ製品においては、機能の大部分が共通化されています。この共通化された部分を開発しているのは主に「開発チーム」と呼ばれるような人たちです。彼ら彼女らはプログラミングが仕事のコアとなるので、一般的な「ITエンジニア」に近いイメージの仕事をしています。
開発チームが実装した機能を、顧客に実際に使ってもらう準備をするのが「導入チーム」の仕事です。「すでに機能が開発されているのに準備がいるの？」と思われる方がいるかもしれないですが、実際には多くの準備作業が必要になります。
例えば、GoogleFormのようなアンケートツールを使う場合、アンケート作成者は「質問文」「回答タイプ」「必須回答」といった設定をする必要があります。パッケージ製品の場合も、これと同様に顧客の用途に合った事前設定が必要です。GoogleFormの場合は設定がそこまで複雑ではないためユーザー側で設定を完了できますが、顧客業務で使用するソフトウェアは設定が複雑かつ影響範囲が非常に広大なため、専門的な知識を持つ導入チームによるサポートを実施します。
そして、多くの場合導入チームによるサポート作業ではプログラミングは行わず、設定作業が主となります。そのため、製品に関する専門的な知識は持つが、普段の仕事でプログラミングをあまりしないエンジニアが存在するのです。（ようやくプログラミングを行わない話に戻ってこられた！！）
ここまで、電通総研ではパッケージ製品に関わる仕事が非常に多いこと、そしてパッケージ製品は開発チームと導入チームの役割分担にて顧客に届けられていることを説明してきました。ここからは私の例を通して業務の実例を提示したいと思います。
パッケージ導入の流れとSEの役割
パッケージ導入の流れは、一般的なシステム開発の流れとほぼ同じです。
下記はシステム開発でよく取られる「ウォーターフォール」という手法を単純化したものです。
要件定義からシステム開発をスタートし、下流の工程に順次進んでいきます。
他の手法としてアジャイル開発を選択することもありますが、下記のサイクルを圧縮して繰り返す手法と思ってもらって大丈夫です。
そのため、ここからは上記の各工程でプログラミングを行わないSEがどのようなことを行っているかを説明します。
要件定義
このフェーズでは、顧客の要望を確認し、実装する機能を決定します。ここでいう「機能」は実際に業務で使用する画面や各メニューのレベルです。
Tagetikの場合は、Excelに似た帳票画面を作成できるため、どのような帳票が必要かを顧客と一緒に検討します。帳票画面は設定のみで素早く（簡易的なものであれば数時間程度）で作成できるため、実際の帳票画面を見ながら検討を進めることもあります。実物を見ながら検討を進められるのは、汎用的な機能が事前に開発されているパッケージ製品を導入するメリットです。
また、帳票画面に出すデータを作成するための数値加工の処理や、各種システムとのデータ連携有無もこの段階で確認します。設計
このフェーズでは、実際に使用する機能の設計書を作成します。プログラミングを行わないパッケージ導入でも、設定内容は複雑かつ、各機能で影響を与え合うためドキュメント化は重要な作業です。
また、設計時に意識しないといけない大きなテーマとして「パフォーマンス(処理速度)」があります。皆さんもWeb画面やシステムが遅くてイライラした経験があるかと思いますが、パッケージを導入する際も各機能の処理速度はユーザーがかなり気にするポイントです。一からプログラミングを行ってシステム開発を行う場合と異なり、パッケージの場合は導入時にコードを最適化する余地が限られているため、各パッケージのベストプラクティスに沿った設計を行う必要があります。そのため、パッケージ導入に関わる時Eはパッケージの知識をつけておくことが非常に重要です。
データ連携や加工が発生する場合はこのフェーズで詳細を決定します。特にデータ連携の場合は他システムとのかかわりが出てくるため、パッケージのみにとどまらないシステム開発全般への汎用的な知識も必要となります。開発（設定作業）
プログラミング言語でコードを書く代わりに、ツール上の設定画面を操作してシステムの機能を構築します。設定は複雑かつそれぞれが影響し合っている場合が多いため、パッケージへの習熟度合いが鍵になります。また、設定する際にアルゴリズムを考慮する必要がある場合があり、プログラミング的な脳の使い方も活きてきます。テスト：設定したシステムが想定どおり動くかを確認します。テストケースの設計の際は、システム開発で使用されている手法を採用することが多いです。そのため、テストに関する知識はパッケージ導入でも必要となります。
運用サポート：完成したシステムをユーザーで使用する際のサポートを行います。マニュアル作成・ユーザートレーニング・問い合わせ対応等と行う業務は多岐にわたりますが、どれもシステムの仕様を把握していることが重要になります。そのため、それまでの導入作業で知識をつけてきているエンジニアが引き続き重宝されます。
パッケージ導入をする中でついた技術的スキル
前の章で説明してきたように、パッケージ導入をする中でも多くの技術的スキルを使用しています。
私が4年半働いてきて多少はついてきたのでは、と思う技術的スキルは下記のとおりです。
パッケージの製品知識
私の場合はTagetikという経営管理ソフトウェアを扱っていますが、その製品知識をつけることができました。各パッケージの知識はそのパッケージを扱うプロジェクトに入らないとなかなか身に着けることができないので、その知識がそのまま希少価値になります。（メジャーなパッケージであれば活躍の機会は多くなりますが、ライバルも多くなります。マイナーなパッケージであるとその逆です。）クラウドの知識（AWS）
私がこれまで従事してきた案件はAWSで構築した環境にソフトウェアをインストールするものでした。そのため、基盤であるAWSに関する知識もつけることができました。もちろんAWSの専門家ほどではないですが、一定程度のスキルはついてきたと感じています。データベースやSQLに関する知識
Tagetikでは、事前定義されたテーブルとプロジェクト内で設定していくカスタムテーブルの領域があります。このカスタムテーブルの設計を行うのは導入チームのエンジニアなので、開発チームでなくてもデータベース設計やSQLに関する知識が求められます。私の場合は、自分で勉強したり開発経験が豊富なメンバーに教えてもらったりしながら必要な知識を習得していきました。
最後に
「プログラミングを行わないシステムエンジニア」の仕事内容について、私の実体験を交えて紹介してきました。仕事の中でコードを書かなくても「エンジニア」として自分の知識を使って仕事をしていることが伝わっていれば幸いです。
個人的にも、知識を習得するのは好きなので、今の仕事はちょっと向いているのかなと思っています。自分の知識を使って仕事をしていきたい！というみなさんと一緒に働けたらとても嬉しいです。
執筆：@akutsu.masahiro
レビュー：@nakamura.toshihiro
（Shodoで執筆されました）
