非エンジニアが見落としがちなエンジニアに必要な能力 - 言語と編集

こんにちは。re:shineギグパートナーの青木（@hirofumi_aoki）です。
（エンジニア兼アドバイザーです。）

この記事では、下記の方々を対象に、エンジニアに求められる能力について、非エンジニアやプログラミング初学者にもご理解いただけるように、解説したいと思います。

・非エンジニアに、エンジニアの役割を正しく伝えたいエンジニア
・エンジニアとしてどのような能力を身につければよいか知りたい、プログラミング初学者
・エンジニア採用でどのようなエンジニアを選考すればよいか考えたい採用担当の方

エンジニアの方々におかれましては、「エンジニアとは何ぞや」を、非エンジニアに説明するためのツールとして、使っていただけるものになれば幸いです。

「プログラムを書ける = システムを作れる」ではない

非エンジニアやプログラミング初学者の方とお話ししていると、「プログラムを書ける = システムを作れる」という印象を持っている方がそれなりに多いように感じます。

その原因はおそらく、システム開発の作業内容がどのようなものか、具体的にイメージを持っていないからだと思われます。

この記事では、システム開発の作業内容を噛み砕いて、非エンジニアやプログラミング初学者の方にでも、システム開発のイメージが湧くように解説しつつ、エンジニアに求められる能力を解説していきたいと思います。

一般的にシステム開発はこのような流れで行われます。

開発の大まかな進め方は、ウォーターフォール型やアジャイル型といった手法などがあり、プロジェクトの特性によって変わりますが、基本的には、要件定義と設計、実装、テスト、リリースといった流れでシステムを開発します。

そして、「プログラムを書く」というのは、この流れの中で、黄色で示した「実装」にあたります。

つまり、「プログラムを書ける」というのは、システム開発の一連の流れの中で、「実装ができる」という、部分的な能力を示しているにすぎないのです。

さらに、「実装」も、ただ単にプログラムを書くだけではなく、適切にプログラムを書く能力が必要になります。

この記事では、「実装」にフォーカスして詳しく解説し、エンジニアに求められる能力が、いかに幅広いものであるか、イメージしていただけるようにしたいと思います。

プログラミングはコンピューターへの作業指示書作り

そもそも、プログラムとは、コンピューターにさせたい仕事を順番に記述した作業指示書です。

つまり、コンピューターへの作業指示書を書く行為が、プログラミングなのです。

プログラムのイメージをつかんでいただくために、簡単なプログラムの例をあげます。

scanf("%d", &number);

if (number < 10) {

  printf("入力した数字は10未満です");

} else if (number >= 10) {

  printf("入力した数字は10以上です");

}

これは、画面で入力した数字が「10未満」か「10以上か」を判断するプログラムです。

このプログラムの一行一行が、コンピューターへの作業指示になっています。

上から順番に、

① キーボードで入力した値を受け取り
② 数字が10未満ならその旨を画面に表示
②' 数字が10以上ならその旨を画面に表示

といった指示内容になっています。

非エンジニアの方でも、メールやWord、Excell、Power Pointなどで、部下や後輩、外注先に作業指示を書いた経験のある方は多くいらっしゃると思います。

メールで数行の作業指示を箇条書きにする程度であれば、日常的に作業指示を書いている人はかなりいらっしゃるのではないでしょうか。

プログラミングでは、作業を指示する相手が人からコンピューターに変わるだけで、本質的には、日本語で書く作業指示と同じなのです。

人に向けて書く作業指示書との大まかな違いは、下記だと考えています。

・コンピューターに伝わる言語として、指示書をプログラミング言語で書く
・コンピューターの性質を理解して、コンピューターが誤解なく動けるように作業指示書（プログラム）を書く

逆に言えば、その他では、人に向けて書く指示書に求められるものと共通することが多く、人に向けて書く作業指示書とプログラムの作成能力には共通項が多くあります。

そのため、部下や後輩、外注先の知識量や読解力を考慮して、スムーズに作業をしてもらえる作業指示を日々考えている方であれば、非エンジニアでも、プログラミングに必要な能力をより鮮明にイメージできるのではないかと思います。

以降では、その理由をより解像度高くご理解いただけるように、プログラミングに必要な能力を詳細に解説していきます。

プログラミングには言語以外の能力が必要

先程の例では、非常に単純なプログラムであるため、誰が書いてもほぼ同じような内容になりますが、実際にシステムを作る場合には、膨大な量のプログラムを書くことになるため、作業の内容も複雑になります。

そのため、単にプログラミング言語を書けるだけでなく、プラスアルファの能力が必要になります。

以降では、その一例を3つほど紹介いたします。

効率の良い段取りを考える能力

コンピューターに指示する作業内容が多く複雑になると、書き手によって、プログラムに書かれた作業の段取りの良し悪しが大きく変わってきます。

作業の段取りの良し悪しは、コンピューターが作業をする速さに影響します。

いわゆる、システムの処理性能と言われるものです。（システムの処理性能は、プログラムの良し悪しだけで決まるものではありませんが、便宜上この記事では割愛します。）

プログラムが膨大で複雑になるほど、その差は顕著に現れます。

極端に作業の段取りが悪ければ、ユーザーが操作してから、結果が返ってくるまでの時間が長くなり、システムの使い勝手にも影響が出てくるのです。

使い勝手が多少悪いだけであればまだマシですが、コンピューターの応答時間に耐えきれず、ユーザーがシステム（Webサービスやアプリなど）を使わなくってしまうことさえあります。

このような理由で、効率の良い段取りで、作業指示を考え、プログラム（作業指示）を考える能力は非常に重要になります。

非エンジニアの方でも、日頃から部下や後輩、外注先などに対して、意図通り、スムーズに作業できるように、作業段取りを考え、指示されている方々は、段取りの良し悪しや伝え方の重要性を良く理解されているのではないでしょうか。

漏れや誤解のない作業指示を考える能力

効率の良い作業段取りに加えて、漏れや誤解なく、作業指示を考え、プログラムを書く能力も重要です。

漏れや誤解のある作業指示が、いわゆるエラーやバグ、システム障害の原因の一つです。

例えば、レジで入力した商品金額（税抜）の合計を税込金額で画面に表示するシステムを作る必要があったとします。

コンピューターへの作業指示は、このように流れで考えられます。

①レジで入力した商品金額（税抜）をシステムが受け取る（入力が終わるまで繰り返す）
②商品金額（税抜）を全て足し合わせる
③合計金額（税抜）に消費税率（10%）を掛け合わせて、税込金額を計算する
④合計金額（税込）を画面に表示する

一見、問題ないように思えますが、実は重大な落とし穴があります。

例えば、購入商品の合計金額（税抜）が105円だったとします。

そして、そのお店の消費税の計算ルールとして、「小数点以下の金額は切り捨てる」というルールになっていたとします。

この場合、合計金額（税抜）が105円に消費税率10%を掛けた金額は、115.5円になります。

お店のルールに従えば、税込の合計金額は、115円が正しい金額です。

しかし、先程の作業指示では、小数点以下の金額をどのように扱うか指示していません。

作業指示に使うプログラミング言語やその言語の指示文の特性で、小数点以下を四捨五入してしまうようなケースがあります。

つまり、明確に小数点以下の金額の扱いを指示していないがために、税込の合計金額を誤った金額（116円）で表示してしまうことがあるのです。

この合計金額（税込）を見て、お客さんが支払いをした場合、間違った金額を受け取ることになるので、重大なミスを招いてしまいます。

このように、コンピューターに伝えるべき指示が漏れてしまうと、重大なミスに繋がりかねないため、コンピューターに伝えるべき指示を漏れや誤解なく考える能力は、エンジニアにとって非常に重要です。

この例を、会計業務に置き換えれば、非エンジニアの方にもよりわかりやすいかもしれません。

例えば、経理部門の社員が、新人に対して、Excelを使って、会社の売上金額（税抜）を合計し、会社の税込の売上金額を計算する仕事を依頼したとします。

そして、会社の会計ルールでは、小数点以下を切り捨てることになっているにも関わらず、新人は何も考えずに、小数点以下を四捨五入した金額で報告してきたとします。

これは、新人側のミスと捉えることもできますが、新人が会社のルールをまだ十分に把握できていないことを考慮して、小数点以下の扱いを指示すべきだったと考える人も多いのではないでしょうか。

つまり、人への指示もコンピューターへの指示も、指示相手の特性（知識量や経験値、思考の癖など）を考慮して、漏れや誤解なく指示を出すことは重要なのです。

読みやすい作業指示書を構成・記述する能力

先にあげた2つの例は、作業の指示相手であるコンピューターに配慮する能力ですが、プログラミングでは、プログラムを作る側のエンジニアに配慮する能力も求められます。

その一つが、読みやすいプログラムを構成し、記述する能力です。

プ読みやすいかどうかで、プログラムの更新のしやすさが変わってきます。

例えば、レジ機能と会計機能のあるシステムを開発するとします。

このシステムのプログラムの一部を日本語でざっくりと表すと、このようなイメージになります。

図中の各プログラムが、独立したプログラムとして一つのファイルになっています。

そして、一つのファイルの中でも、図中の青枠のように、独立した作業毎に指示文のセットをグルーピングすることもあります。

また、指示文のセットを他の指示文のセットの中から引用することもあります。

どこにどんな作業が書かれているのかわかりやすく、ファイルや指示文のセットの分けることで、プログラム全体の読みやすさや更新のしやすさが大きく変わってきます。

例えば、システムを作った後に、月々の原価の計算が下記の通り変更になったとします。

【変更前】
売上金額 - 売れた商品の仕入れ値

【変更後】
売上金額 - 売れた商品の仕入れ値 - 棚卸ロス（棚卸の際判明した、ロスした商品の原価）

その場合、図中のプログラムの「④-2 原価を計算する作業」に修正を加えることで、原価の計算方法の変更にシステムを対応させることができます。

この図の緑箇所の通り、指示文を修正すればよいわけです。

このように、どこにどんな作業が書かれているのかすぐに分かれば、修正が必要な場所をすぐに判断でき、スムーズにプログラムを更新できます。

また、引用を上手く使うことで、修正箇所を減らすこともできます。

このプログラムでは、図中のオレンジ箇所の通り、原価を「④-3 粗利を計算する作業」でも使用しています。

もし、「④-3 粗利を計算する作業」でも個別に原価計算を行なっていた場合、原価の計算方法を変更するには、「④-2 原価を計算する作業」と「④-3 粗利を計算する作業」の2箇所を変更する必要があります。

しかし、「④-3 粗利を計算する作業」から「④-2 原価を計算する作業」を引用しているため、先の例では修正箇所が1箇所で済んでいるのです。

このように、修正箇所を減らすという点でも、ファイルや指示文のセットを適切に分けることで、プログラムを更新しやすくすることができます。

逆に、更新しにくいプログラムでは、更新するために必要な作業量が多くなり、それだけ事業のコストが増えることになります。

プログラムの規模（作業指示書の量）が大きくなるほど、作業効率の影響度は大きくなり、更新する際のコスト差は膨大になります。

つまり、更新効率の良いプログラムになっているかどうかで、事業運営コストに大きな差が生まれるわけです。

こういった点で、更新効率の良いプログラムを書く能力は、エンジニアにとって重要な能力の一つになります。

プログラミングには編集能力が必要

さて、この記事ではプログラミング言語以外に必要な能力の一例として、下記の3つを紹介しました。

・効率の良い段取りを考える能力
・漏れや誤解のない作業指示を考える能力
・読みやすい作業指示書を構成・記述する能力

これらの能力は、いわゆる編集に求められる能力そのものだと考えています。

編集という言葉を辞書で調べるとこのように定義されています。

一定の方針に従って資料を整理し、新聞・雑誌・書物などにまとめること。また、その仕事をすること。

より具体的に、本や記事の編集作業を分解すると、このようになると思います。

① 読者にとって有益な本や記事を企画する
② 伝えたい内容を文字に起こし、文章を書く
③ 伝えたい内容が伝わるように文章を肉付け、整理する

先程のプログラミングに必要な能力は、これらの編集作業に必要な能力と共通します。

各編集作業とプログラミングに必要な能力を対応付けるとこのようになります。

伝えたい内容を文字に起こし、文章を書く

本や記事の場合、読者に考えやノウハウ、事実などを伝えるために、誤解のない表現で、漏れなく文字に起こす必要があります。

また、読者に考えやノウハウ、事実をスムーズに伝えるために、論理展開を考えて、文章の順番を決めていきます。

プログラムにおいては、伝いたい内容とは、コンピューターに行なって欲しい作業になります。

そして、漏れがないように作業を洗い出し、コンピューターが誤解なく、効率的に行える段取りを考え、作業指示書（文章）を書くことが重要です。

「本や記事の論理展開 = 作業段取り」と捉えれば、プログラミングにおいて、編集能力が重要であることが直感的にわかるのではないでしょうか。

伝えたい内容が伝わるように文章を肉付け、整理する

本や記事の構成では、考えやノウハウ、事実などを読者に効果的に伝えるために、ストーリーや論理展開を考え、章立てを決めていきます。

章立てが優れた本や記事であれば、目次の章や節などを見るだけで、伝えたい内容やどこにどんな内容が書いてあるかが簡単に読み取れます。

プログラミングの入門書を例にすると、このような目次が考えられます。

第1章：プログラムとは
　第1節：プログラムはコンピューターへの作業指示書
　第2節：プログラミング言語の種類
第2章：プログラムの書き方
　第1節：プログラミングの基本文法
　第2節：画面に文字を表示する方法
　第3節：条件によって画面に表示する文字を変える方法

章は大きなテーマを表し、節は具体的な内容を示しています。

この本を読めば、どのような知識が得られるか、一目瞭然ではないでしょうか。

プログラミング言語の種類を知りたいなら第1章第2節、

プログラミングの基本文法を知りたいなら、第2章第1節、

といった具合に、目的に合わせて見るべき箇所を簡単に見つけられます。

先にも説明した通り、プログラムでも同様に、全体の構成を考えることが重要です。

プログラムにおける「ファイルを章」、「指示文のセットを節」に置き換えると、その理由がおわかりいただけると思います。

例えば、先程のレジ&会計システムで、原価計算をどのように行なっているか確認したいのであれば、

「④ 月々の会計データを計算するプログラム（ファイル）」の「④-2 原価を計算する作業（指示文のセット）」

に書かれた指示文を読めば良いとわかります。

このように、プログラミングでは、ファイルや指示文のセットを適切に分けることで、本や記事と同様に、人が見てプログラムに書かれた作業の内容や記述箇所が簡単にわかるようになるのです。

言語と編集

さて、これまでの説明で、プログラミングにおいて、編集能力がいかに重要であるか、ご理解いただけたかと思います。

そして、「プログラムを書ける = システムを作れる」という印象が、いかに誤解であるかも、おわかりいただけたかと思います。

「プログラムを書ける」という状態は、プログラミング言語の単語や文法を知っている状態にすぎず、編集能力が備わっているとは限りません。

日本人であれば、誰しもが日本語の文章をある程度書けると思います。

しかし、ビジネスにできるレベルの本や記事を書けるほど、編集能力を持っているとは限りません。

つまり、「プログラムを書ける = （商用の）システムを作れる」と思っているのは、「日本語の文章が書ける日本人 = （商用の）本や記事を書ける」と思っているのと変わらないわけです。

エンジニアは、プログラムの単語や文法を理解する言語能力と、適切なプログラムを書くための編集能力が備わって、初めて必要な能力があると言えるのです。

おわりに

この記事では、システム開発の流れの中で、「実装」工程に絞って、エンジニアに求められる能力を解説しました。

「実装」工程に求められる能力だけでも、ただプログラミングを書ければ良いというわけではないことがご理解いただけたかと思います。

しかし、エンジニアに求められる能力は、「実装」工程だけでなく、要件定義や設計、テストなどにおいて、この記事でご紹介した能力以外も多岐にわたって求められます。

これらの工程の内容を知っていただくと、「プログラムを書くだけがエンジニアの役割ではない」ということが良くご理解いただけると思います。

要件定義や設計、テストの具体的内容や求められる能力も、またの機会に解説し、エンジニアの役割がより多くの人に鮮明に認知されるように努めてまいりたいと思います。

記事執筆の協力者

・re:shineエンジニア 荒川貴将（@arandoros）：記事中のプログラムのコードレビュー

この記事を読んだ荒川さんが、「"が全角に半角になってないので、直した方が良いですー。あっ、ifの後も半角スペースがあった方が良いです。」と、指摘をくださいました。

これは、いわゆるコードレビューと言われる作業になります。

書いたプログラムを他のエンジニアに見てもらって、問題のある記法やバグなどがないかを確認する作業です。

コードレビューは、編集で言うところの校正と同じです。