開発マネージャ(Development Manager)という役割は，とてもストレスの多いものかも知れません。"man in the middle(中間者)" として，あちらこちらから引っ張り回されます。マネージャ，ユーザ，営業，開発者，などなど ... 仕事がうまくできている時には，誰も気に掛けてくれません – すべてが順調で，ドラマもなく作業が進み，全員が望みのものを手に入れるだけです。でもうまくいかなければ，たとえ原因が何であろうとも，すべてあなたのせいになるのです。
開発マネージャとして成功を収める秘訣は，期待される内容を管理すること，そして早い段階であなたの役割を皆に理解してもらうことです。あなたとあなたを取り巻く人々が，開発マネージャとしてのあなたに何を期待するのか，意見を合わせておかなければなりません。
以前，開発マネージャの募集広告で，思わず首を傾げたくなるようなものを見たことがあります。そのひとつでは，たくさんのプログラム言語と開発環境について十分な知識を持っていることを条件にしていました。別の案件では，そのポジションの66%(なぜ2/3ではないのでしょう？)の作業はプログラミング，とありました。他にもPMO認定所有者を求めるものなど，そんな調子で延々と続いているのです。開発マネージャという役割が，ある意味で漠然としたものであることは事実でしょう。しかしこのような求人情報を見ると，募集を出している企業が開発マネージャの役割について本当に考えていないのではないか，という印象を受けてしまいます。雇用する企業にとっても，このような条件で雇用される側にとっても，これは不幸の元でしかありません。
開発マネージャであるあなたは，たくさんの責任を背負っていますが，もっとも重要なのは製品を出荷することです。あなたの目標は，成果をユーザあるいは市場に届けることであって，それに必要なことは，どんなことでも行います。そのためには，開発チームが可能な限り効率的に作業を行えることが必要になります。とりも直さずそれは，チームが短期的にも長期的にも明確な目標を持つことであり，チームの作業に障害となるものをすべて取り除くことなのです。初期のプロジェクトスコープから顧客サイトに製品を配備するまで，すべてのステップがあなたの責任です。可能な限り作業を委譲すると同時に，常に物事が希望通り進んでいるかをチェック可能であること，必要とあらばいつでも手を貸せる状態であること。開発マネージャたるあなたにはそれが可能ですし，そうするべきなのです。
プロジェクトのスコープ設定
開発マネージャとしてのあなたは，プロジェクトのスコープについて詳しく知っておく必要があります。所属する組織や外部グループとの協力方法によっては，これがあなたの主業務になるかも知れません。定常的に第三者からプロジェクトを受託しているのであれば，RFP(Request For Proposal/提案依頼書)に応じて，成果物件やタイムライン，予算 ... などを完備した提案を行う方法を知っておく必要があります。公式文書のシステムを持たない，社内プロジェクトのみを扱っている場合でも，プロジェクトにはすべてプロジェクトスコープ資料をまとめるように習慣付けておくべきです。これらの文書はプロジェクトの進行に合わせて更新し，常に有効なものでなければなりません。アジャイル開発を実践しているのであっても，それは同じことです。
間接経費プロジェクト
これはスコープ設定の一部ですが，独立した章にする価値があります。私は以前，予算やタイムラインを必要としない "間接経費(Over Head)" プロジェクトというものについて，誰かが話題にしているのを聞いたことがあります。そうではないのです！このような "間接経費" のプロジェクトがコストや成果物の面で目標を達成できなければ，スケジュールや他の作業のためのリソースを食いつぶして，結果的にチームを抑圧することになります。どのようなプロジェクトであれ，少なくとも内部的なコスト目標と，少なくとも１つの成果物が存在します。この２つに関しては，実現を約束するものすべてについて，他の利害関係者との交渉が可能なようにしておく必要があります。
人間関係の管理
忘れないでください，あなたは "man in the middle" なのです。どんな失敗があっても，たとえそれがあなたの関与する範囲を越えていたとしても，あなたの責任になるのです。ですから関係者とは，常にオープンで良好な関係を保っていなければなりません。
直属の上司はもちろんのこと，上司の報告先や同じレベルの人たちのことも知っておきましょう。あなたが管理するプロジェクトに利害関係を持つ他の人たちについても，同じように知っておかなければなりません。彼らを "メンバの一員" として常に最新の状況を把握するとともに，あなたのチームが行っていることを彼らが確認できるようにしておくことが大切です。
ユーザとの関係を扱うのは誰でしょう？それは上司と同じように，おそらくはあなたが認識しておくべき，もっとも重要な人物です。ユーザの期待や(顕在的あるいは潜在的な)不満に対処することが可能で，重要なユーザとのコンタクトを提供してくれる人です。その一方で彼らは，あなたの知らないところでユーザの約束を取り付けたり，必要もないバグレポートをポストしたり，非現実的なタイムラインの設定を迫ったりして，あなたをひどい目に遭わせるかも知れません。
チームメンバについても知っておきましょう。彼らは入社何年目で，それぞれの長所や短所は何でしょうか？相性がいいのは誰と誰か，どれくらい忙しいのか，さらには誕生日や記念日など，些細なことも ... このような小さな知識の積み重ねが，コミュニティ意識を育むのです。
マネージャを満足させておくためには，マネージャがチームの作業内容を知り，進捗を確認できるようにしておく必要があります。コミュニケーションと可視性が，これを実現する上での要点です。私は日頃からあらゆる種類のツールを使って，マネージャを仲間に引き込み，多くのことを知ってもらうようにしています。プログラムや掲示板，ホワイトボード，その他あなたが思いつくすべてのツールを駆使して，彼らに最新情報を伝えるようにしてください。
あなたやチームが挑んでいるチャレンジを関係者が理解してくれれば，彼らに非現実的な期待を掛けられることも少なくなるはずです。ただし少なくなるのであって，なくなるのではありません。中には，物事がうまくいかない理由をまったく理解しないマネージャもいるでしょう。そんな時は，他の仕事を探し始めた方がいいかも知れません。
プロジェクト計画
大規模なプロジェクトに関与している場合を除けば，通常はプロジェクトマネージャを専任の業務にする必要はありません。中小規模のプロジェクトやアジャイル方法論を採用している場合には，誰でもその役割や責任を負うことができます。ただし，ひとつ言えるのは，開発マネージャは CPM(Certified Project Manager) ではない，ということです。従来的なプロジェクト管理とアジャイル開発に関する議論はさておき，開発マネージャとプロジェクトマネージャの間には，現在も脈々と続く利害の対立が存在しています。開発マネージャとしての業務が，すべてをできる限り早く完了することであるのに対して，プロジェクトマネージャの仕事は，言わば何をいつ行えるかを示すことです。この２つの視点のバランスを取るように注意しなければなりません。経験豊富なプロジェクトマネージャや，あるいは スクラム マスタを必要とするような大規模プロジェクトであれば，チームにはプロジェクトマネージャあるいはスクラムマスタが必要です。自分でその役割を果たそうとしてはいけません。しかしながら，ウォータフォールあるいはアジャイルのいずれであっても実行すべきことのひとつは，プロジェクト計画を継続的に更新し，進捗状況を反映して，その有効性を保つことです。
プロセス管理
開発マネージャの仕事で，もうひとつの重要な部分がこれです。適用する方法論がアジャイルでもウォーターフォールであっても，プロセスをしっかりと把握し，その軌道を維持することが必要です。あなたには投資への対価が求められていて，それに関与するものはすべて最優先事項であることを忘れてはなりません。
開発プロセスとして何を選択しますか？それはどの程度，規則的なものでしょうか？それが "アジャイル" と呼ばれるものであるなら，本当にアジャイルなのかを確認してください (手近なところにアジャイル憲章のポスターを貼り出して，その原則に従うように心掛けるとよいでしょう)。プロセスを向上させるには，どうしたらよいでしょう？完璧なシステムなど存在しません。常にプロセスの改善を求めましょう。たちの悪いバグの発生に関するRCA(Root Cause Analysis/根本原因分析)の事例は数多くあります。しかし多くの場合のそれは，設計不良やお粗末なコード，あるいはユーザ要件の理解不足のまま製品の出荷を許したという，プロセスの問題なのです。
誰かに任せるのもよいのですが，成果が確認できるまでフォローすることが大切です。アイデアが素晴らしかったのに，実行時に誰もチェックしなかったために失敗した，という例は珍しくありません。私もかつて，必要なものはすべて揃っていたにも関わらず，その実行が不適切だったために大失敗したプロジェクトを引き継いだことがあります。
最後に必要なのは，プロジェクトの状態をさまざまな関係者に報告することです。報告する内容は，しっかりした基準に基づくものでなければなりません。進捗状況を測定し，報告対象とする人々にとって意味のある形で要約する方法を用意しておきましょう。この種の報告書は，組織によって毎日，毎週，あるいは必要時ベースなどで作成されるものです。報告書の頻度や形式，内容について，明確にしておいてください。報告対象者は誰であって，どのレベルの報告書を希望しているのかを意識して，そのレベルを目標としましょう。これらはすべて，報告書をクリアで正確，かつ読みすいものにするためのものです。そうすれば報告書を誤解する人の数も減少するでしょう。ただしなくなる訳ではありません。自己弁護と取られることなく，明確な説明を行うように心掛けましょう。報告書を読む人たちは多忙ですから，表面的な部分だけを見て，自分たちに都合よく解釈しないとも限りません。
テクノロジ
これも求人広告でよく見掛ける分野のひとつです。いくつかの企業では，特定の分野での深い知識を備えた開発マネージャを求めています。しかし開発マネージャは，技術的なグルではありません！そのような役は，先輩や開発リーダに任せておきましょう。現在ある技術に習熟することが必要です。新しい，あるいは今後現れるであろう技術にも注意を払う必要はありますが，自分自身がエキスパートになる必要はありません。時間の浪費ですし，他のタスクに注ぐべき注意をそらすことにもなります。チームで使用しているツールについては，それが効率的に利用されているか，チーム内にギャップが生じていないかを知るために十分な知識を持つ必要があります。ただしチーム内の "頼られ役" であってはなりません。その役割が魅力的なものであればこそ，あなた自身は手を引いて，チームの上級者に委ねるべきなのです。
開発
これも同じです。習熟する必要はあっても，エキスパートになる必要はありません。優れたプログラマは最高のプログラミングはできても，マネージャとしては劣っているのが常です。よいコードと悪いコードを見分けられる必要はありますが，ここはあなたのチームリーダを信用すべきです。もしプロジェクトが正念場であれば，その渦中に飛び込んで開発タスクを引き受けることも必要でしょう。しかしながら，その場合も大局的な見地を保つこと，プロジェクトの遂行に注力することを忘れないでください。プログラミングに埋もれて日々を過ごし，他の仕事を忘れてしまう訳にはいかないのです。
自動テスト
私は自動テストを，品質保証とは切り離して見ています。職務的に異なるものだと思うからです。これらの仕事は通常 QAチームのメンバにアサインされますが，これらを別の作業と考えるのには理由があります。自動テストはユニットテストやテストスクリプトなどによって実施されます。対する品質保証はバグではなく，ルック＆フィールの一貫性やパフォーマンス，ユーザインターフェースあるいはデザイン上の問題を人の手で検査するものです (Testing vs Checking を参照してください)。
自動テストは，99%が時間の無駄と思えるようなものであっても，残る1%にその意義がある，というものがあることを証明するひとつの例です。システムの１カ所に生じた問題が他の部分に影響するという，Jell-O コードルールを思い出してください。私はかって経験した変更ケースでは，影響は極めて限定的なものだと全員が信じていました。フェールした自動テストもわずか12個でした。しかし現実には，自動テストでカバーされていたのはコードの90%でした。運のよいことに，残り10%のコードには新たなバグがなかったという，単にそれだけのことだったのです。
開発マネージャとしてのあなたは，テストコードのカバレッジがどの程度かを把握しておく必要があります。ユニットテストでカバーされているのは，コードベースのどの程度なのか，自動テストではどうか，それを拡大あるいは縮小することに価値はあるか？優秀なQAリーダであれば，これらの質問に答えてくれるでしょう。しかしこれらの値を少なくとも推定するには，システムが適切に機能していなければなりません。コードカバレッジ値が減少するのはほとんど避けられないことですし，当面はこれを容認することも可能でしょう。しかしQAチームのキャッチアップを待つために，開発ペースを落とさなければならない場合もあります。テストコードカバレッジに対する注意の欠如は，バグのあるコードの出荷という結果に結び付きます。
品質保証
"スモークテスト" と呼ばれるものがありますが，正式なQAプロセスのお粗末な代用品でしかないと思います。仕様からの乖離やパフォーマンス低下などは，すべてQAでキャッチするべきものですから，これは矛盾しています。これらのテストを確実に実施するのは開発マネージャたるあなたの任務のひとつです。積極的に参画しなければなりません。QAチームを開発側に引き込むことで，次には何がパイプを流れてくるのか，彼らに分かるようになります。私は開発者用のQAチケットを開発チケットとは別に用意して，開発チケットと同時に，担当者がそちらにもアサインされるようにしています。このようにコード修正のリンクを取ることによって，コーディングのノートとは別の場所に，テストに関するノートを記録することができるようになるのです。
QAテストはさまざまな原因でフェールします。テストの問題，コード変更，仕様の誤解，ネットワークやシステムエラーなどです。フェールの根本原因に到達するためには，開発者とQAチームが共同で作業しなければなりません。QA担当者が開発チームに所属しているならば，これはさほど難しいことではありません。しかしQAチームに独自のマネージャがいる体制では，そのマネージャとの調整が必要です。
リリース管理
プロジェクトが複雑な場合，出荷リリース関連の作業を取りまとめて別のプロジェクトにすることがあります。簡単なシステムであれば，ビルドと実行ファイルのコピー程度のことで済むかも知れません。しかし高度なシステムの場合には，多数のパッケージ(実行ファイル，アセンブリ，JarあるいはDLLファイル)のビルドに加えて，データベーススクリプトや，さらにはサードパーティ製アプリケーションの追加が必要な場合もあります。すべてのコンポーネントの適切なバージョンを揃えるのは難しく，時間の掛かる作業だからです。非常に複雑なプロジェクトであれば，バージョン管理を行うビルドマスタが役割として必要になるかも知れません。いずれにしても，コンポーネントや次期リリースに必要なバージョンについて記載する共通領域を用意しておいて，すべてのメンバが必要に応じてアクセスないしアップデート可能にしておくことが必要です。
コードアーカイブへのリリースマーク，インストーラの用意とテスト，リリースノートの作成と配布といった作業を実施して，適切な人たちが新リリースを利用できるようにしておくことも必要なことです (そして旧リリースについては，現行リリースとの混乱を生じないように，少なくとも名称の変更はしておきましょう)。
配布
リリースの配布はリリース管理作業の一部と見なされる場合もありますが，別プロジェクトとして扱うべきでしょう。
ベータテスト参加サイトのある場合，この作業はさらに重要です。 参加サイトに新リリースの受け入れ準備をしてもらうのは，プロジェクト側の責任です。誰とコンタクトを取るべきか，ベータテスタは新リリースの受け入れ準備ができているか，変更点の説明はなされているか，問題点はどのような方法で報告するのか。レポートの報酬はどうか。ベータテストの期間は。最少のダウンタイムでリリースをロールバックする準備はできているか。
ベータが完了したなら，ユーザの受け入れは準備できているでしょうか。以上すべての質問に対して，リリースがロールアウトされる前に，すべてのユーザに返答してもらう必要があｒます。
管理機能
これは誰もが敬遠する仕事のひとつですが，開発マネージャの業務の中で，もっとも困難な決断のいくつかが行われる部分でもあります。予算，雇用と解雇，リソースとスペースの競合，報告書の作成，会計など，これらはすべて学校では教えてくれず，経験を積む上で幸運ならば会得できた，という類いのものです。ここでもっとも重要なこと，それは自分が何を知らないかを知ることです！これまで多くの優れたマネージャが，この点で行き詰まっているのを見てきました。自分が知っていると思うことを続けることによって，自分の所属する企業や自分自身に，数多くの法的な問題をもたらすことにもなりかねません。自分の行っていることに少しでも疑問を持っているのなら，調査を行って，支援を求めて，知識を備えた人を探すことです。ここでの過ちは，企業に対する訴訟につながる可能性があります。それがあなたの責任になるという点については，どれほど強調したとしても十分とは言えません。
要員配置
これは管理作業の一部ですが，ひとつの章を割り当てる価値のあるものです。すべてのチームメンバを適材適所に配置するというのは実現不可能な理想ですが，だからといってそのような努力が無駄という訳ではありません。適当なレベルの要員を得るのは難しいことです。特に大規模なチームではコストも掛かりますし，小規模チームに比べると効果面でも劣ります。しかしながら，すべての要員が100%の能力で作業することを求めるべきではありません。突然生じる過大な要求に対して，プロジェクトをリスクにさらすことなく応じられるためには，チームにある程度の余裕を認めることが必要です。
家庭の問題などの理由でメンバが休暇を求めても，気に掛けてはいけません。私自身は，チームメンバが効率的に仕事をしている限り，このような休暇についての記録は取らないようにしています。休暇率が(妥当な範囲内で)高いチームが，ほとんど皆勤に近いチームよりも効率的であることは，これまでにも数多くの研究が示しています。担当者がいないときのチームメンバーは、システムのさまざまな部分を学ぶことを余儀なくされているため，というのがその理由です。 ですから，個人的な理由によるオフ時間を容認すれば，チームをより効率的にすることができるのです。
離職ということも発生するでしょうが，これも悪いことではありません。私は若い開発者に対して，５年周期で会社を移るべきだと話しています。そうすることでさまざまな開発環境や技術，さらには開発プロセスに接することができるからです。これは私が履歴書を見るときに期待していることでもあります。ですから私のチームのメンバにも転職を勧めているのです。これには計画性が必要です。プロジェクトあるいはシステムのある部分を知っている唯一の人だからという理由で，誰かを引き留めようとしてはいけません。 情報や知識はチーム全体に広めるように努めて，１人ないし２人の主要人物に固執しないことです。
開発マネージャであればいつかは，メンバの解雇という事態に直面することでしょう。財政的な理由(チームの縮小)であれ，当人の能力不足であれ，いつでもそれが可能なように，会社の方針や手続きについて知っておく必要があります。自分自身の法的責任についても認識しておくべきでしょう。カナダでは，理由のない解雇には法律上の解雇要件が必要です。その他に，所得を喪失することなく次の職を得るための"事前通知" 期間が，一般的な権利として存在しています。単に法的要件のみが充足されている場合には，不当解雇の訴訟につながる可能性があります。最初からその人に受け入れられそうな条件を揃えて提示することが，当人が弁護士の元に走るのを避けるために，もっとも望ましい方法でしょう。再雇用を行う場合のことを考えれば，人を大切にしているという評価を損なうことも回避できます。
結論
長々としたリストですが，どれについてもエキスパートになる必要はありませんし，そんな人もいないでしょう。他にもっとやりたいことがあるのなら，慌てて飛びつくような必要のあるものでもありません。
開発マネージャになる最善の方法として私が考えるのは，製造業の世界において，かつて耳にしたBata Shoesに関する物語です。Tomaz Bata氏は，現在はチェコ共和国にある最初の工場で，貨物エレベータの中に自分のオフィスを持っていました。あるフロアで製造上の問題が発生した時には，それがどこであっても，氏はオフィスごと赴くことができたのです。そして問題が解決するまでそこに留まって，マイクロマネージメントを実践しました。事が終われば邪魔にならないようにメインフロアまで移動して，生産現場に関わることなく，会社経営に専念することができたのです。マイクロマネージも時には必要ですが，それ以外の時間は現場を離れて，チーム自体が活動できるようにしましょう。あなたには他にも，やるべきことがたくさんあるのですから。
著者について
カナダのトロントを本拠地とする Robert McCabe 氏は開発者やチームリーダ，開発マネージャとして，ソフトウェア産業に30年以上従事しています。コンサルタントとしての氏は，プロセスとチームの有効性を改善することによって数多くのプロジェクトを救済するとともに，失敗プロジェクトを軌道に戻す支援をしています。カナダ，米国，さらに海外で広く活動し，金融や保険，マルチメディア，地理情報，放送，医療，行政など多数の分野で豊富な経験を持ち，現在も新たな機会を模索しています。Robert McCabes氏へのコンタクトはこちら。