仕事を分担しよう

パソコン甲子園はチーム戦！

パソコン甲子園のプログラミング部門も、モバイル部門も、チームで戦います。チームとしては、秀でた個人に、サポート役の人が居たり、それぞれ得意不得意があるところを補いながら、目的に向かって走っていきます。

モバイル部門は、特に『長期戦』です。予選の企画審査でも、本選のデモに対しても、どちらも提出まで2か月以上、少しずつ作り上げていかなければなりません。

そんな『長期戦』をチームでやり遂げるには、明確な役割分担と、スケジュールによる統率が必要となります。このページでは、どのようにチームの統率を図るかについての、手法を考えたいと思います。

ここでは、WBSとスケジュールの管理のために、ProjectLibreと呼ばれるオープンソースのソフトウエアを用いて説明していきます。ProjectLibreの詳細な使い方はWeb上にいくつかあります。

[Project Libreに触ってみる] [ProjectLibreのインストールと使い方、基礎、入門]

なお、ガントチャート作成や、ビジネススケジュールの管理については、その他のアプリケーションもたくさん存在します。

どのくらいの作業があるのか？: WBSと工数

皆さんが夏休みの宿題をするときに、『1日どれくらいずつ、何日掛ければ宿題が終わる』と計算しませんでしたか？また、文化祭などでも、何時までに何をする、という流れを考えたりしませんでしたか？

長期間、プロジェクトとして作業をする場合、『どのような仕事があるのか』と『どれくらい作業時間が必要か』を見積もることは非常に重要なことです。

例えば、5教科分の宿題がある場合、どれをどの順番に仕上げていくか、というのは一つの作戦になります。毎日、少しずつ、平均的に進めていく方法もあれば、1教科分をいっぺんに終わらせてしまう方法もあるでしょう。

さて、1教科の中には、色々な単元が含まれている場合があります。『日本史』などでは、夏休み辺りですと、『縄文・弥生』『平城・平安』『平氏・源氏』『室町時代』くらいの分割になるでしょう。更に、『縄文・弥生』の辺りを開いていくと、『石器』『土器』『金印』『卑弥呼』『大化の改新』という細かいテーマが出てきます。このように、大きい括りから、樹形図的に、小さいテーマへと分割していくことをWork Breakdown Structure (WBS)、そのテーマにどのくらい時間を費やすかを考えるのが、『工数管理』という考え方です。

さて、実際の現場を見てみましょう。例は、前のページで取り扱った『ダイエットアプリ』です。WBSと工数で管理をしようとすると、その前に、UML等を用いた様々な図によって、どれくらいのものを作らなければいけないかは、既に説明した通りです。ここから、一般的なV字モデルと呼ばれる開発のスタイルに当てはめて、作業の手順と時間を考えてみたいと思います。

V字モデルでは、『要件定義』『基本設計』『詳細設計』『コーディング』『単体テスト』『結合テスト』『全体テスト』という7つのフェーズに分かれます。また、『要件定義』で定義された仕様をテストする場合は『全体テスト』、『基本設計』で定義された仕様をテストする場合は『結合テスト』、『詳細設計』で定義された個々のパーツをテストする場合は『単体テスト』という形で、『設計 - コーディング - テスト』という流れが作られています。

この7つのフェーズを縦に並べて、更に『基本設計』や『詳細設計』、『コーディング』等の中に、どのような仕事が含まれるかを考えます。『コーディング』には、既に分割された個々のパーツのコーディングが入ります。また、『単体テスト』では、そうして作成されたパーツが正しく動作しているのかをテストするようになります。当然ながら、テストのためには、テストの条件を作らないといけません。それが、『詳細設計』の段階で、先にテストを作成しておくか、『単体テスト』の段階でテストを考えるのかは、皆さん次第となります。

こうして、最初の大きい7つのフェーズから、順々に作業が分割されていきました。そこから、各作業がどれくらいの時間でできるのか（やるべきなのか）を考えていきます。1つのソフトウエアパーツを作成するのに、慣れている人で大体1日 (5時間)、慣れていないと、勉強しながらなので、最初は2~3日 (15時間) かかると考えます。また、テストも、先にテストを考えていれば、パーツ1個に対して2時間程度を見るようにして、全て計算していきます。そうすると、細かい分類から、大きい分類へ、全部足すと、総作業時間が出てくるものと思います。

最終的に、全体まで足し上げていって、どれくらいの作業時間になるかを計算します。この時、出来るだけ『保守的に』計算するようにしましょう。この作業時間は、『かなり遅くなることを考えて』書き込んでおけば、何か予期しない変更があった時に、落ち着いて対処ができます。もし、『早く作ることを考えて』時間を設定したならば、締め切りまでに間に合わない状況に陥ります。

こうして、全体的に見て、どれくらいかかるのかを計算したのが『工数』となります。皆さんの場合、学校もありますので、部活で1日何時間出来るか、夏休みに1日どれくらい作業ができるかの考えで計算するのが良いでしょう。間違っても、ブラック企業のように、残業、作業持ち帰り、休日出勤などしないように！

どの作業が遅れのきっかけなのか？: ワークフロー図

WBSによって工数が決まったら、次は、どのような順番でそれを行うかについての図を考えていきます。

パソコン甲子園は『チーム戦』と話しているのは、この段階で上手く作業分担を決めることで、チーム3人であれば最大3倍速で作業を進めることができるからです。残念なことに、最大3倍速なのは、理論値であって、現実的には、必ず『この作業が終わらなければ次に進めない』という『ボトルネック』が存在します。この『ボトルネック』を見つけるのが、ワークフロー図です。(ProjectLibreでは『ネットワーク』とされています）

左の図は、ProjectLibreで表現されたワークフロー図です。この図については、特に開発に置いての分岐がないので、1つ1つ、それぞれの作業の遅延が次の作業の遅れにつながることになります。

また、全体的な作業の流れも、一直線になっていますので、基本的にはそれらの作業が遅れれば、その後の作業も遅れるようになってしまいます。ですので、『遅れ』を考えたスケジュールにする必要がある、という事になります。

左の図は、ある作業A~Hまで、途中いくつか平行に走らせることができるようなワークフローを考えた図です。この時、それぞれの作業予定時間が割り当たっていますが、BとCが終了しなければEに移ることができない、また、DとEとFが終了しなければGに移ることができない、という状況が生まれることを『ボトルネック』と言います。また、この時、作業開始のために直接的な影響のある作業の順番を『クリティカルパス』と言います。

この場合、CからEに行くのが作業全体で7日目。EからGに行くのが作業全体で12日目になることが表されています。ここが遅れると、次の作業が確実に遅れるという事になるので注意が必要です。

このワークフロー図の中に、各作業を行う人が書き込まれて行きます。1人で2つ以上の作業を受け持つことは難しいと思いますので、基本的に3つの仕事が並列で動ける限界になると思います。ワークフロー図を作ると、簡単に、『誰が余っているのか』や、『どこが遅れるとまずいのか』が分かるようになります。

スケジュールを明確化しよう: ガントチャート

ここまで作業の分担が確立したら、あとは実際のスケジュール表に書いていきましょう。

スケジュールの書き方も、一工夫あると、作業の進み方がどうなっているかをよく把握できるようになります。『ガントチャート』と呼ばれるスケジュールの書き方です。表計算ソフトで、縦方向に作業項目、横方向に日付を並べて、休日などを考慮しながら、作業の日程を横棒で表現するようにします。

左図は、ガントチャートの一例になります。スケジュールの中に、作業するべき期間が青のバーで表記されているのが分かります。これが、左上から右下に、階段を下りるように並ばせて、作業手順の前後関係や、作業期間、または、そこで行われている作業の進み具合（パーセンテージ表示）と、どれくらい遅れているのかを表記することができます。

これは、企画書を立てるためだけに行うものではなく、むしろ、企画書レベルでは、『要件定義』で出てきたような、本当にざっくりとしたレベルでの時間感覚で良いものです。

一方で、実際にプロジェクトを回す時には、この表をしっかり全員で確認しながら、遅れがある場合はどうやって取り戻すかをしっかり議論しながら進める必要がありますので、『開発の段階で重要な図』と言えると思います。

また、この方法は、今のソフトウエアの開発現場や、建築等の現場でもよく用いられている方法です。左図は、Wikipedia (ガントチャート)のページに示されている、東海原発解体撤去工程のガントチャートです。

このように、実際の現場でも用いられている方法ですので、皆さんも、これにならって、自分たちの開発の段階を、よく確認するようにしてください。

上級向け: アジャイル開発ではどうスケジュールを考えるのか？

ソフトウエア開発において、様々な工程管理やソースコード等を管理するツールが増えてきて、少人数のチームでも気軽に大規模なソフトウエア開発が行えるようになってきました。しかしながら、依然として、大規模なソフト開発を行う場合、上記でも挙げたV字モデルのような、『いっぺんに建てる』方法を取ろうとすると、『暗闇の中を、ゴール目指してひた走る』ような開発になってしまって、途中でモチベーションが続かずに頓挫する、なんてこともよくある話だったりします。

そうならないために、小さいものを作って、そこから肉付け、改善、バージョンアップを行っていく開発スタイルが、特にAndroid等のスマートフォンアプリ業界では標準のスタイルになってきています。このスタイルのことを『アジャイル開発』と言います。

アジャイル開発において、一番重要なポイントは、『機能の細分化と優先順位』です。最初の企画段階では、最終的にこんなイメージのアプリケーションを作りたい、というものは同じです。要求の定義までは同じですが、要件定義として全ての要素を出すのではなくて、『最低限使える機能』を、出来るだけ早い期間で作って試す、という事をします。

左図のように、V字モデルによる開発（ウォーターフォール）と比較して違うのは、いっぺんに作り上げるのではなくて、部分的に、テストを繰り返しながら作り上げるという事になります。

Androidアプリに関しては、これがしやすい言語環境となっています。Androidで採用されているJava系のプログラム言語は、元々、『ソフトウエアパーツを組み合わせて作る』のに秀でたものでした。また、Androidアプリでは、小さいアプリケーションを統合して、大きいアプリケーションを作る方法が存在します。

企画書をアジャイル開発前提で書く場合は、画面設計を基に、『どの範囲までで使える（デモができる）アプリを、いつまでに作る』という形でスケジュールを決定して、企画書を書くといいと思います。2週間や1か月毎に、現時点で動作可能なアプリを、ほかの人に使ってもらえるように出来るならば、素早い意見のフィードバックを得られるので、より作り込みが楽に進められます。

Google Sites

Report abuse