Tomofiles Note

ドローンとインターネット、そして人との関係を考えるソフトウェアエンジニアのアウトプットブログ

【Part3】システムは生産するもの?

第三回である。
今回は、自分が何に喜びを感じるか、ということをまとめてみました。

洗練される要件

要件が降りてきて、詰めて固めて、それから作っていく。
要件は、得てして曖昧なことが多い。
そして、要件の先に、本来の目的やユーザへの気遣いがあったとしても、それが見えなくなるほど洗練されて降りてくることが多い。
実際に要件通りに作ってみると、使いづらかったりする。この機能、何がしたいんだ?と、テストしながら首をかしげることも多い。

要件通り作ること

最初にこの話をしたのは、この要件定義の目的が、作るシステムを明確にして、開発を始められるようにするため、という、システム屋目線になってることが気になったからだ。
私が気にしちゃうから、このシステム屋目線に違和感を覚えてしまうのだが、そもそもエンジニアというのは開発の専門家であるのが前提だから、この視点で考えていくのはおかしくない。
だから私は、システム屋の職務である工数管理が苦手である。てか、嫌いだ。それは、要件通り作ることへの、小さな抵抗の表れかもしれない。

システム開発の専門家になりきれないのは、ひとえに、このシステムを使うシーンを考えてしまうことにあった。
だれが、どんなときにこのシステムを使い、どう感じるのか。
ユーザがこのシステムを使うとき、何かを解決するために使うはずである。目的がある、ということである。
それを期待してしまっている。ユーザの気持ちに訴える何かがあるのではないかと、システムを作ることに対して期待してしまっているのだ。

業務システムを開発していると、その期待を裏切られることが多い。
業務システムは、その使い方はユーザの運用次第。だから、どう使われるかは開発者の俎上に載らない。
この、現場と会議室の乖離みたいな状態が、それでいいのか?という気持ちにさせて、なんだか落ち着かないのだ。

要件通り作るって、最終的に誰のためにしているのだろう?って思ってしまう。

隣の人のために

私のこの6年のエンジニア人生を振り返って、一番心を震わせていたのはなんだろう。
そう思い返したとき、思いついたのは、新人時代にやっていた業務改善のツールを作っていたときのことだ。
プロジェクトのメンバーが、作業上ちょっと困っていることを、ちょっとしたツールを作ることで、その作業が少し楽になったのだ。
このとき、私は隣に座ってるこの人が実際に困っていることを、自分がプログラムをちょっと書くだけで少し改善したことが、何よりうれしかった。

  • ミッションクリティカルなシステムのアーキテクチャを決めて、プロジェクトを先導すること
  • 隣の人が困ってることを、簡単なツールを作ることで、少し役に立つこと

この2つの仕事があったとき、私は迷わず後者を取る。
それは、責任の重い社会的に価値のある仕事よりも、誰かに直接的に貢献できる仕事のほうが、私の心を震わせるからだ。
これって、私が仕事に求めるものを端的に表していると思うのだ。

システムは生産するもの?

システム開発は、よく産業・工業のように言われることがあるような気がする。
確かにウォーターフォール式のシステム開発は、生産ラインのように流れ作業感を感じさせる。
もちろん、その過程では、多くのエンジニアが頭を使い、汗水たらして作り上げるのだから、機械的とまでは言わない。
ただ、システムは生産するものだという認識を持ってしまうと、とたんに私はそこに価値を感じなくなる。
きっとこんな人が使ってくれて、身の回りのことがちょっと便利になって、実は人知れず感謝してくれている。
そんなものが作れる可能性を、ITは持っているんじゃないかって思うのだ。


システムを開発するのは手段であり、システムを作って叶えたい目的が何かあるはずである。
その目的に、誰かに直接影響を与える何かがあると、システムを開発することに価値を見いだせる気がしている。