ディレクターあるいはプロジェクトマネージャーに、こういう点を意識してもらえると助かるという点を開発者の視点から列挙します。ディレクターとプロジェクトマネージャーの違いというのは、わたしにはよくわからないので、本稿では同じものとして扱います。以後は文字数の少ないディレクターで統一します。
なお、わたしは数人規模の小規模受託ソフトウェア開発しか経験がありませんので、この記事もその規模の開発が対象と考えてください。例えば、アプリ開発であれば、iOSプログラマー1人、Androidプログラマー1人、UIデザイナー1人、ディレクター1人といったあたりが、よく見られる構成です。開発期間は、せいぜい数ヶ月〜半年程度です。この程度の小規模開発であれば、実際のところ、多少の問題が起きても、作業者が何日か徹夜作業をすればどうにか丸く納まるということがほとんどです。大規模開発ではこうはいかないと思うので、ソフトウェア工学への真剣な取り組みを推奨します。
開発に参加しているメンバーが優秀であれば、自主的にいろいろな取り組みをして、どんどんものごとを進めていってくれるかもしれませんが、なりゆきまかせでうまくいかない場合には、ディレクターの介入する余地がありますし、それはディレクターの責務だと思います。
トラブルの防止と対応
納期・予算・機能(スコープ)・品質 すべてを固定しての開発はギャンブルです。プロジェクトの状況は日々刻々と変化するので、当初の予定とのズレを把握して、これら4要素を柔軟に調整してください。とくに、作業者は、実際の作業に集中すると視野が狭くなるものですので、プロジェクト全体の状況を客観的にモニタリングする責務がディレクターには期待されます。
そうした努力をした上でも、どうしても納期が守れないという状況が発生してしまうことも、ときにはあるかもしれません。実際にトラブルが発生したときに、顧客との間でどうにか妥協できる条件を見付けた上で、作業者の 防護壁 になってくれるディレクターは、ありがたい存在です。
コミュニケーションの円滑化
作業者は、それぞれの領域における技能と経験を持ったプロフェッショナルなので、その資産を最大限活かすべきです。そのためには、各メンバーが相互にコミュニケーションをして、知識の交換をカジュアルにできる場を設けるのがいいでしょう。お互いが物理的に近い場所で毎日作業しているのであれば、それだけで十分かもしれませんが、そうでなければ、開発用のチャットなどを用意するのがいいと思います。 Slack、 ChatWork、 HipChat、Skype、IRCなどツールはいくらでもあります。
また、開発においては、日々刻々と問題や課題が発生し変化していくので、それらをデータベース化して、イシュートラッカー(ITS)あるいはバグトラッカー(BTS)と呼ばれるシステムに記録し追跡するのが有効です。 GitHub、 Bitbucket、 Redmine、 JIRA、 Backlog、 Pivotal Tracker 等、こちらもいろいろ選択肢があります。個人的には、小規模開発であれば、GitHubについてくる程度の簡単なもので十分な気がしています。
これらのツールを運用する上でディレクターにやって欲しいのが、
- ITSはワークフロー込みで成立するツールなので、どのように運用するかを開始時に決めて、全メンバーに周知する
- チャットツール・メール・電話でのやりとりは流れてしまうので、重要なことはITSに登録してデータベース化する
- バグ報告時には、再現環境・再現手順・対象とするバージョンなどの情報を明記するよう周知する
といったことです。このあたりは、なりゆきまかせにしていると必ずグダグダになるので、うまくコントロールしてください。
取り組むプラットフォームや、既存の開発資産などについて詳しくないメンバーがいるのであれば、知識を共有し、認識を合わせるためのオリエンテーションの機会を設けるといったことも、必要かもしれません。
最後に、プロジェクトに関する資料はすべて共有して、メンバーが全員参照できる状態にしておきましょう。これらは、作業をする上での基盤となるものなので重要です。ただし、たくさんある資料が同じディレクトリにゴチャっと置かれていると使いづらいので、ある程度整理して参照しやすい状態になっていることが大切です。古くなって有効性を失った資料は、そうとわかるようにしておいてください。情報が正しく行きわたらないために、無駄な作業が発生するようなことがあってはいけません。
責務の分担と明確化
複数人で共同作業をするのであれば、どのように作業を分担して、どうやって開発を進めるかを決める必要があります。共同作業を進める上で、顧客も含めて、参加者の間でどのような情報のやりとりが必要なのかの洗い出しと共有・指示もディレクターの責務に含まれると思います。
たとえば、デザイナーからプログラマーへのデザイン指示書 は、どのような情報が必要で、どういったフォーマットで作成するのが望ましいのか、といったことも作業着手前に認識合わせしておくほうが望ましいでしょう。なりゆきまかせでは、期待とは異なる成果物がでてくるかもしれません。
システムの開発であれば、開発者のコミュニケーションの基礎になるインターフェイスだけ先に決めておいて、モック実装のみ先行して提供することで、並行作業が可能になるといった可能性もあるので、検討してください。
その他、アプリのIDはどうするのか、バージョン番号はどう付けるのか、ソースコード管理ツール(Gitなど)の運用はどうするのか、サーバーの開発環境やステージング環境は用意するのか、使用するOSSのライセンスはどういったものならOKなのか、といったさまざまな決定が開発では必要になりますが、専門的な内容になってくるので、開発者と相談して決めてください。