markdownでUMLを書くVSCode拡張機能「PlantUML」が素晴らしい!

Table of Content

実はしれっと使ってました。

https://wordpress.local/2022/03/revealjs_wordpress_hosting/
スポンサードリンク

VSCodeで書いたUML図

これですね。
全文はこの通り。

これを出力すると、上記のような図になります。

保守・更新できるドキュメントであるべき

予算や上役へのプレゼンは、どうせ一回しか使わないと割り切ってPowerPointを使ったりdraw.ioやCacooをはじめとした作図ツール・サービスを使うべきだと思います。
しかし、運用チームが使う資料は保守できる形式であるべきです。

具体的には、脱Excelはもちろん、SpreadSheetならいいとかそう言った屁理屈ではなく、すべてコードベースで管理できるに越した事はないです。
わざわざ図解したものをテキストに落とす場合、資料を書き換えるたびにテキストも書き換える必要があるので二度手間です。
こう言った問題があるため、最初からテキストベースで作成・更新する運用を定着させた方が良いです。

PlantUMLは学習コストが高いのか?

学習コストという観点で見るよりは、直感性やデザイン性で評価するべきです。
PlantUMLだろうがPowerPointだろうが、使い方が異なるのでどちらにしても学びが必要です。
デザインセンスだとか編集技術は別の話です。
これを踏まえて、UMLを読み解く、作成するスキルを

  • PowerPointのスキル
  • PlantUMLで書くスキル

のどちらを使うか、の違いでしかありません。
どちらにせよ、UML自体(PlantUMLではなく)についてはきちんと体系的に学んだ方が良いです。

本稿ではUMLについて解説しませんが、UMLを作成・整備することでシステムを作る→システムを使うという観点でシステムを評価する目を持つことができます。
特にQA(設計サイド)には必要な要件です。

QAエンジニアのお仕事

ちょっとだけ言及しておきますね。
ソフトウェアQA(Quality Assurance: 品質保証)エンジニアとは、その名の通りエンジニアリングの知見を持ってソフトウェアの品質を保証する仕事です。
テスト項目自体を作成するかどうかはさておき、テストの内容が妥当であり、漏れ抜け等の問題がなく開発段階では予期していない運用についても考慮する事を業務とします。
そのため、テスト仕様書を作る人という印象を持たれがちですが、主な業務ではありません。

ひとつ、例を示します。
たとえばテスターが家電量販店に卸す製品をガチャガチャ弄り回してソフト的に頑張って壊そうとするお仕事です。
あるボタンを連打してみたり、TAS的に(一部RTAでも)言えば任意コードを実行する方法をあれこれ模索してみたり、できないはずの操作をやってみたりですね。
そして、こう言った作業は基本的にはテストシートに書いてあります。
その分野での経験が長いテスターだと、QAに近い観点でテスト項目をぶち上げられるぐらいに知見があるはずですので、ある意味ではエンジニアリングスキルを持ったテスターと評価できなくもないです。
彼らがソフトウェアの品質を保証できると言えるノウハウを持っているのか、ただ単に開発チームのクセや傾向に慣れているだけなのかはまた別の話です。

QAのミッションは「ユーザーに提供したときに大きな問題にならない(致命的な問題を先に発見し、修正する)」ことにあります。
綺麗にいうと「ユーザーに損害を与えることなく、要望を安全な状態で満たせるソフトウェアを提供する事を保証する」事です。
彼らの厳しい、そしてある意味理不尽なチェック項目を通過した製品だけが一般流通に乗ります。
QAの手が空いていればテスターも兼任しますが、大体の場合はオートメーション(自動テストスクリプト構築)に駆り出されます。
おかげで、QA=オートメーションエンジニアのポジションも確立している気がします。

閑話休題。

UMLを書こう

システムを作って学びを深める事も大切ですが、システムを使う場合も考えて運用イメージと実態を比較して見つめるのも大切です。
どちらも両立させていけると、QAエンジニアも目指せるでしょう。

シェアする