Hatena::ブログ(Diary)

elm200 の日記 このページをアンテナに追加 RSSフィード Twitter

2010-10-06

プログラマが直面する2つの「世界」


プログラマというのはとてつもなく難しい仕事だ。

職業的なプログラムは、それが会社であれ、個人であれ、顧客の何らかのニーズを満たすために存在している。プログラマは、顧客の要求を満たすように、プログラムを設計・実装する。ここで注意しなければならないのは、「顧客の要求」と「プログラムの設計・実装」という全く異質な 2つの仕事を同時にこなさなければならないということだ。

顧客の要求は、社会というシステムに属し、プログラムは、技術というシステムに属する。この2つは全く似ていないし、何の関係もない。それが、「顧客要求を表現したプログラム」という一つの場で切り結ぶ。異質な2要素がぶつかり合い、プログラムコードはまさに戦場と化す。

書かなければならないプログラムの種類によって、この緊張度は異なってくる。たとえば、組み込みソフトウェアや科学技術計算などの場合は、要求自体がかなり技術的であるから、プログラムという技術的世界との相性は比較的よい。

ところが、ビジネス・ソフトウェアの場合、実装されるロジックは完全に異質な社会的要素に基づく。「顧客の要求」と「プログラムの設計・実装」の二つの世界を完全に両立させるのは難しい。

カネを払う顧客の立場に立てば、プログラムの中身はどうでもよい。完全なブラックボックスにすぎない。それが Java だろうが、PHP だろうが、Perl だろうが、C# だろうが、Ruby だろうが、そんなものは全く関係ない。サーバーの中に天才猫が入っていて、正しい応答を返す、というのだってかまわないのだ。

ところが、実際にプログラムを書くプログラマの立場に立つと、どの技術を選択するかは自分の仕事の負荷を大きく変化させる死活問題となる。ウェブプログラムを C で書けといわれたら泣くかもしれないし、デバイスドライバCobol で書くことはそもそも不可能かもしれない。

仮に、顧客要求寄りと実装寄りの二種類のエンジニアがいると考えるなら、顧客にとってありがたいのは、顧客要求寄りのエンジニアである。実装寄りのエンジニアの言っていることは、顧客にはちんぷんかんぷんだし、理解する必要もないのだ。顧客が求めているのは、予算・納期内で自分の要求が満たされることにすぎないのだから。

したがってビジネスソフトウェアの場合、それが受託開発であれパッケージ開発であれ、客と話す機会の多い顧客要求寄りのエンジニアの力が強くなる。カネをくれるお客様は神様、だからね。顧客要求寄りエンジニアと実装寄りエンジニアが同一人物であってもかまわないし、むしろ望ましいのだが、この二つの完全に異質な世界に対して同時に同量の関心を注ぎ、同等に習熟するのは、非常に難しい。実装寄りエンジニアは、技術の海に遊ぶことに夢中になり、社会的諸要素に対して関心を失うことが多い。

顧客要求寄りエンジニアと実装寄りエンジニアは、いきおい別々の人物になることが多い。日本では前者は SE、後者は PG と呼ばれ、PG は SE より低く見られている。たしかに、顧客=カネからの距離で、エンジニアの序列を測るなら、PG は SE より顧客から遠い。ビジネスソフトウェアでは、顧客の要求をすばやく満たすことが優先され、実装上の効率性・保守性が後回しにされる。これが、ビジネスソフトウェアのソースコードが醜くなりがちな最大の原因の一つだろう。

私は、これがどうしても許せなかった。ソフトウェアの魂は、ソースコードに宿る。私は、顧客要求寄りエンジニアに舵を切るチャンスは人生で何度もあったのに、醜いソースコードを捨てておけず、実装寄りエンジニアをやめることができなかった。これは私の業(ごう)である。抵抗しながらも、どうしても実装へ実装へ流されていってしまうのである。これは一種の病気のようなものかもしれない。

総合的なソフトウェアのコストパフォーマンスを考えるなら、実装寄りエンジニアはいまより重要視されるべきだ。コストが安く品質の高いソフトウェアが作れる可能性が高まるからだ。だが、実装寄りエンジニアにしか、技術的な世界は理解できないので、利害関係者を説得するのは容易ではない。彼らの仕事をわかりやすく、素人にも可視化できる方法があるとよいのだが。他者のすべての失敗のしわ寄せが行く実装寄りエンジニアは、損な役回りになってしまっている。

shibu6809shibu6809 2010/10/07 15:40 興味深く拝読させて頂きました。
「私がソフトウェア技術者をやめた理由」も併読しましたので、
なるほど、このような「辞めた理由」をお持ちの貴殿であれば、
今回のエントリのようなことをお考えになるのは、至極当然で
あろうと思いました。
 その上で、私見を申し上げますと、エンジニアを
>顧客要求寄りと実装寄りの二種類のエンジニアがいる
というふうに二分割できるという前提については議論なしに
いちおう認めたとして、ある個人が、この2つを共立することは
そんなに困難なことなのだろうか?と思うのです。
 たとえば、ある業務システムの開発に従事したとする。
 その参画期間が仮に半年としましょう。
そのときに、
「最初の2ヶ月は、顧客要求寄りエンジニアでいよう。
 開発段階に入ったら、実装寄りエンジニアでいこう。
 そしてこのプロジェクトが終わるころには、顧客要求も実装も分かる
 エンジニアになろう」
というモチベーションを持つことは、一見、すごく大変そうに
思えますが、やり方次第というか考え方次第なんじゃないかと
思います。

とはいえ、elm200さんのソースコードへのこだわりは好きですよ。

shibu6809shibu6809 2010/10/07 19:38 コメント承認ありがとうございます。
誤字訂正です。

9行目
:%s/この2つを共立/この2つを両立

でした。
私はドキュメントの日本語にこだわる技術者かもしれません(笑)

solissolis 2010/10/08 10:44 ばっさりと切り口のいいお話で、すっきりしました。
ありがとうございます。

日本では顧客要求寄りエンジニアが実装寄りエンジニアをコントロールする慣習があるので、顧客要求寄りエンジニアが考えること以上のものは出てこないようです。


顧客要求寄りエンジニアと実装寄りエンジニアが両立するのは難しいと思います。
低いレベルならば両立しやすいかもしれませんが、高いレベルでは難しい。

極端にいえば、成功する実業家とノーベル賞クラスの科学者の両立はありません。
たぶん今の時代は国内で低いレベルで競争している時代は終わって、より高いレベルで競争する時代だと思いますから。

uryossauryossa 2010/10/08 14:59 私の場合、「実装寄り」というのは決して「顧客寄り」の対局ではないと感じます。
「実装寄り」こそ正に「顧客寄り」ではないかと思うのです。
それぞれ、短期的に顧客寄りなのか長期的に顧客寄りなのかの違いです。
それは利益として、それぞれ短期的に、または、長期的に返ってくるはずです。
いずれにせよ、後者の組織運営の方が、醸成される組織内文化、組織内暗黙知、が静かに蓄積され、いつか「短期的な顧客寄り」を凌駕できると思います。
でも・・・「言うは易し。」ですよねぇ・・。

石水石水 2010/10/10 00:37 >ソフトウェアの魂は、ソースコードに宿る。

立ち位置あるいは価値観の違いからくる意見の相違かもしれませんが、私は、魂が宿るのはシステムのフレームワークの設計(日本の業界では何と言うのでしょうか?)にあると思います。

業務アプリ開発プロジェクトの存在目的は顧客の要求を満たす事ですから、そもそも顧客寄りとか実装寄りという考え方に問題があるのかもしれません。また、顧客要求と言っても、顧客がシステムの設計や例外条件の洗い出しをしてくれる訳ではありませんので、顧客が言葉に出して、あるいは文書で提出された事項が、必ずしも顧客の「真」の要求と一致していない事が往々にしてあります。これが、業務アプリの開発が頻繁にデスマーチに遭遇する主因であると理解しています。私は、以前にはこれに気付きませんでしたが、経験からこの問題を発見しました。今では、開発プロジェクトを手がける時は、顧客の言葉を鵜呑みにせず、顧客が抱える真の問題は何か、その解決方法はどうするべきかを、顧客の業務分析のフェーズに十分な時間を投入して吟味し、自分で出した結論に基づいて提案を行い、自分でシステムのフレームワークの設計を行い、難易度の高そうな機能の実装方法のアプローチやデータベースのおおざっぱなデザイン方針を決めます。そこまで行った上で、プログラマへ仕事を投げ、開発を開始します。

私の立場からすると、プログラマは適度に効率良くかつメンテナンス性の良いソースコードやデータベース実装を行ってくれれば、その中身の「美しさ」にはあまり興味がありません。その一方で、顧客の真のニーズを吸収し、顧客に満足を与える事ができたシステム設計について「満足」を覚えます。

shibu6809shibu6809 2010/10/11 11:25  私は、先のコメントで書いたとおり、

 <顧客要求寄りエンジニアでいることと、
  実装寄りエンジニアでいることは両立する>

と思っています。
なので、uryossaさん@2010/10/08 14:59の

>「実装寄り」こそ正に「顧客寄り」ではないかと思うのです。

には「それ、分かる分かる〜」っていう感じです。
そして、

>でも・・・「言うは易し。」ですよねぇ・・。

にも、深くうなづいてしまいます。

 ただし、冒頭の<・・・>に書いたことは、
私個人の思いというか願望であって、一般的に
成り立つことではないだろうな、とも思って
います。
 つまり、冒頭の<・・・>をより厳密に書くと、

 <今の私が持っているスキルや技術経歴と、
  今私がいる職場で、私に求められている役割を
  比較考慮すると、私が、今の職場にいる限りにおいては、
  顧客要求寄りエンジニアでいることと、
  実装寄りエンジニアでいることは両立するだろう>

ということであって、

 <誰にとっても、顧客要求寄りエンジニアでいることと、
  実装寄りエンジニアでいることは両立する>

という主張ではありません。
(elm200さんのブログで、こんな大上段からの主張を
するのは、そ、そんな、ええ、もう、恐れ多いと
いいますか(笑))
 実際、たとえば公官庁がITゼネコンに発注して、
以下多層的な請負構造が累々と続くような類の、
何千人月というような規模で、開発プロセスが
ウォーターフォールな職場だったりすると、
まず無理でしょう。
 そういう職場では、プログラマーは"上流"と称する
顧客要求寄りエンジニアたち(彼らは、自分らのことを
コンサルタントと呼ばせたいようですが、)からまともな
人間扱いをされず、一山いくらの奴隷のように
扱われているとの噂も仄聞しております。

 私個人は、常にプログラミングに対するモチベーションを
すり減らされないような仕事のできる職場を求めてきて、
今に至り、冒頭の<・・・>のような考えを
(幸せなことに)維持できています。

 と、ここまで書いて、ある本を書棚から取り出して、
ラインマーカーを引いたところを読み返しています。
以下、引用します。

----------------------------------------------------
 私は、キャリアとは年齢を重ねながら自分自身を
創っていくことで、キャリアを確立するのは、
「やりたくない仕事をやらなくても生きていける
ようにするため」であり、「付き合いたくない人と
付き合わなくても生きていけるようにするため」
であり、「休みたいときに自由に休める状況を
創っていくプロセス」なのだと思っています。
----------------------------------------------------
以上、小笹芳央著「モチベーション自己革命」(講談社)

 プログラミングという技能を使って、自分が
どんな仕事の仕方をしたいのか、いってみれば
どんな自由を獲得したいのかは、個々人に
よって、当然異なってよいはずなので、

【課題】
 顧客要求寄りエンジニアでいることと、
 実装寄りエンジニアでいることが
 両立するかどうか?

についての結論についても、個々人によって違って
当然でありましょう。

 私の興味はむしろ、どういう経験をたどってきた人が、
どういう考えに基づいて、上記の【課題】の結論を出した
のか、そのプロセスにあります。

恐縮ながら、私個人の”気分”としては、

「顧客要求寄りエンジニアでいることと、
 実装寄りエンジニアでいることが
 両立できないような仕事はイヤだな〜。
 (そういう仕事にアサインされそうになったら、
 角が立たないように断って逃げよっと)」

という感じです。

はてなユーザーのみコメントできます。はてなへログインもしくは新規登録をおこなってください。