プロジェクトマネジメント

SIerがAgile開発を始めるための課題と対策

2019年10月12日

日経コンピュータに書いてある。2019年8月22日号。「さらばウォーターフォール型ベンダー」という見出しの記事。アジャイル開発が出来ないベンダーはユーザー企業から見放されるよ。前回私が怒りの提言記事を記載した。

書評
IT業界3つの時代遅れ、ユーザー企業の怒り爆発寸前に怒り爆発

リンクは載せておくが有料記事だ。内容は https://www.nikkei.com/article/DGXMZO49404950U9A900C1000000/ (同内容が日経コンピュータ2019年8 ...

続きを見る

私はシステム屋で働いているが、ウォーターフォール型のプロジェクト開発をしている。アジャイル開発のニーズが有るというのは分かる。ただね、ウォーターフォール型開発が悪、アジャイル開発が正義みたいな論調は如何なものかと思っている。

アジャイル開発
フォトジョーSzczepanskaUnsplash

プロジェクトの基本はウォーターフォール開発であるはず。例えば2019年10月1日から始まった消費税対応。法制度に照らしあわあせてどんな要件なのか、どんな機能が必要なのか?きっちり決めてスケジュール通りに納品する。こんな案件でアジャイル開発スタイル取る必要がある?ウォーターフォール開発はプロジェクト運営の基本形。基本を固めずに応用に走る。それがどれほど危険なことか。別の業界、スポーツ、勉強。さんざん言い尽くされていることではないか。

ベンダーで働くこと22年、今は中小企業で働いているSE崩れがアジャイル開発を始めるための課題と解決策を考える。

ココがポイント

  • そもそもアジャイル開発ってなんなんだ?
  • アジャイル開発を始めるための乗り越えるべきもの。




目次【本記事の内容】

ウォーターフォール開発の問題点

アジャイル開発の定義はなんだ、どこなんだ?

日経コンピュータに書いていたユーザーコメント

  • 依然としてウォーターフォール型での開発と検収でしか対応してくれない。求めても別の開発手法の提案が出てこない。(商社)
  • 今後ベンダーにはアジャイル開発にも柔軟に対応できる契約形態とビジネスモデルを求めていく。対応できないベンダーは見直していく。(通信サービス業)

私は問いたい。「アジャイル開発」とはなんですか?「アジャイル開発」という言葉を使わずにその人が望む開発手法の契約形態がどのようなものかきっちり説明して欲しい。だが無理なことだ。企業名と実名を出さずに上記のような主張する。ユーザー企業自身アジャイル開発に本気で取り組む覚悟が有るのか?なんでそんなにウォーターフォール開発を嫌がってアジャイル開発が必要だと言っているのか?

アジャイル開発と対比して悪者として挙げられるのがウォーターフォール開発。SI業界がプロジェクトマネジメントなんて知らなかった頃、プラント業界からプロジェクトマネジメントの知識を得た。私の先輩にプラント業界でプロジェクトマネジメントの仕事していて、ヘッドハンティングされてベンダーに転職してきている人がいた。プロジェクト管理の基本がウォータフォール開発。IT業界だけじゃない。

それがなんでこんなに悪者扱いされるようになったのか?その理由を理解するためにはウォーターフォール開発の定義を明確にし、それに対してアジャイル開発に抱いているユーザーの思いと課題を明確にする必要が有る。

ウォータフォール開発とは

ウォーターフォール開発とは

ウォーターフォール開発のプロセスは以下の作業の通りに流れていく。基本的に後戻りはできず、先行する工程で決まったことは修正しない事を基本とする。

  1. 企画(どのようなサービスを提供するか、ビジネス企画書を作成する)
  2. 要求定義(当該サービスに必要な業務要求、システム要求を定義する)
  3. 要件定義(要求をどのように実現するか、業務フロー、システム化の対象範囲、主要な機能、非機能要求(可用性、性能、運用保守性、セキュリティ、移行性を定義する))
  4. 基本設計(要件を実現するための画面、帳票、データ構造、バッチ処理、API、外部連携、インフラ、規約類を定義する)
  5. 詳細設計(個別機能のプログラムの振舞を定義する)
  6. 実装    (プログラムを作成する)
  7. 単体テスト(詳細設計通りにプログラムが作成されているか検査する)
  8. 結合テスト(個別プログラムを組み合わせて一つの塊として機能が動作するか確認する)
  9. 総合テスト(業務シナリオにそったテスト、性能テスト、セキュリティテスト、移行テスト、ユーザー受入テスト、システム運用テスト、障害テスト)
  10. リリース

上記のうち1~3までユーザー企業にて行われることがある。私がシステムエンジニアになりたての頃はそういうことが殆どであった。しかし、プロジェクトを重ねるにつれて、トラブルプロジェクトというのは上流工程に問題が有ることが叫ばれるようになった。だからベンダーもできるだけ上流工程から参画し、ユーザー企業とベンダーのシステムエンジニアが認識を共有することが推奨された。

早い段階で無理な要求事項があればその要求はシステム化するには難しいと、システムに詳しい人の判断があると上流工程の品質が高まることがわかっていった。最近の案件は要求定義工程から参画する案件が多いのはそういう事情だろう。

しかしウォーターフォール開発では様々な問題点が発生する。だからユーザー企業はアジャイル開発という言葉の響きに惹かれる。ウォーターフォール開発で問題になっていることが解消できる銀の弾丸だと思っている。

そういうことがアジャイル開発こそ正義という論調や要求につながっているのではないかと私は思うんだ。銀の弾丸なんてものは無い。そんな事わかっている。しかしより良いものを探求すると精神を失っても駄目だ。

ウォーターフォール開発で発生する問題点

1.要求定義をしてからシステムがリリースするまで長い期間がかかる。

ウォーターフォール開発の一番の問題はこれだろう。アジャイル開発の書籍でもまず述べられるのはこの観点である。

一般的には要件定義や基本設計が終わった段階でベンダーが見積もりをする。だから要件定義や基本設計の内容が変わると見積もりにずれができる。当初予定した予算や期間をオーバーする。だから一度次のフェーズに移ると最初に決めたとおりに作ってしまう。本当は変えたいと思っているユーザーの意向は無視して、もしくは一旦リリース後に様子をみて本当に変更が必要であればその時にやりましょう。などと言ってベンダーのシステムエンジニアはユーザーをなだめる。

ユーザー受入テストの段階になって要求したものがシステム化されて、実際にユーザーが目にする。要求定義をしてから実際にシステムを目にするまで半年や一年かかるのはザラである。これだけ変化の激しいIT業界で一年前の要求が現在の要求と一致することのほうが少ないのではないか?ITベンチャーが同じようなサービスの提供をはじめてしまった。Amazonさんが自分の業界に乗り込んできた。なるほどユーザー企業が絶望するのは最もだ。

2.プログラマーストレス問題

繰り返すがウォーターフォール開発では前工程に戻ってやり直すというのはご法度である。そんな事はプロジェクト計画を作成する時に考えてはない。

詳細設計フェーズから実装フェーズになると起こる問題が、

  • もっといい実装方法が有るのですが?
  • 別の画面と共通で使えるロジックが有るので共通化していいですか?
  • 今回の変更点とは違うのですが、既存ロジックがイケてないのでリファクタリングしておきました。

とプログラマーの人が言い出す問題だ。

分かる。分かるよ。みんなの気持ち。私も若い時はプログラマーだった。マーチン・ファウラーのリファクタリングやコードコンプリートを読んで完全なプログラムを目指した時期もあった。それなのに立場が変われば言うことも変わる。プロジェクトを期日通りに要求どおりにシステムを作って終えるのが私の仕事だ。だから心を鬼にして言わなければならない。

生徒
詳細設計工程に手戻る事になるから詳細設計どおりに進めてくれ。

残念そうな顔をするプログラマーの人たち。プログラムで作りたいものを作る喜びがプログラマーの醍醐味だろう。

詳細設計通りに作るのなら創造性や工夫なんか必要ない。ただタイプしてコンパイルするだけだ。中にはやる気を無くしたプログラマーが、もう今月で契約を終わりにしたいと言ってくることもある。それもやむを得ない。前工程に戻ってプロジェクトが遅延するのはご法度だ。私だってコピペだらけのソースや解読困難なソースを見るのは嫌だ。こんな嫌なことを言わなければならない仕事だったらいっそプログラマーに戻るかとも考えたぐらいだ。

アジャイル開発

アジャイル開発の定義とは

リス
フォトドゥシャンスメタナUnsplash

アジャイル(Agile)=「素早い」「機敏な」「頭の回転が速い」

言葉の定義だけを聞くと、これや!これが求めていた開発手法や!と思わざるを得ない。「遅い」「のろまな」「頭が悪い」そんなふうに誰も言われたくないだろう。アジャイル開発やろうじゃないのと思わせてしまう響きがある。私だってそう言われたい。ITプロジェクトやっていれば誰だってそうなりたいと思うだろう。

ウォーターフォール開発で定義した問題点を解消するための手法がアジャイル開発手法ということであれば以下のように定義することができる。

  1. 要求定義をしてからシステムリリースまでの期間が短期間
  2. プログラマーはエレガントなコードを書くことができる。リファクタリングできる。創造性を発揮できる。

これがアジャイル開発で実現できると聞けばシステムエンジニアなら挑戦したいと思うだろう。ユーザー企業のシステム部門の人たちだってこんな方法が有るという本を読めばアジャイル開発でプロジェクトを進めてみたいと思うに違いない。私だってそう思う。ではなぜ日経コンピュータの記事にあるように、アジャイル開発をはじめないベンダーが多いのか?

アジャイル開発の問題点

今の時代はどんなサービスを提供すれば成功できるのかわからない時代。要求定義ってやってみても何を要求すれば良いのかユーザー企業の人がわかっていない。

とりあえずこんな感じでって要求出してみるけど1年かけて開発したものが、市場に投入してみたら全然使われず。これじゃない。こっちの要求だったかも。そんな事を半年や1年サイクルでやっていたら、当たりを引くまでとんでもない時間と金を浪費する。

でもベンダーから見たアジャイル開発を提案できない理由も何となく分かる。ウォーターフォール開発では以下のようにプロジェクトに参画するメンバー数が推移する。

最初にプロジェクトの工数が分かる。マスタスケジュールがわかる。だからいつ頃要員を手配すれば良いかも分かる。いつぐらいから何人ぐらいのプログラマが必要だから手配してほしいと協力会社の人にお願いするのだ。

要員の推移

 

対してアジャイル開発ではどうなるか?

アジャイル開発の要員推移

短いサイクルで要求分析→開発→検証のサイクルを繰り返すから要員のアサインが断続的に増員・減員を繰り返さなければならない。一度要員を開放してしまうと、同じ要員を都合よく次のサイクルでアサインすることは無理だ。

また、少数精鋭体制にになるからビジネスの話もできてシステムにも詳しくて実装する力もあってというスーパーエンジニアが必要になる。そんな人はそうそういない。いたとしても今までのウォーターフォール開発ではスーパーエンジニアの下にシステムエンジニアやプログラマーを何人もつけて人月を稼げていたのに。アジャイル開発では少数精鋭体制だから人数もそれほど必要ない。かと言って単価を上げるとユーザー企業の人に怒られるだろう。

  • ビジネスも分かってシステムにも詳しくて実装もできて運用もできるシステムエンジニアがいない。
  • プロジェクトが短いサイクルで推移するため、要員を連れてきたり手放したりしないといけない。

それではアジャイル開発案件を受けられるようにするにはどうするか?

アジャイル開発の問題点を解決する提言

ベンダーから見るとアジャイル開発のというのはリスクがある。ユーザー企業から見てもせっかく一回目の開発に携わってなれてくれた人が二回目の開発のときにはいない。これは生産性が落ちるしデメリットだろう。

だったらアジャイル開発する間は繁閑に関わらず一定量の仕事を出すからという覚悟でユーザー企業も臨んではどうだろうか。要求事項も決められないのだから準委任契約になる。ベンダー側にとってもアジャイル開発の実績ができるし、ビジネス強いシステムエンジニアを育てることができる。そりゃ売上減るかもしれないけど。何もしないよりマシでしょ?

道幅契約

プログラマーの中には業務知識が必要な設計を好まない人もいる。だったらそういう人たちに空いたタイミングでドキュメントとソースの整合性を取る前提でリファクタリングしたり回帰テストの整備やってもらうような事をお願いすれば良いのではないか。谷間の時期にもプログラマーの人たちを稼働させて、より良いプロダクトにするための作業は作れると私は思う。

 

まとめ

日経コンピュータの記事に触発されて自分なりに考えてみたけど、私自身は明確にアジャイル開発プロジェクトというのを経験したことはない。ただ、アジャイル開発の手法を一部使ってみたりはしている。

1.ペアプログラミング

これは若い時にまだプログラミングしている時に試してみたけど、自分には合わなかった。新人の教育時。自分がよくわからない所を分っている人に教わる時。ロジックが難しい所を複数人で考える時。そんな時に部分的に取り入れるには良いのかな。今はモブプログラミングが流行っているみたいだけど、設計やマネジメントする人はモブ設計とかモブ計画づくりとか普通にしていませんでした?

私は主要メンバー集めてマスタスケジュールを一緒に考えたり、リスクの洗い出しをやっているから若い時にペアプログラミングを経験したことに影響されているのかもしれない。

2.ツールやプロセスよりも個人との対話を

アジャイルソフトウェア宣言の一節。包括的なドキュメントと動くソフトウェア。どちらも大事だと思っている。動くソフトウェアだけ作って包括的なドキュメントがなければシステムの保守性が悪くなる。ただ、ドキュメントがあれば会話はいらないと考えているシステムエンジニアが居る。職人気質なのか、話下手なだけか。メールでひたすら反対意見の応酬とか。そういうのを見ると膝突き合わせて話せよと私は思ってしまう。

設計書を書いたあと、プログラマーの人に説明するときドキュメントは当然書くとして対面でも説明するようにしている。疲れている顔をしているメンバーがいれば大丈夫か?疲れ溜まっているなぁ。って声をかける。

3.嘆いても始まらない。動き出そう。

私が経験したウォーターフォール開発で、三段階に分けてリリースをするという案件を経験したことがある。一回あたり三ヶ月の案件を三回するイメージ。しかも、これが顧客からの提案だった。ベンダー側の我々としても要員の山が高くなりすぎず、段階を分けてリリースすることは構成管理の手間が増えるという事はあるが、リスク低減できる良いことだと思った。

本来だったらそういう提案を私達ベンダーの方からしなければならないのだが。三ヶ月というサイクルはスクラムが提唱する、最長四週間単位でリリースするよりは長い。でもその案件は基幹システムを改修する案件。ある程度要員数も必要だし、要求事項が不明確だったわけでもない。

ウォーターフォールはだめ。アジャイルが正義。みたいな論調は如何なものか。アジャイル開発の「要求事項をユーザーは考えることができない」という前提。ユーザー企業の人達はこれ読んで頭にこないのかな?今回の特集が組まれた日経コンピュータ2019年8月22日号に木村編集長の極言正論で、

契約書を作成しないで開発に着手してしまうのは、ユーザー企業がシステム要件を固めきれないからだ。

と巻頭の記事で語っているのである。システム要件を固めるのはユーザーの責任だと木村編集長は言っているし、私もそう思う。ユーザー企業が要件定義書を承認しておいて、プロジェクトが終わってみると「ベンダーの作った要件定義書が悪かったから今回のプロジェクトは失敗」という責任回避をするものは如何なものか。

 

ウォーターフォール開発がいいのかアジャイル開発が良いのか?それは案件の特性によっても違うだろうし、ユーザー企業やベンダー企業のプロジェクトメンバー特性によっても変わってくるだろう。

くしくも日経BP社から出版されているFACTFULNESSの中から引用をもって締めくくりたい。

ひとつの集団のパターンを根拠に物事が説明されていたら、それに気づくこと。

パターン化は間違いを生み出しやすいことを肝にめいじること。

違う集団の間に共通項を探そう。異なる集団の間に、はっとするような共通点を見つけたら分類自体が正しいかどうかを改めて問い直そう。

「アジャイルソフトウェア開発宣言で計画に従うことよりも変化への対応を」という柔軟性を示しておきながら、「イテレーションの間は要求を変更しない事」という面白い方針が示されている。ウォーターフォール開発でも聞く話である。

 

参考文献

  1. 日経BP社 日経コンピュータ2019年8月22日号 当該記事WEBサイト
  2. 小椋 俊秀 著 ウォーターフォールモデルの起源に関する考察 ウォーターフォールに関する誤解を解く。(リンク
  3. バートランド・メイヤー 著 アジャイルイントロダクション(amazonリンク
  4. IPA情報処理推進機構 ITSS+ アジャイル領域(リンク
  5. ハンス・ロスリング FACT FULNESS (amazonリンク

-プロジェクトマネジメント
-,

Copyright© ビジネス中学 , 2019 All Rights Reserved.