情報系学生のマネージャー体験

大学の講義でマネージャーを経験することになったので、考えたことなどを記述しておこうと思います。学んだことだけでなく、自分が途中で考えていたことなども書いているので、適宜飛ばしてみてください。

講義概要

私がマネージャーを担当したのはPBLという形式の講義でした。(PBLがどういう形態の授業であるかは本質的ではないので割愛します。）
講義では4名１組のチームを作り、そのチームで所定の課題を達成するソフトウェアを作成することを目的とします。ソフトウェアはArduinoで実行するため、Arduino言語(C/C++をベースにした言語)を使用します。
講義前の時点でプログラマが担当するコードの機能縮小版のようなものは作成されており、それに機能を追加する形でソフトウェアの開発が行われました。

チーム構成

チームはマネージャー、補佐、プログラマ２名で構成されます。
以下では各役職の役割と今回のチームメンバーの概要・印象を述べます。

マネージャー

私が担当していた役職になります。
スケジュール管理と設計書などの各種ドキュメントの作成が仕事になります。講義最終回に行うソフトウェアについての発表資料の作成も担当します。（発表資料の作成は一部他の方に協力をお願いする形になりましたが）

プログラマ（２名）

コーディングを担当します。今回は作成するソフトウェアによってプログラマ１とプログラマ２の２つへと分けられました。

補佐

プログラムへのコメント、仕様書のチェック、ペアプログラミング等を行います。マネージャー視点ではなんでも屋の印象です。

チームの状態

メンバー4人のうち私を含む２名がプログラミング経験が十分にある学科、もう２名がプログラミング経験に乏しい学科出身です（１人は理系、もう１人は文系）。講義で教員から課された制限により、プログラミング経験が十分でない２人がプログラマを担当することになりました。

プロジェクト初期に考えたこと

チームメンバーについて

前述の様にプログラマはプログラミング経験に乏しい状態でした。このため、補佐に積極的に関与してもらう必要性があると考えていました。また、プログラマ１はある程度真面目な方で、講義前の縮小版の時点で大枠が完成していることあり、ソフトウェアの完成に対して心配する必要性はないと考えていました。
一方、プログラマ２はモチベーション・技量的に開発が心配でした。このため、実質的には補佐に大部分を作ってもらう流れになることを想定していました。

スケジュールについて

前述のプログラマ２の担当箇所への不安があったため、いざとなれば自分も介入してプログラム作成に介入することを想定していました。このため、１週間前の時点でプログラムの大半が完成するようにスケジュールを立てました。これは他の人員によってプログラマ２の作業へと介入する余裕を確保することを予定していました。

自分の作業について

プログラマの作業の開始とスケジュール・各種ドキュメントの作成が同時でした。このため、仕様が確定していない状態でプログラマに対して作業を依頼する必要性がありました。このため、プログラマの作業の能力と制作するソフトウェアの特性を考えて初回の作業内容とそこで制作する範囲の使用を考える必要性があると考えていました。

初期対応の自己評価

チームメンバーに対する評価およびそれを基にしたスケジュール立案の方向性は間違っていなかったと考えています。また、プログラマの進捗を予想して仕様を整えていったことにより、講義序盤でプログラマが遊ぶ時間を作らなかったのはよかった点だと考えています。
ただ、補佐に対してプログラマの補助という曖昧な指示を出したため、若干遊ぶような状態となっていました。プログラマの技術的不足による遅れを予期していたのであれば、初期時点から補佐には積極的に介入してもらうべきでした。

プロジェクト中盤

基本的に各員が割り振られた作業を行うという状態でした。
私自身も、仕様書・設計書の細部を詰める作業を行う必要性がありました。ただ、その間のスケジュール管理が甘く、プログラマ１・２ともに遅れを許容してしまう形になってしまいました。（これが後半に響く…）

プロジェクト後半

予想通り、プログラマ２の作業が終了していなかったため、プログラマ１と補佐に作業を依頼する結果となりました。実際にはほぼすべてのコードをプログラマ１と補佐に依頼する形となり、スケジュールの余裕もない状態でした。

反省

スケジュール管理について

プロジェクト全体を通して、スケジュールは想定より遅れ気味でした。この原因は以下の２点だと考えています。

• スケジュールの想定が甘かった

• スケジュール管理が徹底しきれていなかった。

前述のように主に作業を行うプログラマはプログラミング経験が十分ではありません。このため、実際に作業を行う際には、プログラム経験が一定以上ある人と比較すると時間がかかります。この遅れはある程度想定して組んだつもりでしたが、結果としては想定が甘かったと言わざるを得ません。

実際のプロジェクトではなく、あくまでも講義の中のプロジェクトであることもあり、課外にも作業できる状態と考えていました。このため、中盤でプロジェクトが遅れている状態でも「次の講義までに～しておいて」とすることで何とかなると考えていました（甘い）。
ただ、実際にはその指示をしてもプログラムが作られていないということもあり、最終日はかなりギリギリになってしまいました。そもそも講義外の作業を前提にするのが良くなかったです。（講義外で作業してもらわないと終わらない状態になっていたので仕方ないとは思っていますが。）

チームマネジメントについて

今回のプロジェクトは講義として開催したこともあり、たった４人のチームでも背景が異なります。プログラミング経験の差、モチベーションの差などが顕著でした。前者は仕方がないとしても、後者は何とか出来たものだと考えます。また、プログラミング経験の差を対応できればモチベーションの維持につながった可能性があります。
もう少しうまくやれたのではないかと思っています。

その他のドキュメント作成について

コード作成作業と並行して仕様書・設計書を作成するため、制作開始までに仕様と設計を本来では固めるべきでした。ただ、実際には設計を仕上げきれなかったことがありました。

教訓

実際のプロジェクトとはかなり違う状況なので経験としては活かせないだろう事柄もいくつかありますが、今後社会に出るうえで役に立ちそうなことをまとめてみます。マネージャーとしてのものとマネージャー以外に対して思ったことを載せています。

仕様書・設計書を確認しよう

基本的なことです。仕様が定められている案件で仕様書の条件を満たさなければ製品としての価値はありません。これを満たしていない開発は行わないべきです。
また、設計書には複数人でプログラムを書く上で必要な要件を示しているものです。これを守れなければ複数人でコードを作ることは難しいでしょう。こんな記事を読んでいる方々には当たり前のことだと思いますが、遵守してください。

進捗はまめに報告・確認しよう

進捗がわかっていないということはマネージャー・プログラマの双方にとってデメリットしかありません。
進捗さえわかっていれば、マネージャー側がプログラマをフォローできる可能性があります。ただ、進捗がわからないとフォローはできません。このため、プログラマは積極的に進捗を報告しましょう。（報告・連絡・相談は社会人の皆様はある程度できるイメージなのであまり問題はないかもしれませんが）

マネージャーはプログラマが定期的に進捗を報告する仕組みを構成するべきでしょう。また、相談しやすい関係性を構築するのも重要でしょう。ただし、プログラマの自主的な進捗報告を期待するだけではなく、マネージャーも積極的に確認するようにしましょう。

他人を期待するのはやめよう

語弊をかなり含んだ言い方になります。ただし、字面のままです。作業しておいてくださいと言っても進捗０です。（最も、実際のプロジェクトとはコアタイムの長さが違うので、スケジュール維持のために業務外の作業を依頼しなければいけない状況は生まれにくいでしょうが）（やらないではなくできないの可能性もありますが、結果は同じです。）
このため、余裕を持ったスケジュールにして、いざとなれば介入できるようにした方が無難だと思います。（ただ、これができるのなら炎上するプロジェクトは存在しないはず。ﾑｽﾞｶｼｲﾈ…）

チームの関係性構築

期待するなと言っておいて関係構築について述べるのは、言っていることが矛盾するように思われるかもしれません。これらは背反ではありません。そして、プロジェクトは他人と協力する必要があります。
他人に自分が望んだ作業をしてもらうには立場だけでは不十分です。相手に作業の動機付けをしてもらう必要があります。この上で、チーム間の信頼関係は重要です。
また、関係構築が十分にできていないと、連携などの面でパフォーマンスが落ちます。効率化を図る上でも関係性は重要なものです。このため、関係性の構築は積極的に行いましょう。
（こんなことを言っている私はこれが一番苦手だったりします。正直プログラマ２と関係構築が上手くできていなかったのも、失敗の原因だろうと考えています）

最後に

以上が私が講義でのプロジェクトマネジメントの経験およびそこで考えたことになります。実社会のプロジェクトではあまり関係ない事項も複数ありますが、管理する側を一度経験しておくのはよかったと思います。
この経験がどこかでいきることを祈っています。