担当するシステムの全体像を知らないとどうなるの？【実例あり】

2023年10月テク二ケーション入社のY.Mと申します。
この記事では、前職の経験から「システムの全体像を知ること」の重要性について記していこうと思います。なぜこの話をするかというと、自分の担当範囲の業務しか対応しない、もしくはできない場合、下記事項が問題になります。

• エンドユーザーが求めるものを提供できない
• 独りよがりの製品を作ってしまう
• ただの作業者になってしまう何を開発しているかわからない

また、これに加え、理解が乏しいと作業の出戻りや遅延が発生する可能性が高いと感じています。

実際にあった話

私の実体験から二例ほど紹介します（わりと極端な例なので、当てはまらないかもしれませんが）。

一つ目はハードウェアでの話

ハードとソフトを自社内で開発する製品があったのですが、エンジニアのチーム内で下記の問題がありました。

• ハード担当のエンジニアはソフトを顧客環境に近い使い方をしたことがなく、何ができるかやどう使うかを知らない
• ソフト担当のエンジニアはハードを触ることがなく、どう動かしていいかわからない

問題点や顧客要望はもちろんありましたが、ハードとソフトでカテゴリ分けされていたので自分の担当範囲しか見ないという状況でした。

そんな状態だったので、お客さんが求めているものが良く理解できない。つまり、独りよがりの装置になっており、エンドユーザーが求めているものを提供できていなかったということです。かくいう自分もハードだったので、ソフトのことはほとんどわからずでしたが、一年間技術営業として対応したことで、この問題点に気づくことができました。

そして、ハード・ソフトそれぞれの担当者にフィードバックしたことで、体質改善に繋げ、自分たちの開発しているモノの全体像を知ることが大事だと学ぶことができた経験です。

二つ目はソフトウェアでの話

仕様レビューの際、理解していない感じが否めなかったので、詳しく質問をすると、ソフト担当のエンジニアが「この画面は自分の担当だけど、前後の画面は自分の担当じゃないから知らない」と発言することが実際にありました。

私「この画面って何に使われるか理解していますか？」
エンジニア「設定する機能です」
私「では何の機能に使う画面か理解していますか」
エンジニア「……..」

このような感じで、全体像や機能レベルを把握しておらず、どういう機能のどの部分を作っているかを理解していない。これでは、ただの作業者になってしまい、何を開発しているかわからないといった状況に陥ってしまいますね。そして、前後関係を加味していないと仕様がボロボロの可能性があります。この時の現場は、チームメンバーの複数名が上記のような取り組み方をしていたので、とても苦労したのを覚えています。

全体像を知らないと何が起こるか

上記は極端な例だと思いますが、全体像を把握していないと自分が今何の開発してるのか見失ったり、担当作業に過不足があるかのどうかの判断に困る、最悪見逃してしまうといったケースも出てきます。そうすると性能不足でエンドユーザーの期待値を下回る場合も出てくる可能性もあるので、少なくとも自分の担当に関わる周辺は、確実にキャッチアップすべきだと思います。

しっかりしている案件でれば全体像は共有されると思いますが、そうでなければ自らキャッチアップするしかありません。「全体像が把握できる資料」が無ければ、有識者に聞いてみることをおすすめします。

【おまけ】日常生活で不便だと感じることをストックしておく

生活していく上で改善して欲しいと思う点は、結構出てくると思います。例えば、日頃何気なく利用しているWebシステムの場合も様々なサービスを利用していると、使いにくい、こうあったらいいのに…とかあると思います。

そうした事柄を改善点をセットでスマホのメモ帳などに記載しておくと色々使えたりします。ストックした内容を抽象化して自分の担当するシステムに置き換えた時に「何か改善・提案できる点がないかな？」「これが無いけど大丈夫かな？」というような気づきになるので。普段、何気なく見ているものに「不便さはないか？」というフィルターをかけてみると違った見え方があるかもしれません。

まとめ

「システムの全体像を知ること」の重要性が伝わったでしょうか。実体験ベースで記してみました。現場で業務する際の何かしらの参考になれば幸いです。