トップ > 仕事環境

すべてのプログラマーに読んでもらいたい本

仕事環境 プログラミングの勉強 書籍紹介

ネット上で「97きのこ本」として既にいろいろとうわさになっているようですが、私も書店で購入して読み始めました。

プログラマが知るべき97のこと

プログラマが知るべき97のこと

翻訳のクオリティーも非常に高くて読みやすいですし、値段も2000円以下と手ごろですので、最近出版されたプログラミング関連の和書の中では一押しの本だと思います。タイトルにはプログラマーとありますが、もちろんPGだけでなくてアーキテクトやSEの方にも是非読んでいただき、世界中のトッププログラマー*1の考え方を多くの方々に知っていただきたいと思います。
日本語版には外国のプログラマーの記事だけでなく、日本人のトッププログラマーの記事も収められています。ちょっと残念なのはオープンソースやWeb系のプログラマーの方々ばかりで、SI業界で業務システムの開発に深くかかわっておられる日本人の業務プログラマーの方の記事がないと思われることですが。
こういう本を読むと「うんうん、なるほど」と感心させられる一方で、プログラマーがこのように生き生きと専門性を発揮して活躍できる場所が、現状の日本のSI業界では非常に限られているという厳しい現実にもあらためて気づかされてちょっと悲しい気分にもなります。ただし、SI業界で働いているいわゆるPGの皆さんも、いままでどおりのやり方に何の疑問も持たずに惰性で仕事を続けるのではなく、是非こういう本を手にとって勉強し、無知なSEや上司に対して間違っていることははっきりと間違っていると主張できるくらいの技術力を付けるべきだと思います。不遇な労働環境を嘆いているだけではいつまで待っても職場環境は改善されません。

*1:Googleなどのプログラマーだけでなくて普通の業務プログラムを開発しているPGの人も含まれる。また、記事を書いている人には年配の人も多い点に注意。

私は「自分の職業はSEです」と名乗るのがちょっと恥ずかしい

IT業界 仕事環境 PGのキャリアーパス

ITproの記事に以下のようなものがありました。
「SE」は和製英語にあらず | 日経 xTECH（クロステック）
その記事ではSystems Engineerという職業はアメリカでも存在するから和製英語と呼ぶのは間違っていると主張しています。確かに、Systems Engineerという職業はアメリカにおいてトップ100に入るような人気職種となっているようなので、SEという用語自体はれっきとした英語でありそのような職業がアメリカにも存在するということは間違いないようです。
Best Jobs in America 2010 - Top 100: Systems Engineer - Money Magazine on CNNMoney.com
コメント欄を見るとアメリカでもSEの指す仕事内容の理解についてはあいまいなところがある（より広義ではITやソフトウェアにかかわらない仕事も含む）ようですが、一応定義としては

  • 業務プロセスの分析、改善
  • システム統合の検討
  • 大規模なシステム化の検討
  • パッケージ製品の適用の検討
  • 大規模プロジェクトの管理

などの仕事が中心となっています。日本の業界で言うと、ITコンサルタント、ITアーキテクト、ビジネスアナリシスト、PM（大規模プロジェクトの）などの仕事に関係した仕事であると理解できます。また、学歴としても最低でも情報技術や計算機科学の理系の学士号が必須となっています。
一方、日本のSI業界で大部分SEと呼ばれている人たちの仕事を考えると

  • 顧客に対する御用聞き
  • 下請けの人員調達や計画の管理
  • ExcelやVisioを使った外部設計（画面設計、テーブル設計）
  • テストケースの作成、テスト打鍵
  • システムの文書化
  • PGの上位職としてプログラムの詳細設計書を書く
  • システムの管理、運用（カスタマーエンジニア=CEにも区分される）
  • 実際はPGと変わらない仕事内容だが単価の関係でSEと名乗る

などの仕事が大半を占めているのが現状です。こういった仕事はアメリカではSEとは呼ばれることはなく、ドキュメントライターとかテストエンジニアとか別の名前で呼ばれるのだと理解しています。
もちろん、アメリカ的な意味でのSEに属する仕事を担当している一握りの人もいますが、そういう上級職は最近ではあえてSEと呼ばない傾向が高くなってきていると思います。（もっと単価の高いコンサル、アーキテクト、PMという呼ばれ方をする）
そういう事情を考えると、SEという職業名は広義で和製英語であるといってよいと考えます。実際、和製英語 - Wikipediaでも、

英語の語句を原義とは異なる意味で使用しているものや、動詞であるものを名詞の如く扱って単語を組み合わせているもの、さらには、日本語的に略して発音しているものや、もともとの英語を日本独自の発音で言い習わしているものも含めて、広義の和製英語に含めることがある。これらはしばしば「誤用」とされる。

と書かれています。たとえば、「マンション」という単語(mansion)はアメリカでは大邸宅やお屋敷を指す用語であり、日本のような共同の分譲住宅の建物を指すことはありません。ディズニーランドにホーンテッドマンションというお化け屋敷がありますが、ああいうイメージの建物を意味します。また、「セレブ」という単語(celebrity)は英語では有名人を指す言葉ですが、日本では有名かどうかによらず成金や大金持ちの意味にも使われています。このように誤用からまったく違う意味で使われている英単語はやはり和製英語といってよいと思います。
ちなみに、SEという職業はPGの上位にくる職であり、PGは下級職であるという考え方もアメリカではまったく通用しません。*1アメリカではSEとPGはそもそも対象とする分野がまったく異なる領域の専門家である*2とされていますし、PGを何年か経験したらSEになるというのも一般的ではないと思います。なお、日本的な意味での外部設計や内部設計を行うようなSEの仕事は大部分Software Developerの仕事であり、ほとんどの場合この仕事はプログラミングをする人たちが担当しているのですから、日本的な用語でいえば、「PGが外部設計から、プログラミング、テストのような（日本の意味での）SEの仕事まで行う」というのが実情に近いと考えています。
日本では、本を書いているような発言力・影響力のある人までもがこの日本独自のSEの定義にこだわり続けているようです。
「SE」という言葉は「プロ野球選手」と同じだ | 日経 xTECH（クロステック）*3
日本的ガラパゴス状態が常に悪いというわけではないと思いますが、IT技術は進歩の早い分野ですし、今後はオフショア開発、OSS、クラウドなど国境がどんどんあいまいになっていく時代ですから、やはり用語定義としては誤解を避けるためにもグローバルなスタンダードを取り入れていくべきなのではないかと思います。そのためには私はSEという日本独自の用語（そういう意味だとPGもコーダーという日本独特の意味では和製英語ですが）をそろそろ廃止するか、本来の意味にきちんと修正して使うべき時期に来ていると思います。和製英語としてのSEという言葉はPGの対義語として利用されることで最重要の工程の一つであるプログラミング工程を付加価値の低い単純労働として捉え、プログラマーの社会的地位を大きく低下させる原因の一つにもなっています。その上、外部設計以降の比較的下流の工程を担当するSEなど、本来はプログラミングなど実装技術に関する知識が必須であるにもかかわらず、プログラミング工程を軽視してまともな技術の勉強をおろそかにするようなSEを大量に生み出す原因ともなっていると考えます。
こうしたことから私はSEという言葉が好きではありません。なんだか、日本におけるSEという職業名は老害の蔓延した業界の有様を象徴しているようでもあり、そのような肩書きを持つこと自体が技術者としては時代に取り残されているようで、なんとなく恥ずかしいことのように感じてしまうのです。したがって、私自身は会社からはSEという職位を与えられてはいますが、プログラマー、アーキテクト、コンサルタントなどの用語を利用し、SEという言葉は自分自身ではあまり使わないようにしています。
近い将来SEという職業名が死語になるかどうかはわかりませんが、とにかく今後は「プログラミング=下流*4=付加価値が低い仕事」という時代遅れの古い考え方を一刻も早く無くしていくことが業界の健全な発展のためには大切だと思います。

*1:もちろん私自身はアメリカで仕事をした経験が今のところありませんが、システム開発に関する洋書でSystems Engineerという単語が日本的な意味で使われているのを見た記憶がありません。

*2:アメリカ的な意味のSEとPGの役割分担をあえて自動車の製造にたとえると、SEはマーケティング調査や車台の流用検討、デザイン、全体的な製造コストの見積もり、製造計画といった部分に相当し、PGはエンジンや電子部品など各パーツの設計から、プロトタイピング、組み立て試験までを行う技術者ということになると思います。（一方、工場の製造ラインはコンパイラーやビルドシステムに相当。）どちらが上位というものではありませんし、PGからSEへの仕事の変更はまったく別分野への転職に匹敵するものと思われます。

*3:ただし、この記事ではPGや下流工程を軽視している点を除くと外国のSEの定義にできるだけ近づこうとしているように思われるので一般的な日本独自のSEの定義にこだわり続けているというのはちょっと違うかもしれませんが。

*4:本来、ウォーターフォールの開発プロセスにおける上流工程、下流工程には単に工程の前後関係しかないはずだが、意識的にあるいは無意識のうちに上流階級、下流階級の意味と取り違えて考える人が多いのも問題だと思う。この用語の響きにより下流工程を担当するPGは、実際の作業内容を理解しない人々から下等な職業であると誤解されて認識されてしまう傾向がある。

グルーポンのおせち事件を受けてSI業界が本当に教訓とすべきこと

仕事環境 IT業界 PGのキャリアーパス

共同購入サイトのグルーポンでバードカフェというお店が販売したおせちの話題がネットで大いに盛り上がっています。
痛いニュース(ﾉ∀`) : グルーポンの割引で買ったおせち料理が酷すぎると話題に - ライブドアブログ
痛いニュース(ﾉ∀`) : グルーポンおせち騒動で、「バードカフェ」社長が辞任発表 - ライブドアブログ
ネット上のネタとしてだけでなく、最終的にNHKのニュースでも取り上げられたみたいです。
http://www.nhk.or.jp/news/html/20110103/t10013172511000.html
昔なら、こういう事件があっても食中毒事件でも起こさない限りここまで大きな話題になっていなかったかもしれませんが、正月早々、ネットの怖さを思い知らされた感じですね。以前なら消費者もこうした商品を購入してだまされたと思っても泣き寝入りで我慢してしまう人も多かったかもしれませんが、うわさが一気に広がって社長の辞任にまで追い込んでしまうとはまさにIT技術は偉大ですね。
ところで、一般の人はこの事件のニュースを聞いてグルーポンのビジネスモデルの問題とか、バードカフェの金儲け優先で品質を考えないという点に対してひどい話だと思うくらいなのでしょうけれど、我々のようにSI業界で働いている人にとっては寓話的というか、教訓としていろいろなことを考えさせられる事件だと思います。

  • もともと100人分の想定なのに500人分の注文を徹夜で処理（いわゆるデスマ）
  • 写真をみるといかにも臨時アルバイトのような素人がおせちを作っている
  • 衛生面を考えない作業場（古いPCの使用などPGに与えられる貧弱な開発環境と似る）
  • 品質より第一に売上・利益を優先
  • 品質面でもともと描いていた要件を満たせない

などの点考えるとどうしても我々の業務システム開発の仕事と比較して考えてしまわざるを得ないところがあります。実際、以下のような風刺もあり、ちょっと笑えないところもありますね。
顧客が説明した要件：おせち版 - REVの物置::Group::Grev - grevグループ
ただし、このおせち事件とシステム開発との間のアナロジーは完全でなく、結構違う部分もあるため解釈の上では注意が必要だと思います。まず第一に、SI業界は多重下請け構造になっており、そもそも非常に生産性が低い構造になっていることがあります。おせち事件の場合は単なる要件のスコープの見積もりミスですが、SI業界の場合は、間に何社も入ることからくるお金の面でのオーバーヘッドもありますし、システムの開発や保守運用の役にたたないような大量のドキュメントを作成する*1など実に無駄が多いです。だから、おせち事件のように単に半額で無理やり作ったから当然品質も下がるということではなくて、無駄なところにお金をかけているわりにはたいしたシステムが構築できないというところがあります。
また、第二に、多くの場合業務システムの品質が多少低くてもユーザー側*2は甘んじてそれを受け入れるしかないということが多いのではということがあります。一般ユーザーの目に触れるB2Cサイトやゲームなどは例外ですが、だいたい、SIerが作る社内システムの使い勝手などはそのようなものだと半ば諦められているところもあるのかもしれません。バグがないシステムというのは、おせちで言えば、腐っていないというような最低レベルの品質に相当するものではないかと思います。こうなるのは、多くの場合社内情報システムの開発ということ自体が企業秘密とされていて、絶対に外部に漏らすことが硬く禁止されているというところもありますね。これは情報システムの戦略性ということからしかたがないことですが。実際、職務経歴などでも自分の関与した仕事を明示的に書くことが契約上禁じられているケースがほとんどですし、仕事の話をする場合も「S社が」とか「M社の」とか隠語を使って（知らない人が聞くといったい何の話をしているのかと不思議に思うかと思いますが）会話をするのが常識とされています。だから、おせち事件と違ってうわさが世間に堂々と広まることもありません。
最後に、情報システムの場合、おせち料理と違って本当のシステムの品質というのがエンドユーザーに見えにくく正しく評価されにくいということがあります。どんなに内部構造がひどい作りになっていても、システムのレスポンスさえ確保できれば、おしゃれなUIでユーザーは簡単にだまされてしまうものです。ただし、プログラムの品質などは長い目でみた保守コストに確実に響いてきますから、実は見過ごすことができない問題なのですが。
このような問題が複雑に絡んでいることで、SI業界ではバードカフェのような仕事が長いこと続けられるし、臨時のバイト店員も高級料理店の板前も評価や待遇があまり変わらないといった他の業界ではとうてい考えられないようなことも既成事実としてまかり通ってしまうのだと思います。
ただし、頭数要員だけでこなせる仕事が今後もずっと取れると考えているSIerの仮説は間違っているでも指摘したように、最近はOSSやクラウドなどの影響で社内システムもどんどんネット上のオープンな世界から調達されるようになってきているわけですし、いい加減にこうした状態がこの先何年も続くことはないのではないかと思います。アリとキリギリスの話ではありませんが、来るべき冬の時代に備えて、本物の技術力（プログラミング力だけでなくて提案力などプロの技術者としての仕事力も含む）をつける勉強をしておくことは決して無駄な努力にならないと思います。自らが作り出して深く関わっているIT技術によって「真面目に勉強する人が損をする」「正直者が馬鹿を見る」業界の体質はそろそろ終わりにならざるを得ないのではないでしょうか？

*1:これには異論もあるかと思いますが、端的に言ってしまえばプログラミングのできないSEの作業を無理に作り出しているような面もあります。特に何百人以上の大規模プロジェクトだと大人数での会議などの無駄も加わって、システムの開発に貢献しない人の割合が一層増えることになります。

*2:ここではユーザー企業の情報部門のSEではなくて業務システムを使って実業務を遂行するエンドユーザーのことを主に想定しています。

フレームワークごとの生産性の違いを定量的に計算する方法があったらいいのにな

アーキテクトの仕事 仕事環境

アーキテクトの重要な仕事の一つに、フレームワークの選択があります。そこで上流の方から毎回必ずと言っていい程求められるのは、選択肢となるフレームワークごとの生産性の違いがどのくらいあるか「定量的に」教えてほしいというものです。たとえば、Strutsの工数を100とした場合、Spring MVCなら70になるというようなことを事を答えとして求めてくるわけです。今、あるプロジェクトの提案書作成の支援をしているのですが、元請のマネージャーから提案書に生産性比較の定量的な評価を載せたいと言われてしまいました。まあ、いつものことですけれどね。
この業界では理科系の発想のできる人は少ないと言われていますが、なぜか数値化や定量化だけは良いことと信じられており、数字なら信じてしまう、（あるいは数字しか信じない）という人が多いようです。もちろん、性能の見積もりにしても、DBの容量見積もりにしても、定量化できる対象であれば、概算であっても見積もりを行うことはエンジニアとして当然の仕事です。しかし、フレームワークの違いによる生産性の比と簡単に言われても、実際に意味のある数値をはじき出すことは極めて難しいと思いますね。
第一、「生産性」が何を意味するのかということをはっきりさせなくてはなりません。単位時間辺りに生産可能なプログラムのステップ数やクラス数を元に定量化したらコピペコードが最大の生産性で、逆にスマートな設計は生産性が低いということになってしまいます。
逆に、実装すべきユースケースを固定した場合に、作成すべきコードや設定ファイルの分量の比から生産性を求めることもできます。この場合、たとえば、Spring MVCならStrutsよりコード量や設定ファイル記述量が70%になりますよということはある程度予測可能です。でも、記述すべきコード量が半分になったから開発期間も半分になるかというとそんな単純な仮定は成り立ちません。つまらない配管コードなら自動生成なども可能ですし、頭をあまり使わなくても記述できるわけですから、頭を使うコードよりも短い時間で作成できます。良いフレームワークを使って残った部分が頭を使うコードであったら、結局そこがボトルネックになってしまい生産性の差はあまりないということにもなってしまいます。
しかし、私の経験上、プロジェクトの生産性は単純にコードを書き下す時間ではなくて、むしろ以下のような要素によって決まることがほとんどであると思います。

  • バグを埋め込む確率が低いほど生産性が高い
  • バグを埋め込んでから発見するまでの期間が短いほど生産性が高い
  • 機能追加や変更に強い設計は修正コストが低いから生産性が高い

このように生産性の違いといった場合、長い目で見たバグ修正や変更のコストの違いもスコープに入れて考慮すべきです。実際、XPのプラクティスにあるような継続的結合とか試験の自動化というのは結局上記のような要素を最適化するものです。ハイスキルのPGは10倍生産性が高いといった場合、最近のプログラミング技術を知らない人は他人より10倍の分量のコードを記述するような超人PGを想像するかもしれませんが、実際はそんなことはないですよね。10倍の差と言っているのは結局いかに無駄なコードを書かないか、それによってバグの発生確率を減らし、無駄な再試験コストをなくし、変更に強い設計にするかということが本質であって、ステップ数とかクラス数といった単純な分量の問題を言っているのではないのです。だから、フレームワークやツールの違いでどうこうという議論はナンセンスであり、結局アーキテクトやPGのスキルによっていかに無駄のないアーキテクチャーや開発環境を構築するかというところが重要になってくるのですし、そのための開発プロセスというものが必要なのです。
結局、開発生産性というのは

  • 開発者のスキル
  • そもそもの業務の本質的複雑性
  • 設定ファイルや配管コードの量（偶発的複雑性）
  • 開発環境の快適さ（PCの性能、画面の広さ）
  • ガイド類、Wiki、ペアプロによるノウハウの共有
  • インターネット接続の有無などによる調査にかかる時間の差
  • バグ発生率
  • バグ発生から修正までの間隔
  • ビルド、デプロイの間隔

などさまざまなパラメーターが非常に複雑に絡み合って決まるものであり、単純な多項式とか初等関数で解析解が簡単にきまるようなものではないと思います。そういう複雑系の世界で演繹的に生産性の違いを求めるというのは原理的に不可能なのではないでしょうか？
もちろん、統計的にどのくらいの差になるかというのを求められなくはないですが、そもそも同じ要件で同じ条件の開発者で複数のフレームワークを使って十分な量の開発を行わなくては統計的に意味のあるサンプルを得ることはできません。
こうした生産性の見積もりの参考になる研究の成果があれば、非常に良いのですが、私が知る限り、フレームワークの違いによる定量的な生産性の差という話で科学的根拠のあるものは聞いたことがありませんね。

SIerが優秀なPG（エンジニア）を積極的に採用する社会を想像してみる

仕事環境 IT業界 アジャイル PGのキャリアーパス

もしSIerがまともなエンジニアリングの会社だったとしたらどんな仕事が考えられるか？でSIerがITゼネコンでなくてエンジニアリングの会社だったらということを書きましたが、ここではもっと踏み込んで「SIerが優秀なスーパーPGを高給で積極的に採用する社会」「SIerが正社員の技術力（コミュニケーション力、マネジメント力だけでなく）を重視しきちんと教育する社会」をちょっとした思考実験として考えてみたいと思います。もちろん、現状大手のSIerでは研究所のような部署があり、専門の教育を受けた優秀な人も働き場所がまったくないわけではないと思いますが、ブクマのコメントにあるように

研究開発的なところでまともなエンジニアリングしてるように見えるけど、現場に全く生かされない、っていう感じもある。

というのが実態ですよね。このことは現状の低価格競争に晒されている人月のビジネスモデルではある意味で当然のことであり、せっかくの優秀な人も現場のプロジェクトにべったり参加して、長期に渡って仕事したのでは採算が合わないのです。言うまでもなく人月モデルでは有能でも無能でも単価はほとんど差がありませんから。それで、自然と優秀な技術者は製品開発や標準化などプロジェクト横断で広く適用できるような仕事を担当させられることになります。ただ、もともと優秀で素質のある人でも現場から離れて研究だけしていると、残念ながら現場の感覚が身につかないというか、あまり現場で役に立たないようなスキルを身につけてしまうということが多いと思います。とくにそういう環境だといつまでたっても業務知識というかドメインモデリングする力がつかないですね。
ですので、ここではR&Dの部署で採用するということではなくて、開発の現場でバリバリ働くPGをSIerが高給で直接採用したらという前提で考えてみることにします。これはまったくあり得ないトンでもない世界の夢物語と思われる方も多いかもしれませんが、既にいろいろなところで指摘されているように優秀なPGの生産性は初心者の10倍以上も高いということは事実としてよく知られていて、外国では競うようにハイスキルのPGを高給で採用するのが常識ということを考えれば、まったくありえないということではありません。*1私としては、現状の日本のSIerがこういった発想にならないのは、どちらかというといわゆる「老害」というか、「PGはコードを書くだけの単純労働者」だから、できるだけ低単価で雇い、下請けなどで流動性を確保するのがよいと考えている経営者の思い込みに過ぎないところがあるのではと思います。仮に、SIerの経営者の頭がアメリカのCIOの発想に一夜にして変わったとしたらどうでしょう？
「正社員のPGを高給で雇ってしまったら流動性が低くて、無駄な固定費がかかる」
という意見は当然出てくると思います。でも、これもPGを単純作業労働者と考えていることによる思い込みの部分が大きいと思います。実際、現在ハイスキルのPGが不足することはあっても、余るという話は現場ではあまり聞きません。百歩譲って、そういう状況に陥っても、優秀なら製品開発に回すとか、教育を担当させるとかいくらでも仕事は与えられそうです。また、日本では正社員の保護からもし高給で雇ったPGのパフォーマンスが期待に反して低くても簡単に解雇できないという問題はありますが、少なくとも降格とか減給というのは可能ではないでしょうか？
もともと大手SIerはユーザー企業や公共団体からプライムで案件を取得できるブランド力や営業力があります。だから、一括で受注したら後は内部をどのようなプロセスで作っても文句は言われないでしょう。もし、プロパー*2の優秀なPGが確保できるのだったら、Excelの詳細設計書作成に時間を割くような無駄はしないので、効率は大幅に上がります。だから、従来の手法ならトータルで10億かかる案件を半額の5億で受注して、実際は7000万くらいの原価で作成するというようなちょっとぼったくりのようなモデルも考えられなくはありません。
この議論に対して出てきそうな反論は、いくら優秀なPGでも何十億もかかるような大規模な案件はアジャイルではできないから結局大量のドキュメントを作成してきちんとウォーターフォール開発しなければならないということです。しかし、優秀なPGは当然アーキテクトでもあるのですから、そもそも大規模なシステムを一枚岩の構造で作るというような過ちは絶対犯しません。小さなチームで作業できるようなサービスやコンポーネントの単位に分割し、それぞれがアジャイルで作業できるようにすれば、リスクも減るし、効率性も損なわれないでしょう。
顧客が大量のドキュメント作成を要求してきたらどうするのだ*3という意見があるかもしれません。また、ある程度は保守や2次開発のために、ドキュメント作成が必要です。私はこういう時こそアウトソースの出番だと思います。優秀なPGが口伝とメモ書きで要点を伝えて、文書作成の専門業者にExcelやWordで清書してもらえばよいと思います。そのような単純作業をわざわざ高給取りのSEが担当するものではないと思います。
最後に、もし、優秀なPGが本当に高品質のシステムを作ってしまい長期に渡って機能拡張も容易にできてしまったら作り直しなどの機会も減ってしまい、儲からないから自分の首を締めるのではという反論があるかと思います。従来の人月ビジネスモデルの欠点なのだと思いますが、そこは、長期に渡って使われ続ける程儲かるモデルを考えればよいと思います。保守料やライセンス料を取るとか、実行基盤を貸し出して使用料をとるなどいくらでもあるかと思います。
このようにSIerでは優秀なPGは不要であるという思い込みをやめたら結構いい仕事ができそうなのですけれどね。必ずしもアメリカのようにSIerを無くして、ユーザー企業が直接PGを雇うというモデルにしなくてもよいということです。SIerで上流のコンサルタントをやっている方は、「いかに業務を効率化して、収益を上げるか」という分析が専門のはずです。まずは、自分の会社の非効率をAsIsモデルとして分析し、より効率的なやり方をToBeモデルとして検討していただきたいものです。そうすれば、PGスキルをもっと重視すべきという議論が出てこないものでしょうか？

*1:PG一人の生産性が10倍高ければ、単純に10分の1の工数で済むかというとコミュニケーションパスの減少効果により実際はもっと生産性の開きは大きくなります。

*2:SI業界では下請けに対する正社員を意味する言葉。本来は生え抜きの社員という意味らしいが。

*3:SIerの常識に反して意外に無駄なドキュメントは不要と考えているユーザー企業もあるかもしれません。

上流の壁？

IT業界 仕事環境 オブジェクト指向 アジャイル PGのキャリアーパス

達人プログラマーを目指すための素質 - 達人プログラマーを目指してで、PGの社会的地位の低さについて言及したのですが、ステレオタイプな上流コンサルと思われる方から、以下のようなコメントをいただきました。

現在の貨幣経済において、情報システムサービス業(SIer)におけるPGはそこまでの価値なんだと受け止めるべきかと。
実際の話、SIerにおいては優秀なPGが沢山いるより、大型案件を扱えるPMが沢山居る方が、より儲けやすいでしょう。

あと、別にPGだけが頑張って勉強してるわけではないです。
上流コンサルやITアーキテクトと呼ばれる人たちも勉強はしています、平均をとればPGたちよりも勉強はしてるでしょう。
営業だって馬鹿ではありません、刺しつ刺されつの世界でなんとかプロダクトを売っているんです。

貨幣経済において、付加価値の高くないことを勉強しても付加価値は低いままです。
「清掃作業において俺は誰にも負けないほど勉強しているが、なぜ給料は低いんだ！？」
と叫んでるのを聞いてあなたは何を思いますか？

要するにこの人はプログラミング作業を清掃作業に類する単純労働作業と捉えており、それゆえ付加価値の低い仕事だからそれなりの地位と収入なのは妥当であると考えておられるようです。（この方は年収1000万近くも稼ぐかなりの高給取りの方のようです。）もちろん、すべての上流コンサル、上流のITアーキテクトの方が全員この方と同様な考え方をされているわけではないと思いますが、割合的にはこのような考え方をされる方が多いのでしょうか？もし、そうだとすると上流のエンジニアの方と私のようなコードを書く下流のエンジニアとの間には容易には崩せない厚い壁が存在していることになりますね。
私の考えでは、マーチンファウラーのようにコード上の設計もできる人が、上流のアーキテクチャーやシステムの要件を考えるというのが理想的であると考えています。そうすることにより、オブジェクト指向的な発想で拡張性や再利用性の高いシステム設計、本当の意味で付加価値の高い分析や設計というのが可能になると思います。逆に、OOPとかデザインパターンなどプログラミング上の設計技法を理解していないような人が高給取りの上流エンジニアの立場になって、SOAなどの手法を活用して本当に有効な設計ができるのか疑問を感じてしまいます。
20年くらい前からシステム開発のアウトソース化が急激に進み、SIerという会社が生まれたと聞いていますが、不幸なことに、この時期はちょうどオブジェクト指向プログラミングやC/S環境などの普及が本格的に始まった時期と見事に一致しています。SIerのゼネコン化の問題もあり、そうした中でオブジェクト指向などの下流の技術革新をまったく理解しない上流専門の会社と立場の低い下流の会社に分断されてしまいました。立場の高い上流の人は新しい技術を知らず、逆に新しい技術を正しく使う能力のあるPGの立場が必要以上に低く、付加価値の高いポジションで仕事をする機会が極端に少ないというのが現状の日本のIT業界なのかと思いました。
やはり、上流と下流を隔てる壁を今後何とかして崩さないと先に進めない気がしました。自分がプログラミングを中心とした仕事をしているということはありますが、やはり、基本的にはPGの地位をもっと向上させ、プログラミングの分かる人がもっと上流の付加価値の高い仕事に参加できるような環境を作っていくことが大切なのではないかと思います。アジャイルのような開発モデルがもっと浸透し、ユーザー企業も直接システム開発や運用をコントロールするようになれば、たちどころに、この「壁」を崩すことは可能かとも思います。冷戦の終結によりベルリンの壁も一気に崩壊したのです。もっと多くの人がこの問題に気づいて、改革することを望めば、ちょっと馬鹿げた上流の壁を崩すことは決して不可能なことではありません。

高い品質のプログラムを作らなくてはならないと考えている職人PGの考えは間違っていた？

IT業界 仕事環境 PGのキャリアーパス

ソフトウェア工学の教科書やプログラミングに関する技術書は、例外なく「プログラムの品質を（制約の範囲内で）できるだけ高いものにするべき」という前提で書かれています。それがエンジニアリングの目標だし、そもそも、ものづくりの職人として、できるだけ良いものを作りたいという思いがあるのは当然だと思います。
また、よく言われることはプログラムというのは一度書いたら終わりなのではなく、長い年月をかけてメンテナンスされるものであるという考え方です。ですから、単に短い期間で作るということでなくて、長い目で見て保守性、拡張性の高いプログラムを作るということは、こういった専門書では当然良いことであるとされます。ネット上でもプログラムの品質に関するこのような特徴については、いろいろ意見が書かれていますね。
http://blog.miraclelinux.com/yume/2007/10/post_9db7.html
ソースコードの質：気難しいプログラマ：エンジニアライフ
それで、私もずっとそういう価値観で今まで仕事をやってきました。だから、プログラマーの成長を考えないSIerの仮説は間違っているで、プログラマーのスキルを向上させるべきということを書いたわけですし、Java EEや.NETはCOBOLやVB6よりも本当に生産性が高いか？でも、ある程度スキルの高い領域で仕事をしようという議論をしたわけです。しかし、

「なんか動くものを作る」のが目的であって「OOPで作る」のが目的ではないのだから別に良いのでは？という確実にスキルレベルを一定化させる発想があるけど、それは必ずしも悪ではないと思う。

争われるのは営業力と政治力で品質面は最低ラインさえ割らなきゃ後同じ。この状況下でのプロマネなら平均点の向上でなく赤点の回避を目指す方向で合っている。大型案件を奪い合う争いへの最適化かと

その通り！なんだけどそう言われ続けて何十年も変わらん。単価2倍で人月1/3とかの会社が出てきて業界を席巻しないのは、技術成長による生産性向上より客を騙す大人力のほうが利益になるって事なのかも

SIerでプログラマの成長というのは、営業を覚えて若手に仕事を与えることだったりする。それが嫌なら別業界へ逝けばいいだけ。

などのご意見を多数いただき、私が今まで当然と思っていた「プログラムは高品質であるべき」というものがSIerの常識の世界では間違っていたのではないかと気づかされました。ショッキングなことだけれども、SI業界の現状としてはそういった意見が多数あることは事実として受け止める必要がありますね。
結局、私が信じてきた本などの情報は主に外国の著者のものであり、当然日本のSI業界の考え方とはまったく異なる価値観で書かれていても不思議ではありません。実際、欧米ではユーザー企業が直接PGを雇って主体的にシステムを開発するのが普通と伺っています。そうであれば、当然作ったプログラムやシステムを資産として長いこと活用したり再利用したりしたいという発想になるのは自然です。オブジェクト指向やSOAなど、粒度は異なりますが、さまざまな再利用の手法が考えられてきたのはそういう背景があるのだと思います。
一方、日本のSIerの考え方では基本的に契約したシステムの機能を期限内に実装できれば良いというのが基本的な考え方です。再利用性などはユーザー企業側のメリットですが、多くの場合ユーザー企業は丸投げ状態でシステムの中身は理解できませんから、コピペが蔓延し、単体試験不能なコードであっても、一度試験し、納品できてしまえば良いというところがあります。実際は顧客のビジネスは変化しますし、要件が変わらないということはないはずなのですが、そこは「有能な」PMの政治力によっていかに顧客のわがままを抑えてやりやすい方向にコントロールする*1かというところが最重要となります。逆にソースの綺麗さや保守性といった職人PGのスキルが活かされるところは重要視されません。
エンジニアリングとしてはあるべき姿ではないと思いますが、一度作って納品してしまえば終わりで、数年後に機能拡張が必要になったら、ほぼ全面作り直しなどということはSIerのビジネス上はむしろ成功とされてしまうというところがあります。お客様を怒らせない程度に、かつ、なるべくたくさんのお金を出させるというのがSIerとして最適な成功するパターンであると言われれば、そうなのかと納得せざるを得ない面があります。私としては非常に悲しいことですが、お金儲けということを考えればそういう価値観があってもよいと思いました。
ただし、長い目で考えると、ユーザ企業もずっとだまされ続けるほど馬鹿ではないし、費用対効果や再利用性など、徐々にですが気にする企業も増えていくのではないかとも思われます。事業仕分けなど、政府関係でもだんだん財布の紐がきつくなってきている時代ですから。「ゆで蛙」のたとえ話のように、SIerが知らない間に世の中の価値観が変化して、品質の高い、保守性の高いシステムというのが最重視される世の中にいつの間にか変わっているということもありえないことではありません。そういう時代*2になった時には職人PGのスキルが業務システム開発の領域で本当に発揮できるようになると考えています。
（追記）
本記事のタイトルから私が言いたいことを誤解される方がいらっしゃるようですので、ちょっと補足させていただきます。「高い品質のプログラムを作らなくてはならないと考えている職人PGの考えは間違っていた？」という質問に対しては、今までの一般的なSIerの価値観に則って考えるとそういうことになるという事実があるということに気づいたということに過ぎません。ただし、本記事で絶対的普遍的に職人PGの考えは間違いと主張するつもりはまったくありませんし、私自身今後考え方を悔い改めますということでもありません。実際、良いプログラムを作りたいという私自身の欲求を捨てることなど到底難しいことですし、私としては会社の評価がどうであれ、自分の基本的な姿勢を転換することは考えていません。記事の内容を最後まで読んでいただければ分かると思いますが、むしろ、近い将来職人PGの考え方がビジネス的にも評価される時代が来るはずであるという期待があります。長期的に見てユーザーをだましてお金儲けするなどという考え方のビジネスが永続的に成功するとは私は決して信じたくありません。客観的に見てユーザーも開発者も幸せになれるようなビジネスこそ神の教えに沿った*3正しいあり方であると信じます。

*1:現実には多くの場合お金を出すお客様は神様で、そういったコントロールが難しいところがあるようです。それで結局デスマになると今度は下請け会社に責任を押し付けてありえない納期での作業を要求するなどPGの買い叩きを行う能力が重要となります。

*2:上記のコメントで「赤点」「最低ライン」という言葉がありますが、最近のプロジェクトはこの最低ラインがかなり高めに設定されているか、あるいはテストの問題が非常に難しくて最低ラインの60点を取ることすら難しいというところもあると思います。実際、どこの会社が作っても合格できるような単純なワークフローやマスターメンテのシステムなど、安価なツールで自動生成できる時代になってきていますから。（頭数要員だけでこなせる仕事が今後もずっと取れると考えているSIerの仮説は間違っている - 達人プログラマーを目指して）既に、そういう時代への変化がかなりの部分進行してきているという考えもありますね。

*3:日本語としてはちょっと大げさな表現ですが、シンプルで正しい設計のプログラムというのは客観的に見て美しいのであり、制約の範囲でそういう方向を追及するというのはエンジニアリングの自然な欲求です。今日はクリスマスイブですし、神様について言及するのもよいでしょう。