エンジニアからみるマネジメント基礎 - 第2回 仕事の管理
では前回に引き続き、以下の全７回のうちの第2回目になります。
- 管理の基礎
- 仕事の管理 ← 今回はここ
- 改善と問題解決
- 人間行動の理解
- 部下の育成
- よい職場つくり
- 管理者の自己啓発
第2回 仕事の管理
管理者の仕事は「仕事と人を上手に結び付けること」である。
2.1 管理の5機能
こちらの図が管理の5機能（マネジメントサイクル）になります。
- 計画
目標を設定し、それを達成するための段取りを決めること
- 組織化
目標を達成するためにヒト・モノ・カネなどの資源を効果的に編成すること
- 指令
目標や計画に向けて人々に行動を起こさせること
- 統制
活動の過程や結果がはじめの計画通りに行っているかどうかを検討し、必要なら修正行動をとること
- 調整
これらの機能が円滑に動くように関係者に働きかけ、調和と均衡を保つこと
上記の5機能を以下で１つづつまとめて、考察していきます。
2.2 計画
目標を設定し、それを達成するための段取りを決めること。言い換えれば、管理者が将来とるべき行動コースを現在決めること。
2.2.1 計画の重要性
重要な3点がある。１つは明確な目的に沿っているかという合目的性、２つめは計画そのものが将来の仕事の基準になっているという基準性、さらに３つめは計画の内容が将来様々な範囲に影響を及ぼすという意味での関連性である。
エンジニアマネージャーとして
合目的性。１つ１つの実装予定機能がなぜ必要なのかをはっきりさせなければいけないです。営業から言われたから、競合サービスが実装しているからなどは、理由になりません。基本的に、全ての機能は利用者にメリットを提供するためにあるのですから、そのメリットが明示されている必要がります。これが明示されていない場合、実装された機能が利用者にとって「なんか違う」ということになりかねません。利用者がほしいのは、機能ではなくて、機能がもたらすメリットなのですから。
基準性。アジャイルとしては、Acceptance Criteria（受け入れ基準）が該当すると思います。何を持ってして完成とするのかという点ですね。テストケースやシナリオが通っていることなどがよく用いられます。これを決めておかないと、「完成」の定義がバラバラになってしまいます。
関連性。1人で開発を完了できるものもあれば、他チームとの連携がないと開発完了できないこともよくあります。特にインターフェースが絡んでくると特にです。この種類の開発は、開発をスタートする計画の段階から、他チームに話を付けておいて、協力者の工数も予め確保しないといけません。
2.2.2 計画の種類
中期経営計画のような、大きな範囲のものから、作業計画のような狭い範囲のものまで様々な計画の種類が存在します。
いずれも「何のためにたてる計画か」という目的の違いが計画の範囲や時間の長さ、中身を規定しているのです。
エンジニアマネージャーとして
アジャイル開発している場合には、スプリントが短期間の計画となると思います。これもバックログから漫然とチケットを持ってくるのではなく、「このスプリントは何を実現するためにするのか」という目的を持ちながらチケットを選定すれば、プロダクトオーナーには「このスプリントでは○○のメリットが顧客に提供できるようになりました」と説明できるのです。
「OAuth対応」というチケットが終わりましたではなく「クライアントが安全に弊社のAPIに接続できるようになりました」というのが伝えるべきメリットであり目的です。
2.2.3 計画の設定要素
計画の設定要素は数のようにおおよそ４つである。
- 目的・目標
- 現状分析
- 方針
- 実施計画
1. 目的・目標
前述したように計画をたてる際には、まず目的・目標が明確に設定されなければならない。目的・目標にもいろいろな考え方がある。例えば、「究極の目的」「理想とする目的」「当面の目標」「ターゲット」というように分類されることもある。しかしこれらも管理者の立場や役割などによって変わってくる。上位者にとっては「当面の目標」であっても下位の立場からすれば「理想とする目標」になる場合もある。ここでいうところの目的・目標とは「計画を実行することによって実現したい状態を具体的に示す」ことである。
目的・目標は次の要件を備えていることが必要である。
- 期限が設定されていること
- 具体的であること
- 達成可能であること
- 挑戦的であること
エンジニアマネージャーとして
開発においては、この目標をどれだけ具体的に建てられるかが大事です。またその目標は本番環境における目標でなければいけません。
いくら開発環境上で機能が動いても、本番環境にリリースして使えなければ意味がありません。またセキュリティなどの非機能要件を満たしていなければ、本番運用可能とは言えません。マネージャーとしては本番環境で運用されている「理想の状態」（可用性や品質などの非機能要件も含めて）をまず描き、そこに向かっていくための実施計画を建てる必要があります。そしてその考えられた理想の状態をソースコードに落とし込むのが実施計画となります。インフラですらソースコードに落とせる時代です。全部Gitに上げましょう。
2. 現状分析
計画にあたっては現状を事実に基づいて把握・分析することが需要である。現状分析にあたっては分析の目安（指標）を具体的に知る必要がある。営業部門であれば、売上や粗利、市場占有率など色々な数字がある。製造現場であれば、納期・原価・安全・品質などが重要な指標になるだろう。
エンジニアマネージャーとして
プロダクトのマーケットにおけるポジションや、プロダクトの売上予測は、エンジニアマネージャー1人で分析しなくてもいいでしょう。マーケティング担当の方を巻き込んで一緒に考えましょう。餅は餅屋です。
ですが、プロダクトに関われる開発者の人数やスキル、機能の拡張性、既存バグの深刻さ、負の遺産などエンジニアでなければ分析できない点もありますし、それをプロダクトオーナーに説明するのも管理者の役割です。現状の分析をしなければ、関係者に説得力ある優先順位の説明ができません。
3. 方針
目的や目標を達成する上での方向づけと大まかな枠組み・考え方を定めるものである。方針が明確に示されることによって、部下が自主的な判断で仕事を行ったとしても、整合性が保たれるのである。
4. 実施計画
目的・目標に達するまでの具体的な対策であり、目的・目標達成のために必要な一連の行動手順に順位をつけて（手順計画）、時系列的にしたもの（日程計画）である。
エンジニアマネージャーとして
ここまで来たら、ガントチャートでも引きましょう。大体いつまでに何を実現させるのかです。正直計画するのが嫌いなエンジニアも多いと思います。私もあまり好きではありません。気の向くままに開発をするのが好きです。ですが、組織として動く以上は計画を立てなければなりません。どの程度の金と時間をかけて、何を作るのかを経営層と握っておく必要があるのです。夢を語るだけで、計画がなければ同意を得るのは無理でしょう。
2.2.4 計画立案のステップ
科学的接近の態度による計画立案のステップは以下のようになる
- 目的を明らかにする
- 事実をつかむ
- 事実について考える
- 案を立てる
- 計画を決める
2.3 組織化（割当）
組織化（割当）とは「目標を達成するために人・物・金などの資源を効果的に編成すること」である。人間と仕事を結び付けることを組織化（割当）という。
2.3.1 割当の際に考慮するべき条件
1. 仕事の条件
仕事が要求する条件。仕事の種類・性格・内容・基準などの他に、仕事が要求する熟練度・作業量・その他資格要件など。またその仕事の重要性・緊急性・将来性なども重要な条件となる。
2.3.2 割当の留意点
1. 必要な職務はもらさず特定個人に割り当てること
2. 同一個人への職務割当は、具体的で同種類・同目的のものであること
3. 部下同士間の職務を不用意に重複させないこと（責任範囲を明確にすること）
4. 割り当てた職務の量は適量であること
以上は、「第1回 管理の基礎 合理的職務割当」で述べたことと同じであるが、部下は与えられた仕事の内容により、やる気を出したり能力を伸ばしたりするし、逆のこともある。合理性を尊重すると同時に部下を育成という観点からも配慮が必要である。
5. 部下の能力をややオーバーした職務を与えること
6. その職務に挑戦し、達成する過程で充実感や能力向上の機会がもているようなまとまりのある職務を与えること
エンジニアマネージャーとして
第1回でも述べたが、難しいからといって新人にアサインしなければ、永遠に新人は成長しないのである。マネージャーとしては、もし新規案件で新人にチャレンジさせられる余地があるなら迷わずアサインしてみましょう。一方でベテランにもキャパオーバーの仕事をアサインすることを忘れないようにしましょう。ベテランだって成長したいのですから。
一方で成長より安定を求めるベテランがいるのもまた事実です。その場合は、ポジションに見合っただけのアサインを行い、新人の育成に時間を費やしてもらうのもいいと思います。給料より成果が高いのでしたら問題ないでしょう。ただ、成長なしに将来彼らに仕事があるかどうかは市場が決めることになると思います。
2.4 指令
目標や計画に向けて人々に行動を起こさせること
2.4.1 指令を与えるときの留意点
- 目的を納得させる
- 目標を明示する
- 正確に伝える
- 分かりやすく伝える
- やる気を起こさせる
2.4.2 指令と意欲づけ
指令の与え方にはいろいろあり、それによって部下の自発性や意欲づけのあり方が違ってくる。
1. 命令（いいつける）
部下は原則として、提案したり自分の判断を加えることは許されない。
例）このバグを明日までに直しておきなさい
2. 依頼（たのむ）
部下に多少の自由裁量の余地を与える場合
例）1つAPI追加してくれないかな。仕様は呼び出し側と相談して決めてください。
3. 相談（はかる）
管理者と部下が同一の基盤にたつ。部下の自主性を促したり、強い責任感をもたせる。
例）データベースはMySQLを選定しようと思うのだが、君はどう思うかね
4. 暗示（ほのめかす）
部下にどのような仕事をしてもらいたいかをヒントで示し、部下に自発的に行ってもらう。
例）うちも自動テストやってみたいな
5. 募集（つのる）
部下の自主性を求めるものである。
例）オンプレからクラウドに移行できるか誰か検証してくれないかな
エンジニアマネージャーとして
マネージャーもまた、その上から指令が降りてくることもあるでしょうが、その指令の種類によって、どのような気持ちになるかは部下と同じだと思います。うまく利用して部下のやる気をあげていきましょう。
2.5 統制
活動の過程や結果がはじめの計画通りにいっているかどうかを検討し、必要ならば修正行動をとること
2.5.1 基準による統制
人が人を主観的に統制するのではなく、基準（目標・計画・予算など）が人間活動を統制することであることを忘れてはならない。そのためには計画の段階からどのような基準で、どのように統制するのかを考えておくことが大事になってくる。
管理者が計画の段階で仕事の量・質・時間・方法などについてはっきりと部下に示し、部下との間で妥当なものとして相互に了解されたものが統制の基準となるのである。
エンジニアマネージャーとして
バグ修正は基準がはっきりとしているが、機能追加などは基準があいまいになることが多い。あらかじめどこまでが範囲なのかをマネージャーは部下と合意しておく必要がある。あいまいな機能追加も、小チケットに分解することで基準を1つづつ明確にできることもあるので、是非活用願いたい。
2.5.2 計画とのズレの測定と評価
測定するための簡単なものさしを用意するのと同時に、部下からの報告がズレを測定・評価する重要な手段となる。
エンジニアマネージャーとして
このチケットをいつまでに終わらすなどがわかりやすいズレの測定であるが、あまり大きく長期にわたるチケットだと本当に期日までにDoneとなるかどうかは怪しいものである。最後に蓋を開けたら出来ていませんでは困るので、せめてチケットを細分化して長くても5日以内では終わるチケットにしましょう。理想は1日で終わられられるチケットである。
2.5.3 望ましい統制のあり方〜自己統制
管理者が部下を統制する前に、部下自らが自分の仕事の進行度合いや結果を測定・評価することによって差異（ズレ）を修正する手段を講じ、期待通りの仕事を達成するのが望ましい。つまり部下自身が「自己統制」を行うということである。
エンジニアマネージャーとして
マイクロマネジメントをされたくないエンジニアはとても多いと思う。エンジニアマネージャーとしては自己統制を行ってくれるように指導していくべきである。目標と納期の合意を取ったら後は、彼らを信じてあげよう。
2.6 調整
計画から統制に至る機能が円滑に動くように関係者に働きかけ、調和と均衡を保つこと
2.6.1 統合による調整
お互いの利害や得失が相反する場合には得てして「権力によって相手を制圧する方法（強制）」や「双方の意見の中間を取るという安易なやり方（妥協による調整）」を取ってしまう場合が多い。望ましい調整の仕方としては、より高次も目的からみて双方の目的が無駄なく取り入れられ、お互いが納得により価値の高いものにする「統合による調整」を行うことである。
エンジニアマネージャーとして
一部機能が納期に間に合わないということはよくあることである。こんなときにマネージャーは利害者と調整しなければならない。まずは案件のスコープを小さくしたり、延期したりすることが調製方法として上げられる。画面の開発1つとっても、一度に全ての画面をリリースできなくても、順番を付けてリリースしていく方法もある。もしくは、画面の中の小さい機能（例えば一覧のソートなど）は、リリース時にはなくても顧客メリットは変わらないと判断して、案件スコープを小さくする（例えば「様々な検索ができる、とても便利な管理画面」というスコープから「検索機能はないけど、運用は止めない管理画面」のように」）。
ここで大切なのは、「リリース」ということである。案件を先延ばしにしてリリースできる機能からリリースするというのはよくあるが、この「リリース」のハードルを極限まで下げておかないと、先延ばし交渉が難しくなる。本番環境に迅速に安全に高頻度でリリースできる仕組みなしには、「3ヶ月延期させてください」「リリースのために土日停止させてください」など、難しい交渉しなくてはいけなくなる。無停止で安全に適用できる仕組みの構築は早い段階で行わなければならない。AWSを初めとしたクラウドベンダーはこの分野もサポートしてくれているので、是非利用されたい。
2.6.2 他職場との調整の方法
他職場と調整を行う必要を感じたときは、まず「調整の目的」を確認する。「内から外への原則」に従い、内部固めをして、他職場と調製する。
エンジニアマネージャーとして
チーム外や他部署との交渉はマネージャーの仕事である。特にジュニアのメンバーに他部署のトップと交渉させてはいけない。その交渉は失敗に終わる可能性が高いからである。
以上、第2回 仕事の管理でした。
