現場から届けるアジャイル開発(5) パラレルプログラミングとは？

パラレルプログラミングとは

パラレルプログラミングとは、要件定義や設計中にプログラミングを並列に(パラレルに)実施するという手法です。この手法は、近年自分がチームリーダーを務める全てのプロジェクトで採用している手法です。今回は「パラレルプログラミング」を導入するメリットについて考えていきます。

これは、一般的にシステム開発では最も行なってはいけないとされている方法の1つです。通常は要件定義で何を作るかを明確化し、そして設計でどのように作るかを決めてから実装に入ります。アジャイルではイテレーション開発などで開発期間を短く何度も繰り返す進め方をすることが多いと思いますが、それでも要件定義で何を作るのかを明確化し、設計でどのようにつくるかを決定してから進めることが多いはずです。

パラレルプログラミングでは要件定義すら決まらないうちに作り出すというのですから、どういうこと？と疑問を持たれる方も多いでしょう。

上流工程での不具合

上流工程では要件定義で何を作るのかを明確にし、設計でどうやって実現するかを決定していきます。要件定義に入る段階では、お客様は「何を実現してどういう効果を得たいか」というビジョンは持っていますが、開発側はまだきちんと認識できていません。開発側はもお客様の要求事項が何かをよく理解したうえで設計に入るのは自然の流れです。

そして開発者なら一度は聞いたことあるフレーズとして、「上流工程の不具合は下流工程ではコストと期間が大幅に増大する」があるかと思います。上流工程で間違った要件定義や設計書が作成されたら、その後の実装やテストもすべて間違えていることにになるのですから、普通に考えると確かにその通りと思われます。

しかし開発現場をよく見てみましょう。毎回経験豊富なエンジニアが複数人で要件定義や設計をし、入念にレビューも繰り返したはずなのに必ずと言っていいほど上流工程の考慮漏れや問題が下流工程で発覚しています。そしてプロジェクトが終了するたびに「振り返り」を実施し、「上流をもっと重要視し、より時間をかける。人数も増やし、レビューも徹底する」なんて対策が決定されるのです。よく考えて下さい。今まで何回システム開発をしてきたのでしょう。その都度同じ対策をたてていませんでしたでしょうか。そのような対策は有効だったのでしょうか。実際には次のプロジェクトでもいくら上流をきちんとこなそうと思っても、下流工程で上流での問題が発覚し毎回苦労してきたのではないでしょうか。

完璧な上流を捨てる

完璧な上流を実践することはほとんどは不可能だと思います。よほど単純なシステムならば可能かもしれませんが、ビジネスとして成り立つ難易度のシステム開発ではやはりほとんど不可能でしょう。要件定義や設計でいくら完璧と思っても、実際に開発後半でシステムを動かすといくつも問題や不整合がおきるものです。

要件定義や設計は重要ではない、と言うつもりはありません。しかし、ドキュメントや打合せだけではどうしても気づかない部分があるものです。そこを気づくことができなかったから、開発の後半で火を噴くプロジェクトとなってしまうのです。推理小説でもトリックがわかってしまえば「ああ、なるほど」と感じますが、前半部分ではそのトリックにはまず気づくことができません。システム開発でも同じです。

ただ開発前半で問題に気づかなければやはり工数は増大するのはその通りです。そこで、パラレルプログラミングという手法を取り入れている、という訳です。

パラレルプログラミングの実践

実際に自分が開発に関わる場合は、プロジェクトのスタート時点から開発に携わるメンバーを全員集めます。想定どおりにいかないこともありますが、基本的に開発の立ち上げからリリースまで同じメンバーで作業します。要件定義だから少数で、開発になったら人数を増やすということは行いません。

そして要件定義で「なんとなくこういうことがしたいのかな？」という感触を得たらその時点で開発に入ります。ドキュメントは非常に簡易なものをWikiに記載して共有します。そして毎日の朝会で日々の作業の確認をし、動くシステムを作り上げていきます。

もちろん、お客様との打ち合わせなども並行しますが、ある程度動作するようになったらその時点でお客様にシステムを触ってもらいます。Webのシステムの場合はクラウド上で作りかけのシステムをお客様だけに公開し確認してもらいます。最近ではタブレット案件なども多いので、その場合は機能が増えるたびにアプリをインストールして端末ごとお客様にお渡ししています。

こうやって出来る限り早期に動くシステムを作り上げることで、お客様から早い段階でフィードバックを得ることができ、結果的に期待通りのものを作ることができる、という仕組みです。

実際に動くシステムを作っていくと、通常なら開発後半でしか気づきにくいような問題や不整合、齟齬にもその場で気づくことが多くなります。システム開発で最も問題なのは、下流工程で不具合が発覚することではなく、開発期間の後半で問題が発覚することなのです。開発の残り期間が長ければ、柔軟な対応も可能ですし、前回ご紹介した「捨てる技術」を活かす機会も増えます。しかし、開発後半では何を捨てるかを考える余裕もなく、要件や実装を変更することも難しくなります。

開発前半に問題を発見するには開発前半に実装するしかない、というのが結論です。実際に冒頭でも申し上げましたが、最近は全ての自分のリーダープロジェクトはこの方法で進めており、すべてが問題なくリリースすることができています。

パラレルプログラミングの効果

パラレルプログラミングには、その他以下の様なメリットもあります。

開発メンバーが毎日を充実して過ごすことができる

やはり設計書だけの作成はあまりおもしろいものではないと感じる人が多いと思います。実装をして動くシステムを確認する作業は楽しく時間も早く過ぎます。毎日が充実しているとチームの生産性は何倍にもなります。

見積もり時に導入すると効果絶大

実はパラレルプログラミングは見積もり時には特に有効です。見積もり時に簡単な実装をすると驚くほど見積精度があがります。プロジェクトの規模や状況に応じて見積にかけるコストはさまざまですが、数日だけでも実装をすると「この要件を実現するには、こんな問題があるんだ」と驚くことが多々あります。つまりそれだけ通常の見積では気付かなかった必要工数などに気づくことができ、より適正な見積もりを算出することが可能になるのです。

注意点

こう書くと良いことばかりのようですが、導入するにはいくつか気をつけなければいけない点もあります。

お客様との交渉

要件の変更が最後まで止まらない場合もあります。そのような場合は前回ご紹介の「捨てる技術IT編」などを駆使して、本当に必要な要件に絞ってリリースをするようお客様と交渉していく必要があります。

残業は禁止

パラレルプログラミングを実施していると要件変更が非常に多くなる、ということは理解しておく必要があります。要件変更が多いと、せっかく作ったものに対して作り直しが多く発生するため、開発者にとっては大きなストレスになります。このストレスが「作り直しのないよう要件を明確に詰めてから実装を指示して下さい。」となり、入念な要件定義や設計を開発側からも要求されることになるのです。一見ムダを排除するために必要なようにも感じますが、要件変更のない要件定義をすることができないため、このムダな実装も必要だという判断です。とはいえ作り直しはストレスになるので、あくまで就業時間以内の作業としてメンバーに依頼することが大事です。

テストコードは必須

要件が変更されれば当然実装を修正し、再テストが必要になります。この再テストに時間やコストを掛けていてはパラレルプログラミングは成り立ちません。単体テストコードは必須です。単体テストコードがあれば、デグレードを回避する回帰テストをコマンド一発で実施できます。CIを導入していればより確実にその変更対応の問題にも気づきやすくなります。従来型では一度作ったものを修正することは、デグレードの温床となるため、手動で全テストをやりなおす必要があり非常にコストがかかっていました。しかし、現代では単体テストコードやUI操作のテストなどを自動化できる技術が確立されています。そのため以前よりは要件変更に対する確認コストが大幅に減っているのです。つまりテスト自動化により要件変更の影響を最小限にとどめることができるということです。(テストの自動化範囲をどこまで広げるかは適宜プロジェクトに応じて検討が必要ですが、最低でも単体テストコードは必要です。)

簡易なドキュメント維持

コードだけではなくドキュメントにも変更が大量に発生します。そのため、自分のプロジェクトでは、「第2回ドキュメントを効果的に保つには」でご紹介したように全員参加のWikiをドキュメントの維持管理に使っています。要件変更のたびに仕様書も修正しなければならないので、WordやExcelで共有フォルダ管理などでは修正のスピードに耐えられません。最近ではGitなどでドキュメントを管理するプロジェクトも多いようですが、如何に早く簡易に維持管理できるか、を考慮すると現時点ではWikiが最も適していると感じています。

まとめ

いかがでしょうか。パラレルプログラミングとは、コストのかからない回帰テストや簡易なドキュメント共有ができる現代だからこそ実施できる手法です。ウォーターフォール全盛時代にはこのような手法ありませんでしたが、時代の変化に伴って効果的な開発手法も変わってくるということです。

パラレルプログラミングは組織によっては導入は難しいかもしれません。その場合は、パラレル開発を始めるタイミングを出来る限り早くするという努力をすると良いでしょう。見積時に無理なら要件定義時に、要件定義時が難しければ設計時にというように、できるだけ早期にパラレルに実装を開始するのです。目的は「いかに早く問題に気づくか」であり、そのためになるべく早く実装する、というだけなのですから。

次回は、「朝会議事録」をお伝えします。

執筆者紹介

川上文夫

パッケージベンダーのグループマネージャーとして複数プロジェクトのPM、PLを兼務。要件定義からプログラミング、テスト、運用を担当している。数多くのプロジェクトのリーダーとして20年のキャリアがあり、オフショア開発の経験も豊富。独自プラクティスに軽量議事録、朝会Wiki、設計実装並列手法などがある。アジャイル系コミュニティにも所属し、記事の執筆やワークショップ登壇など精力的に活動を続けている。