私はいくつかのアジャイル開発のPMを担当してプロジェクトが成功になり、自分にとってアジャイル開発が重要の存在です。最近以下の記事をみて、反論する気持ちが沸いて、アジャイル開発の成功要素をまとめてみたいです。
「幸福な家庭はどれも似たものだが、不幸な家庭はいずれもそれぞれに不幸なものである」という言葉があって、同じく、「成功なアジャイルはどれも似たものだが、失敗なアジャイルはいずれもそれぞれに失敗なものである」も一理になるでしょう。この記事はアジャイル開発を試したい方のご参考になれば幸いです。
どうするPMさん？
若いとき知り合いからの言葉ですが、「会社の営業さんが努力してお客さんと接触できて小さいプロジェクトからスタートして成功して信頼されて、発注がどんどん拡大されて、大規模のプロジェクトになると延期したり予算オーバーしたりいろいろトラブルが発生して、縁が切ってしまって、次のお客さんを探さないといけない」。
業務を分かるお客さんの担当者が設計できないし、設計できるSEさんが業務を知らない状態から、プロジェクトがスタートして、みんながゆっくり背景知識を準備する余裕がありません。お互いの用語を勉強しながら、プロジェクトを進めます。小さい規模の場合、認識疎通しやすいが、大きいプロジェクトになると、伝言ゲームみたい認識の歪みがどんどん発生します。
開発チームとお客さんの担当者は運命共同体です。成功になれば、次期開発に繋がって、お客さんの担当者は昇進し、開発チームはボーナスが貰えます。「失敗は成功の母」ですが、社会人は母親を連れて出世できません。失敗になったら、お客さんの担当者が転職し、開発チームは解散です。
どうするPMさん？アジャイル方式の回答は、ある程度のやり直しを覚悟して、本番可能のスモールプロジェクトの連続にしましょう。
- ある程度のやり直し
- 本番可能のスモールプロジェクト
- スモールプロジェクトの連続
なぜ「本番可能」が必要か？
「本番可能」の装飾子は大事です。本番にすれば、お客さんの担当者の成績になり、業務の現場のフィードバックもきます。これで、要件⇒設計製造⇒本番⇒指摘⇒要件調整、いわゆる閉ループ制御の実現です。
なぜ「スモール」が必要か？
小さいプロジェクトなら人数が少ないです。伝言ゲームが発生しにくいし、プロジェクト統制しやすいし、成功の可能性が高いです。また、開発期間が短い、つまり閉ループ制御の制御周期が短いので、「システム」の安定に繋がります。ここの「システム」は開発するコンピューターシステムのことではなく、開発チームとお客さんの協力関係のことです。
なぜ「やり直し」が必要か？
２つの原因があります。１つは、最初できたものは、お客さんの既存システムと外部連携が必要です。でも将来の完成形のシステムにはその連携は要らない、あるいは別の連携が必要かもしれません。もう１つは、業務現場のフィードバックの反映です。そして、ある程度の「やり直し」は、開発チームとお客さんの担当者が認識して見積りとスケジュール設計時考慮すべきです。
どうするSE/PGさん？
「SEなら仕様を書く、PGならプログラムを組む」というのは従来の考え方です。仕様も書く、プログラムもやる人ならSEPGと書きたいですが、すでに別意味の専門用語になっているので、仕方がないから「/」をつけます。
自分のチームに、ひとりのメンバーはお客さんの担当者から要件をヒヤリングして、画面イメージなど作成してレビュー依頼を出します。問題なければ、基本設計を書いてチーム内レビューします。プログラムを組んで単体テストエビデンスを作成してリリース責任者に提出します。リリース責任者は納品物をチェックして、結合の観点で動作確認して、お客さんへUAT依頼に提出します。簡単な機能ならこれで終わります。複雑な機能の場合、しっかりした結合テスト仕様書を作成してテストします。特徴は設計と製造は同じ人です。
- 機能ごとの仕事割り振り
- みんなが窓口担当
- 順番にリリース当番
機能ごとの仕事割り振り
ウォーターフォールの場合、プロセスで仕事割り振りします。設計と製造は担当者が変わるから利益を違います。SEは早く設計書を片付けたいから、PGの意見を取り込むことはさほど積極性がないです。また、SEとお客さんとの検討はPGに結論しか伝えないので、疑問を抱えるPGは変な誤解を生じます。
SEかPGかと関係なくてそれぞれ１機能の設計製造両方を担当すれば上記伝言ゲームの問題をクリアでしょう。
みんなが窓口担当
とはいえ、仕様を見ない聞かない話さない、プログラムだけをやりたい技術者がそれなりの数です。伝言ゲームを壊したら、一人ずつ積極的に仕様を確認したりまとめたりなどをやらないといけないです。つまり全員窓口です。
仕様確認の結果のみではなく、それにたどり着くプロセスもレビューできる仕組みが必要です。そのためSlackなどのチームコミュニケーションツールを導入すれば、PMまたはベテランは若手をフォローできるし、全貌を把握しやすいです。
順番にリリース当番
新しく作成できた機能はすでにリリースしたシステムに加えるため、検証サーバにて結合or総合のテストが必要です。大抵１～２カ月ひとりずつ数機能が作成できて、本番可能のものを選別してリリース作業を行います。
ソース・基本設計・エビデンス・リリース手順書など資材を準備します。緊張感と達成感たっぷりでありながら、他人の作業を理解するチャンスにもなるので、できれば順番で担当されたらよいと思います。
どうする技術長さん？
アジャイルの出番は開発技術の進歩と深く関わっています。
COBOLとVBの時代にアジャイルの言葉はありません。数人１カ月で数画面しか作れないので、それを持って本番するのは寂しいです。効率のよい開発手法がないと、開発チームはバグと戦うばかりで業務実装に専念できません。Javaの時代に開発言語とその関連技術はどんどん進歩していますが、アジャイルのため発明されたものではないのです。
技術の細かい箇所にひっかからず、業務に専念してもらいたいアジャイルに対して、どうする技術長さん？
「技術長」とは開発チームに技術のNo.1を指しています。アジャイルにしたいなら、このような立場の人物は、開発言語と技術を選んで、効率よい開発方式を決めて、開発便利、やり直し便利にする必要です。「便利ってなに？」、若手がうまくできないものを無くすことでしょう。
- 必要な勉強を絞り込む
- フレーワークで面倒な箇所を避ける
- 基本設計により開発可能
- 従来の技術と親和性がよい
必要な勉強を絞り込む
自分はJavaのWeb系に得意です。一般的に一人前になるまで、以下の勉強が必要でしょう。
HTML
CSS
JavaScript JQuery Ajax JSON
Java FrameWork
SQL Database
各種Javaのフレームワークはそれぞれの考えでその中の一部を代替したり合併したり努力していますが、Java・JavaScript・SQLの３本柱は変わらないです。※HTMLとCSSは一般的にはおまけの存在です。
１０数年前intra-martの「ページベース開発モデル」に携わりましたが、「JavaなしのJava開発」もありと啓発されました。うち会社の自社フレームワークを開発時「JavaなしのJava開発」の特徴も取り込んでみました。
またほかいくつかのポリシーを取り込んで必要な勉強は以下のように絞り込み成功です。
HTML
CSS
JavaScript JQuery(Selectorのみ)
SQL Database
実績によりこれは一つの正解だとわかりますが、唯一の正解といえません。世の中にまだいろいろな探索方向があり、慎重にお見守りましょう。
フレーワークで面倒な箇所を避ける
一つの例を出しますが、以下の記載レベルは多分一般的な基本設計でしょう。エンドユーザさんは絶対文句がありません。
CSVファイルを開いて一行ずつ読んで取込処理を行う。
処理中エラーが発生する場合、以下のエラーメールを送信する。
...
でもPGからファイルハンドルを閉じる処理を記載していないと指摘されるかもしれません。その内容が書いたら細かすぎると反論するSEさんがいます。
もし上記ファイルを閉じる処理のような面倒な箇所をフレーワークの実装で実現できたら、基本設計から開発できてメリットが大きいです。
| 実装案 |
|---|
| ・JSPと各種サーバレットに対するフィルターを設ける。 |
| ・ファイルを開く関数でスレッドコンテキストにファイルハンドルを登録する。 |
| ・フィルターに個別処理を実行された後、スレッドコンテキストから登録されたファイルハンドルをループする。 |
| ・個々のファイルハンドルが閉じったかどうかをチェックして、閉じっていないものがあるとそれを閉じる。 |
このような工夫の積み重ねで、プログラムは基本設計とマッピングしやすくなります。以下はうちのフレーワークはこのあたりの努力です。
db._closeAll();
Excel.prototype._closeAll();
CSVWriter.prototype._closeAll();
framework.removeRequest();
framework.removeResponse();
FileManager.removeUploadFiles();
framework.removeI18nProp();
framework.removeThreadLogs();
framework.removeRestStatus();
framework.removeNumberFormats();
framework.removeDateFormats();
基本設計により開発可能
上記「面倒処理の共通化」によりプログラムがある程度簡略になりますが、詳細設計不要まで物足りないです。以下２点をフレーワークに実現すればもっとよいでしょう。
- プログラムの順番は基本設計の順番と近い
- プログラムの粒度は基本設計の粒度と近い
この点についてうち会社の自社フレームワークの対応は以下の記事に記載しました。
従来の技術と親和性がよい
フレーワーク改善で生産性アップする話は、オブジェクト指向の言葉ならほぼ「隠蔽」というキーワードでしょう。複雑なプログラムをフレームワークの中に隠して、わかりやすい・使いやすいインタフェースを提供することです。だが、そのインタフェースで満足できず、どうしても従来の書き方でなければならない場合、フレーワークはこれを対応できないと仕事が進まないです。
例えば、Spring JPAは、DB処理のSQLを隠蔽しました。だが一旦ちょっと複雑なSQLが必要になるとき、どうすればよいか答えがないです。それでMyBatisと併用するというイマイチの退避策で凌ぐでしょう。だが、もしSQLは１０個テーブルのJOINのような複雑なものなら、MyBatisにも記載しにくくなります。このためにテーブルJOINをやめて、一つずつのエンティティを設けるとどれほど複雑になるか想像してください。
うち会社の自社フレームワークには以下のような対応例があります。
| 対応例 |
|---|
| ・基本的にjavaScriptでプログラムだが、必要に応じでJavaのプログラムをも取り込める |
| ・SQLを外だしXMLに格納するが、必要に応じてプログラム中に文字列のSQLを組み立てて実行できる |
| ・基本的にHTMLにjavaScriptを書かないが、イベントの戻り値にeval関数を利用すればクライアント実行のjsを書ける |
一歩進むとともに、一歩引けるように準備します。こうすれば現場からのフレーワークに対する苦情がなくなるでしょう。
まとめ
アジャイルはチーム内外のコミュニケーションを一層重視すべきです。アジャイルは仕様書なしでなく、詳細設計からでなく、基本設計から開発すべきです。このあるべき姿を目指して、いろいろ探って開発プロセスを革新しましょう。
※ 本記事はQmonus Value Streamの投稿キャンペーン記事です。