底辺過ぎてちょっとビビる

26歳からIT業界にいるエンジニアが、まったく成長できてないことを確認するブログ。備忘録的に使いたいとも考えています。

Excelでドキュメントを作るのは、原始人並に文明が遅れてる

始まりの言葉

「え、いまだにGoogleSpreadSheetなんかでドキュメント(テスト設計)書いてるの?原始人じゃないんだから!これは早急に対処が必要だぞ〜〜〜」

 

これは我がQAチームの管理者が発した言葉です。それまで当たり前のようにテスト設計をGoogleSpreadSheetで作成していた自分からすれば青天の霹靂でした。GoogleSpreadSheetでテスト設計するのは猿並みの文明人の所業なのか?

 

 

ドキュメントツールあれこれ

SESでシステム開発の仕事に従事していた頃、設計書といえば「Excel」で作られたものが大半だった。要件提議書・基本設計書・詳細設計書・テスト仕様書・バグ管理票...またはWBSなどのスケジュール管理系についても。要件提議書についてはWord文書だったりもするので、一概に全てExcleというわけでもない。

 

これらは印刷されることが前提で、書式もかっちりと決まっており書式からずれた記載であった場合などはレビューの場で設計内容よりも書式に合ってないことを真っ先に指摘を受けたりもした。苦い思い出だ。

 

基本的にこれらのドキュメントは「納品」するもので、データとしても残すのだけど、印刷して物理的に保管されることも想定していたと思う。だいたいプロジェクトが終わるか、その途中でプロジェクト先から退場することが多かったので、その後どうやってドキュメント類が運用されていたのかがあまり分かってない。もし保守やフェーズ2に関わるようなことがあれば、ドキュメントを参照することもあったのだろうとは思う。

 

2021年現在、今のSES先では設計書のベースになるのはConfluenceといったWEB上で作成するツールだ(GoogleSpreadSheetもWEB上でドキュメントを作っているけど)。コンフル(エンス)の何が便利かというと、WEB上に格納することで「キーワード」で検索することが容易という点。Excelベースのドキュメントもファイルサーバに格納したりすることでWindowsのファイル検索などで検索をしていたが、それよりもだいぶ検索した時にキーワードが引っかかるので、目的のドキュメントにたどり着きやすい。

 

何より「印刷することを目的にドキュメントが作られていない」のでプロジェクト内容やその記述目的によって柔軟に設計の記載が行える点が良い(記載レベルが統一されていないことで理解しやすい、理解しにくいの差が顕著だったりするので、この辺は運用ルールというかある程度指針が必要な気はしている)。

 

Excelの時のように、いちいちページの上部と下部にページ設定やドキュメントタイトルなどをしなくて良いのだ。タグを貼り付けることで関連するドキュメントをひとまとめに管理することも可能だし、ドキュメント間の繋がりをURLを貼り付けることで対応することができるのでスマート。

 

 

じゃあ全てのドキュメントをConfluenceに移行したかというとそうでもなく、テスト設計中のテストアプローチとして機能一覧を抽出するときや、テストケースの作成にはバリバリExcel(=GoogleSpreadSheet)を使っている。なぜか?冒頭の管理者の発言に対しては以下のように意見を述べている。

 

「表形式で項目を作る時にはやはりExcel形式のドキュメントの方が使いやすいからというのが大きな理由。コンフルはどちらかというとWordタイプのツールなので、表形式も使えないわけではないが本職ではなく、そこは使い分けをしている。」

 

全てコンフルで賄うことも当然可能だが、それだと「ツールを用途に合わせて使う」ではなく、「ツールに合わせて人間が工夫する」ことになる。Confluenceも使わず、Jiraでバグ管理を行わず、ということあれば批判も甘んじて受け入れるけれど、そうじゃない。特定のツールを使うことそれ自体が目的化するのは間違っている。移動するのに飛行機が便利だからと近所のスーパーに買い物に行くのも飛行機を使うのか?というのと同じだと思う。

 

個人的には現在WBS(WorkBreakdownStructure)としてGoogleSpreadSheetを使っているが、良いツールがあればそれに置き換えたいと考えている。探せば色々あるのだけど、それを選定して導入するというのはまた別の苦労がある...