コーポレートエンジニアになって1年半ほど経ちました

corp-engr 情シスSlack（コーポレートエンジニア x 情シス）#3 Advent Calendar 2020、7日目の記事です。

誰に向けてでもない振り返りです。
これまでと、やったことと、気づきと、これからを書きます。

これまで

前職は割と大きめのSIで人材系のプロダクト開発をやっていて、設計、実装、プロジェクトマネジメントを学ばせてもらいました。

やったこと

最初情シス部門に所属してコーポレートエンジニアぽい事やろうとしていたところ、まもなくフロントオフィス系の社内システム運用と営業事務が合流して業務改善チームとして分離し、そこへ異動して主にプロジェクトマネジメント、システム構築しているという感じで、もしかしてコーポレートエンジニアの文脈から外れてるかもと書きながら思いました。
最近は情シス部門の再構築で兼務として戻り、セキュリティ強化のためのプロジェクトメンバーとして施策やツールの検討に携わっています。
以外チームでのアウトプット

契約管理の改善、請求業務の改善
契約管理に利用しているSalesforceが自社の契約形式に合っていなかったり書面情報や請求情報との対応が不明瞭になっていたため、色んな野良スプレッドシートで補完していた状態から、ほぼSalesforce上で完結できるようにデータ構造変更とデータクレンジングを行い、自チームの毎月20日かけていた請求作業を1週間以内に削減し、他チームの売上集計作業や契約更新作業の工数削減にも寄与しました。

フロントオフィス業務管理の改善
マーケティング、インサイドセールス、フィールドセールス、プリセールス、アカウントマネジメント、カスタマーサクセスといった一連のビジネスプロセスのデータをSalesforceに集約できるよう、各種部門と連携して機能開発を進め、運用が乗るように継続してフォローしています。
Marketo連携やFORCAS連携する上での調整や、契約状況とプロダクト利用状況をモニタリングして顧客を支援するためのサブシステム開発もしました。
現在は来期に向けて新定義されたKPI算出のためのデータ設計修正・データクレンジングのプロジェクトをフロント・バック連携して進めています。

気づき

社内システム≠ソフトウェア
社内システム＝企業活動を仕組み化したもの、ソフトウェアと人の組み合わせだと考えるのがいいと思いました。
企業は人も含めて成立しているので、誰かの役割を経て次の役割の人に渡されていく、というフローになっていて、その中でソフトウェアが再現しやすい定型化された役割をツールとして置き換えているので、そのツールの前後のステップにいる人の挙動も含めて考慮することが社内システムの設計だと意識するようにしています。
ツールは役割を正確にこなしてくれますしバグも再現性ある場合がほとんどですが、人は再現性がない上に自由なバグを起こします。これはソフトウェアの範囲（ツールのUIやUXなど）だけ見ていたら解決しきなくて、例えばツールでは判断できないタイプの誤った情報を入力するとか、なんならツールを使わないでみるとかも人間ならできるので、ツールが期待するインプットをされるために周知やマニュアル作成や後ろに確認修正するステップを用意するなども検討したりします。
また、置き換えられるところを全てツール化できたら望ましいですが、中には複雑なプロセスを組まなきゃいけなくなるものがあったりして、その質が担保できるほど社内システムの開発リソースがないなら、あえて人が介在するままにするという選択をしてもいいと思います。
そういった経験から、社内システム≠ソフトウェアという考え方に至りました。

意外に開発できなくて悶々とするようなことはなかった
たしかにほとんどの時間は調整業で、開発するとしてもモダンな技術ではなく言語でいうとApex（Salesforce上で実行できる古いJavaっぽい言語）かGASになりましたし、なんならコード書くのも控えているのでツールの設定をポチポチするのがメインです。
ただ、運用含めて設計するだけでも自分の中では割と作る欲求を満たせていますし、ビジネスモデルや管理会計の理解が進んだことで、むしろ今後プロダクト開発するとなってもブランクを補える他の何かがある気がしてます。
あと捨てても問題ないところに趣味でコード書いたりもしてたり。

あまり気軽にコード書かなくなった
コード書くのも控えていると書きましたが、基本的に社内システムは様々な既製ツールを組み合わせてなるべくGUIベースの設定で構築するようにしています。
コスト観点でもありますが、それよりエンジニアの安定した調達が難しいというリソース観点でそうしているところがあります。
プロダクト開発にいるとちょくちょく人が出入りしますが、その感覚は改めないといけなくて、エンジニアは不足しているので、会社の規模や方針にもよりますが大体の会社は採れる（or外注する）ならプロダクト開発に配置したいし、エンジニアもプロダクト開発したい人がほとんど、ということで、非エンジニアにも作業を分担できる既製ツールを活用し、既存コード資産もなるべくノンプログラミングで実現できる手段に移行していく方向に舵を切りました。
また、お世話になっている同僚の方のこちらの記事では責任者がシステム設計する重要性が述べられていますが、実際に業務責任者の1人が構築方法を覚えてから組織の数字可視化を自力でガンガン進めてくれる状態になり、エンジニアリソース節約だけでなくシステム構築スピードが上がる実績も出ています。
システムと聞いて反射的にエンジニアを挟まなければできないという思い込みにも気づかされた出来事でした。

段取り
一度Salesforceで大きなアップデートした時に四方からフルボッコされる失敗をしてしまいまして、その時も要望対応に関連する責任者との握りはありましたが、それだけでは不十分な時があります。
その時は、こちら側も相手側もツールの仕様やユーザーの利用状況に詳しくない状態で、ツールのコンサルも入ってもらってはいたんですが各業務への影響を洗い出しきれてなくて、蓋を開けてみれば現場が混乱するという結果になりました。
Salesforceは仕様が多すぎてキャッチアップするのは難しいし、カバーする業務領域が広くて影響を洗い出しきるのも難しいので、考慮漏れは起きる前提でロールバックやカバーできる選択肢（ツールと人の両面）を作っておくのが大事だと思います。
また、現場には機能レクチャーやマニュアル作成して現場の運用浸透に一役買ってくれているユーザーコミュニティリーダーみたいな存在がいたりするので、大型アップデートのときはその人たちともすり合わせして先に理解しておいてもらうと問い合わせ対応がスケールアウトしていいと思いました。
あと、レポートライン上では、上記のような握りの記録や事前周知の記録を残した上で仕様通りに実装できている状態であれば多少の混乱は評価に影響しないよう握っておくのも大切だと思いました。

これから

最近は今の仕事を続けた先に何者になれるんだろうかと考えることがあります。

もっとコーポレートエンジニアっぽい業務に振り切るか、思い切ってビジネスの人になるか、スタンスを明確にしないといけないのかもしれないと思っています。