LoginSignup
5
3

More than 1 year has passed since last update.

Vモデルについて勘違いしていたと思ったこと

Last updated at Posted at 2022-01-31

はじめに

Vモデル(V字モデル)について、勘違いしていたと思ったことを記録しておく。
ただし、ここに記録していることも勘違いの可能性もある。
最初に、勘違いを気づかせてくださったのは、小川清氏と白坂成功氏だったと記憶している。

V字モデル

Wikipediaでは以下のように説明されている。

V字型に表される概念図の左側はシステムの仕様を記述していく流れを示している。右側はテストの流れを示す。

世の中のVモデルの図を見ると、左上から真ん中下に、真ん中下から右上に、矢印が記載されていることが多くあると感じている(統計的な確認は未実施)。

勘違いしていたこと

『Vモデルは順序を示している』

「Vモデルは、左上から真ん中下に、真ん中下から右上の順番に、開発を行うことを示している」と思っていた。
しかし、今はこれが勘違いだと思っている。

参考メモ

白坂成功氏の資料

参考文献[1]で、白坂成功氏が、以下のように述べている。
http://deos.or.jp/event/files/20140625_DEOS_001.pdf?fbclid=IwAR1Pd8LJGUwHTG4VPYIzLeyIQUbfsZ9Mc9M02hIO99hj6CLH30GwRpkHKjE

Vモデルに関する間違い
・Vモデルは時系列的なプロセスを示している。

白坂成功氏の講演(2016年)を聞いた時の私のメモ

Vモデルに関する知見とは、関係ないものもあり。

  • 受動的でなく能動的に説明する。
  • 開発はボトムアップでもよい。説明はトップダウンでしかできない。
  • 標準に従うと差がでない。優先性もでない。
  • 要求は開発者が自分達で定義する。
  • 製造だけでなく設計を計測して改善する。
  • Vモデルの左と右の間に評価と解析の活動がある。

松尾谷徹さんの資料にブリコラージュという考え方があります。
http://www.jasst.jp/symposium/jasst15tokai/pdf/S1.pdf

仕様から均一なソフトはできない。創造的な作業では、人は試行錯誤しながら、ものを作る。

この原則からしても、白坂成功氏がおっしゃっていた「開発はボトムアップになる」は普通なのかなぁと思えてきます。すごく、納得感を得ました。

@kaizen_nagoyaさんの記事

@kaizen_nagoyaさんの以下の記事からも、V字は順番を示していないと認識した。
https://qiita.com/kaizen_nagoya/items/1b679769470c3dfd3012
これ、すごくわかる。すごく、大切な考え方。V字は順番を示していない。何からやると効率的か作戦立てないといけない。

CEST技術交流会(2019年)に参加したときの私のメモ

過去に、2019年のCEST技術交流会では、林健吾氏と以下の議論をさせていただいた。
http://www.ertl.jp/CEST/act2019.html

炎上している大きな要因、開発終盤での性能問題である。
全部の機能が入らないと最終的な性能(リソース、時間)はわからない。
開発終盤だから、大きな設計変更はせず、ごまかすことが大半。
設計変更をした場合は、デグレがよく起きる。
ごまかした場合は、イレギュラーなことをやっており、次の開発で、埋め込まれた設計制約や分かりにくいコードの地雷にはまる。
炎上を退けるためには、先行開発で早く性能の検証ができることが、ポイント。

私の経験則

実際の開発をしていても、以下のような場面があり、「順番でなくてもいいのでは?」と思っていた。

  • 今回は、右上のテストから手を出したほうが効果的かも
  • とりあえずプロト版のソフトを作っておきたい
  • 設計の検証はこのフェーズでは見送り、次フェーズでやりたい

大切だと思うこと

Vモデルの左と右を繋ぐ線

個人的な経験則では、Vモデルの左と右の活動を繋ぐ線は、重要だと思う。
何をもとに評価をするのかを明確にすることが重要だと思う。
そのときに、箱の粒度等は業務・プロジェクトによって変わる。

参考文献[4]で小椋俊秀氏が書かれている図「ウォーターフォール型開発のV字モデル」では、左と右を繋ぐ矢印しか書かれていない。
自分がVモデルの図を書くときには、同じように左と右を繋ぐ線のみを書こうと思う。

参考文献

[1]白坂成功,「システムズエンジニアリングとディペンダビリティ」
http://deos.or.jp/event/files/20140625_DEOS_001.pdf?fbclid=IwAR1Pd8LJGUwHTG4VPYIzLeyIQUbfsZ9Mc9M02hIO99hj6CLH30GwRpkHKjE

[2]松尾谷徹,「テストから観た実体のモデリングと実装構造の評価 ~ 検証指向設計の実現に向けて ~」,JaSST'15 Tokai ,2015
http://www.jasst.jp/symposium/jasst15tokai/pdf/S1.pdf

[3]@kaizen_nagoya,「仮説・検証(9)TDD, Agile, Performance Testは関係があるか」,2019
https://qiita.com/kaizen_nagoya/items/1b679769470c3dfd3012

[4]小椋俊秀,「ウォーターフォールモデルの起源に関する考察 ウォーターフォールに関する誤解を解く」,商学討究 第64巻1号,2013
https://barrel.repo.nii.ac.jp/?action=pages_view_main&active_action=repository_view_main_item_detail&item_id=269&item_no=1&page_id=13&block_id=135

[5]室谷隆,「ソフトウェア開発の標準プロセス」,財団法人計算科学振興財団 ソフトウェア・エンジニアリングセミナー,2011
https://www.ipa.go.jp/files/000004771.pdf

参考記事

5
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
5
3