開発言語と、通販対応配送センターERPの開発者の視点を中心としたコラムです。

「ダメな現場は何をやってもダメ」、勇気を持って根本を変えよう

»

 やはり、IT技術者たるもの、日々、プログラムを作るスキルはアップさせて、今まで難しく感じたものがすいすい書けるようになることに喜びを感じるものだと思います。

 しかし、このためには、正しい勉強方法やスキルアップできる環境を用意できなければ、時間ばかり経ってしまいます。

■今の一般的な現場だけでは本当のスキルはつきにくい

 ITにかかわる環境は、日々、ものすごいスピードで変化しています。昔は、ほぼスクラッチでプログラムを書くのが当たり前でしたが、今は、SaaSやオープンソースのパッケージや商用パッケージの利用などで納期が短くなっていると思います。

 しかし、この「納期が短くなっている」というのが幻想である場合が多くあります。それは、発注者側が「パッケージだから」という理由で、実際の現場でどのくらいの考察と作業が発生するかを無視してごりおしをしてしまうことも多いと思います。

 このような環境では、絶対に何かしらひずみが出て、「完全な形で納品」されるということがない場合が多いのではないかと思います。

 また、その現場での政治的なやりとりから発生したスキルの多くは、他の現場では再利用できません。

 一般的に、このようなところでは、「分からない人に対して分かりやすいもの」のみが優先される傾向にあり、「作業を圧倒的に楽にする(変化に対応しつつ工数を減らしてくれる)本当の工夫」は一般的に分かりにくいので、いわゆる「力作業」だけがなし崩し的に強要される現場が多いのではないでしょうか?

■「問題発見」→「分析」→「作業」の順番が守れない現場は何をやってもダメ

 結局のところ、開発現場で守るべきことというのは、「問題発見」→「分析」→「作業」という順番を守ることです。

 この順番を守らなければ、なし崩し的に行われた作業は、上流の仕様変更によって一気に0に回帰します。つまり、蓄積がないのです。

 また、この3つのプロセスで時間をかけるべき部分は「分析」です。しかし、この作業は、非常に分かりにくく、進捗を自分で管理したいけれどもプログラムが作れない人にとっては、「一体何をやっているのか?」ということになります。

 そして、良くできた分析結果ほどシンプルで、ドキュメントもすっきりとまとまってしまうので、「仕事をしているのか?」という話になります。

 この順番を守れるかどうかは、この「分析」の価値が理解できて、そこに対して時間を投資できるかどうかに掛かっていると思います。しかし、海外ではともかく、日本ではここに対する認識が他の国にくらべて弱いような気がします。

 一時期、むりやり、ITバブルでSEを増やしてしまったり、プログラマ35歳定年説などITを実質的に顧客が喜ぶように仕事を達成するよりも、終身雇用的な社内の保身のための仕組みの方が重要視された結果だと思います。

 プログラマ35歳定年説などというものは、開かれた実力主義であるシリコンバレーでは存在しません。

■解決方法は「権利のみ主張する人」の排除

 なぜ、日本ではそのような特殊な文化になってしまっているか?これは、日本古来からの「和を持って尊しとなす」という文化からきていると思います。

 どんなものの考え方も、良い部分、悪い部分があり、結果を出すためにはどのカルチャーがいいのかをきちんと選択することが必要です。

 ITの場合、この「和を持って尊しとなす」は筆者は現場に合っていないと思います。なぜならば、このカルチャーで現場を運営するためには、必ず主従関係を付けなくてはなりません。そして、「正しいこと」よりも「主従関係で上に立つものの意見」が採用されるので、もし、決定的な判断をする人に十分な知識がなければ現場は大変なことになります。

 「意見を採用させる」というのは1つの大きな権限だと思いますが、権限の裏には、「採用した結果に対して自分で責任をとる」ということが付きまといます。この責任を自分では取らずに、他の人や主従関係で下の人間に押し付ければよいと思っている人が上に立ってしまうととても大変です。

 現に、日本ではそのような考えの方がいます。海外では、きちんと。海外では、きちんと権利に加えて裏側にある責任も最初の段階でフェアに話し合われ、リスクも認識したうえで契約が結ばれますので、「自分は現場で何が良いか判断できない」と考える人がその契約を結んで、決定権のあるポジションに就くことは稀です(ただし、利権が絡む場合は同様のことがあると思います)。

 権利と義務がきちんとセットになって議論されている現場では、プロマネがきちんとプロジェクトチームのどこかできちんと下流工程の状況まで調べたり、きちんとした分析がなされる仕組みが整備されます。

 なぜならば、そうしなければ、プロマネの方は自分の責任が果たせないからです。

■プロマネのスキルの本質は経営スキルと同じ

 プロジェクトのマネジャーという仕事は、ある意味、経営者の仕事に似ていると思います。

 ただし、「社長の能力より高い社員はその会社には入らない」というルールが適用されているレベルではなく、「自分が評価的ない分野の高いレベルの人間を評価する仕組みが組織のなかに構成されるように工夫していく」ということができるレベルだと思います。

 筆者は「プロマネはプログラムができないといけないのか?」「プログラマは、一生懸命頑張ってSEになるべき、そしてSEはプロマネを目指すべき」というのは、この観点でいうとまったく方向性が違うのではないかと思います。

 なぜならば、プログラマ(およびアーキテクト)、SE、プロマネはそれぞれ目的が違うからです。そして、どの職種も1つのプロジェクトで必要だからです。

 もし、筆者は、プログラムも要件定義もプロマネも一通り経験があるので、現実的にはどれも自分で評価してしまえばいいかという話になりますが、もし、要件定義をある程度やっていてプロマネをやるならば、

  • プログラムのアーキテクチャの責任者
  • SE、要件摺合せの責任者

ときちんと分業し、責任範囲を決めて進めると思います。

 また、何人かで協業するとなると、お金の問題が出てきますが、これは、「負った責任」に対してプロジェクトの進行を3者でオープンにし、フェアに分配するといいと思います。

■「正直者」にはスキルが必要

 仕事でシステムを作る場合には、当然ながらお金の問題が発生します。そうすると、完全に経営の問題になってきます。

 「負った責任」に対してプロジェクトの報酬を分配するときには、それぞれ3者が担当する分野においてスキルがある人と組むことが必要です。なぜならば、スキルがない人を入れてしまうと、責任転嫁が始まり、間違ったところで責任を無理やり取らせる方向になっていきます。

 また、プロマネの担当者は、他の担当者が責任転嫁しようとしているのを見逃してはいけません。そこから、モラルの崩壊とプロジェクトの崩壊の大連鎖が起きていきます。

 そういう意味では、プロマネは社長業そのものかもしれません。しかも、その「責任転嫁」を見抜けるくらいはひととおり分かっているジェネラリストでなくてはいけないところが難しいところだと思いますが、これは絶対に必要です。

 結局のところ、それぞれが自分の担当している部分がどこか責任範囲がしっかりしていて、きちんとその部分をしっかりこなせるスキルがあれば、このようなモラル破壊も起きません。なぜならば、きちんとできる人が、責任転嫁をしてプロジェクトを崩壊させても何のメリットもなく、デメリットだけだからです。

 「モラル」や「正義」というのは、それを定義することよりも、「絶対的な正義など存在しない」と割り切ったうえで、「なぜ、それが必要なのか」をお互いの利害関係から考えていけばわりと素直に成り立っていくので、本当に世の中はよくできているなあと思います。

 昔、子供のころ、別に勉強熱心だったわけではないのですが、たまたま放課後に宿題を忘れて居残りで勉強している風景を見られて、用務員のおじさんに「君は、よく勉強して偉いね」と言われたことがありました。

 その当時は、なぜ、勉強をすることが偉いのかが分かりませんでしたが、勉強をして知識やスキルをつけることによって、ずるいことをせずに他人に対して貢献することで食べていけるようになるという意味で偉いのだと大人になってから分かりました。

 大人になってからは、また、さらに「お金」という要素が出てくるので、さらに複雑化しますが、「他の人に対して貢献した対価としてお金をもらえる」というルール自体は変わらないと思います。

 そして、現実の社会で、もし、その利害関係からきちんと成り立たせる「正義」に矛盾があるようであれば、

  • なぜ、それぞれが仕事を行っているのか?
  • 他の人を幸せにした人がきちんと報われるか?
  • 最終的にプロジェクトを発注した顧客のためにもなるか?

を考えて、プロジェクトマネジメントの範囲を超えた本当の意味での「経営」を考えていかなくてはいけないと思います。

■戦略の失敗は戦術では取り返せない

 「戦略の失敗は戦術では取り返せない」というのは、まさに本当だと思います。

 エンジニアとしてこの社会で生きていくためには、ときには、自分の置かれた環境について考えてみることも非常に大事です。筆者はそう考えて起業という道を選びました。

 「ダメなものは何をやってもダメ」というのは、認めるのが難しく、場合によっては周りの空気から「逃げ」ととらえられてしまうかもしれませんが、勇気をもって「ダメ」ということも時に、「結局は」と考えれば一番大事で良心的であることも多いと思います。

 破壊と創造は本当に背中合わせだなあと思いつつ、筆者も今後はこの「ダメという勇気」を今後は大事にしていこうと思います。

Comment(2)

コメント

アラファイブ

飯塚さん、こんにちは。自分はロートルのプログラマです。

早速ですが、思ったのですが、

下流工程だと『「問題発見」→「分析」→「作業」』の「作業」に単体テストが
含まれていて、**力押しで有っても**、「作業」終了後に『次の「問題」』を発見し、
サイクルが回る面が有るのですが、
上流工程だとその様な追加ポイントが無く、そのサイクルが回らず、「仕様バグ」が
そのまま下流に流れてしまいがちに見えます。
(お客様の問題意識以上の「問題発見」になかなか繋がらない。)

本当に上流の「仕様変更」なら(甘んじて)抱擁しないとならないでしょうが、
不備による「仕様バグ」を「仕様変更」と強弁されるのは釈然としないです。

(自分の所特有の話ですが)特にこの2、3年以降、当たり前の様に「仕様バグ」を
出してくる傾向に有ります。
『「問題発見」→「分析」→「作業」』に問題がより起こっているのは、上流の方で
は無いでしょうか?

アラファイブさんこんにちは。
まさにおっしゃる通りだと思います。そして、このカルチャーは、日本独特でもあると思っています。
上流専門の人は日本にはたくさんいるとおもいます。しかし、その上流専門の方は、仕事において「何に対して責任をとるのか?」というのがはっきりしません。
つまり、上流の人は、見積もりに責任を持ち、もし、下流の工数がUPするならば、本当は下流の担当者にその分の費用を渡さなくてはならないのです。
この部分が、顧客理由であれば顧客に追加費用を要求しますし、自分の仕様ミスであれば、そのぶんを自分の取り分から支払います。
この文化は、ちょっと他の国ではなかなか見ませんね。オフショアで失敗する理由も大抵この文化に影響するものがほとんどです。
仕様が決まっていないソフトウェアに対して見積もりを書いたり、テストケースが設計できるのは世界で唯一日本くらいだと思います。
上流のエンジニアの仕事は技術であって、政治ではありません。最近よく、SIerは終わったという記事が目立ちますが、そうではないと僕は感じています。「勘違い上流」が必要ないと、顧客にばれただけだと思っています。

コメントを投稿する