開発モデルとQCD

日付:

開発モデルとQCD

 
 
このエントリーをはてなブックマークに追加 　 　
シェア
　
今回は、開発するうえで、やり方の基盤となる開発モデルと、QCDについて解説したいと思います。

開発モデルについては、よく使われるウォーターフォールとアジャイル開発について取り上げます。
 

開発モデル

開発モデルとは

（システム）開発モデルとは、開発するうえで目的・目標にあわせて標準化された手順やプロセスのことを言います。
 
微妙に難しいので簡単に言うと、「どういうシナリオで開発していくか」ということです。
開発モデルは以下のようなものがあります。
  • ウォーターフォール
  • アジャイル
  • プロトタイプ
  • スパイラル
  • DevOps
前述しましたが、今回はよく使われるウォーターフォールとアジャイルについて説明します。
私としても、ウォーターフォールとアジャイルとプロトタイプ開発しか経験がありませんので。。。
 

開発の工程（マイルストーン）

開発モデルの中で用語として出てくる開発工程について、一覧化しておきます。
何故なら、しばしば開発者は略語（アルファベット2文字）で開発工程を話すためです。
 
なお、以下の一覧については、モデルや、プロジェクトによって微妙に言い方が変わってきますので、この限りではありません。
  •  開発計画・企画
    • 開発を始めるうえでの計画や企画
    • ほとんどの場合、開発者とは関係ない
  • RD
    • Requirements Definition
    • 要件定義：機能要件や非機能要件
  • BD
    • Basic Design
    • 基本設計：開発の概要、ユースケース、保証バージョンなど
  • FD/AD
    • Function Design/Architectural Design
    • 機能設計/方式設計：開発する機能全般、概念クラス、画面、DB設計など
  • DD
    • Detail Design
    • 詳細設計：物理的な設計、クラス定義、処理詳細など
  • CD
    • Doding
    • 製造：ソースコード記述、レビューなど
  • UT
    • Unit Test
    • 単体テスト：クラス・メソッドや機能に限定したテスト
  • IT
    • Integration Test/System 
    • 結合テスト：機能をつないだテスト
      しばしば内部結合テストと外部結合テストに分けられる
  • ST/OT/QT
    • System(Scenario) Test/Operation Test/Quality(Qualification) test
    • システム(シナリオ)テスト/運用テスト/品質(適正)テスト：本番と近い状態のテスト
      運用できるか、性能は問題ないか、脆弱性はないかなどを確認する
  • (U)AT
    • (User) Acceptance Test
    • 第三者（受入)テスト：客先が開発したものが正しいかを判定するテスト
 

 ウォーターフォール開発

ざっくり、開発モデルとは何か、工程に何があるというのがわかったところで、次にウォーターフォール開発について、説明します。
 

ウォーターフォール開発とは、工程を順々に進んでいき、問題があっても逆戻りをせず、一つずつ適切に終わらせていくものとなります。
言葉の通り、「水（ウォーター）が落ちる（フォール）」ように流れに沿ってやっていくもので、よく滝と表現されます。

なお、ウォーターフォールでは、Vモデルという、製造前と後で対比させる考えがよく用いられます。「開発したものが要件定義を満たすことを確認するために品質テストを行う」、「開発したものが基本設計、機能設計を満たすことを確認するために結合テストを行う」という考えです。

図にすると以下のようになります。

メリット

工程を一つずつやりつつ、完成させていくため、管理しやすいものとなります。
また、作業者としても、素早く次を考える必要がないため、1つのことに集中することが可能です。
 

デメリット

前述しましたが、「後戻りしない」事が前提であるため、計画、設計にミスがあった場合に、仕様変更することが難しいです。
 

アジャイル開発

アジャイル開発とは以下のマニフェストにのっとった開発になります
 
私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。

プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、

価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。 

 
簡単に言うと、「顧客からの要望を優先」し、「仕様変更や改善されることを前提」に、「短いサイクルで設計、開発、テストを繰り返す」開発となります。
 

メリット

開発の中で軌道修正が早く、顧客のニーズに合った開発が可能です。
最終的な製品完成スケジュールが同じでも、顧客のニーズに合ったものが最終的に出来上がるというわけです。
※ スケジュールが早くなると勘違いしている人が多くいる気がします。
 

デメリット

顧客のニーズに合わせようと、仕様変更、改善により、スケジュール調整や仕様調整の負担が大きいです。
顧客との調整が多くなるものがアジャイルなので、「開発者に全部お任せ」「開発知らない」みたいな顧客には合いません。
 
なお、アジャイル開発を求めておきつつ、アジャイル開発を否定する発言が多い現場があることもデメリットと言えるでしょう。
 

アジャイル開発という魔法の言葉

開発していく中で、ウォーターフォールでなく「アジャイル開発ならうまくいく」という勘違いをしている上層部が結構います。
多分、「いつまでウォーターフォールなんて古い開発しているんだ？アジャイル開発にすればいいじゃん」という他からの発言を受け、何も勉強せず、理解もせずに、下の人間に「アジャイルでやれ！」という人でしょう。
 
正直、ウォーターフォール開発に慣れきってしまっている日本人に、アジャイル開発は向いてない開発モデルと私は考えます。
なぜなら、日本人は「完璧に完成されたものを欲する」からです。 
 
ウォーターフォール開発の本はほぼなく、アジャイル開発の本が多量に出ている点でも、（日本人には）難しいものなのではないかと考えています。

アジャイル開発は、動くもの優先で、少しずつ機能を追加していくものですが、これが日本人には合わない。
入れたい機能について優先度がつけられず、あの機能がない、この機能がない、このスケジュールでなんで入らないんだなど、不満しか出てこないのです。
「次の開発で入れましょう」と言っても、通じず、どんどんスケジュールが伸びていき、アジャイルではなくなってしまうわけです。

そして、ドキュメントがほぼない、スケジュールが長く、要望を顧客がいい様に入れていく中途半端なウォーターフォール開発のことをアジャイル開発ということになってしまうわけです。
 

ウォーターフォールとアジャイルの違い

ウォーターフォールとアジャイルの違いについて、例を用いて説明します
例として「車を作る」ということを想定します。

ウォーターフォールでは、ギアチェンジができて、4人が乗れる椅子があって、ハンドル、ドア、トランクなど、基本ベースor完全な完成までを1回の開発で行います。
なので、スケジュールは半年から2年と長くなるわけです。
 
アジャイル開発の場合は、まず、タイヤが4つあり、まっすぐ走るモノを作ったらリリースします。次のリリースではハンドル、次のリリースではドア、トランクなど、小規模の開発でリリースしていきます。
なので、スケジュールは2週間から4週間と短くなるわけです。

上記の図を見ていただければ、基本完成までのスケジュールは変わらず、アジャイルは何段階もリリースしているだけであることを理解していただければと思います。


さて、あなたが企画者だった場合、アジャイル開発の場合、まっすぐ走るタイヤだけでエンドユーザに出せますか？そんなものエンドユーザには出せないと思いませんか？
そう思っていくうちに、あれもこれもどれもそれもと、ほとんど完成形を最初のリリースから求めたりしていませんか？
最小限というものの理解ができない人には、アジャイル開発はできません。

QCDとS

QCDとは「Quality」、「Cost」、「Delivery」の頭文字をとったもので、それぞれ「Quality：品質」、「Cost：コスト(価格)」、「Delivery：スケジュール(納期)」を表します。
 
もともとQCDは製造業におけるもっとも重要な3つの要素で、どれを優先に作業をするかなどを検討するうえで利用されているものです。
 
 
それに加えて、開発業界でよく使われる「Scope：スコープ(機能)」を入れて、品質を上げるための三角形を考えるとよいと思います。 
注釈：よくあるQCDSのSはセキュリティなので、上記は別です。

IT業界では、基本的に
  1. スケジュール：納期
  2. スコープ：機能
  3. コスト：価格
の優先順位で品質を決める傾向にあると考えます。
 
開発するうえで、品質に対し、どれをとっても重要なのですが、開発依頼が来た時点で、全体的なスケジュールとコストはすでに決まっているものです。
そのため、決められたスケジュールとコストを使って、スコープを決めるわけです。
なので、どんな時でも、QCD+S、特にスケジュールを意識し、作業することが必要になるわけです。
 
顧客と仕様（スコープ）調整する場合でも、スケジュールに入るかどうか意識する。
顧客が要望を増やしてきたときも、スケジュールに入るか意識する。
この、スケジュールを意識するというのは、表に出すか、自分で考えるだけなのかはありますが、見積もりをする必要があるわけです。

見積もり

見積もりというのは、自分（もしくは他人）の力量を知り、どれくらいの作業ができるかを検討することを言います。
 
全体的な見積もりはリーダがやってくれる可能性がありますが、その見積もりのスケジュールを守れるかどうかの判断は自分でする必要があります。
見積もりはスケジュールとなり、リーダなどから通知されるので、そこで開発者は了承、もしくは、拒否（再見積もりの依頼）をする必要があるわけです。
これをさせてもらえないリーダは、炎上させるリーダでしょうし、全て了承する開発メンバは炎上を生むメンバとなるでしょう。
なお、拒否する場合は、その理由や自分の見積もり内容を報告する必要があります。
 
もし、見積もりが間違っていた場合、スケジュールを変更、もしくは、スコープを見直す必要があります。
なので、開発者は「スケジュールどおりにならないとわかった時点」で、報告する義務が発生します。
スケジュール前日など期日が迫っているときに、【薄々でも】わかっていたにもかかわらず「間に合いませんでした」では済みません。

まとめ

いかがだったでしょうか。
今回は開発モデルとQCDについて解説してみました。
 
実は、私はまともにアジャイル開発しているプロジェクトにあったことなくて、中途半端なウォーターフォールかプロトタイプ開発によってるものがほとんどでした。
スクラムマスターなんて見たこととない！

そして、アジャイルでの非機能や全体機能などに対する品質保証について、いい感じに書いてあるものがあまりないんですよね。
以前、品質保証という計画を立てて、開発抜きで回す期間が必要という話を聞いたのですが、そういうの書いてるの見たことないんですよね。。。。
 
 
このエントリーをはてなブックマークに追加 　 　
シェア
　

コメント

コメントを投稿