要件定義の進め方

システム開発の大炎上を防ぐために、上流工程(前工程)に位置する「要件定義」について、考えていくブログです。

要件定義書の作り方
PDCAサイクルではなく、PDCサイクルを回そう
あるべきV字モデルについて整理した
スコープを決めてから、QCDの議論をしよう

プログラムしか書けないエンジニアの需要はますます少なくなる

プログラマーという仕事は、「きつい、帰れない、給料が安い、休暇取れない、結婚できない、子供作れない」IT土方などと言われる。ひどい言われようだ。一方で、アジャイル開発界隈では、「包括的なドキュメントよりも、動くソフトウェアを」という宣言があるように、プログラマーが主役のように見られる。今回は、歴史を振り返ってみると共にプログラマーという仕事の将来について考えたい。

インターネットがない時代

今から考えると信じられないかもしれないが、インターネットすらない時代があった。この時代のプログラマーの情報源は限られていた。情報を検索する術は少なく、会社のノウハウや本から情報を収集することとなる。専門的でクローズドな業界であるため、プログラマー需要は底堅かったと思われる。

インターネットが出現した時代

その後、インターネットが出現し、Googleという会社が出現した。90年代後半だったと思う。Yahoo!ディレクトリ型サーチエンジンを採用していて、Googleはロボット型サーチエンジンを採用していて、やがて、Googleが主流になった。この時代は、インターネットで検索すれば何でもだいたい分かるという時代だ。ggrksという言葉も出てきた。ただし、モバイル端末のインターネット環境は貧弱であった。セキュリティが厳しい企業の中で、ガラケーを使って情報検索というのもなかなか難しく、まだプログラマーの世界はクローズドであった。

スマホが出現した時代

インターネットの回線速度も向上し、スマホ持ち込み不可の会社を除けば、個人が簡単にその場で自由に情報を検索できる時代となった。この頃から、プログラムという行為自体も簡単になる。既存のフレームワークを活用すれば、ほとんどプログラムを書かなくても機能が実現できるようになってきた。低級言語でアルゴリズムを考える時代から、高級言語フレームワークを活用して処理を組み立てる時代になってきたのだ。

インターネットでも、先人たちが作ったアルゴリズムを簡単に見れるようになってきた。プログラマーのやることといえば、まずはインターネットで検索を行い、似たような困りごとを抱えている人がいないかを確認し、解決法が書いてあれば、それを真似ることであった。つまり、プログラムを書く作業が、検索してコピーアンドペーストをする作業になってきたのである。

自動コード生成ツールの出現

ライブラリの充実化により、難しい処理を独自のロジックで一から記載するということがなくなってきた。そうなると出てくる発想が、プログラム自体を自動で生成してしまおうという発想だ。色々なツールが出てきているものの、この辺りについては、まだ試行錯誤段階に思える。

プログラマーの仕事の仕方の変遷

元々、プログラマーの仕事というのは、設計書通りにプログラムを書くという仕事だった。当時はマシンの性能も貧弱であり、プログラムを書くにも専門的な知識が必要だったので、プログラマーという職種が必要であった。

しかしながら、現在においては、マシン性能も向上し、インターネットには色々なライブラリが公開されている。プログラム自動生成ツールの枠組みに沿って設計をすれば、ある程度のプログラムを自動で作成することが可能になってきているのだ。

設計者と実装者(プログラマー)の境界がなくなる

そうなると、プログラマーの実装という仕事はほとんどなくなってくる。コーディング作業が無くなったプログラマーのやることは、ロジックの検証と動作の検証である。そして、これらの仕事は、設計者が行う仕事と酷似している。

req-definer.com

上記の記事では、設計者が設計書を書き、実装者がその設計書に基づきプログラムを書くという図式であった。自動コード生成ツールの出現により、実装という作業がなくなり、大半のプログラマーは行き場を無くしてしまうこととなるだろう。ごく一部の有能なプログラマーが、短期間で次々とシステムを完成させていき、他のプログラマーは仕事があまりないという状況になりそうだ。

これからの時代に向けて

これからますますプログラムを書かない時代がやってくるだろう。そうなると、プログラムしか書けない人材というのは、価値がなくなってくるようになる。一部の特殊な能力を持つ人たちを除いて、いわゆる、設計書に書かれた通りのプログラムしか書けない人は用無しになるのだ。

逆に必要となってくるは、プログラムも書けるし、設計書も自分で書ける人材だ。要件を正しく理解し、その要件を実現するための設計書を自分で書き、ツールを活用し、システムを動作させられる人材こそが、これから求められる人材となる。

このような人材に求められるスキルセットは非常に高い。

req-definer.com

 

req-definer.com

上記の記事で示している、設計者と実装者に求められる能力を同時に備える必要があるのだ。このようなスキルを持つ人は、認識を共通化する能力があり、正しい論理思考ができ、適切な日本語で設計書を記載し、APIやインターフェースの命名も英語である程度適切に記述できるような人材だ。

残念ながら、このような人材はそこらへんに転がっているようなものではない。人材の奪い合いになるはずだ。IT業界に止まらず、いわゆるシステム発注側の企業も欲しがるであろう。

スキルアップのパターンは2つある

設計者としてもプログラマーとしても振る舞える人材は、どこからも引く手数多であろう。食い扶持の確保という意味で、上記の人材を目指したいところだ。スキルアップを目指した場合、最初の職種が何かでスキルアップのパターンが変わる。

①設計者が実装者のスキルを身につける場合

この場合は比較的容易である。世界的な流れとして、インターネットを活用できれば、自学自習で専門性を身につけることができるようになってきている。自分で勉強し、自分で動かしてみることで、ある程度の専門性は身につけられるであろう。

②実装者が設計者のスキルを身につける場合

この場合は、人によっては難しい場合がある。コミュニケーションというのは、コンテキストにより必要な対応が変わるものである。設計者の仕事は、関係者同士の認識合わせであり、文章作成であり、それらは、受け手や読み手を意識して行われなければならない。人によっては、このような仕事が苦手な人もいて、後天的な努力でスキルを身に付けるのはなかなか難しいと感じる。ただし、最低限の必要なコミュニケーションであれば、後天的な努力で十分身につけることが可能であろう。

終わりに

今回は、プログラマーの将来について考えてみた。プログラムを人手で書くというのは、あくまでもシステム実現の手段の一つであるので、単純なシステムの実現においては、プログラムしか書けない人材の需要は減っていくであろう。筆者としては、設計者として設計書を書けるようになる努力をしておくほうが、仕事に困ることはないと感じる。

結論:設計書もプログラムも書けるようになろう