【51】デベロッパーに力を

　普通、ものごとはするよりも言う方が簡単です。そして、ソフトウェア・アーキテクトは、言ってばかりいることで悪名高い存在です。あなたの言葉がでたらめ（ベーパーウェアの主原料）にならないようにするためには、優れたデベロッパーチームが必要です。アーキテクトの役割は、通常は制約を設けることですが、支援者になるべきときもあります。職掌が許す限り、あなたは同僚のデベロッパーたちに力を与えるために手段を尽くすべきです。

　まず、デベロッパーには必要なツールが行き渡るようにしましょう。デベロッパーにツールを押し付けてはなりません。今すべき仕事のために適切なツールを慎重に選ぶようにすべきです。頭を使わない反復作業は、できる限り自動化します。また、最高級のマシンと太いネットワーク、仕事を進めるために必要なソフトウェア、データ、情報へのアクセスを自由に使えるようにするのも、価値ある投資です。

　デベロッパーに必要なスキルを身につけさせましょう。トレーニングが必要なら、受けてもらうようにします。本に投資し、テクノロジーについての積極的な議論を奨励します。デベロッパーのワークライフは実践的で地に足のついたものでなければなりませんが、アカデミックなところも必要です。予算があれば、チームを技術プレゼンテーションやコンファレンスに送り込みましょう。予算がない場合でも、技術的なメーリングリストに参加させ、市内の無料イベントを探すことです。

　また、可能な限り、デベロッパーの採用活動にも参加しましょう。学ぶことに意欲的で、技術を掘り下げて考えていることを示す「ひらめき」を感じさせるようなデベロッパーを探すのです（そして、チームプレイできることも大切ですが……）。活力のないチームからはビッグバンは起きません。

　設計の全体目標と摩擦を起こさない限り、デベロッパーには自分で判断させるようにしましょう。しかし、必要な場合は、制約を課することをためらってはなりません。これは、単に品質を保証するためでなく、デベロッパーの能力を引き上げるためでもあります。一貫性を確保するために標準を作るとともに、デベロッパーが解決しようとしている問題とあまり関係がない決定は減らしましょう。そのようなものには大した意味はありませんし、かえってトラブルを起こす原因になります。ソースファイルをどこで管理し、どのように取り出し、いつ新しいソースファイルを作るかといったことに関して明確なロードマップを作りましょう。これは、デベロッパーの時間節約につながります。

　最後に、デベロッパーを本質的ではない仕事から守りましょう。ペーパーワークやオフィス作業が多すぎると、オーバーヘッドがかかるばかりで、彼らの力を活かすことができません。アーキテクトは、普通は管理職ではありませんが、ソフトウェア開発に関わるプロセスには影響力を行使できます。どのようなプロセスを使うにしても、障害を減らせるようにデザインすることを心がけ、間違っても障害を増すことがないようにしましょう。