仕事を受注しよう

インターネットが普及した現代では、アマチュアでプログラムを作ってフリーソフトやシェアウェアとして公開している方も多くなりました。中には、プログラム作りを職業としている人よりも、スキル的に優れた人もかなりいます。という筆者など、プログラム作りを職業としているとはいえ、技術的にはそういったアマチュアプログラマよりも低いものが多いです。

ところが、仕事でプログラムを作る場合、フリーソフトやシェアウェアを作る場合とは異なりプログラム作りの能力以外の能力が必要とされる事が多くあります。そこで、ここではプログラムを作る以外に必要とされる能力についても確認してみましょう。

プログラム作りを仕事とするなら、ソフトウェア会社に就職するのが一番良いのですが、ある程度経験を積んでコネクションを広く持ってくると、直接仕事を受注できるようにもなります。（ただし、筆者はケンカ別ればかりしていたため、そのようなチャンスは皆無です。）

会社で仕事をする場合にしても、フリーのプログラマとして直接仕事を請けるにしても、仕事の請け方としては大きく分けて３つあります。

自分、もしくは自社の営業担当が自分で仕事を請けてくる場合です。自社にSEがいればプログラマーレベルではアルゴリズムを考えずに済むのですが、筆者のいたような中小のソフト会社では、SEとPGという役割分担は特にありませんで、プログラマーが自分で考えたアルゴリズムでプログラムを作ってました。

営業担当やSEがある程度システムのわかる人ならば良いのですが、そうではない場合は自分で打ち合わせをしてそれに基づいてプログラムを作成するわけですが、ここで注意しなければならないのがエンドレスという状態です。

入力時におけるエンドレス
たとえば、こんな入力をする業務ソフトがあったとします。


まず品名を入力、つづいて数量、単価をいれ、金額は自動計算されて、次の行へといくでしょう。ところが、ある人はいいました。「数量を入れない場合に、いちいち単価を聞いてくるのはおかしい。数量が空欄ならば単価も空欄に決まっている」と。

という事なので、数量をもし入れなかった場合は、単価の入力は飛ばして直接金額入力になるように作ったとします。この仕様で、一見便利なように見えますが、実はものすごく不便です。もし、数量も単価も不要なのに間違えて入れてしまった際に、品名や数量をバックスペースで消していったとします。すると、数量が空欄となり、単価を空欄にしようにも、カーソルがワープしてしまって、単価を消すことができないのです。

じゃあ、数量が空欄なら単価は強制的に空欄にすべきでしょうか。すると、もし数量を間違って空欄にしてしまうと、せっかく前に入れた単価が空欄になってしまうのです。とくに、単価を商品マスターから自動で読み込む場合、マスターに入った単価が消えてしまうのです。

じゃあ、数量が空欄なら単価は強制的に空欄で、数量が入力されたら復活させるべきでしょうか。しかし、実際には単価は商品マスターから読むだけでなく、手で修正する事もあります。これでは、せっかく手で直した単価が、デフォルトに戻ってしまうのです。

じゃあ、数量が空欄ならば、単価は裏でメモリには取るが、表示だけ空欄にすべきでしょうか。しかし、単価が出たり出なかったりするのは、見ていて非常に煩わしいです。っていうか、十中八九「バグだ」といわれます。

そういうわけで、数量が空欄ならば、単価の入力を飛ばすというアルゴリズムは、入力ミスをしない人が使えば問題ないのですが、人間誰しも入力ミスはするもので、入力ミスをすると訂正困難なソフトになってしまいます。であれば、むしろ単価は常に変更可能とし、変更しない場合はenterキー等でその都度入力を飛ばす方が総合的に見てメリットが高いという事になります。

印刷時におけるエンドレス
この伝票をプリントアウトする際に、このように商品名を印刷したとします。


これだけなら、特に問題があるようには見えません。しかし、もし商品名が短かった場合の事を考えてください。

見ての通り、左に寄りすぎていて格好悪いです。こんな印刷をしたら即クレームになります。

品名というのは、


このように、左に若干の余裕をもって印刷しなければ見づらくなってしまいます。が、しかし、これでもし長い商品名があった場合、

文字が枠からはみ出てしまいます。文字が枠からはみ出てしまうと、クレームどころの話ではありません。下手すると、取引先が納入を受け付けてくれない（早い話が売れない）事があります。

この際にまず言われるのは、「印字がズレている」です。つまり、左側に余裕があるばっかりに、右側がはみ出ていると「これははみ出ているのではなく、ズレているのだ」と認識されるわけです。というわけで、長い商品名は、枠ギリギリでも枠に入れないといけません。しかし、「もし商品名が長かったらギリギリにつめて印刷する」なんてアルゴリズムにしてしまうと、商品が複数あった場合に困ります。



見ておとおり、文字の印刷開始位置がデコボコになってしまい、見栄えが非常に悪くなります。この際に言われる事は「印刷位置が時折ズレてしまう。」です。つまり誰がどうみてもバグです。

バグっぽい挙動はバグ
昔、「ぎゅわんぶらあ自己中心派」という麻雀のゲームがありました。その中で店野真澄太（みせのますた）というキャラがいて、彼は振り込んでしまったり負けてしまった場合に（他のキャラは怒ったり泣いたりするのに）、 「人生ｵﾜﾀ＼(＾o＾)／」のようなポーズをして開き直るわけですが、 これを見た私の母は 「なんでこの人は負けてるのに笑っての？おかしいじゃない」と言ってました。


私は、負けてもニコニコしてる（というか、もう笑うしかない）というのが店野真澄太というキャラの特徴だと思っていたのですが、おそらく同様の問い合わせは多かったものと思われます。結局、負けてニコニコしてるのはPC8801SRで、後のPC9801版は泣いてる絵になりました。


顧客（依頼者）の発言は逆らえないとはいえ、相手が話のわかる方であれば、ある程度は話し合いで解決します。伝票の印刷の例でいくと、文字がはみ出しているのを見て「印字がズレている」と言われた場合、文字数が短い場合の例を印刷して見せて、「短い場合にはこうなってしまいますよ」と告げる事です。

そして、下記の場合のどれにするかを、顧客と相談して決めてもらいます。

（１）文字が左によりすぎるのをあきらめる。
（２）文字が途中で切れてしまう場合がある事をあきらめる。
（３）文字がデコボコになる可能性がある事をあきらめる。

最も要求される能力は"交渉力"
コンピューターがナイト2000のように人間の思い通りに何でも動いてくれれば良いのですが、残念ながら現代のコンピューターはそこまで便利にはできていません。どんなプログラムにも、必ず何かしら気に入らない事が１つはあります。１つ問題を解決すれば、１つ不満が出てきます。何の不満もないプログラムはナイト2000だけです。

先の伝票の印刷の例のように、１つの問題を解決する事によって新たに別の不満が発生する場合は、きちんと相手にわかるようにそれを説明できなければなりません。このように直売りの場合は、プログラムを作る能力よりも、むしろ交渉の能力を必要とされます。

直売りのメリット／デメリット
直売りでは、顧客との打ち合わせによって、自分で考えた通りに自分で作るわけですから、それだけ仕事にやりがいが出ますしモチベーションも上がります。また、納期についても打ち合わせ時にある程度は決めますが、キッチリ何月何日までと指定される事は稀で、謝ればある程度延ばせる事が多いです。そのため、筆者も直売り専門の会社にいた頃は、徹夜作業はありませんでしたし、比較的早く帰る事もできました。

デメリットは、もし自分の設計にミスがあった場合にまったく動かなくなってしまうという事です。ですので、きちんと自分で全体的な業務の流れを理解している必要があります。

また、大手の下請けの仕事をする場合と違って、打ち合わせ中に交渉が決裂してしまいケンカ別れになった場合は、最悪一銭も報酬が入らない事がよくあります。顧客が途中で廃業してしまってシステムが完成したのに報酬が全く入らないという事もあります。要求が２転３転して、作ってはやり直し作ってはやり直しのエンドレスになって、永久に報酬がもらえなかったという事もあります。

これを防ぐために、契約時にある程度前金をもらっておく必要があるのと、法律の専門家を別途雇う必要があります。

大手の企業は、自社で開発部を持っている所もありますが、大抵はそのプロジェクト限りの外注社員を使います。その外注要員として、大手企業に他の社員と同じように出勤して、そこの社内で作ります。そのプロジェクトの発注元と打ち合わせをする際には、大手企業の社員の一員として参加する事になり、名刺も大手企業の名刺を作ってもらえたりします。筆者のような中小企業を渡り歩いている人は、友人に大手企業の名刺を見せて自慢する事もできます。（まやかしですが・・・）

丸投げですので、アルゴリズムから何から全部自分で考えるわけですが、それは会議で大手企業や発注元に承認されなければなりません。したがって、プログラム作りよりも、資料の提出を求められる場合が多く、テキストエディターよりもワープロを使う事の方が多かったりします。このような仕事を受注しても良いように、普段からワード／エクセル／パワポを使えるようにしておきましょう。また、フローチャートぐらいは書けるようになっている必要もあります。

「自分は一太郎、ロータス１２３派だ」というかもしれませんが（実際に私もかつてそうでしたが）、大きいプロジェクトというのはドキュメントを色々な人が開けなければなりませんので、そのためにはどうしても互換性の高いMicrosoft Officeで作成する事を求められます。

こういう仕事で大切な事は、「１に忍耐、２に忍耐、３４がなくて５に忍耐」「耐えがたきを耐え、忍びがたきを忍び」です。というのも、まず大きいプロジェクトは、それだけバグのテストにかなりの大人数をかけます。なのでバグを見つけてくれて嬉しいなー・・・と思っていたのは最初だけです。テスターは見つけるのが仕事なので、何も見つからないと困るわけです。普段入力しないようなとんでもない値を入れて「こういう値が入ってしまう不具合」とか言ってきます。それでも入ってしまうのがいけないから制限をつけると、今度は「○桁以上入力できない不具合」とか言ってきます。

とにかく、不具合といっても、ハードやＯＳの制約上、「こんな機能まで作ったら時間がいくらあっても足りない」というものもあります。「入力の途中でブラウザの戻るで戻れてしまう不具合」「入力の途中で×ボタンで閉じれてしまう不具合」みたいな、「○○ができてしまう不具合」みたいな事を言ってきます。

こういうのにいちいち対応していたら時間がいくらあっても足りないので、先に要求仕様を完成させる事を目指すべきです。すると、「不具合が放置されている」「修正予定日を報告してください」と言ってくるので、やるべき事は「謝る」です。とにかく謝る。謝って謝って謝りまくります。

また、半年間苦労して作って「計画通り納期前に余裕を持って完成させたぜ」なんて思っていると、いきなり３日ぐらい前に全面やりなおしになるような仕様変更が来ます。こういう場合、納期になっても要求仕様が決まらないのであれば特に問題はないのですが、必ず要求仕様は納期前に、それも寸前に決まります。これは、火のついた爆弾を回すのと同じです。納期前には、発注元、大手の担当者、デザイナー・・・などなど、みんなで火のついた爆弾を回してきます。

爆発した時に爆弾を持っている人がアウトです。つまり、納品日に自分のところで仕事が止まっていたらアウトです。どんなに納品日より早く完成させていたとしても、直前に仕様が変わってその変更を自分がしていれば、自分がアウトです。

自分のところで納品日が過ぎると、大抵は謝罪と始末書を要求し、また原因と再販防止のための提案を求められます。原因として「だって直前に仕様が変わったから」なんて言っても認められないので、大抵は「計画が甘かった」「努力が足りなかった」みたいな自分で原因であるという反省文を書かないといけなくなります。

という事になっちゃうので、大手のプロジェクトに参加するために必要なのは、技術云々よりもまず「忍耐」という事になります。

そういえば、大手のソフト会社の下請けでソフトを作っていた会社が、社員が大量に退職したために会社自体が廃業してしまったという話を聞いた事があります。おそらく、忍耐力が足りなかったものと思われます。

そのかわり、大手の仕事の場合、万一途中で仕事を引き上げられたとしても、そこまでの報酬はもらえます。また、他の（直販売の）仕事に比べても報酬は高額である場合が多いです。ストレスには、それなりの報酬がつきものです。そのため、現場の人間には評判の悪いこの手の仕事も、経営者にとってはとてもおいしい仕事になります。

大手のプロジェクトに加わるためにはコネクションが必要で、以前にそういうプロジェクトに加わったことのある人なら、口コミで仕事がまわってくるケースがあります。それは、大きいプロジェクトはそれだけ人手を必要とするため、スキルを認められれば向うから仕事を依頼してきます。コネのない人は、まずはそういう大手の仕事を受注している会社に就職する事から始めます。大手にスキルが認められれば、「次から会社を通さずに直に仕事をうけてくれないか？」みたいな事を言ってきます。

という筆者の場合、スキルは認められましたが、その手の誘いは全て断ってしまいました。これも経験則ですが、大手の大きいプロジェクトは継続していれば問題ないのですが、不景気でそのプロジェクトが廃止になった際には、外注社員は真っ先に切り捨てられるため、そういう誘いに乗るのはあまりオススメできません。

大手の担当者から細かく仕様を言われるので、こちらでアルゴリズムを考える必要はありません。そのかわり、何に使うのか教えてくれない場合が多々あり、どの程度の完成度でいいのか不透明な事が多いです。といっても、納期の許す限り最大限というべきでしょうが。

この場合、アルゴリズムを考えずに済むのは楽なのですが、仕様書に曖昧な部分、何通りにも解釈できる部分、その通りに作ると矛盾して作れない部分などがあります。これは担当者に質問をするしかないのですが、外注との窓口になる担当者もそのプロジェクトの中では下の方の立場だったりして、よくわかってない場合があり、その場合、何度質問をしても同じ答えがコピペされて返ってくるだけというケースがよくあります。そうなった時はもう謝る準備をするしかないですね。大抵は作ってから「要求仕様と違う」といって怒られますので。

というように、一部を作る場合でも忍耐は必要になりますが、もともと作るものが「何かの一部」であるため、直前での仕様変更に対する影響は少ないです。もし前日に最初からやり直すような事を言われても、やり直せちゃったりします。

ただし、納品して報酬を受け取った後にも、しばらくは日程に余裕をあけておく必要があります。これは、作ったものがあくまでも何かの一部であるために、実際に組み込んでみると不具合が発生する場合があります。大きいプロジェクトに関する納期は異常に短いわりに、そのプロジェクトが本格的に軌道に乗るのは信じられないぐらい後です。下手すると何年かしてからようやく自分の作ったものが使われ出すといった事もあります。（もっとも、そんなに遅れたら、そことは取引がなくなってて連絡が来ない事も多いです。）

大手の大きいプロジェクトの一部を作るにしろ、丸投げされて全てを作るにしろ、納品期限は大抵は連休明けに設定されます。ゴールデンウィークはもちろん、月曜に祝日が入る場合は火曜といった具合です。

ただでさえ納品期限はできるかどうかのギリギリに設定されているのに、前の週の金曜日に全てが完了しているという事はまずないし、仮に完了していたとしたら、金曜に提出を求められその日中に不具合を大量に指摘されるでしょう。

大手のプロジェクトに参加中は、連休中の計画などは立てない方が無難です。休みを堪能したければ、全てが終わった後にしましょう。