<h2 data-sourcepos="1:1-1:15">
<a></a>はじめに</h2>
この記事は 
(Webアプリケーション開発プロジェクトでディレクター担当の) 
私が経験した反省点を振り返り、みなさんと共有するものです。 
プロジェクト管理における一つの重要なテーマ、バッファの設定について考えるきっかけにしていただければと思います。
<a><img alt="images.jpg" data-canonical-src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3552881/fc663ff8-7146-114b-a3e6-f722e22ed0a6.jpeg" srcset="https://qiita-user-contents.imgix.net/https%3A%2F%2Fqiita-image-store.s3.ap-northeast-1.amazonaws.com%2F0%2F3552881%2Ffc663ff8-7146-114b-a3e6-f722e22ed0a6.jpeg?ixlib=rb-4.0.0&amp;auto=format&amp;gif-q=60&amp;q=75&amp;w=1400&amp;fit=max&amp;s=ba1831ab88d7bf64845741ddbea95631 1x"></a>
<h2 data-sourcepos="9:1-9:9">
<a></a>まず</h2>
<h3 data-sourcepos="10:1-10:22">
<a></a>バッファとは</h3>
「バッファ」とは何かを簡単におさらいしましょう。 
プロジェクトのスケジュール見積もりにおいて、 
不測の事態に備えて設けられる安全余裕のことです。
<h3 data-sourcepos="15:1-15:25">
<a></a>タイトルの回収</h3>
さて、私がなぜ1タスクごとにバッファを設けたのか？ 
答えはシンプルに「その方がスケジュールの確度が向上する」と思ったからです。 
(その方がエンジニアにも易しいのかな？とも思ったり…) 
しかし、 
その後の学びを通じて、「タスクバッファ」よりも「プロジェクトバッファ」の方が効果的だと考えるようになりました。 
（もちろん、100%正解かどうかは賛否ありそうですが）
以下では、 
プロジェクト全体で後半にバッファを設ける方が有効だと感じた理由を3つ 
ご紹介します。
<h2 data-sourcepos="27:1-27:45">
<a></a>プロジェクトバッファの優位性</h2>
<a><img alt="新規ドキュメント_page-0001.jpg" data-canonical-src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3552881/ff056cea-d294-3c53-42e9-c500d6d4d663.jpeg" srcset="https://qiita-user-contents.imgix.net/https%3A%2F%2Fqiita-image-store.s3.ap-northeast-1.amazonaws.com%2F0%2F3552881%2Fff056cea-d294-3c53-42e9-c500d6d4d663.jpeg?ixlib=rb-4.0.0&amp;auto=format&amp;gif-q=60&amp;q=75&amp;w=1400&amp;fit=max&amp;s=31b9784c73dfa42a223c8538b88742c9 1x"></a>
<h4 data-sourcepos="31:1-31:68">
<a></a>1. 中盤以降にタスクが遅延したら挽回が難しい</h4>
理由の大半はこれに尽きます！ 
プロジェクトの初期段階での遅延は、他のタスクでバッファを調整することが可能ですが、 
中盤以降になるとその余裕がなくなります。 
結果として、スケジュール全体が崩れてしまう危険性が高まります。
<h4 data-sourcepos="38:1-38:62">
<a></a>2. エンジニアを信じている、だが人間だ①</h4>
学生症候群という言葉を聞いたことがありますか？
<blockquote data-sourcepos="42:1-46:65">
学生症候群
納期のある作業を行う際に、 
時間的な余裕があればあるほど、実際に作業を開始する時期を遅らせてしまうという、 
多くの人間に見られる心理的行動特性のこと。
</blockquote>
簡単に言うと締め切りの直前になって初めて作業を始めるという傾向のことです。
たとえば、 
・10日間のタスク 
に対して 
・7日間の作業時間 
と 
・3日間のバッファ 
を設けたとします。
エンジニアも人間ですから、 
・逆算して「4日目から作業を開始しても間に合う」 
と考えるかもしれません。
→この思いが、結果的にムダにバッファを利用する方向に向かわせるのです。 
※夏休みの宿題をイメージしていただけると分かりやすいかと。 
(一部の真面目くん・真面目ちゃんを除く)
そして、 
なんと、この"貯金"は使わずにはいられないのです。 
その理由は↓
<h4 data-sourcepos="70:1-70:62">
<a></a>3. エンジニアを信じている、だが人間だ②</h4>
パーキンソンの法則という言葉を聞いたことがありますか？
<blockquote data-sourcepos="73:1-78:65">
パーキンソンの法則
第１の法則 
仕事の量は、完成のために与えられた時間をすべて満たすまで膨張する。 
第２の法則 
支出の額は、収入の額に達するまで膨張する。
</blockquote>
簡単に言うと人間は、時間とお金を用意された分すべて使ってしてしまうということです。 
(ちなみに、収入が増えたのに貯金や投資が増えないのもこれが理由と言われています)
つまり、 
7日間で終わる作業でも、バッファがあることで10日間フルに使ってしまうことが多いのです。 
(一部の真面目PG・真面目SEを除く)
<h2 data-sourcepos="87:1-87:12">
<a></a>まとめ</h2>
今回の話を通じて、 
スケジュール管理の観点でも、人間の心理的な観点でも、プロジェクト全体でバッファを設ける方が得策だと考えるようになりました。 
そして、 
これを実施する上で欠かせないのは、エンジニアとの良好な関係性です。 
タスクの進捗が遅れる可能性がある際、気軽に相談してもらえるような信頼関係を築くことが重要だ、ということも再認識できました。 
プロジェクトごとに最適なアプローチは異なりますが、この考え方が少しでも役立てば幸いです。 
みなさんの経験談も大歓迎です！！！ぜひコメントでお聞かせくださいませ！
<h2 data-sourcepos="96:1-96:18">
<a></a>参考リンク</h2>
<a>１分で学ぶ！学生症候群・パーキンソンの法則</a>
<h2 data-sourcepos="99:1-99:15">
<a></a>さいごに</h2>
弊社のご紹介もさせてください！
「日本で一番エンジニアが成長できる会社を創る」 
<a>株式会社PRUM</a>
Wantedly募集 
<a>いつから挑戦しても遅くない！Webアプリ開発エンジニアを目指しませんか？</a> 
<a>RA・CAの両面型で、自社従業員に寄り添い成長を見届けることができる営業！</a> 
<a>育ち盛りのエンジニアたちを支えてくれる労務経験者を大募集！</a>
弊社メンバーは日々学習した内容をアウトプットしております！ 
ちょこっとでもご興味を持たれた方は求人を見てみてください！ 
（ご応募もお待ちしております！）
<h3 data-sourcepos="114:1-114:73">
<a></a>最後までご覧いただき、ありがとうございました！</h3>

不測の事態に備えて設けられる安全余裕

タスクの進捗を監視するためのツール

エンジニアの作業時間を短縮するための指標

プロジェクトの予算を管理するための計画

中盤以降のタスク遅延の挽回が難しいから

エンジニアの作業を効率化するため

時間的な余裕があればあるほど、作業を遅らせる傾向のこと

締め切りが近づくほど、作業を早める傾向のこと

作業を始める前に、十分な準備をすること

タスクを分割して効率よく進めること

与えられた時間をすべて満たすまで膨張する