必要性の訴求を考えて話をしていただきたい。雑な説明から発生した活動は、残念な結果となる場合が多い。それでは、技術者が成功体験を獲得できず、トラウマや後ろ向きになる場合もある。それは、組織の技術力向上の芽をつぶすことと同じである。
集中できる環境を作る
本人の自主性を尊重し、テーマだけを伝え「後はやりたいようにやっていい。任せた」としていないだろうか。必要なモノはスペックの良いPCだけと考えていないだろうか。
これは丸投げでしかなく、環境も作っておらず、管理を放棄している。「自主性を尊重する」というのは言い訳である。要員が集中して仕事に取り組めるように管理職が状況を確認して、先導しなければならない。
「フルスタックエンジニアとしての成長に期待している」といって、役割を設定しても、それだけではどうしようもない。既存の保守や運用を担当している場合には、仕事が増えただけと受け止められ、フルスタックの道を進む速度が一向に上がらない。また、フルスタックの意味を拡大して、複数のシステムをお守りさせようと考えてはいけない。フルスタックは、なんでもかんでも都合良く解決できる魔法ではないからだ。
フルスタックではシステムの頭の先からつま先までのすべてをカバーする。その実現には、雑音を払拭し、集中できる環境を管理職が作らなければ、スムーズな育成は達成できない。このため、1つのプロジェクトに専任させるべきである。
しかし、できる人には仕事が集まりがちであり、相談事やその人にしかできない仕事もある。複数のシステムを担当している場合もある。これらの現状を整理し、どうすれば集中できる環境を作れるかを考えるのは管理職の仕事である。
育成する人がどのような作業を持っているか、問い合わせにどのような事項があるか、自身しかできない仕事にどういった作業があるのか。これらをヒアリングして、管理職が文書化し、整理の上、集中できる時間の作り方を一緒に考えなければならない。
「空き時間の作り方を考えてこい」と投げて、プランを評価するだけにしてはいけない。時間をかけて、どうしていくべきかを一緒に考えるべきである。そうすると、考える過程で本質的に何に時間をとられているかを詳細に把握でき、組織的な問題も浮き彫りになる。なにより共同での検討は信頼関係が増す。
また、目の前の作業と先の未来の検討を混ぜてもいけない。現在進行中の担当しているプロジェクトの他に、中期計画のセキュリティ施策や品質向上施策、PC刷新計画など全員が分担して、それぞれが検討すべき事項を振ってはいけない。
これでは、言っていることとやっていることが違うと指摘される。例え、先の未来を考えられる適任者だとしても、その役目を割り当ててはいけない。管理職はせいぜいオブザーバーレベルにとどめるべきである。
挫折しないように管理職がチェックする
フルスタックを目指して、全方位を担当させるにしても、できるところから取りかかるといったやり方ではいけない。それでは、一部では成果が出ても、期日内にシステムができあがらない可能性が高い。このため、担当者が作業計画をキチンと考えて、予定と実績を管理職がチェックする。このようなベースラインがないと後でうまくいったがどうかの評価ができないからだ。
しかし、そうはいっても、計画段階では構築するモノへの要求の変化が考えられるし、今までに実施したことがない作業に、どれぐらいの時間がかかるかは分からないと言われもする。そうであれば、期日を設けて、その期日での達成度合いを設定する。期日は週次で設定するぐらいでいい。
全部が全部の先がどうなるかはみえないにせよ、大体これぐらいの時間があれば、何合目までいけるだろうという想定はつくはずである。個人のパーソナリティを考えて、そもそもチャレンジングな計画を策定しがちか、保守的なスケジュールを策定しがちかを考慮し、スケジュールに余裕を持たせるか、ストレッチ的な目標を設定するかも考慮する。
いざ、プロジェクトを進めるが、初動時にも注意点がある。フルスタック的に全方位を担当してもらう場合には、実施する作業が多岐に渡る。このため、検討するべき事項の全方位を一度に考えてしまい、その関連性を気にしてアウトプットがなかなか出せない場合がある。そして、計画を無視してさまざまな検討を1日の内に詰め込んでいきアウトプットが全く出なくなる。極論では「明日、何をしたらいいのか自分でもわからない」といった状況に陥る。
やらなければいけないタスクが多いと考えて、落ち着かず、ドキュメントを色々と書いてはみるが、抽象的にしか書けず、悩んでうまくいかないパターンである。この状況を改善するために、管理職が計画に立ち返り、「後回しにしても良い作業は後回し。その検討は後回しでも問題ない」と言い切ったり、検討のタスクを一旦引き取って担当者を楽にしたりする必要がある。
