「プログラマーに必要なことは？絶対外してはならないことは？」
よい質問は、よい回答に勝る
とあるかいちょー氏は問いました。
「プログラマーに必要なことは？絶対外してはならないことは？」
かいちょー 氏のツイートより
これ、今の日本のIT業界の変なところなども含めて、色々語れるので記事にしちゃいます。
問題を分解する
「プログラマーに必要なこと」という命題を語る前に、まず「プログラマー」という言葉の定義を考える必要があります。
辞書的な回答だけで言えば「プログラムを作成する人」または「プログラムを作成することを職業とする人」という感じになります。実のところ、この2つの定義でも結構な開きがあります。なぜなら職業ではなく、趣味や社会貢献などの目的で、プログラムを作成する人も居るからです。
もう1つ、「必要なこと」という言葉も、これまた定義が難しいものです。
極端な例を挙げれば、たとえば、人間が人間として存在する上で、法律や社会的規範を守っていることは一切、必要ありません。物理的に存在する上では。
ただし、一般的には、法律や社会的規範を守ることは、人間が社会生活を行う上で「必要なこと」とされるのが、極めて一般的です。
では、すべての人が、完全に法律や社会的規範を守っているかというと、必ずしもそうではありません。そもそも、法律の解釈が割れたり、社会的規範の認識の相違などというもの、日常茶飯事です。
話をプログラマーの例に戻しても、「必要なこと」というのは、必ずしも見解の一致をえることは難しいと思います。
なので、先にネタばらしをしておくなら、このテキストに、最初の問い――「プログラマーに必要なことは？絶対外してはならないことは？」の、直接的な答えは書きません。誰もが納得する答えなんてあるわけがないからです。
ただ、このテキストを読んだ上で、プログラマーとは何か、あるいは、貴方が、プログラマーに期待する、必要なこと・絶対外してはならないことは何か、を探すための補助線にしてもらうのが、このテキストの目的です。
「プログラマー」とは何か
最初にちらっと書きましたが、「プログラマー」の定義として、
プログラムを作成する人
プログラムを作成することを生業とする人
の2つが、一般的には使用されます。ただし、これらは割と、「人に対する属性」です。
他にもう1つ、「ポジションに対する属性」という観点もあります。
たとえば、システム開発現場において、
システム全体を設計する人
プログラムを作成する人
データを入力する人
作成されたシステムをテストする人
のような役割分けがされている場合、内部的には、2番目のみを「プログラマー」と呼称することもあります。
実際にはもっと細かい区分けがありますが、それらも、開発の主体・方法論・会社等によって異なるので、一般化は難しいし、本筋とは少し離れるので言及しないでおきます。
さて、「何をもってプログラマーと呼ぶか」という話に入ります。
話の目的は、この記事を読んでいる貴方が、「プログラマーに必要なこと、絶対外してはならないこと」という命題に向かい合う上で、「プログラマー」という存在を具体化し、また、それ以外の（具体化したパターン以外の）ケースがあることも理解して、考察の次のステップに進むためです。
Case.1 「プログラムを作成する人」とは
最初に書いた「プログラムを作成する人」に関して言えば、別に生活の糧となる職業であるかどうかは関係ありません。また、プログラムを作成すること自体に、特別な免許が必要な国や地域、というのも、私が知る限りは存在しません。
すなわち、プログラムを作成する能力があれば、誰でもプログラマーになり得ます。
ちなみに、プログラムを作成する上で、コンピューターやスマートフォンなどの機器は、あるに超したことはありませんが、必須というわけでもありません。
数十年前には、パンチカードといって、紙の決められた場所に穴をあけることで、文字や数字の入力の代替としたり、紙テープ等に、プログラムに対応した穴をあけることで、プログラムを記述していました。
それらを機械に読み取らせることで、実行していたわけですが、前述のように、プログラムを作成するのに使う媒体は、紙やテープだったわけです。そうでなくとも、たとえばノート等に、プログラムを記載してから、入力する等の方法もありました。
さらに昔の話をすれば、コンピューターの配線そのものを切り替えることで、プログラムを作成していました。
つまり、最近の主流の「コンピューター等にプログラムを入力する作業」も、主流ではあっても必須ではないとも考えられます。土の地面に木の棒でプログラムを書く、でも、プログラムを作成していることには変わりません。
ところで、ここまでは「能力」と「プログラム入力の手段」の話をしました。とはいえ、「能力」だけでは語れない部分もあります。
つまり「プログラムを作成する能力・知識はあるけれども、プログラムを作成しない人」をどう扱うか、です。最初に挙げた、言語的定義であれば、「プログラムを作成しない人」はプログラマーではない、とも言えます。
他方で、能力的にプログラムが作成できるけれども、何らかの事情――時間が無いなどの生活上だったり、そのほか色々です。
たとえば、この記事を読んでいる貴方は、次のような境遇に置かれている人を、プログラマーと考えますか？
――大学でプログラミングを習いはじめたばかりで、入力したことはないけれども、極めて簡単なプログラムの記法は理解している大学生。交通事故に遭い、一命は取り留めたものの、両手も両足もしばらくは動かせず、また声を出すことも難しい。彼は集中治療室で、頭の中でぼんやりと、何度もプログラムを思い出し、試したい内容を頭の片隅に溜め続けている。
上記のような「極めて例外的な状況」をいくつか想像してみると、あるいは、貴方の考える「プログラマー」の定義が、導き出せるかもしれません。
Case. 2 「プログラムの作成を生業とする人」とは
さて、「生業としている人」については、少しばかり状況が異なります。単純に「企業などの組織に所属し、指示されたプログラムを作成し、それでお給料をもらっている」なら、プログラマーと言って差し支えない――という共通認識は、割と得やすいと思います。少なくとも100人中、99人ぐらいは賛同してくれるでしょう、という温度感です。
他方で、次のようなケースはどうでしょうか？
プログラマーとして採用されたが、ここ数ヶ月は新卒の若者にプログラムを教えるのが主で、自分でプログラムを作成することはない。教育完了後の予定は未定だが、プログラム作成の業務に戻る可能性が高い。
事務員として採用されたが、プログラミングの知識もあり、業務に使用するツールなどを、プログラミングにより自作して使用している。名刺にはあくまで「経理担当」とだけ書かれている。ツールの作成・使用は必須ではなく、手作業でも業務は遂行可能。また作成の指示を受けたわけではない。
プログラマーとして採用されたが、あまりに能力が低すぎて、求められるプログラムを作成できず、仕方なく雑用や、単純な動作テストなどの業務を行っている。名刺には「プログラマー」と書かれている。
プログラマーとして採用され、当初はプログラムの作成に当たっていたが、コミュニケーション能力や業務知識などが評価され、仕様を決めたり、システムの配置や設定などを決める作業をもっぱら任されるようになり、プログラムの作成はしていない。
上記の1. ～ 4. のケースは、それぞれを「プログラマー」と呼ぶかどうかは、人によって意見がわかれるのではないでしょうか。
少なくとも、判断がわかれるであろうこと自体は、自然なことだと思います。
これらについても、「プログラマーに必要なこと」を考察・検討する上で、1つの指標になるのではないかと思います。
ここまで読んでいただければわかると思いますが、少なくとも、単純な用語として「プログラマーとは何か」定義するのは、それが独断の定義であっても、細かいケース分けまで含めると、難しいということです。
でもまあ、別にいいんじゃないでしょうか。私達は、「プログラマーに必要なこと」を正しく答えないとスフィンクスに喰われる、というわけでもありません。
最初に書いたように、「プログラマーとは？」「必要とは？」を、どのように捉えるかで、答えがいくらでも変わってくる命題だからです。
あくまで上記のブレは、ブレがあることそのものを前提に、この先もお付き合いいただければと思います。
「必要なこと」を考える
では、当初の問いの軸となる「必要なこと」について考えます。
最初に意図的に「トンチ」として答えるならば、プログラマーには酸素が必要です。これがないと死んでしまいます。
「そんなの当たり前やん」と思われるかもしれませんが、言葉尻だけで言えば、大きな間違いではありません。
まあ、この辺は「プログラマーに必要なもの」という言葉自体が、「プログラマーである人にとって必要なもの」と、「プログラマーであると他人が認めるのに必要なもの」の、2つの意味を持つから、とも言えます。
つまり、「あの人はプログラマーだ！」という認識をする上では、別にその人に酸素が行き渡ってなくても良いのです。そんな状況であれば、しばらくしたら「あの死体は生前はプログラマーだった！」になってしまいますが。
さて、あまりに極端な部分は抜きにして、一般的に、プログラムの作成（プログラミング）という作業を行う上で、あったほうが良いとされる「適性」的なものは、割と簡単に列挙できます。
裏を返せば、これは「プログラマーとして活動する上で、利点がある」適性であって、それを「必要なもの」と見なすべきかどうか、という点については、意見は書けても、万人が納得する回答はできないことを、前提にした列挙になります。
1. コミュニケーション力
複数人で。あるいは誰かからの依頼を受けて。プログラムを作成するのであれば、コミュニケーション力は必要になります。もうちょっとブレイクダウンして、「文章作成力」「会話力」「語学力」などとしても良いかもしれません。
コミュニケーションを取る相手も人間なので、愛嬌がある、誠実に見える等のポイントも左右することはあります。
他方で、たとえば、個人で趣味のプログラミングを行い、自分のためだけに使う、あるいは不特定多数に一方的に公開する、というだけであれば、コミュニケーション力が必要とされる部分は皆無です。
2. 論理的思考
いわゆるロジカルシンキングというものです。
プログラミングに関する名言の1つに、「プログラムは思った通りに動くものではなく、書いたとおりに動くものだ」というのがあります。
これは割とよくある、「作成したプログラムが思ったように動かない」という愚痴に対する戒め（あるいはカウンター）です。言われてみれば当たり前のことですけどね。
プログラムを作る上で、そのプログラムの要求・目的が、具体化されていない、あるいはロジカルに表現されているわけではないことは、多々あります。むしろ、出発点は常にそんな感じと言っても差し支えはないでしょう。
経理の計算の業務をプログラミング化したい
実際にどんな作業が行われているか確認
それぞれの具体的な式や使われる数字を確認
作業方法の手順をプログラム（あるいはそのひな形）として作成
みたいな流れは、プログラミングに携わっていない人でも、何となく理解できるのではないでしょうか。論理的思考力が高いと、特に3. や 4. の過程で、足りない要素に気がついたり、既存の方式の問題点に気がついたり、あるいはプログラムで行うことによる問題などにも気がつくかもしれません。
また、本セクションの最初に書いた「プログラムが思った通りに動かない」状況に際して、自分の意思と、記載されているプログラムのズレを探ったり、実際の動作から、プログラムのどの部分が意図とずれているのかを探っていく、というような作業は、論理的思考力があるほど、効率的に行えます。
ここまで書くと「論理的思考力は必須では？」と思われるかもしれませんが、そうでもなかったりします。
たとえば、プログラムを作成する前段階での、設計などの準備が十全に行われている環境であれば、プログラムを実際に作成する人は、ただ設計書に書いてある操作を、プログラミング言語に置き換えるだけ、ということもあります。
そういった作業だけの場合、プログラマーではなく、コーダー（プログラムのコードを書くだけの人）なんて呼ぶこともありますが、それはそれとして、条件によっては「論理的思考力がまったくなくても」プログラマーとして仕事ができうる状況も、これまた存在するわけです。
3. 技術力／知識力
「優秀なプログラマーに必要なもの」といったら、まあ技術力なのですが。
前述のように「プログラマー」にも色々定義がああって、個人が趣味でプログラムを作成する分には、作成者が満足する結果が得られるなら、別に技術力は必要ない、ということもあります。
あるいは「プログラマー」という肩書きで、実際には別の作業なんかをやらされている場合にも、必須ではないくなることも十分にあります。
とはいえ、技術力や知識力がなければ、職業としてのプログラマーに就職することは難しいでしょう。未経験から鍛えます、みたいな職場であれば、就業段階では技術力や知識力は不要かもしれませんが、その状態をプログラマーと言うのかどうか、という（前章での問いも含めて）きわめて微妙な話であることに、間違いはないかと思います。
追加で、2つの話
少し別の観点、現実に起きた事件や事象から、エンジニアのあり方について考えるネタを。
Case. 1 故・金子勇氏
金子勇 氏という、ソフトウェア開発者・研究者がいました。
前提として、彼は、プログラムの作成、そのものを職業にしていたわけではありません。技術研究をやっていたので、必要に応じて、仕事としても作成していたでしょうが。
それと同時に、彼は Winny という、ファイル交換ソフトを、個人（単独）で作成し、配布しました。
Winnyは不特定の相手と、インターネットを経由して、ファイルを交換することができるソフトウェアでした。また、管理するサーバーを持たないため、交換されている特定のファイルをWinnyのネットワークから削除する、最初にファイルを公開したのが誰なのかを特定する、といった作業が、少なくとも個人では極めて困難という特性がありました。
さて、金子氏は、匿名掲示板の2ちゃんねる（現：5ちゃんねる）にて、このソフトウェアを頒布しました。それにより、多くのユーザーが、音楽データや、テレビ・映画の動画、あるいは市販のプログラムなどを、著作権を侵害する形での交換を行いました。
当然、金子氏は、そのような使い方がなされていることは理解していましたし、また、違法でないファイルの交換であれば、わざわざWinnyを使用するメリットはありませんでした。
そしてWinnyは、ファイルを交換する際、必ず誰か別の人が起動しているWinnyを中継する動作があり、知らない間に他人の違法行為の手伝いを行うような仕組みでもありました。
すなわち、たとえユーザー自身が合法なファイルの交換のみを行っていたとしても、尚、システム的には違法なファイル交換に加担する仕組みとなっていたのです。
これにより、多くのデータ（ゲームや映画、音楽CDの中身など）が不正に共有され、厳密な金額の推定は困難であるものの、ACCSの推定によれば100億円規模の社会的ダメージを生じさせました。
それ以外にも、不適切なWinnyの設定や、マルウェアがWinny経由でばらまかれ、それに感染した機器による情報漏洩の問題なども噴出しました。
翻って、Winnyの匿名性や機能性により、何か良い方向に（合法的な）価値を生み出した、という実例は、少なくとも私が知る限り、皆無です。
もちろん、不正なデータの公開や、その受領の主体は金子氏ではなく、実際に逮捕されて有罪になったのも、データを送信していたユーザーのみでした。金子氏は逮捕されたものの、上記の著作権侵害については幇助は認められなかったわけです。刑事的な判断としては。
しかしながら同時に、金子氏はWinnyの特性を理解し、行動としては、そういった不正アップロードを行う人が、それを円滑に（かつ表面的には匿名で）行えることを助けたことは、確固とした事実です。
さて、金子氏の「プログラムやシステムを作成する能力」は、間違いなく優秀でした。Winnyも、その使い方が違法行為であれ、ユーザーからは喜ばれ、またユーザーの求めた機能を実装していくなど、コミュニケーションもとれていました。
金子氏はプログラマーとして、最低限必要なものを持っていたのでしょうか？
意見は数多あると思いますが、金子氏のようなプログラマーのあり方を肯定するか否定するか、否定するなら「何が足りなかったのか」について考える上では、1つの、複雑かつ重い題材になると思います。
端的な言葉で言えば「自分の扱っている技術がどのように使われるか、それが反社会的な方向性であることを放置したり、積極的に推進するか」という、いわば倫理のような部分は、プログラマーに必要でしょうか？
上記の例は、あくまで個人開発ですが、では、プログラマーを職業としている人が、開発に携わっているプログラムに、法的・倫理的な問題があるとして。それに気がつくことは、要求されるべきでしょうか。気がついたとして、どう行動するべきでしょうか。
「プログラマーに必要なこと、絶対外してはならないこと」に、これらの視点は含まれるべきか。
さあ、大いに悩んでくださいませ。
Case. 2 日本と海外の違い
これは、企業によって、方針などは異なりますが、日本では「システムエンジニア」という役職を比較的、耳にすることが多いと思われます。
日本で言うところの「システムエンジニア」は、現実的には、コンピューターなどのITシステムに関連する技術職、ぐらいの範囲の、かなりぼんやりとした言葉でしかありません。（会社によっては、自社の人間の役職としては区別していることもありますが）
そして日本では、いわゆるシステムインテグレーター（SIer）などが、顧客企業から要件を聞き、システムを作成して納品する、という形式が非常に多く取られています。すなわち、IT企業でない会社が、自社内で、自分たちの使用するシステムを構築する、というスキームがあまり用いられません。
故に、SIerや大手開発会社が、システムの発注を受けて開発することになります。必要なメンバーやスキルは必ずしも一定ではないので、自社にストックしておくことは限界があり、極めて不効率になります。
そこで、自社外から、適宜、人を集めてくる形になります。これがいわゆる「SES案件」の正体です。
こういった開発案件では、特に集められてきたSESのメンバーは、顧客の業務などは基本的に知らない状態からスタートします。直接、案件を請け負う会社のメンバーであっても、十分な説明や、現地調査などを行った上で把握していく形になるでしょう。
そして、上記のような形式で人を集める場合、ピンポイントで能力がマッチした人を探してくることは、現実的ではありません。そこで、言ってしまえば「質より量」とか、「想定する能力を平均化して必要な数を推測する」などということが行われます。
こういう状況だと「他に優秀な人がいれば、プログラマーとしてそこで仕事をするのに（何かしらが）足りない」人でも受け入れられたりします。
また、必要な人数やスキルの見積もりがおかしかった場合、いわゆる「炎上」が起きることもあります。これを防ぐのは誰の責務か、プログラマー側が炎上を防ぐため、どこまで求められるのか、等は、人によって意見がわかれるところでしょう。
そういった形態なので、自社のシステムは自社内で作成する、あるいは全部を作成しないにしても、業務的なコアな部分を開発する能力のあるメンバーを揃えられる、海外の企業に比べると、日本でのプログラマーは「業務は知らない、単にプログラムを作成できるだけ」という色が強くなります。
すなわち、プログラム作成を職業とする、というケースに絞った場合に、「日本的な企業で働くか」「外資系や海外の企業などで働くか」でも、プログラマーに求められる諸々（能力・資質・立ち位置など）が異なってきます。
ちなみに、海外での中小企業で、自社でシステムを設計・開発までできる人員を雇えない場合、通常は、パッケージソフトや、最近ではオンラインのサービスなどを組み合わせて、社内のシステムを作り上げます。業務とのズレがあれば、業務の側を変更します。
ここら辺、業務ありきで「それをやるためのシステムを作る、業務は可能な限り変えない」がスタートラインになりがちな日本が、IT導入や投資に失敗しやすい一因でもあります。
さて、こういった差異については、国内で、日本の企業に就業する分には、直接意識する必要はないかもしれません。
しかしながら、各種ITツール等の多くは、海外製です。残念ながら、日本発で、企業向けに多く使われているソフトウェアやツールは、殆どありません。
たとえ表示言語などはローカライズされていても、海外のソフトウェアは、上記のような「プログラマー」を含む、社内のITエンジニアがいる環境を、想定する利用状況としているケースも多々あります。
そして、そのズレは、これからどんどん深刻になっていく可能性があります。なにせ社会規模に比べて、開発を含む、ITエンジニアの数が足りなくなってきているので。
最後に
貴方が、プログラマーか、プログラマーでないのか。あるいはプログラマーを志しているのか。どうであれ、一般論としての「プログラマーに欠かせないこと」を定義することは、不可能であることは、既に理解いただけていると思います。
その上で、特に貴方がプログラマーや、プログラマーを志しているのであれば。
この記事に記載した要素や、あるいはそれ以外に貴方が知りうる「必要そうなこと」も含めて、何を必須とし、何にウェイトを置き、何を求めていくのか。
その組み合わせが、言ってしまえば「プログラマーとして生きる上でのセンス」であり、「プログラマーとしての価値」に繋がるものだと思います。
誰かが指し示してくれる正解はありませんが、貴方が道を定める上での参考になれば、幸いです。
この記事が気に入ったらサポートをしてみませんか？