ソフトウェア開発

プログラマという職業は「ふつう」の人には厳しくないかでは結構な反応もらって少しびっくり。

そこらへんのことをもう少し述べると、僕自身はプログラマが勉強をしないでいい職業とは思っていない。ただ、現状プログラマをやっている人で、普段自分でコードを書かない(能力的に平均以下であろう)人達がかなり多く存在している。個人的にはハッキリ言ってそういう人達は足手纏いだと思っている。なので正直、そういう人達がいなくなればいいとも思っている。

だが、現状そういう人達が存在している以上、「あなたたちはプログラマとして無理なのでやめてください」と言ってしまっていいのか、それはさすがに傲慢じゃないのか、普段からコードを書き能力がある人達と、そうじゃない人達が共存する方法はないのかと思って色々書いたのが先のエントリ。

@ukstudio 別にその仕事を好きでもなくて向いてるでもなくて、ていう人たちに別の仕事やったら? ていうのは排除してるわけじゃないと思うんだけどなー。

しかし、ogijunさんにこのように言われて、それもそうかと納得してしまったので、僕にとって結局のところプログラマは自己学習をし、ある一定以上の能力がある人達が就く職業ということで落ち着いた。

で、落ち着いたはいいけど、現状そうはなっていない。個人的に一番疑問なのが給与面である。

先のエントリでの反応で、「業務時間外の行動が業務に影響し、それ相応の査定・給与となっているのだからいいではないか」と言ったような意見をいくつかもらったが、本当に査定・給与に反映されているのだろうか。正直、プログラマは技術力にかなりの格差があるにもかかわらず、給与にそこまでの格差がないように思える。

はてブで「プログラマや専門職はそういうもんだ」「社会人なら勉強してて当然だ」という意見が多数だったが、そういう人達は相応の対価をもらっているのだろうか。そこが一番不思議だ。個々の能力を給与に反映されてないにも関わらず、業務時間外に勉強するのが当然と思っているとしたら、少々社畜っぽいなと感じる。医者や弁護士を例に出した人もいたが、それらは資格が必要なのもあって供給の少なさからそれなりの高給をもらっていると思うのだが、プログラマはそうじゃない。

これは多分、プログラマに限った問題ではない。この間聞いた話だと、不動産の営業で片や2億売り上げた、もう片方は200万売り上げた。しかし給与はほぼ同じという例もある。もちろん、会社という存在があってこその2億だとは思うが、それを考慮しても本人からしたら1億9800万の差が給与に反映されていないならモチベーションがあがるはずもない。

プログラマの場合、問題になるのが成果がわかりづらいという点である。なにをもってプログラマの価値を決めればいいのかわかりにくい。例えば、優秀な人であればコード量は少なく労働時間も短く作れるものが、他の人であればコードは肥大化し労働時間も長くなるだろう。その場合、後者の方が残業代なども含めて給与が高くなるだろう。

結局のところ、プログラマが作りだす価値を定量的に評価できないのが問題だとは思うけど、そこを解決する術が正直わからない。

業界云々ではなく、自分で自分の問題を解決するだけなら、会社に所属した以上自分の価値を決めるのは会社になってしまうので、それを解決するには起業や個人事業主などを検討するのがいいとは思っているけどどうなんだろうか。

例えば、会社員だとあるサービスを作ったとしてそれが大成功をしたとしても、売り上げた金額に比べて自分の給与に反映される金額はそこまで大きくないだろう。しかし、法人や個人事業主としてなら契約金+レベニューシェア的なことも検討できる。

いまのはあくまで1つの例だが、そういう選択を自分で出来ることを考えると起業・個人事業主というのも1つの選択肢としては全然有りなはずだ。法人なら税金も安くすませるはずだし。

最近、実はプログラマという職業が「ふつう」の人には厳しいなーと思っていたりする。

業務外にコードを書いたり、技術書などを読むというのは素晴らしいことだと思う。けど、会社側がもし「業務時間外にコードを書いたり、技術書を読んだり、勉強会に参加しなさい」と言ったら、それは業務時間外労働と変わらないと思う。個人のたのしみとは別に会社側がそれらを求めたらそれは業務だ。

しかし、僕が思うにはそういう業務時間外に自主的に勉強をしないと、正直いってまともな品質なソフトウェアを作るのは難しい。

例えば良書と言われているものは結構な数あり、ある程度経験がありそれらの本を読んだことがある人は「プログラマならこの本は読んでおくべき」という本をいくつかあげたりもするだろう。けど、それらをいつ読むのか。業務時間内にそれらをじっくり読んだり、実際にコードを書いたりする時間があるところはないだろう。そうなると自分のプライベートの時間を使うしかない。

別に僕はそういうことが好きだからいい。会社への貢献とかそういうことは関係なく自分で読みたい技術書は読むし、書きたいコードは書く。では、そうじゃない人達は? (とりあえず、ここではそういう人達を「ふつう」の人と言うことにする)

「ふつう」の人達はプログラマになるべきじゃないのだろうか? 例えば、プロスポーツ選手であれば普段の生活からそれ相応の生活を求められるだろうが、プログラマもそういう職種なのだろうか。

少なくとも今現在まわりと見渡すと「ふつう」のプログラマも結構いるように思う。結婚して妻子がいて、そういう勉強の時間があまり取れないって人もいると思う。そういう人達にプログラマはもう無理だねと言ってしまってもいいのだろうか。

多分、個人的にそれは違うと思っている。なぜ?と言われると正直「なんとなく」程度でしかないのだが、プログラマは「ふつう」の人達でも普通に働ける職種であるべきじゃないのか。

業務時間外に勉強をすることを業務時間外労働と捉えた場合、業務時間外労働をしないとやっていけない職種はおかしいというか病んでいるんじゃないかなぁ。

考えるきっかけになったのは、最近話題になっている以下のエントリ。

人生を書き換える者すらいた。: 人材獲得作戦・４　試験問題ほか

個人的に、あるアルゴリズムを用いて解くような問題を採用試験にだすのはどうかと思っていた。理由としてはいくつかあるのだけれど、「業務でそういったアルゴリズムを使うことが少ない(為、そういう知識がない」「知っている人と知らない人とで差がでてしまう」などなど。

で、先程Twitterに発言しながら似たようなことを考えていたのだけど、よくよく考えると上記の理由は「採用される側」での意見ということに気づいた。

まず、「採用する側」で一番避けたいのは、「ダメな人を雇ってしまわない」ということ。優秀な人を間違って落してしまうのも勿体無い話ではあるが、ダメな人を雇ってしまうよりはマシだ。そうなると採用試験では、その「ダメな人」を確実に篩い落したいわけだ。

大体において、業務で使わないようなアルゴリズムを知っている人は優秀である可能性が高い。「知識の差で合否が決まるのか」という話もあるが、知っている人は独自で勉強をしているだろうし、それをきちんとこういう問題にあてはめられる人はやはり優秀な人が多いのではなかろうか。

逆に言うと、それ以外の人は「ダメな人」である可能性が高いのであって、採用側がこのような問題を用いるのは割と理にかなっている。

それに仮にアルゴリズムを知らなくても、プログラマの基礎能力として「アルゴリズムを自分で考えられる」というのは大事なので、「私はこのアルゴリズムを知らないので理不尽だ」というのも結局自分のダメさアピールにしかならない。

採用試験をある種のフィルタと考えた場合、取り零しよりそのフィルタを抜けてきた人が重要という点を考えれば、この様な採用試験はかなり有効だと思われる。

やけに煽ってるタイトルだけど、別にそんな大した話でもない。最近個人的に思ってることをつらつらと書く。

まず、Web系受託会社の定義だけどまぁWebサービスやWebアプリケーションなど比較的規模の小さいものを受託で作っているところとする。「規模の小さい」も割と感覚的なものだけど、まぁその辺の詳細は省く。

で、なんでまた亡びるとか言いだしたのかと言うとこの程度の規模のものは外部に開発を依頼するより、自分達で作る内製に向かっていくんじゃないと思っている為。特に最近の不景気でエンジニアを雇って内部で作るという流れがあるように見える。少なくとも僕のまわりでは。現にそういう話で「うちこない?」的なことも何度か言われている。受託会社に勤めている身としてはうちに発注してよと思わなくもないが、なかなかそうも行かないらしい。

まぁ個人的にはWebサービス、アプリケーションに限らず、いわゆる業務システムも内製した方がいいと思ってるからまぁこの流れは歓迎してると言えばしてるんだけど、受託会社としてはちょっとやばいかなと。

要は今まで発注してくれてた会社が自分達で作るようになって、受託会社に仕事がこなくなるからやばいんじゃないのって話。業務システムとか割と規模の大きい仕事を受けてるところはまだ大丈夫だと思う。 それよりWebサービス、アプリケーションをメインで受託してる会社がやばい。

なんでやばいかと言うと、ちょっと優秀なエンジニアなら1人で作れるものが多い。例えばSNS(ブームは去ったけどね)を作ろうとなったときに、外部に依頼するよりエンジニア1人とデザイナ1人雇えば十分だと思うし、僕自身作れる自信がある。まぁSNSと言っても規模は色々あるんだろうけど。

まぁさっきも言ったように、内製するのは歓迎だしそれはそれでいいんだけど、受託会社として今後どうするのかって話。

いくつか思いつくのは、業務システム系に手を出す、売るものを作る(パッケージ開発)、自社サービス(広告、課金)とかとか。まぁどれが正解とかわからんし、もしかしたら他にも道があるかも。

そんなことを考える日々です。他のWeb系受託の人たちはどう考えてるんだろうねー。

献本して頂いたにも関わらず、書評が大部遅くなってしまいました。角谷さん、ごめんなさい。

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~
	安井 力 角谷 信太郎 毎日コミュニケーションズ 2009-01-29 売り上げランキング : 8925 おすすめ平均 「正直になること」がアジャイル成功の秘訣 ソフトウェアの見積りは本来こうでないか？ 自信を持って見積もりを出すための手引き書 Amazonで詳しく見る by G-Tools

さすがに全てのアジャイル本に目を通しているわけではないけれど、最近までに出版されているアジャイル本の中でも断トツの重要度な本だと思う。これを読まずしてアジャイルとか言っちゃダメだ。

まず、出版から3年が経過した現在、本書の原著は北英圏のアジャイルソフトウェア開発コミュニティで「必読の一冊」という評価を確立していることです。

すでに北英圏から3年遅れっていうところも衝撃だけど、それよりも日本に持ってきてくれてありがとう!という感謝の念が強い。安井さん、角谷さん、本当にありがとうございます。

この本は23章のケーススタディがよくできている。個人的にこう言ったケーススタディが好きなので、まず最初にここから読んだ。それだけで十分にこの本が素晴しいことがわかったし、冒頭から読み始めた時もケーススタディが具体例としてイメージできたので理解しやすかった。

ケーススタディもそうだが、この本は非常に例え話が豊富だ。この本を初めて読んだときは、ストーリーポイントをはじめ見知らぬ概念が多かった。それらの理解を助けるのに、例え話は非常に効果的だった。

このボリュームの内容をここで全部書くことは厳しそうだが、1つ思ったのは「正直」の重要さだった。正確な見積もりができないことを認める。顧客やプロダクトオーナー(もちろん他のメンバーも)に細かく報告する。これらは全て「正直」にならないといけない。この「アジャイルな見積りと計画づくり」も非常に正直な本だった。

先日、うちの会社でストーリーボイントとベロシティの説明とプランニングポーカーを数人で実施してみた。好評で、「じゃあどう導入していこうか」という話にはなりつつある。問題なのはうちは少人数で小さい案件を回すことが多いので、例えば仮に僕がメンター的な役割をしようにも、僕がAという案件をやっていて、ほかの人がCだったりBだったりすると中々面倒を見れない。そのあたりを今どう解消しようか考えている。

個人的に、この本は手元に置いておきたいのがだ、会社のメンバー全員にも読んで欲しいと思っている。できれば全員に買って欲しいのだが(本の売上げ的にも)、なかなかそうはいかなそうなので、献本してもらった本を会社に置いて、もう1冊新しいものを自分で買おうかと思っている。

あと、この本はアジャイル入門本ではないので、この本と一緒に「Head Firstソフトウェア開発」と「アート・オブ・アジャイルデベロップメント」も読んでおけばいいんじゃなかろうか。まぁ僕はまだどっちも読み途中ですけどね・・・

最後にもう一度言います。この本を読まずしてアジャイルとか言っちゃダメ!絶対!

Head Firstソフトウェア開発 ―頭とからだで覚えるソフトウェア開発の基本
	木下 哲也 (監訳) 有限会社 福龍興業 オライリージャパン 2009-01-22 売り上げランキング : 165325 Amazonで詳しく見る by G-Tools

アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング
	木下 史彦(監訳) 平鍋 健児(監訳) 笹井 崇司 オライリージャパン 2009-02-18 売り上げランキング : 28100 おすすめ平均 現時点で最良のアジャイル解説本 アジャイルなやり方の具体的なガイド アジャイルのための練習曲集 Amazonで詳しく見る by G-Tools

木下さんと角谷さんが監訳したアジャイル本。なんとか年内に読み終わった。このエントリーを書くのは2008年になってしまったけど。

アジャイルな開発者もそうでない開発者も

今までアジャイルな開発とは無縁だった人達も、既にアジャイルな開発手法を採用している人達、どちらの人達にも得るものがある本だと思う。前者の人達にはこれからの道標として、後者の人達には振り返りとして。ちなみに私は前者。

そもそも本書での「アジャイル」の定義は以下のようになっている。

開発がアジャイルであるということは、協調性を重んじる環境で、フィードバックに基づいた調整を行ない続けることである

つまり、開発手法がXPとかScrumである必要はないし、極端な話、組織とかすら関係なく開発者が自分1人だけでもアジャイルな開発は行なえる。なぜなら、未来の自分に対してフィードバックをすればいい話だから。アジャイルプラクティスにも1人で実践できるプラクティスがいくつか載っている。

悪魔の囁き、天使の助言

各プラクティスの構成は、悪魔の囁きに打ち勝つべく天使の助言を授かるという形ですすめられている。まさに表紙の通り悪魔 VS 天使の構図なわけだ。悪魔の囁きはちょっと表現がオーバーな気もするけど、そこが悪魔っぽいと言えば確かに悪魔っぽい。仮に悪魔の囁きにピンとこなかったとしても、天使の助言は聞いとくべきだし、なんなら悪魔の囁きを自分なりに変えてみるのもいいと思う。

まずは1つのプラクティスから

いくら天使の助言を聞いたところで、それを習慣にしなければ意味がない。アジャイルプラクティスには全部で45のプラクティスが掲載されているが、流石に一度に全部実践しようと思ってもまず無理だ。とりあえず自分にとって重要なプラクティスを1つ選んで、それが習慣づいたところで次のプラクティスに進むのがいいと思う。(プラクティスによっては複数同時に実践できるかもしれない)

この辺に関しては「第9章 終章：アジャイルへ踏み出す」を読んでもらえればいいと思う。アジャイルへ踏み出すと言うタイトルからもわかるように、この本を読んで終わりじゃいけない。むしろ読み終わってからが本番なのだろう。

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣
	Venkat Subramaniam Andy Hunt 木下 史彦 オーム社 2007-12-22 売り上げランキング : 16000 おすすめ平均 迷える開発者への最初の一歩となる本 Amazonで詳しく見る by G-Tools