川村渇真の「知性の泉」

スキルアップできる仕事を選ぶべき


営業活動をしたことがないと言うものの……

 ここ数年の間に、何人かのフリーランス・プログラマーと話をする機会があった。全員に共通するのは、プログラマーとして、ある程度の実力を持っている点だ。そしてもう1つ、仕事を得る活動に関して、全員が同じことを言っていた。「自分は、営業活動をしたことがない」と。
 発言したときの態度から見て、「自分は営業活動をしなくても仕事が入ってくる」と言いたそうに感じた。しかし、これは良いこととは言えない。そう思うので、こう発言した相手には質問を投げかける。「では、実際にやった仕事はどんな内容ですか?」と。また「最初に約束した金額で、きちんと支払ってもらってますか?」とも尋ねる。
 この質問への回答も、ほぼ共通していた。まず仕事の内容だが、大手が引き受けたがらないマイナーな仕事が多い。加えて、きちんとした開発体制ではなく、やっつけ仕事的な体制での開発が多かった。ひどい場合だと、誰かが失敗して大変な状況となり、それを助ける仕事も受けているようだ。
 支払いに関しても、ほぼ共通していた。短期間で高額をもらえる割の良い仕事が、数は少ないがたまにある。逆に、予定より2倍の期間も拘束されて、支払いは最初に予定した期間分だけという損な仕事も経験している。全体としては、きちんと支払われていない印象が強い。
 以上の話をまとめると、営業活動をせずに済んでいるが、仕事の内容は選べていないし、支払いも予定どおりでないことが意外に多い。理想的な状況からだけでなく、良い状況からもほど遠く、「営業活動をしたことがない」と言ってみても、他人がうらやましく思う境遇ではない。

幅広いスキルアップを目指して仕事を選ぶべき

 システム開発の世界では、良い組織と悪い組織の差は極めて大きい。良い組織では、プロジェクト管理、システム開発方法論、的確なニーズ分析、質の高い設計手法、きちんとした仕様書、設計内容やソースコードなどを対象とした幅広いレビュー、本格的なテストなどを採用し、参加者が確実にスキルアップできる。逆に悪い組織だと、プログラミングすら自己流になって、質の高いソースコードを作れないまま経験年数だけが増える。
 どうせ働くなら、良い組織を選んだ方が絶対に良い。システム開発に必要な幅広い能力が確実に高まるからだ。適性のある人が5年も働けば、自信を持って仕事できるレベルに達する。ソースコードも安心して他人に見せられるはずだし、それをレビューされても怖くない。もし複数の良い組織で働けば、それぞれの“いいとこ取り”が可能で、総合的な能力は相当高まる。これこそ、フリーランスの理想的な姿であろう。
 前述のプログラマーの全員が、独学ながら積極的に勉強していて、オブジェクト指向やデザインパターンなどの技術的な知識はよく知っている。しかし、レベルの高い開発で必要となる能力に関しては、あまり持っていないし、持っていたとしてもレベルは高くない。
 職種がプログラマーなので、もっとも心配なのは、作成するソースコードの質である。これも様々な工夫を盛り込まないと、変更しやすく、変更しても信頼性が高く、処理内容が解読しやすいプログラムには仕上がらない。こういったコーディング方法は、単行本や雑誌には初歩的な部分しか載っておらず、良い組織でレビューを受けながら知るのが一番だ。
 以上の話から分かるように、どんな組織で仕事をするかが重要なのだ。レベルの高い組織で働かないと(より正確には、高い能力を持った人と働かないと)、重要な能力は身に付かない。能力の高さは仕事の質に大きく関係するため、質の高い仕事をするためにはスキルアップが必須である。その意味で、仕事先は慎重に選ばなければならない。営業活動をしたかどうかなど、まったく関係ないのだ。
 営業活動しないで悪い仕事ばかり受けている人は、その人の適性が高いほど、明らかに本人が損をしている。現実には数が少ないだろうが、同じぐらいの適性を持つ人がいて、良い組織で働き続けるとしたら、その差は確実に広がる。「営業活動をしたことがない」などと言っていないで、この点に気付くべきである。
 もう1つの重要な点は、契約の形態だ。フリーランスにこだわる必要はなく、契約社員や正社員になっても構わないので、質の高い仕事を選ぶべきである。もちろん、ずっと勤め続けるわけではないので、退職金の分を報酬に加えるなど、可能な限り良い条件を引き出したほうがよい。

悪い組織ではマネジメント能力が最悪

 ついでなので、フリーランス技術者と契約する企業の側を見てみよう。多くの企業を知っているわけではないが、自分が見たり聞いたりした範囲内では、悪い組織のほうが圧倒的に多い。
 もっとも悪い点は、開発に関するマネジメント能力の低さだ。システム開発では、各工程で決めなければならない内容があり、それが予定どおり終わらないと、開発全体で遅れが生じる。現実の開発では、企業側の管理者がその点を理解せず、大切な決定を先延ばしにしてしまう。そして後半になったとき、あせって騒ぎ出す。
 以上のような注意点はマネジメントの基礎であるが、それすら理解していない。予定より大きく遅れる開発は、この種の基礎的なことを分かっていない場合が非常に多い。つまり、マネジメントのレベルが相当に低いわけだ。
 こういった失敗は、大企業や有名企業の開発現場でも起こっている。こうなる最大の理由は、開発のマネジメント能力を身に付けさせない点にある。開発の責任者となる人には、最低限のマネジメント能力を教育して、開発が失敗する可能性を減らさなければならない。それは企業の上層部の責任だ。おそらく、何が必要かにすら気付いてないのだろう。
 現状のスキルアップでは、開発の直接的な作業だけ経験させ、それ以外の能力は無視している。それを改め、どの仕事をするには何の能力が必要かを調べ、その能力を身に付けるように教育する体制へと、できるだけ早目に移行しなければならない。そうしない限り、小さな開発でも遅れが出続ける。
 レベルの低い企業に対しては、何が悪いのかを知らせることも大切だ。少しでもマトモな話が通じそうな幹部を見付け、悪い点と改善方法をできるだけ論理的に説明しよう。こうした地道な活動でもしない限り、レベルの低い企業を改善するのは難しい。ボランティアの一種だと考え、簡単な助言ぐらいは無償でやってあげるしかないだろう。

良い組織は、個人と契約する仕組みを用意しよう

 良い組織にも改善の余地がある。日本では、とくに大企業ほど、個人と契約するのが難しい。しかし世の中では、組織を飛び出した優秀な人材が増えている。この傾向は、今後も続くだろう。フリーランス技術者の中には、本当に優秀な人がいる。その能力を生かせば、自社の開発力を高めるのに役立てられる。
 特に優秀な人と契約できた場合、その生かし方も重要である。せっかくの機会なので、システム開発の能力に限定せず、マネジメント能力や分析力など、幅広い分野で教えてもらったほうがよい。開発に参加した社員を教育してもらえれば、普通の教育では困難なほど能力が伸び、大きなメリットが得られる。何も言わないと教えてくれないので、最初からきちんと依頼し、意識してやってもらうようにしたい。当然のことだが、契約者にとって余計な仕事が増えるため、それに見合った報酬を払うべきである。
 ただし、日本の現状を見る限り、優秀な人の数は非常に限られている。口ばかり一人前で、幅広い能力を身に付けてない人もいるので、本当の能力を見極めなければならない。そのためには、スキルの記述用紙を工夫しよう。本当のスキルが書ける書式を、本コーナー内で説明してあるので、それを利用すればよい。この書式だと、はったりは通じにくい。
 フリーランス技術者との契約方法だが、コンサルティングとしては一般的な、単価を事前に決めて作業時間でチャージする方式もある。大きな開発が終わった後、小さな相談や手助けを得る方法としても適している。他の仕事を中心にやってもらいながら、ずっと契約し続けることも可能だ。また、その人が空いていれば、急ぎで仕事を依頼することもできる。
 外資系のコンサルティング会社を利用すれば、同じことができる思う人もいるだろう。しかし、実際にはほとんど不可能だ。コンサルティング会社でも、非常に優秀な人はごく一部しかいない。当然、単価が非常に高い(時間あたり5万円とか)ため、マトモに請求されたら高額になる。しかも、優秀なフリーランス技術者と同等の助言しかできない。そもそも、優秀なコンサルタントは、大きなプロジェクトを優先して担当するため、よほどの仕事でない限り割り当ててもらえない。平均よりは優秀な人が割り当てられるのが一般的で、凄い助言など期待できない。
 契約方法に関しては、契約の形式だけでなく、予算の使い方も含めた部署の裁量など、本気でやろうとすれば改善の余地は多い。個人と契約できる体制が整えば、優秀なフリーランス技術者を見付け、社内の人材を教育してもらえる。社内だけでは高い能力を身に付けるの難しい場合、これは最良の方法となる。

 システム開発のレベルが低い日本においては、フリーランス技術者の側も企業の側も、まだまだスキルアップする必要がある。お互いが積極的に活動して、幅広い能力の向上を期待したいものだ。そうすれば、レベルの高い開発がもっと増えるだろう。
 フリーランス技術者は、営業活動をしないで済むことよりも、持っているスキルを自慢すべきである。そうなるためには、必要なら営業活動もして、能力を確実に向上できる仕事を選ばなければならない。「自分は、営業活動をしたことがない」と言うのは、ひととおりの能力を身に付け、営業活動をしなくても質の高い仕事が来るようになったときだ。

(2000年6月28日)


下の飾り