ブログ

こんにちは。ryuzeeです。

先日、スキルマップ作成のすすめという記事を書きましたが、それに関してオンライン上で色々議論になりました。 せっかくですので、その内容を共有します。

まず、おさらいですが、スキルマップとは以下のようなものです。横軸にプロジェクトで必要となる技術、縦軸に名前を入れます。 それぞれの記号は、★：エース、◎：得意、○：一人でできる、△：助けがあればできる、空欄：できない、・：今後習得したい、というのを指していますがこれはチーム次第です。 このスキルマップを作ることで、「スキルの見える化」「リスクの見える化」「学習速度の向上」が期待できます。

さて、議論になったのは、以下の話です。

チームに足りないスキルセットがあることがわかって、でも期間的にそれを埋めてる余裕がない場合どうする？
スキルの話なのかヒトの話なのか。ジャッジメントしなければならないのは誰なのか。

端的にいえば、スキルマップを作って足りないところは分かったけど、それでどうやって対処するのか？ということです。順番に考えていきます。なお文脈として開発プロセスにはスクラムを採用しています。

足りないスキルのクリティカルさ度合いを確認する

当然のことながら何かの判断をする場合には、現状の課題と影響範囲の認識が必要です。 つまり、そのスキルがないと「プロジェクトつまりはビジネスにとって大きなリスクがある」のかを把握します。

乱暴な例を挙げると、「既にリリース日がビジネス上の理由で決まっているのに、集められたメンバーに必要なスキルがなく、開始時点でそのスキル習得にかかる時間が予測できず、おおよその計画すら立てられないため、期日を守れないリスクが高い」といったものです。

リスクが高ければ手当が必要ですし、リスクが低いのであればそれを受け入れるという選択をすることもあります。

その判断なしに、単に足りないスキルは身に付ければ良い、と考えてしまうと出だしで躓く可能性もあります。

これが一方で、「プロジェクトの頭1か月は新しいスキルの習得にフルに時間を使える」状況で、一ヶ月後に再評価してからでも対策が間に合うというのであれば、クリティカル度合いは低下しています。もしくは、メンバーが保持している他のスキルを使うことで対処することができるのであれば、それもクリティカル度合いは低下しています。例えば「今回はGo言語でやってみようと思ったけど、やはりみんなが慣れているRubyでやろう」みたいな感じです。

足りないスキルが代替不能でクリティカルならどうするか？

それが判明しているなら対処するしかありません。

もしあなたがスクラムマスターであれば、チームのImpediments(妨害事項)を管理し解決する役目を背負っているので、プロダクトオーナーやステークホルダー、外部のマネージャーなどなど、その問題を解決できる力を持っている人と一緒に解決にあたる必要があります。この時にチーム自体はリスクに気づいていない場合は、チームを交えてオープンな議論をしてみると良いでしょう。その時、チームのメンバーが「正直に思っていることを言っても安心(人事評価などでごちゃごちゃ言われない)」をいう安心感を持てることが重要で、それはスクラムマスターの腕の見せ所でもあります。

もしあなたが単なるチームの一員だった場合、その問題を声を大にして表に出すことが必要です。 時には、スクラムマスターがだらしなくてまともなアクションが取られない可能性もありますが、自分たちが約束できないものを先に進めることは誠実ではありません。 ちなみにスクラムマスターがだらしない場合、チームの総意としてスクラムマスターをクビにして構いません。

なお、スクラムマスターが手を打とうとした時に、外部の第三者(特にマネージャーとかが多い)が、「人もいないし、君たちなら学習すれば大丈夫」という根拠のないことを言ってくる可能性がありますが、リスクがあるから手を打とうとしているので、問題の先送りは止めましょう。

今回の質問について言えば、「必要なスキルが何かで代替可能ならそちらを使う」「人を入れ替える」「期間を延ばす」の3択です。制約として期間は変えられなそうに見えるので、前者2つのどちらかになると思います。

足りないスキルが代替可能/またはクリティカルではないなら？

この場合はリスクを受け入れて進めば良いのですが、そこを起点にして別の問題が発生する、見落としていたインパクトがあってそれが顕在化するという可能性は否定できないので、ふりかえりなどのイベントを使ったり、スプリントごとの成果を見て判断していきましょう。

今回の質問からのもう1つの示唆

ここまでスキルは技術に限定しませんでした。それは「自分たちの仕事の進め方」にも当てはまるからです。

したがって、「今回のプロジェクトは時間がないし要件はなかなか決まらないので、初めてのアジャイル開発に挑戦してみよう」というのがかなり大変な選択であるということです。 見よう見まねで一発目をやるのは避けて、外部から識者を招聘したり、スケジュールを延ばしたり、自分たちがいつもやっているやり方でやったりといったことを初期の段階で冷静に判断するようにすることをおすすめします。