ITエンジニアは悪意に満ちているのか?

感想おまちしてます!

3月の月報として提出予定。
*
*
悪意は2種類あると思う。1つ目は故意に発生するもの。もう1つは、意識せずに発生するものだ。一番身近である仕事、システム開発でも同じことが考えられるように思う。多分、どの世界にも悪意は満ちているからだろう。
システム開発ではよく「妥協点を探す」という言葉が使われる。これは期間、コスト、人員のスキル、実現性などを考慮して、可能な限りの理想を見つけるという意味の言葉だ。
海外への外注などによる低価格競争に対抗すべく、短期開発という厳しい現実の中でこの妥協点はよく現れるが、ほとんどの場合、「これをやる時間がないから妥協する」といった作業(手順)の省略などネガティブな内容が多い。
しかし、妥協点については、どうしても譲れないキーポイントを見つけ出し、そこである程度の品質を維持すると言うポジティブな妥協が重要だ。つまり、「いいモノを作りたいんだけど妥協する」のではなく「いいモノを作るために妥協する」のだ。
だが、現実にはこれが無視される傾向にあるように思う。すばり今回の問題はこれだ。
なぜポジティブな妥協が無視されてしまうのだろうか?


*
前に述べたように、ある程度の妥協点をリーダーは顧客に対して考える。方向を定め目標からできる限りずれない着地ポイントを見つける。顧客に理解してもらい作業者に伝える。作業者は理解して実施する。
この時、プロジェクトリーダーや開発リーダーが当座の問題に迫られてしまうと、プロジェクトの方向性を伝達できなくなってしまう。
最初の原因は、上記のようなリーダーから作業者への伝達がきわめて少ない(もしくはまったくない)ことだ。つまり、「ここは理由があって妥協します」という認識について話されることがないというところが問題なのだ。
個人的には別に難しいことでもなく、話さない理由もないと思っているのだが、なぜか妥協点について話されることがない。話されないのだから、ポジティブな妥協など生まれることがない。
私はこの「妥協点を探す」という言葉が大嫌いで、初めはやれることをやらないという「あきらめ」が嫌いなのかとと思っていた。
昔月報のコメントで「妥協することもある【TODO コメントを確認しておくこと】」という言葉をもらったときに「それはわかっているんだけれどなぜ大嫌いなんだろう」とさらに考えてみて、今回の結論に至った。ようやく答えが見つかった気がする。
*
もう1つの原因は作業者の意識だと思う。これは最初の原因に関連する原因とも言える。
今まで入社して以来、「メンバー間のまとまりというものがないのではないか」という疑問を持ち続けていた。それぞれの力を合わせれば「1+1=2以上」になるはずなのに、「1そして1そして1・・・」となっている仕事場の雰囲気。また、「10そして1そして1・・・」といった現状の散漫な技術レベルでもあることから、「なんてまとまりのない会社なんだ」と思った。
ある友人が「同じプロジェクトのメンバーが同じ方向を向いて作業していない」と言っていた。まさに、この表現がぴったりだと思う。
(別の問題になってしまうが、よく言われるように集団では「2:6:2ルール」になぜか従って意識は分かれてしまう。でも、技術レベルにこれがあてはまってしまうことも問題だと思う。)
通常ならば、妥協点に関する懸念点を考える。「これで開発がうまくいくのか」、「これで品質をどこまで確保できるのか」といった内容について考えるはずだ。しかし、リーダによって妥協点の意義を浸透させることができなければ、作業者はこれらの観点を「これはやらない、これはやる」という単純明快な考えの元に作業を行ってしまい、さらに自分の意識しないところで妥協してしまう。
逆にリーダーが完璧に伝えたとしても、個々に独立したメンバーだと同じような妥協が生まれてしまう。
*
今回の問題の原因と考えた部分に、私はとても悪意を感じる。これは無味無臭で人畜有害の悪意だ。
この悪意は、個人の意識の外に生まれる。この悪意を感じたときにいつも思うのが、その判断の理由を誰かに聞かれたときに、どのように説明するつもりなのだろうか。大抵の場合、「忙しいから」とか「前にやったから」とか「理由はないんだけれど」という回答を受け、いつも脱力してしまう。
これは断言できるが「忙しいから」なんて絶対に理由にならない。エンジニアとしての発言でもなく、ビジネスにも含まれない言葉だ。
完全に単純作業者としてしかプロジェクトに参加できていない。
*
妥協と言うのは必ずといっていいほど生まれるし、膨大な情報を処理する仕事の中で完璧なものはなく、どこかで我慢しなければならない部分がある。では、自分には何ができるか。ここで思いついたのが手を抜かずコストとリスクを減らそうとする考え方だ。
まず思いついたのが、エクストリームプログラミング(eXtreme Programming)などを取り入れ、アジャイルソフトウェア開発を推進し、無駄のない開発プロセスを実行、そしてその精度を高める手法を身につけることだ。
また、組織レベルと言われているQMSを開発プロセスに組み込み、品質面での安全性を高めたりすることだって可能だ。この場合、QMSが掲げる「継続的な改善」に当てはまることができるので組織としてもうれしいかぎり、一石二鳥でもある。
さらに、これも組織レベルの考えだが、CMMと言われるモデルも開発現場に組み込めることができそうだし、ITSSのような基準を持って自分のスキルに対するロードマップを意識、そして評価することもできる。
調べてみると自分にできることが、思った以上にあることがわかった。これからは、これを実行に移すだけだと思う(とりあえずXP関連の本はすべて読破することが目標)。たくさんあるので大変そうに感じるが、努力してできないことなど今までなかったのだから、不可能ではないだろう。
私はいつも「楽すること」を考えている。これを人に話すと「ふざけている」と一蹴されるが、そういう人間ほど残業が大好きで非効率な場合が多い。
「楽すること」と「手を抜くこと」はまったく異なり、「楽すること」はその文字の通り楽しく快適に仕事ができ、とても楽になる。その分、楽するまでに相当の手間が発生するため、なかなか大変なことなのだ。
最期に、今回書いた悪意について、昔、アルバイト先の先輩が言っていた言葉がある。
「考えない人間は猿以下だ」
*
【参考】
アジャイルソフトウェア開発プロセス
XPプログラミング
オフショア開発の委託先
品質マネジメントシステム(QMS)
ITスキル標準
ITSSユーザー協会
CMMとは:http://www.atmarkit.co.jp/aig/04biz/cmm.html
ピープルウエア 第2版 ? ヤル気こそプロジェクト成功の鍵
ピープルウエア 第2版 ? ヤル気こそプロジェクト成功の鍵 XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法 XPエクストリーム・プログラミング導入編 ― XP実践の手引き XPエクストリーム・プログラミング適用編―ビジネスで勝つためのXP