事業会社のシステム部門で勤務して2年ほど経ち、仕事に慣れてきた頃、モチベーションの壁にぶち当たったことがあります。
システム開発って言ってるけど・・・これってただの事務じゃない？？
私の市場価値って、ほぼゼロじゃない？
という悩みです。※事務職といっても、専門的スキルの必要な経理などではなく…調整とか雑用とか。そのようなイメージです。
当時の私が未熟すぎたのもありますが、現在も若手から「調整しかしていない…」という悩みが聞こえてきたり、「やりたいことと違った」と転職していく若手がいたり、ということがあります。
プログラムが書けるようになるわけでもないし。覚える知識は、（長年の歴史を経て無駄に巨大化している）自分の会社のシステム構造についてだけ…。システム開発部門のやるべきことって何？というのは、見失いやすいポイントなのだと思います。
同じような悩みを持つ人の参考になるよう、システム部門歴4年目になろうとしている今、
システム部門としてやるべきこと
は何か、について考えを述べておきます。ポイントは
少し先の事業を考えることです。
何も考えていないと、本当にただの事務だよね
当時やっていた仕事
当時やっていた仕事は、「既存システムの開発担当」です。
組織図（イメージ）
- システムの「要求定義」をもとに、「要件定義」を作成する
- 概要設計的なところを少し（テーブルの結合条件の指定や、バッチの組み方など）
- 開発の進捗管理
- 試験の進捗管理
- システム作業の管理（リリース等）
がメインでした。
「要求定義」をもとに、「要件定義」を作成するというのは、具体的に
ビジネスで何がしたいか既に決まっており、 既存のシステム群でどうすれば実現できるかをシステム統括部門と話し合って決める。そして、自分のシステムの受け持ち範囲の要件定義を書く。
というものです。
※要求定義と要件定義の違いは、一言でいうと以下の通りです。
「要求定義」とは
ビジネスで何を実現したいか？ユーザの希望を扱う工程「要件定義」とは
要求定義をふまえ、業務や情報システムに何が必要か？システムの仕様を扱う工程
なぜ調整しかしていないと感じるのか
当時の心境はこんな感じでした。
- 要求定義ができるまでの工程で、ビジネスでやりたいことは決まっている。「この施策にこの条件を追加したい」まで具体的に決まっている。
- 故に、なぜ必要なのかを考える習慣が無く、言われたことをやっているだけ」の状態になる。
- 要件定義の作成にあたり、複雑な既存仕様の紐解きに奔走する必要がある。「社内でしか通用しないスキル」にたくさんの時間を使っているという感覚が強い。
- 工程管理はベンダー側のマネージャーがメインでやっている。責任がこちらにあるので、目を光らせている状態。
- 品質管理も、責任がこちらにあるのでベンダーの作成したものをレビューする。作るのでなくレビューするだけなので楽しくない。
一言でいうと、「正解のある仕事」しかやっていなかったのだと思います。
- 障害を起こさずに作業を完了させられたら「正解」。障害が起きたら「失敗」。
- 既存システムの仕様を正しく理解できて拡張させられれば「正解」。昔の人の設計思想を間違って解釈し、間違った拡張をして障害を起こしたら「失敗」。
さらに、
既存システムの拡張
というところもポイントで、最新技術など知らなくても、JavaとSHELLがだいたいどんなことができるか知っておけば、なんとなくやり過ごせてしまう状態なのも、雑用感が出てしまう原因でした。環境が変わったことで見えたものもある
私の場合、その後の2年間で、幸運にも環境が変わったことで視野が広がり、やるべきことが見えてきています。
- 新規システムに携わることになった
- 既存機能の拡張ではなく、新しい機能を立ち上げていこうという文化があった
- 要求定義に基づく仕事だけでなく、自分たち発信で、システム構造改革の企画を立ち上げる必要があった
- 尊敬できる人たちに出会った
- 「価値駆動」の大切さを教えられ、会社事業へのつながりを考える機会が増えた
- 自分たち発信の企画を考えるときに、ビジネス価値があるか徹底議論した
- AWSオタク？が多く、新しい機能を立ち上げるたびにアーキテクチャを徹底議論した
- 最新技術を勉強する動機が芽生えた
- 上層部の文化も変わってきた
- 平社員（私のような）が、上層部と「事業を見据えて、システム部門が目指す方向」を議論する機会ができてきた（2年前は無かった）
システム開発部門（の平社員）がやるべきこと
視野の広い人たちと話して、私なりに重要と感じたことを述べます。
システム部門の責務は、
ビジネスとシステムをつなぐこと。
システム部門の現場社員としてできる仕事は、
未来のニーズ（需要）をとらえて、シーズ（技術のタネ）を準備しておくこと。
３年先の事業を考える（未来のニーズ）
3年後、自分の担当するシステムに関連する事業はどのような姿になっているべきなのか。そのときにシステムに求められることは何なのか。
例えば銀行の窓口システムであれば、
- ネット銀行も今以上に普及して、窓口に来る個人顧客は減るかな？
- 法人顧客の需要は〇〇の理由でむしろ増えるかもな？
- ネット銀行を使えないお年寄りをターゲットにするなら、こちらから老人ホームに出向くべきなのかな？
- 仮想通貨が流行っているけど、銀行の窓口でも扱う日が来るのかも？
とか。（上記の例は適当です）
一般的には、顧客がほしいものを作る（マーケットインと呼ばれる）のが基本です。
ただし、変化の早い昨今の世の中では、後述するように
「シーズ」を先に作っておく
ことも必要だと考えます。（特に大規模システムは、システム開発に時間がかかるので、言われてから作る、だと遅いこともあります。）そのためには、システム部門のメンバーこそ、
「未来を考える」
のが重要だということです。（企画部門と議論できたら、さらに良いですよね）参考資料：プロダクトアウト・マーケットインとは？誤用されがちな両者を解説｜ferret
技術の種（シーズ）を増やす
未来を見すえて技術的に必要なものを準備しておき、企画部門が「これをやりたい！」となったときに、すぐに試せる環境がある。
この状況が作れれば強いと思います。
システム開発方針を変えるとか、そのための予算をとってくるのは上司の仕事かもしれませんが、上司も含めて「こんなことが必要そうだね」と議論することが大事ですよね。
また、現場の判断でも作れるシーズは存在します。
- （自分が保険の窓口システムだとして）今から作る「お客さんの年齢に応じて入れる保険の一覧を出してくれる機能」、いつかデジタル部門も同じことをやりたくなるだろう。そのときにAPI化してあげられるように、共通化可能な部品として作成しておこう
- （自分が契約管理システムだとして）今はフロントシステム向けにAPIを提供しているけど、デジタル化に伴ってアクセス数が増えることが予測されるから、AWSのRDSでリードレプリカを使えるようにしておこう
- グループ会社の情報を使わないと達成できない要求があったが、今回は納期が見合わず見送った。これまではグループ会社の情報は使えなかったけど、今後、グループ会社の情報も使う時代が来るだろうから、連携する調整をはじめよう。
上記の例も適当ですが、
小さいことでいいから始めよう。
ということが伝えたいです。参考資料：ビジネスシーンで耳にする【シーズ】ってどんな意味？〝ニーズ〟や〝ウォンツ〟との違いは？ | Domani
技術の勉強もしよう
そのためには、技術動向の勉強もする必要があります。
マニアックな超最新技術はどのみち大規模システムでは使いにくいので、ある程度出回っている技術をキャッチして、ちょっと使ってみることができると良いですね。
正直、何を勉強するかの判断は難しいと感じています。。
私はAWSに携わっているので、AWS Certified Solutions Architectで基礎的な知識を得たのは良かったと思います。
あとは、このサイトを作成するためにフロントエンドの知識が、役に立つこともあるような、無いような。
他社の先進事例を調査し、企画にも反映する
３年先の事業を考える際には、他社事例や、他社で使われている技術を先取りしてリサーチしておきます。
個人的には、手順書レビューより100倍重要な仕事なんじゃないか、、と感じました。今まで全然やってこなかったので、反省。
例えば、
ヤマト運輸は、顧客にとってもドライバーにとっても面倒な「再配達依頼」をすべてLINEで完結させることができている。 自分たちのサポート部門にも、電話以外のコミュニケーションが必要なのではないか？（この例はちょっと古いですが。）
という例であったり、
自分たちの会社の課題も同じように解決されないか？店舗で売らない場合は、店舗で見たものとオンラインショップでの購入導線が簡単に紐づく必要があるな。
など。
時間は作るもの
もちろん、当時やっていた仕事に書いたような、要件定義、設計書レビュー、手順書レビューの仕事がなくなるわけではありません。
時間を作るための手段は色々ありますが、個人的には
「8割の出来でOKにする」
作戦で何とかしています。0点を80点にするのは簡単だけど、80点を100点にするのは大変です。以前は、100点の出来を目指して多くの時間を使っていたので、これを減らそうとしています。例えば、レビュー系の仕事では、ある程度、後輩やベンダーの方々を信用して、
「外すと本当にマズイことだけは押さえる」
レビューするようにしました。SQLのコマンドは全部レビューせず、DELETEだけレビューします。（業務データが万が一消されたらマズいから。）全員で出席していた作業承認会の人数を減らすなど、チーム全体で時間を作り、その分、未来に向けた前向きな議論の時間に充てられるといいと思いました。
複雑怪奇な大規模システムを紐解いて要件定義するスキルも、無駄ではない
本題とは外れますが、今にして思えば、ただの事務じゃない？と思っていた「大規模な複雑システム」を定期的に開発・運用した経験も、無駄ではありません。
そもそも、日本で大規模システムを触れる環境が、大企業にしかありません。そして、それらのシステム連携を考えたり、要件定義をしたり、数か月にわたるプロジェクトマネジメントをしたり、ベンダーと価格交渉をしたりするスキルは、思っていたより市場から求められているかもしれません。
おわりに
事業会社のシステム部門の役割は、
「ビジネスとシステムをつなぐこと」と考えると、少し仕事が楽しくなりました。
実はこの記事を書く2週間前に、システム部門の役員の方と話す機会があり、考えていることの高度さにひれ伏しました。 その勢いでモチベーションが爆上がりし、平社員の私がやるべきこと、が見えてきたので、勢いで執筆した状態です。
最近は、システム部門の人間として成長するためにも、企画部門の仕事も知りたいなと思い、兼務で参加したりしています。マーケティング分野も、奥が深いので面白いです。
関連記事：
本記事の内容も、私自身の成長に伴い変わってくる可能性もあります。
共感や、違う意見がありましたら、ぜひGitHubアカウントを使ってコメントいただけますと嬉しいです。
