チーム開発とソフトウェア開発プロセス

まずは昔話から。

一人でソフトウェアを完成させるのは、大変クリエイティブで楽しい作業です。実際、昔のゲームプログラマは、プログラミングは勿論、キャラクターデザインから音楽、パッケージの制作まで一人でこなしてしまう、素晴らしい方々がたくさんいらっしゃいました(今でも、きっと、いらっしゃることでしょう)。

ソフトウェア制作は一種の創造作業ですから、どんな内容であれ、明確な方向づけが欠かせません。その点で一人ですべての方向づけを行う、と言うのは理にかなっていると思っています。

その後、自分のあまり得意でない分野の作業や、一人では時間のかかってしまう作業を、気心の知れた知人等と共同で進める開発スタイルが登場してきました。オープンソースソフトウェアや同人ソフトウェアの開発はこの流れの延長線上だと言えるでしょう。同じ志をもつ人々が集まって、一つのソフトウェアの開発に携わり、一人では難しい規模のソフトウェア開発を実現してきました。

複数人で作業を行う場合、一人で作業を行う場合と異なり、何らかの規約が必要になることが多いです。この規約は、目指す方向や、チーム自体の性格、また参加者の思いで大きく異なります。例えば「声をかけ合って、二人で同じファイルを編集することがないようにしよう」という程度な緩い規約だったり、「発売日に向けて、毎日互いの開発進度を報告しあい、進捗を明確に管理しよう」というような真面目な規約だったり。

こんな感じで作られたチームの規約が、そのチームの有益な「ソフトウェア開発プロセス」なわけです。チーム内での合意なわけですから、チームに適した、チームが進みやすい、チームの目的を達成するための規約でなければならないのは当然のこと。プロセスの規模やその適用範囲は、チームの合意として選択されるに過ぎません。

ここまでこの記事を読んで下さっている方には言わずもがな、なわけですが、いつの間にやらこの前提がひっくり返り「急造混成チームへ一本の軸を与えて運用する為、既存のプロセスを組み合わせたベストプラクティスとやらを適用するのだ」という、大変不思議(?)な現象が蔓延するようになってしまいました。

例えば悲しい話として、無理矢理混成チームを与えられてしまった方、例えばチームリーダが「僕の立ち位置では、この与えられたチームを存続させ、どういうやり方であれミッションをこなすことが重要なのだ」等と思い詰めてしまった挙げ句「よく分からないけど、チームに軸を通す為には、チームへプロセスを適用しなきゃいけないらしい」と右往左往している状況を目の当たりにすることがありますが、意味のすり変えられてまった「プロセス」という悪魔の言葉に躍らされ、なぜ故、皆が不幸になっていってしまうのだろうか、と考え込まざるを得ません。

本来、チーム自体が「統一された目的無きまま強制的に集められた人員で作られたチーム」ですから、その時点では多かれ少なかれ、メンバの心が各々違う方向を向いていたりします。ほんの一瞬立ち止まって考えれば、まずはチームの一体感が重要だよね、と考えが進むのでしょうが、心の焦ってしまっているチームリーダがまかり間違って「強固なプロセス」を、そのチームへ適用してしまったりすると...。

お寿司をたべたいなー、とか思っている人と、今日は絶対中華だな、とか思っている人を、無理矢理引っ張ってフランス料理屋へ連れて行き、あげく「こら、音を立ててスープを飲むな」とか叱ってみても、誰も食事本来の目的である「美味しいものを楽しむ」という心は満たされないですよね、なんて話をすると、誰もが、うんうん、と笑ってくれます。でも、企業のソフトウェア開発の現場って、こんなことが、それこそ毎日、真面目な顔で行われているのですから、どこかで何かボタンの掛け違いが起こっているに違いありません。

この問題を解きほぐし、開発者が個人の能力を最大限に発揮できるチームを創造でき、しかもビジネスとして成功できるには、という視点で、以後、少しずつ模索して行きたいと思います。