「いくら技術力があっても、仕事ではコミュニケーション能力がないとダメだ」
もちろんこの意見は、別に間違ってはいません。ですが、僕が言いたいのはその逆のことなのです。
「いくらコミュニケーション能力があったって、プログラマに最終的に必要となるのは技術力」
ということです。
僕が関わってきた現場でたまたまそうだっただけかもしれませんが、多くの場合プロジェクトがうまくいかない原因はコミュニケーションよりも技術力が不足していることの方が多いのです。
■ プログラミング経験の重要性
これはなぜでしょうか。
僕が思うに、彼らはプログラミングの経験が圧倒的に足りないのです。プログラミングは一朝一夕では身に付きません。
文法とかは本でも読めばすぐにわかりますが多くの人がつまづくのはそういった汎用的な箇所ではなく、もう少しシステムに特化した部分です。
特に、フレームワークや共通ライブラリによって多くの機能が提供されている場合、プログラマは考えることをしなくてもロジックを達成できてしまいます。
コンポーネント（部品）をつなぎ合わせるだけで、簡単な処理は実現できるからです。
■ フレームワークだけではシステムは完成しない
しかし、実際にはこれだけでは足りないのです。
どんなにシンプルに見えるシステムでも、必ずどこか特異な処理というのが必要になってきます。
よく「簡単なシステムを作るだけならフレームワークだけで充分だよね」
なんて人がいますが、そういう人はきっと実際にシステムを作ったことがないんです。
もう一度言います。
どんなに簡単なシステムでも、必ず汎用的な処理だけでは足りない部分が出てきます。
逆に言えば、そういう特殊な事をしたいからシステムを手作りするのです。
フレームワークだけで達成できるほど、業務というのは汎用的ではありません。
システムを使うのは人間ですから、どうしたって画一的ではない部分が出てきてしまうのです。
そういう時、（本当の意味での）プログラミングをした事がない人達はそこで止まってしまいます。
自分で1からものを作ることができないのです。
「アルゴリズムを考える」という経験を、したことがないからです。
■ 1からものを作るということ
この状況を打破するには、とにかく物を作って経験を積むしか方法はありません。
もちろん今の時代は、フレームワークを覚えることも必要です。
しかし、それだけでは足りません。フレームワークは2日で覚えられるかもしれませんが、独自の処理を
自分の思うがままに作り出すためには相当の経験が必要になるのです。
コミュニケーションにこだわる人の多くは、こういった事を軽視します。
もしくは、こういったことができないから、コミュニケーションという楽な道に逃げようとします。
「技術力なんて2～3年経験を積めば大体身に付くでしょ」なんて思っていませんか？
そんなことはありません。
10年選手でも、自分で1からものを作れない人が、この業界には山ほどいます。
そういった人達は何人集まっても、あるライン以上のものは作れません。
しかし、ユーザはそんな事は知りませんからその技術力以上のシステムを要求してきます。さぁどうしましょう（笑）。
■ 力押しではなく、スマートに
大抵の場合、力押しでも何とかユーザの望むシステムを完成させることはできます。
技術力がなくても、「それっぽい」動きをさせることは可能なのです。
しかしそのために多くの時間を使った上に、システムはギリギリの線で動いていることを見過ごしてはいけません。
良いシステムを作りたかったら、もう一歩進んだ技術力を持っていないといけません。それこそがプログラマの個性であり、他者より優位に立てる点です。
プログラマなら、まずは「コーディング力」を磨きましょう。
それは業界一般で言われている付け焼刃程度のコーディング力ではなく
どこへ行っても通用する位に研ぎ澄まされたものであるべきです。
■ コミュニケーションも必要
もちろん、コミュニケーション力が必要がないと言っているわけではありません。
しかし実際、コミュニケーション力は大抵の人が持っています。
人間的に普通の感性があれば、コミュニケーションで困るなんてことはないと思います。
大体、世間一般に言われている「コミュニケーション力のないプログラマ」というのは、社会人としての最低ラインにすら到達していない人のことを指すのです。
よっぽど人員(の数)に困ってる現場でもない限り、そんな人は必要ありません。
システムの良し悪しは、実際にシステムを使うユーザが判断します。
そのシステムを直接作っているのは、他でもないプログラマです。
ですから、プログラマは実はユーザの一番近い場所にいるのです。
システムの良し悪しを決定するもの、それは最終的にはプログラマの技術力に他なりません。
残念ながら今の日本の状況では、いくら優れたコンサルタントがいても、いくら優秀なSEが作った優れた設計書があっても、それを形にできるプログラマというのが圧倒的に不足しています。
# もし足りているという人がいたら、あなたの現場はとても幸せです。
■ 最後に
プログラマの皆様。
いちど初心に戻って自分のコーディング力を見直してみましょう。
もし自信を持って「コーディング力は足りている」と言えないのならば、それを磨くことをした方がいいかもしれませんよ。
]]>なんか最近、生産性向上について盛り上がっているようです。今月のお題というやつなのでしょうか。というわけで自分も乗っかって書いてみました。
僕も「生産性向上」というキーワードは仕事を始めた頃からずっと考えてきて、実際に現場でもそれが大事だと言い続けてきました。
しかし、ビジネスモデルとして考えるとそれが果たして良いことなのか、など様々な議論になり、結局正しい答えは出てきません。その辺の議論は別の人達に任せるとして、自分は少し違う視点で書くことにします。
■ 過程と結果
まず最初に、「生産性向上」について改めて考えてみました。なぜ自分は生産性を向上させたいのか？
…(考え中)…
はい、結論が出ました。
僕は別に『生産性を向上させたいわけじゃない』んです。よくよく考えてみたら。
生産性を向上させたいのではなく、やってきた結果として生産性が向上したというだけだったんです。しかし仕事場に出ると、自分と他の人との生産性があまりにも違うことに気付くのでつい言ってしまうのです。「生産性向上させようよ」とか。
「プログラマとしての本質は何か」というのがこのコラムの主旨ですから（ホントか？）、もっと根本から考えてみましょう。
■ 理由
では、なぜ僕は生産性が向上したのか。
長いことプログラミングしてればそれは当然だって気もしますが、他の理由もあります。
それは『早く物を作りたい』という僕の性格によるものです。
プログラマはクリエイターだと思っています。物を作ることに生きがいを感じる人。だから、自分が考えたことを早く物（プログラム）にしたいわけです。
「こんな物を作りたい」という欲求と、「こんな物が完成した」という達成感。この間隔はできるだけ短い方がいい。
時間が掛かると情熱も冷めてしまうし、ほとんどの人の場合は頭で考えるスピードとプログラムを書くスピードでは後者の方が圧倒的に遅いので、少しでも速くプログラムを書けることが望ましいです。
そして何より「遅いことにイライラする」んです。プログラマっていうのは。
gcc の Make が4時間も掛かることに対して
「まぁコンパイラのMakeだからこれ位かかってもしょうがないよな～」
ってあきらめの感情を持つか、
「遅いものは遅い。俺が何とかしてやる」
と改善する心を持つか（実際に改善できるかはまた別の問題）。
後者の気持ちを持つ人っていうのは、自然と生産性が向上します。
常に速さを求めるのです。
思ったものを即座に形にしたいから。遅いことでイライラしたくないから。
■ 趣味と仕事
これは性格の問題ですから、そう思わない人がいたとしてもそれはしょうがないことなんだと思います。
もちろん「プロなんだから向上心持って仕事してほしい」とも少しは思うのですがすべての人が生産性向上を望んでいるかといえば、それは違うと思います。
「そんな急いでどうすんの」って言われてしまうかもしれません。
おそらくですが、仕事からプログラミングを始めたという人は生産性向上をあまり意識しない人が多いです。
趣味でプログラミングを始めた人は、おそらくプログラムが好きなはずです（よね？）。そういう人は、自然と生産性が向上します。
そして仕事でプログラミングをするようになっても、その生産性は向上し続けます。
■ 結論
そう。だから。
生産性を向上させたかったら、プログラミングを好きになるしか道はないのです。
利益効率どうのこうの言ったって、人はそんな簡単に変われません。でも、物を作る喜びを一度知ってしまえば、その魅力に取りつかれてあっという間に生産性は向上します。
「好きこそモノの上手なれ」。昔の人はうまく言ったものです。
皆さん、もっとプログラミングを楽しみましょうよ。
I love programming.
]]>このコラムでは、日々思うことから専門的な内容まで、気ままに書いていこうと思いますので、よろしくお願いします。
■ 自己紹介
今回は最初ということで、自分がPCに出会ってから、これまでやってきた仕事などについて簡単に紹介させていただこうと思います。
え？ 生い立ちなんてどうでもいいって？
……なんか空耳が聞こえましたが、とりあえず聞こえないフリで先に進みましょう（笑）。
● 1台目
まず、僕が最初にパソコンというものに出会った頃の話です。詳しくは覚えていないのですが、おそらく小学校1年か幼稚園ぐらいだったと思います。
相当古いですね。25年位昔のことです。うちの父親が機械好きだったこともあり、大して裕福でもない我が家にパソコンがやってきました。
ちなみに、機種は「MZ-1200」というシャープのマシンでした。
グリーン一色のコンソール画面、記憶媒体はカセットテープという今となっては化石級の代物です。『記憶媒体がカセットテープ』といっても、今の若者には通じないかもしれませんね。
今では当然のようにハードディスクですが、その前はフロッピーディスク、さらにその前はテープ、その前は紙（！）だったんですよ。知ってました？
で、その頃パソコンで何をやっていたのかというと……あまり覚えていません。ただ、当時から僕がパソコンに興味を持っていたのは確かです。
● 2台目
小学生1～2年の頃、我が家に2台目のパソコンがやってきました。富士通の FM-7 という機種です。
グリーン一色だった前機とは違い、今度のは何と8色も出るんですよ！（笑）
そして文字だけのコンソール画面から、VRAMを搭載したグラフィック画面に進化しました。ちなみに解像度は 640×200 でした。CMのイメージキャラクターはあのタモリさんです。
このパソコンには標準で F-BASIC というOS兼プログラミング言語が内蔵されていました。おそらくこれが、僕が最初に覚えたプログラミング言語です。お絵描きプログラムなんかを作っていた記憶があります。
BASICでは処理速度が遅いので、機械語を学びました。搭載CPUは、モトローラの6809。8ビットPCです。アセンブラ言語を買う金はなかったので、自作の簡易アセンブラを作ったりもしていました。
そして、このパソコンの特徴は様々な周辺機器がオプションで付けられることでした。以下、我が家に導入されたオプション機器たちの紹介です。
どうです。すごいでしょう（笑）。でも当時は、どれも画期的なことだったんですよ。
● 3台目
高校に入学するとき、初めて自分用のパソコンを買ってもらいました。機種は NEC の PC9801 FA。当時としては結構高性能の機種です。
搭載CPUは一気にパワーアップして Intel の i486。OS は言わずとしれた（最近はそうでもない？）MS-DOSです。画面解像度は 640×400。色は4096色中16色だったかな？ ←ちょっと自信ないです。
パソコン本体の次に真っ先に買ったのは、Borland の Turbo C++ でした。C言語には、前から興味を持っていました。BASICよりずっと優れていて、綺麗なコードが書ける！
C++ になってクラスやポリモーフィズムが追加され、より進化したこの言語をやりたくて仕方ありませんでした。
300ページ以上もある分厚いマニュアルを何度も何度も読み返しひたすら勉強しながらコードを書きました。この頃には、完全にプログラミングが趣味になっていました。
● 4台目
大学に入って、Windows マシン（いわゆるDOS/V機）を買いました。機種は忘れてしまったのですが、自作PCだったかな？
そして Visual C++ を買いました。MDやテープに溜め込んだ楽曲を整理するのに、今まではノートを付けてやっていたのですが、専用のアプリケーションを作って管理などをしていた記憶があります。あとは、DirectXを使ってシューティングゲームなども作りました。
この頃、自分のホームページも開設しました。当初は好きな音楽についてのページや日記などを書いていました。
● 5台目
自宅サーバのために、コンパクトなベアボーンPCを買いました。Redhat Linux を入れ、Apache で HTTPサーバ、qmail でメールサーバを立ち上げました。
最初のうちは HTML と Perl CGI でサイトを構成していました。しばらくして、ある言語に出会いました。Ruby です。
「何て素敵な言語なんだろう」
この言語を使ってみてそう思いました。eRuby というライブラリを使い、Perl の代わりに Ruby で CGI を書くようになりました。
Java を勉強して Tomcat サーバも導入しました。
Servlet を使って最初に作ったシステムが、自分用の日記サイトでした。それまで日記はテキストに手書きしていたのですが、現在のブログのようにログインして、Webブラウザから直接日記を更新できるようにしました。
一般公開もして、ブログサービスも始めました。今でも、一応やってます。ほぼ誰も利用者いなくなりましたが(笑)。
■ 就職
さて、プライベートの話はこれ位にして。ここからは仕事の話です。
2001年に大学を中退し、プログラマとして派遣会社に就職しました。
最初の現場は、Unix C でした。入ってすぐ気付きました。とんでもなく汚いコードが平気で書かれています。そして月間労働が300時間を超えるような人達が山ほどいて、顔はやつれていました。
それまで15年以上プログラミングし続けてきた僕には、この開発現場がどれだけ非効率かわかりました。
でも、下っ端でしかも業務実績のない僕が、彼らを指導することはできませんでした。
それからは数ヶ月に1回のペースで、現場を転々としました。どこへ行っても、状況はあまり変わりません。紙くず程度の価値にしかならない分厚い設計書を必死で書いている人、プログラミングもロクにできないまま設計を担当している人、テストでたくさんバグが出ないとシステムが信頼できないと思ってる人、いろんな人がいました。
そんな人達に共通して言えることは、
「どうやったら優れたシステムを作れるのかを知らない」
ということです。
しかし、知らないのも無理はありません。彼らは優れたシステムを見たことがないし、ましてや作ったことなどないのですから。
僕だったら、彼らに「どうやったら優れたシステムを作ることができるのか」を教えることができると思っています。
しかし、派遣というパッチワーク的な役割の人間がそれを説いたところで、現場は変わらないということに気付きました。
● 正社員
随分時間が経ってしまいました。
派遣の仕事に限界を感じていた僕は、2年半ほど前に今の会社に正社員として中途入社しました。
入った当初、僕が配属したチームはリーダーのワンマン体制でした。
チームメンバーは、そんなリーダーを恐れてただ言われた通りに仕事をしていました。人の言うことをハイハイ聞いてるだけなんてことが嫌いな僕はそんな中で浮いた存在でした。
僕の力がある程度チームでも認められてきた頃、（関連があるかどうかはわかりませんが）そのリーダーが会社を去りました。そしてしばらくして、そのリーダー色に完全に染まってしまった人達もいなくなりました。
僕はチームのサブリーダーとなり、ある程度自分のやりたいように仕事ができるようになってきました。
しかし今度は、別の問題が出てきました。
不況です。
今の現場で仕事を続けられるかどうか、先行きが見えなくなりました。でも、こんな時だからこそ自分の力が役に立つかもしれないと前向きに考え、コラムを書こうと決意しました。
■ 最後に
今回は、最初ということで自己紹介をさせていただきました。
今後は、コラム毎にテーマを決めて、それについて掘り下げて話をしていきたいと思っています。テーマによっては毒舌度が高くなることもあるかもしれません(笑)が、皆さんのお役に立てれば幸いです。
それでは、長文お付き合いいただき、ありがとうございました。
]]>