久し振りに書いた記事です。Qiitaのアジャイル開発アドベントカレンダーに参加して書いてみました。 こういう理由でもないと記事ずっと書かないまま過ぎていく気がしてしまい、アドベントカレンダーに乗っかってみました。
普段一人で開発をしていて、あまり意識はしていないのですがアジャイル型の開発をやっています。なにをもって「アジャイル開発」なのか、という定義の問題については後述しますが、まずはWikipediaにある
人間・迅速さ・顧客・適応性に価値を置くソフトウェア開発
を定義として、特に顧客の求めに応じて迅速に開発対応をし、更に適応性の高い対応を行うことと位置付けて話を進めます。
ひとりアジャイル
フリーランスエンジニアという立場で開発の仕事を受注する場合、一般的に大規模開発などで使われる「ウォーターフォール型」の開発方式をとることはできません。できないわけではないでしょうが、ひとりで全工程を実施するという前提であれば、そもそも各フェーズ(企画・設計・製造・テスト)がクリティカルパスになっているし、それぞれの工程内でもクリティカルパスがあればもちろん、なくても並行してコーディングはできないので積み上げた工数はイコール開発にかかる時間になってしまいます。30人日の開発工数が見積もられる場合、その開発期間は必ず30日かかるわけです。短縮するためには要員追加をしなくてはならないわけです。
「アジャイル」の場合、特にひとりでやる場合は、もちろん全体像の把握をしなくてはならない企画フェーズや基本設計フェーズレベルであれば最初にまとめて実施して顧客とのコンセンサスをとる必要がある可能性もあるはずですが、そのあとの詳細設計以降はもちろんそうですし、基本設計フェーズにおいても小刻みに設計を作りながらレビューして、徐々に基本設計を進めながら並行して設計→製造→試験のイテレーションを回す、という方法が取れるわけです。
似非アジャイル
個人的には私がひとりでやるアジャイル開発は「似非アジャイル」と呼んでいます。今でも自分のやり方は、我流と言えば我流ですしそう思っています。アジャイル関係の書籍で読んだのはこの本一冊だけだし、そもそもXPって二人でやるモノなのでそれを一人でやれるように翻案してみたりしましたが、結局は自己流に落ち着いています。
自己流とは言え、ある程度はXPに沿った内容で実行しています。例えば、XPにおいては「コーディング、テスト、傾聴、設計」を書き出すことになっていますが、私は開発する単位においてはまず(詳細)設計から作ります。手書きのメモで、大体フローチャート・アクティビティダイアグラムだったりしますが、何をすればいいのかをざっと書き出してしまいます。
そしてコーディング。設計ができていればコードは設計通りに書けばいい、という持論があるので、設計通りに書いてみる。そして、最近取り入れたのがTDD(テスト駆動開発)の手法。MVCモデルみたいなフロントエンドとバックエンドがわかれている仕組みの場合は、とりあえずフローに基づいてフロントエンドを先に組んでしまう。そしてフロントエンド実行で発生したエラーがバックエンドのモデル(ビジネスロジック)部分になるのでコードを書いていく。
テストをパスすればお客様に「できたから見てちょうだい」と依頼する。それでヒアリング/レビューに代えられる。これまた最近のやり方は、レビューをオンラインで実施、その場で動かしながらその場で直せるものは直しちゃう。もちろんすぐに直らないモノもあるので裏でコードにコメントで打ち合わせのメモを残しておいて、「やっときますぅ～」と言って翌日あたりから開発にいそしむ、という。
あまり体系化されていないし、本当に自己流・我流なので、このあたりの説明はこれくらいでご勘弁願いたいのですが、実際問題、これでなんとかお客様に、多少ご迷惑はかけつつもなんとか何年間しのいでおります。
チーム開発とアジャイル
アジャイル開発が生きてくるのはやっぱり少数のメンバーでゴリゴリと開発していくシーンかな、と思っていたのですが、先日たまたまそんなゴリゴリのアジャイル開発現場に管理者として入り込むことができて、チームメンバーの「総意」としてアジャイル開発方式で行きましょう、というコンセンサスが取れていたので、ではアジャイルで、とやってみたのですが、これがまた、絵にかいたような大失敗。実は現在も失敗の火消し中ではあるのですが、その失敗を踏まえて、アジャイルってたぶんこんなのがいい、あくまでもこんな感じにすれば上手くいったはずでは？という意味を込めて*1ベストプラクティスを探ってみたいと思います。
失敗例
まず今回のプロジェクトは(詳細は守秘義務もあるので書けませんが)既存プログラム機能を使った新しいプログラムの開発。ほぼ既存プログラムのままで、少しデータの読み込み方を変えて、集計用の計算ロジックを考え直すくらいですむはず、というのがお客様の考えなので、工数も大してかからないだろう、ということだったのですが、私と私が率いるチームは今回この現場に入るのが初めて。既存プログラムについても見たこともなければ触ったこともない。似たようなシステムがあるわけでもないので(特定用途のためのシステムのため)、当然誰も何もわかっていない。
仕方がないので私だけ先行して現場に入り、まずは現行のシステムの理解をすることになるわけですが、そのために作ったのが実は「設計書」でした。と言っても、現在のプログラムを解析して設計書という誰が見ても分かる内容に落とし込むことで、この後に入ってくるエンジニアたちは設計書を見ればなんとなくシステムのやりたいことややるべきことがわかるはず、と書いてみました。
ある程度書き終わり、クライアントからの了承も得て、更にそのあと実際に作る設計書を基本設計レベルで書いてみたのですが、それをエンジニアに渡して、「ではここからは皆さんの出番ですのでアジャイル方式で開発進めましょうね」、とお願いしたところ、数日くらいしてから「何をしていいのかわからない」という質問が上がるようになってきました。
私としては、設計書は渡しているし、データベース構造の情報も渡しているし、そこから探って作り込んでいくしかないよね、と思っていたのですが、どうやらそうではなかった。よくあった例は、「この画面要素にどのデータベース項目を適用すればいいのか？」という質問*2。
その機能/表示項目は何をするものなのか、ということが設計書に書かれていた「はず」だと設計担当をしていた私はもちろん思っていましたが、設計書を読んだ人たちにはそれが伝わっていなかった。まず、設計書を読んでいるかどうかすらわからない。
とにかくそんな状況でずっとメンバーからの質問に答え続けて毎日が過ぎていき、次のプロジェクトにアサインされて次の作業を始めてもいい時期なのに何もできない、という毎日が実は今も続いていたりします。
失敗例に見る課題とその解決策
ここまで読んで、『そりゃそうだ』と思うでしょう。自分もまとめていて思います。こりゃ失敗するよね、と。
キックオフが実施されていない
私自身キックオフミーティングなどの実施は必須ではないとも思いますが、それでもメンバー全員が同じ方向を向くために、設計書の読み合わせや意識統一はされるべきでしょう。今回のプロジェクトではそれが一切行われていませんでしたし、途中参加のメンバーについてもドキュメントを読んで理解することは一切指示をしていませんでした。
「(プロジェクト)スコープ」の共有ができていない
ゴールがどこなのか、ということもチーム間で共有できていませんでした。ゴール、という言い方よりも、プロジェクトを管理する立場で言えば『スコープ』という言葉を使いたいのですが、プロジェクトそのもののスコープ(What to make)もわかっていないし、いつ納品するか、という情報すら伝わっていなかったメンバーもいたりしました。そのため、どれくらい工数がかかるのか、という質問に対して「わからない」という回答をしれっと投げてくるメンバーもいました。
「アジャイル方式」の定義が明確でない
これはかなり後のほうになって気が付いたことだったのですが、「アジャイル方式」と言ってもそれぞれが同じやり方をするわけではないわけです。自分の例が一番わかりやすいですが、いわゆる我流でやっているアジャイル方式は、もちろんほかの人が実施している「アジャイル方式」とは違うわけです。だとしたら、「アジャイルで」と言った場合に全員が同じやり方を指すとは限らないのだから、きちんとやり方を示すべきであっただろう、と思います。
[解決策]コミュニケーションを頻繁に取る
結局はコミュニケーションなんだな、と感じています。情報の共有、という言葉を使ってもいいのですが、ただ共有する＝シェアする、のではなくて、意識が統一されていることが重要になってきます。
実は今回の反省点をメンバー内でも報告しており、課題としてもコミュニケーションが大切だ、という話をしているのですが、どうしてもメンバー間ではそれが「ではコミュニケーションツールを導入することで云々」という言葉に翻訳されてしまい、ツールの選定を急ぐように指示をされているのですが、私はそうじゃないよ、と何度となく言っています*3。
コミュニケーションをとり、情報が一方通行ではなく相互に共有されるようになり、更にその情報が整理されたうえでメンバー全員の共通認識となる、という状態が正しいコミュニケーションの取り方、だと思っています。
ウォーターフォールとアジャイルの共存
実は今回の開発メンバーの中にもいたのですが、「ウォーターフォール方式とアジャイル方式は相容れない」という主張をする人は多いです。確かに全く考え方が違う、といえばその通りで、プロセス・計画重視であるウォーターフォール型に比べて、コード(納品物)重視のアジャイル、というのはその通りではあるのですが、「相容れない」とまでは言い過ぎでしょう。
今回の開発受託において、私自身が考えていたのは、基本設計フェーズまでは「ある程度」ウォーターフォール型で進め、途中から、または基本設計フェーズが終わり次第「アジャイル型(イテレーション型)」で進めるというやり方でした。そのやり方を伝えておらず、結局メンバーは開発ドキュメントを開発が始まる当日まで見ていなかった(提供していたのはもっと前であったにもかかわらず)、という状況であり、更には開発中にもドキュメントの一部しか見ていないメンバーが多数いた、という状況で、ドキュメントを作った立場の人間としてはここまでの努力を見事に水泡に帰してくれたものだ、と思うほどです*4。
アジャイル型開発においてドキュメントは不要である、という主張はよく聞かれるのですが、私自身はドキュメントがないことには何をすべきかがわからなくなる、と思っています。プログラムを書く立場の人間が必ず何かを残すべきか、という議論に関しては、それは人それぞれ、と思うのですが*5、全体の設計ドキュメントはもちろん必要になるし、それを疎かにすることは許されないはず、と思っています。
ウォーターフォール型の開発にアジャイル型の開発を組み込むとしたら...、と言う日本語自体がおかしい気もしますが、設計の一部→開発→試験の一部、または大部分をまるまるアジャイル型に置き換える、というやり方は可能なはず、と私は考えています。
ベストプラクティスを探すために書籍を紐解くことも必要だと思いますし、新しい方法論を採用したり、トライアンドエラーで改良を加えていくことでよりよい開発ができるようになる、と思っていますが、一朝一夕に上手くいくこともないでしょう。やってみるしかないのですよね。上手くやるためには。
*1:実際に次のプロジェクトが並行して始まるのでその時の運用テンプレートの作成を兼ねて...
*2:実は今回のプロジェクトメンバーはほとんど外国人だったという別の問題も抱えていて、日本語で書いた仕様書が外国人が理解するには少し難しすぎた、という問題も実はありますが、それを除いてもこの質問は多かった
*3:それでもツールを導入したいと急かしてくるのは、ゼロだったところから少しだけでもいいから進めなければ、というメンバーの焦りがあるのだろうと推測します
*4:もちろん、ドキュメントに目を通させることをしていなかったのが問題なのですが
*5:先述の通り私は詳細設計をメモレベルではあるけれど必ず作るので
