マルチスキルで小さなチームを作るときに考えておくこと

フルスタックエンジニアとか実はとってもブラックなんじゃないかとおもうようになってからしばらく経つのですが、一方、小中規模のプロジェクトはビジネスの流れから相変わらず多いのも事実です。まぁ、最近は景気回復の一端からかアプリケーション開発プロジェクトではそこそこの規模のプロジェクトも増えてきたようですが、現実的にはそうでない方が圧倒的に多いのです。

お客さまから見たプロジェクトは大雑把に分別すると、プロジェクトマネジメントチームとアプリケーションチーム、インフラチームで構成します。大雑把ですからね。今風のインフラはクラウドを使うとかすればインフラは一見なくなっちゃいますが既存にオンプレのインフラがあればそれを維持管理するチームがいるでしょうからプロジェクトとしては１つの構成要素になるので忘れちゃいけないです。

プロジェクトの役割としての要素を契約時に押さえておくことはとても大切です。それが過去の経験からであってもとても大事。要素が増えるということは、インタフェースを持つ可能性のあるということです。それはコミュケーションにコストが掛かることを暗示しているし、意思決定のリスクの可能性も示しています。割と恣意的にコミュニケーションコストは考慮しないケースが多々見られますが、小さなチームであればあるほど、コミュニケーションコストはチームのリソースを侵食するので考慮しなくてはいけません。

その要素のアプリケーションチームでもインフラチームでも小規模案件ならメンバは数人のときがざらにあります。とは言え今日日のプロジェクトに適用する技術はアプリでもインフラでも多様です。その上、トラブればトラブル分だけ奥が深い。だから、ITSSでは職種が細分化されすぎたように感じるくらいです。

その適用技術も毎度使う技術もあればプロジェクトの特性から特殊技術を適用しないといけないときがあります。これが厄介に成るんですがそれはそれとしてもプロジェクトで必要なら調達できないとプロジェクトがキャリーできないので１つの大きな考慮点です。別の切り口でいうと、特殊技術だからこそ、人的リソースのリカバリが取りづらいのです。ここで出てくるのはトラックナンバに対する対処をチームとしてどうするかという判断です。リスクを受容するのか対策を打つのか。特殊技術の場合、サービスフィーは高く取れても人的リソースの層の厚さで危うさが変わってきます。

そうそう、チームの向かう方向性、プロジェクトの目的、到達すべき目標を共通の理解としておくことも欠かすことはできません。第一人が少人数ですから、５人のチームのうち２人が別のことを考えていたら４０％の作業は期待とは外れた結果として返って来る可能性があるからです。期待は勝手にするものではなく、期待どおりにコントロールするするものです。そのためにも同じ向きに顔を向くように、毎日チームで確認するという観点を地味に続ける必要があります。

チームの人数が少なければ少ないほど、仕事は小さく１つずつ渡す方が効率がいいです。どうせ長い作業期間のWBSをアサインしても手をつけるのはそのWBSの後続の作業が必要とする時期、つまり、締め日の直前なのですから。だったら、ちっちゃいWBSにして渡して確実に計画どおりに回収するほうが賢いです。タスクを渡す側も工夫が必要です。

小さなチームなのでコミュニケーションの濃度は高くなります。だから、チームで気持ちよく仕事ができるように最低限のルールは必要です。そしてそのルールを守ることと柔軟に変えていくことです。特に、ミーティングの開始時間などは規律として守ることを約束ましょう。