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