月日の過ぎるのは本当に早いもので、独立してから4年が経ちました。 未だ法人化もできてはいませんが、それでも縁故もなかったこの山梨で事業を継続できているのは、ひとえに周囲の皆様の力添えによるものでしょう。

さて、これまでの仕事であちこちの現場に入らせて頂いていますが、その在り方は本当に多様です。 規則・規約でアウトプットの内容と形式を厳格に制限し、技術者を「部品として扱う」ことが徹底されているところもあれば、「技術者に (しかも外部委託先である私) にここまでの裁量を与えて大丈夫なのだろうか」とこちらが心配になるほど奔放な会社も。 また、内部の雰囲気についても然りで、従業員間で公私共に良い関係が築かれている職場もあれば、互いのプライバシーには極力干渉しないといったスタイルもありで、一概にどれが良い・正しいと言えるものではありませんが、そうした違いを観察できるのは、個人事業主ならではの醍醐味かも知れません。

そんなわけで、このエントリでは、そうした多様な現場を渡り歩いた経験から、特定の企業・団体に限らず、IT業界全体 (といっても私の観測範囲など多寡が知れていますが) について私が感じていることを述べてみることにします。

今に始まったことではありませんが、IT業界においてプログラマというのは最底辺ないしその付近に位置付けられることの多い職種です。 それはおそらく、ソフトウェア製品の開発において指揮系統の末端に位置することに由来するものでしょう。 プログラマは、上級職 (大抵の場合はシステムエンジニア) が作成した仕様書の通りに動作するコードを書き上げるだけの仕事であり、そこには特別な (敬意あるいは高い賃金を払うに値する) 知識, 技術, あるいは経験などない、といった認識が、程度の差こそあれ、どの現場にも浸透しているようです。

例えば「システムエンジニアには1ヶ月あたりxx万円出せるけど、プログラマならその半分まで」という条件に遭遇することもしばしばであり、私が現場に入るときの肩書きは「プログラマ」ではなく「システムエンジニア」であることが殆ど。 実質的な業務内容にはまったく違いがなくても、肩書きだけでそれほどの差が付いてしまうのです。 これまでに幾度、次の台詞を聞かされたことでしょうか:

こうした認識は誤りであり、プログラマの技術力・生産性の個人差が他の職種と比較しても非常に大きいこと、そして、コード品質の軽視はビジネス上の重大なリスクとなるということを幾度も主張しています。

ソフトウェアもこれと同じで、ロジックの共通化、インターフェイスの整備などにより、できあがった「もの」をちょっと眺めただけでは分からない、しかし、決定的な品質の差が生じます。 その差を生み出すのは、一言で表すならば、作られるに際してどの程度「作りやすいカタチ」「壊れにくいカタチ」「直しやすいカタチ」が意識されたか。 しかし、残念なことに、この「作るときの意識 (あるいは思考, 目線)」はドキュメントにも完成品にも残らず、常に抜け落ちてしまうもののようなのです。

flint blog: 抜け落ちるもの

コードが読みづらいものであれば、読解・修正には余分な手間、即ち工数が掛かることとなり、それは作業に対する見積・請求の金額にダイレクトに反映されることになるでしょう。 報酬を多く払えばそれで済むのならばまだマシな方で、納期直前に退職, 入院, 死亡, 失踪などの理由でコードを書いた人間がいなくなってしまった場合は、各方面に頭を下げてのスケジュール調整が必要となる上、下手をすれば賠償請求をされる可能性すらあります。

flint blog: 引数のデザイン

こうした見方はプログラマやシステムエンジニアを含めた技術者や、実際の開発を担当する業者のレベルではある程度の危機感をもって共有されているものの、発注者の側にはなかなか広がらず、新聞などで時折報じられる所謂「動かないコンピュータ」問題の温床となっています。 空前の技術者不足と取り沙汰される「2015年問題」の只中にあっても、未だIT技術者は頭数幾らで取引され、その単価も上がる気配はなし。 エンジニアを雇用して技術を育てるという発想を持たないメーカが殆どという現在のIT業界が、今後確実に到来する「技術者余り」によってどうなるのかについて、明るい見通しはまったくありません。

最近はあまり耳にする機会もなくなってきましたが、私が独立した2011年頃は「ノマド」なる言葉が流行していました。

「ノマド」とは遊牧民のことであり、いつも決まった場所ではなく、カフェや公園、お客さんのオフィスなどでノートパソコン、スマートフォンなどを駆使しネットを介して場所を問わずに仕事を進めること。 「サードプレイス」という自宅でもなく、オフィスでもない、第三の自分の居場所で仕事を行う新しいスタイル。

ノマドワーキングとは - はてなキーワード

「じゃあ具体的にどんな人が "ノマド" で成功しているのだろうか」と思い調べてみたものの、出てくるのは「こうすればノマドになれますよ」というノウハウを著書やセミナーを通して売って稼いでる事例ばかり。 つまるところ、単なるファッション商品でしかなかったわけですが、当時はそれなりに「若者」からの支持を集め、「新しい働き方」として注目・利用されていた概念ではありました。

その一方で、ノマド賛美の反動から、会社勤めをしている人たちを、「企業に飼い馴らされている」「自分の判断で行動することを放棄している」という揶揄を込めて「社畜」と呼ぶ風潮が生まれ、それは今もなお (一部にではありますが) 残っています。 しかし、実際にフリーランスとしてソフトウェア開発業務に携わる経験をしている者としては、

「お前ら、傭兵だけで戦争ができると思ってんの?」

以上の感想が出てきません。

ある程度の規模以上のソフトウェア開発には、設計や実装以外にも多くの職能を持つ人間が携わります。 その際、個人で賄うことが特に難しいのが、全体の調整と金銭まわりの処理、そして顧客 (発注者) との遣り取り。 例えば、各機能をどの順で、それぞれいつまでに作るかというスケジュールは技術的な要因だけでなく、他部門のスタッフやレビューの実施計画によって応じて決める必要があります。 また、開発中に仕様変更などがあった場合には、スケジュール変更や予算の調整なども必要になるでしょう。 スタッフの雇用契約に関する処理も適切に行わなければならず、そのためには各種の法律に関する知識やある程度の実務経験が欠かせません。 また、仕入れに関して発注者からの前払いが受けられない場合は、その分を立て替えなければなりませんが、個人事業主のレベルでは不可能なほど大きな金額になることもしばしばです。

そして何より、そうした大規模なプロジェクトの業務は個人の事情で遅滞させることは許されず、誰かが職務を遂行できなくなった場合に代替の人員を充てる (場合によっては新たに雇用する) ことが必要となるわけですが、それを可能とするバックアップ体制は組織にしか持ち得ないもの。 この「確実性」「信頼性」の有無こそが、個人と組織の達成しうる成果を分ける要因であり、また、趣味的なソフトウェア開発とビジネスにおけるそれの違いでもあるわけです。 会社あるいは担当者によって、そのこなし方の上手い/下手の差はありますが、いずれにせよ、20年前であればいざ知らず、現代のソフトウェア開発はそうした「組織の力」なしには成立しません。

この事実を省みることなしに、勤め人を「社畜」「組織の奴隷」呼ばわりし、自分たちが特別に素晴らしい働き方や仕事をしているという優越感を持っているフリーランスのプログラマを見かけることも少なくありませんが、それは技術者として世を渡っていく上で致命的な勘違いです。 そうした思い上がりをしているフリーランスと付き合うことはビジネスの上では「汚いコード」以上に大きなリスクとなるもの。 こうした心得違いをしていないか、折に触れて自分自身を省みつつ仕事に取り組んでいきたいものです。

そんなこんなで、当初は無謀とも思われたこの事業も今年で4周年。 今年は柄にもなく組合の理事になってしまったりもしましたが、今期はこれまで「なんとなく」目指していた法人化に指向けて、より具体的なアクションを起こしていければと考えている次第。 現在お取引頂いている皆様には変わらぬご愛顧を賜りたく存じます。

それでは、今後ともよろしくお願い致します。