スキルシートでいったい何が分かるのか：開発チームを作ろう（1）（2/3 ページ）

[佐藤大輔，オープントーン]

スキルシートで何が分かる？……スキルシートは取り方ひとつ

あまり吟味されないスキルシートの中身

　40歳代後半のベテランエンジニアとして、協力会社から呼ばれたEさんの例です。案件は、最近よく見られるホストのシステムのマイグレーションでした。そのため、Eさんは「十分な現場経験があり、ホストのCOBOL言語と新しい技術の双方が理解できる」という内容で選ばれ、スキルシートもそのような内容になっていました。

　スキルシート上の記述では、14年にわたるホスト系のCOBOLの経験が中心でした（表）。ここ1年は転向し、クライアント／サーバのシステム構築に携わってきた……という内容です。今回本案件では、クライアント／サーバでのマイグレーションが主任務です。

内容	経験年数	担当
金融機関COBOL勘定系	11年	PG、SE
金融機関COBOL基幹系	3年	PG、SE
Web（VB ASP）プロジェクト	6カ月	リーダー
VBクライアント／サーバ プロジェクト	3カ月	設計・実装
VBクライアント／サーバ プロジェクト	2カ月	設計・実装
スキルシート上の記述

　このスキルシート上も、後から思えば「同じシステムのPG、SEを10年近くもやっている」という危険要素があったのも事実です。Eさんがどうしてそこに10年張り付かねばならなかったのか？ それほど顧客に買われていたのか、あるいはほかに案件がなかったのか？ 会社が異動させるのを忘れていたのか？

　など、想像の域を出ませんが、何らかの事情があったのでしょう。ただし、Eさんの場合「採用する側の判定」としては、以下の理由で十分な評価がありました。

• 十分な業界経験がある
• 技術的にマッチしている（ホストの事情も分かり、クライアント／サーバシステムの事情も分かる）
• 設計や実装、リーダーを経験している

　基本的に所属している会社・組織の評価を前提に「通す方向」で検討しているのですから、褒め言葉が並ばざるを得ないでしょう。

不適切なロールが呼ぶ不幸

　果たしてEさんが置かれたのはどんな状況だったのでしょう？ プロジェクト的にはいわゆる追い込みの真っただ中で、すでに一部はテストに入り始めていました。その中でEさんは、稼働までのヘルプと、本番稼働後の開発保守まで対応するための要員として呼ばれました。うまくいけば、大きくて長い現場が得意である彼にとっては、「幸せな現場」になれたかもしれません。

　方向としては、テストを手伝ったり修正を手伝ったりしながら仕様を理解してもらい、徐々にリーダー＋SEの立場になってもらう、手数が足りない分は自分でも直せる、というプランとしては悪くない内容でした。

　しかし、最初の綻（ほころ）びは、「取りあえず簡単な修正をお願いする」ところから始まりました。「簡単な修正」ということで、修正個所も特定し、コードを印刷し赤ペンで「どう直したらいいのか」を書き込んで手渡したのです。もしわずかでも経験があれば、ここまでのガイド付きであればすぐに修正をしてテストをしてリリースをしたでしょう。規模のあるプロジェクトだったので、すべては手順化されており現にほかに入った2名は特に問題なく作業をしていました。

　しかし、1つ目の不幸は、彼にはレガシー言語以外の実装作業経験が5カ月程度と不足していたことでした。また14年も同じ現場にいたため、そこ以外の手順にも慣れていなかったのです。

　人間は習熟していないことを要求された場合、どうしても自信がなく、何事もハタから見ていて「挙動不審気味」に見えてしまうものです。しかし多くの場合「その不安」を解消するために「他人に聞く」「学ぶ」という行動を取ります。

　ところが、2つ目に不幸だったのは、彼は容易に聞くことができなかったのです。

図2 本当は聞きたい

　カベとなるのは「スキルシート」です。スキルシートには「経験があり、分かる」ことが記述され、またその記述を前提にチームに採用されています。そのため、彼は容易に聞くことができません。また「聞く」にも最低限のスキルは必要です。「分からないところも分からない」という状況ではどうにもなりませんでした。

不幸は増幅される

　この場合、多くの人が取る典型的な行動があります。「独り言」です。自分が分からない状況であることを人に伝えようとするのです。要するに「Help Me」をいえないので「HELP ME」に代わる内容で訴えようとします。それは他人に聞こえる独り言であり、しかもその内容は「僕が分からないわけではないが、どうもおかしな部分がある」というものです。

　具体的には「あれー」「○○になっているはずなのになー」「おっかしいなー」という内容の連発になります。私もよく独り言をいいますが、この種の独り言には以下のような特徴があるようです。

• その独り言が他人に聞かせるものであること
• 何かの問題……それも自分のせいではない問題があって作業がうまくいかないことを訴える内容であること

　Eさんもやたらと首をかしげて、1人で自問自答する日が続きます。

　ちなみにある程度の規模のプロジェクトを観察していると必ずこういう人を1、2名見つけてしまいます。無論「そういった人＝問題がある人」ではありませんが、少なくとも「他人に訴えたいが訴えられない状況」「外部環境の問題をしきりに口にして自分が作業を進まない理由を周りに宣伝している状況」を考えると、「順調に活躍中」でないことは容易に想像できます。

　初日から、彼の作業スケジュールは担当者が当初予想していたよりはるかに遅れ始めます。いろいろな理由があって全く作業が進まないことを説明する日々が続きます。独り言で述べている理由を定例会のたびに伝えます。しかし、Eさんの作業効率は一向に上がることがありません。すると次第にプロジェクトメンバーのEさんに対する風当たりも強くなっていきます。そしてEさんの独り言も増えていく悪循環……。

間違った窮余の策

　決定打は、それでも2カ月ほどEさんが屈辱と不安に耐え、周りの人も同じだけ独り言や作業内容に我慢した後、ある日の朝に起きました。

　前の日の夜、Eさんがリリースした修正が原因でした。とにかく作業効率が悪く、問題視していたマネージャは「簡単な修正なので明日の朝まででお願いします」と厳しく期限を切っていました。あるいは間に合わないのを理由にそろそろ対策を打とうと考えていたのかもしれません。

　彼も「PCの問題が多くて明日まで間に合わないかもしれない」と独り言で述べながら該当するPGを印刷し読み始めました（彼はまず、印刷してからPGを見る「机上デバッグ」をするようにしていました）。しかし、厳しくいい渡された期限までに終わる見込みは一向に立ちません。悩んだ末に彼が打った方法は、「エラー処理を修正し、問題のエラーを無視するようにした」というものでした。

　修正結果のチェックは二重にしていましたが、多くの人が簡単な修正と認識していたためにチェックの項目もそれほど多くなく、問題は正しく修正されたと認識され、リリースされてしまいました。またすべて修正を完全にチェックし直すにはリソースも不足し過ぎていました。

　こうして、そのプログラムはリリースされ、深夜稼働し……、はるか後続のバッチ処理で別の開発会社の担当者が早朝4時に起こされることとなりました。

図3 後続バッチでエラー

　プロジェクトは並行稼働の段階に来ており、事実上の本番稼働と同じレベルでテストや障害時の運用が行われていました。データも本番のものです。すでに、問題は非常に大きくなっていました。エラーを無視して素通しするように直してしまったために、不完全な勘定が発生し処理され、後続の機能でそれが処理できないものになってしまっていたのです。始発電車で全員が集められてリカバリー作業です。始発で早朝から集められたメンバーはすぐに修復作業に取り掛かりました。その中で責任範囲をまだ持たされていないEさんは事情も知らずに定時に来ます。

悲しい結末

　取りあえず、メールを読みながら周りの様子をうかがっています。毎朝行っている朝会の時間になっても誰も席を立ちません。そのうちに聞こえてくる会話の端々に自分への悪意ある言葉が多く含まれていることが分かってきます。大体事情は察したのでしょうか？それでも、あえてEさんは気付かないフリをして、リーダーに今日の作業を聞きに行きます。

「朝会は？」

「今日はいいです」

「……。私の作業は？」

「今日はいいです」

「……」

「じゃあほかの人を手伝いますね」

「そうしててください」

「……」

　所在なさげにメールやネットニュースを読むEさん。だんだんと最早、遠慮なく単なる悪口というような内容まで飛び交います。とうとういたたまれなくなったのでしょうか。彼は荷物を片付けていなくなってしまいました。

　結局彼はその後も来ず、後に文書で扱いが不当であったためにこのような事態に至ったことを伝えてきました。

　そのときに決裁者が象徴的な言葉を述べていました。「なぜ、すぐに切らなかったって？ 彼を切るにも、われわれは顧客に彼の2人月が意味のないものであったとは説明できない。人月でお金を計算しているこの業界では、払ってしまった工数に意味がなかったという説明はできないのだ」