ソフトウェアプロジェクトの期間見積もりは3倍で
ソフトウェア開発のプロジェクト管理は難しいです。
これは現在チームを率いている人間が誰しも感じていることだと思います。
何がどう難しいのか？
それはもう、現在誰がどんな作業をしていて割り当てたタスクの進捗がどうなのかということが不明瞭、当初の完了日時に対してタスクの進捗が合致していない(締め切りに間に合わない)というマネージャーのお腹を痛くする要因がたくさんあるからです。
加えて最近はリモートワークによる弊害というのもあります。
リモートワークの難しさについてはまた次回にでも話そうと思います。
ドラッカーの名著『マネジメント』には「誰しもがマネジメント意識があればマネージャーというのは存在する必要がない」という言葉があります。
たしかにプロジェクトに関わる全員が「プロジェクト達成に関して必要なタスクを鳥瞰図的に把握しており」、「締め切りまでにどうタスクを完了していなければいけないのか」、「もしタスクの完了に支障が出た場合はステークホルダーにどうコミュニケーションを取るべきなのか」ということがわかっていればマネージャーというのは不要です。
ただ、現実問題としてマネージャーという役割の人間は絶対に必要であり、実際に各社ではマネージャーに相当する人間が必要とされています。
ソフトウェア開発の文脈ではプロジェクトマネージャーやプロダクトマネージャー、エンジニアリングマネージャー、CTO、VPoEあたりでしょうか。
大切な原則として、ソフトウェアエンジニアは与えられたタスクの見積もりを正確に行うことができません。
これはソフトウェアエンジニアを貶すつもりはなくて、タスクの完了に関してソフトウェアエンジニア側の視点で確からしい見積もりというのは極めて難しいという事実があるからです。
これは僕自身がソフトウェアエンジニアとして正しく見積もりをできたことがないという経験則にも基づいています。
かなり具体的な例で話を考えみましょう。
Issueで「Webアプリの開発においてバックエンドからデータベースに接続をする関数を実装してほしい」というのをエンジニアAにアサインしたとします。
このIssueはエンジニアからすると極めて簡単なように思えます。
PythonならSQLAlchemyでsessionmakerを使って中にDBの接続文字列を入れて、DBのユーザー名やパスワードなどを環境変数から拾って...というように作業の流れがだいたい想像つくと思います。
恐らくこのIssueをアサインされたエンジニアは「あーそれなら1日もあればできますよ」なんて言うかもです。
この時点でもう見積もりが甘いです。
ローカル環境でこの作業を行なった際はたしかに一瞬で終わるでしょう。
僕ならこの程度の作業なら15分もあれば終わるなという感覚はあります。
しかし、このサービスをホスティングしている環境は恐らくAWSとかのIaaSで、そこで実際にバックエンドサーバーとDBが正しく接続できるかを確認する作業は地味に時間がかかるでしょう。
実際にデプロイしてみたとき、セキュリティグループの設定かVPCのサブネットの設定かIP割り当てか、ローカル環境で動作確認した際には起きないだろう調整作業が発生します。
こうした地味な作業というのをやっていって、もしここで沼にハマってしまうと軽く2日くらい溶けるでしょう。
プロジェクトマネジメントにおける憲法書としてPMBOKというのがあり、ここではプロジェクトの期間の見積もりは思ってる2倍をとっておけという言葉があります。
ここで僕のTipsですが、ソフトウェア開発に関して言えば思ってる3倍の期間を確保しましょう。
先ほどソフトウェアエンジニアにアサインしたIssueの例で言えば、本人は1日もあれば終わるという表現をしていますが、マネージャーであるあなたは3日かかると見積もっておきましょう。
プログラミングのアルゴリズムの世界では最良計算時間と最悪計算時間、平均計算時間という概念があります。
ベストなケースであればO(n)だが最悪だとO(n²)とかです。
なぜかわからないのですが、エンジニアが何か開発作業をやろうとするときに基本的に最良計算時間で考えてしまうという傾向があるようです。
タスクをアサインされたときに、プログラミングとしてどういう作業を行えば良いのかというのは想像がつきますが、実際にデプロイ作業を行なったりした際にどういう作業が発生するかはベテランのエンジニアでないと見積もりは正確に出せません。
エンジニアの多くはデプロイ作業に慣れていないので、ここの作業見積もりが抜け落ちてしまうというのが原因だと思われます。
また、自分がプロジェクトを任されるにあたってプレイヤーとして活動していると自然とプラス思考をしてしまうという問題もあるかもしれません。
なんにせよ、マネージャーは進捗管理において最良計算時間と最悪計算時間の両方を見積もっておき、ビジネスサイドのステークホルダーには最悪計算時間を提示しておきましょう。
そして同時に最良計算時間を過ぎたあたりでアサインしたエンジニアに進捗がどうかをヒアリングするというのが鉄則だと思います。
こうした話を踏まえて、ソフトウェア開発プロジェクトのマネージャーに相当する人間は絶対にソフトウェアエンジニアリングに造詣がある(=プログラミングができてデプロイ作業などインフラ技術にも造詣がある)必要があります。
これは十分条件ではなく必要条件です。
そして実際に組織で活動するためにはマネージャーはビジネス感覚というのもある程度持ち合わせている必要もあります。
ただ現実としてそんな人間は世の中多くないので、K Squadが各社で重宝していただいているというのはあるかもしれません(突然の宣伝)
マネジメントって難しいですよね。
今後様々なトピックを発信していくにあたって、こういう話が聞きたい！という要望があれば是非ともコメント等にてよろしくお願いします。
以下、お知らせです。
今後はK Squadの普段の活動の中で得た知見をどんどん発信していこうということでウェビナーをどんどん実施していきます。
第一弾は3月6日(水)の12:00-13:00です。
是非とも気軽にご相談ください。
すでに登録済みの方は こちら
読者限定の内容も逃しません。