前回 の記事に入らなかったが、今年考えたことなどのおまけ。
全体的に観測範囲が限定的な話ではあると思います。
プロジェクト体制とか
PG工程をオフショアで安く済ませ、テスト工程で品質を担保しようとして地獄の進行を辿ったプロジェクトをいくつか見てきた。
もちろん日本人かどうかという話ではなく、リソースをどこに使うかという戦略の問題だ。
オフショアと言わずとも、いわゆる上流工程をプロパーが担当し、事細かに記載された設計書を外注や協力会社に投げて、でき上がりを待つ間に総合テストのシナリオを作っておく、といった体制の取り方をする日本企業は多いと思う。
それが問題なく機能している間はそれで良いが、遅延・低品質その他でうっかり燃えあがったしまったときに、てこ入れとしてなぜかやたらと上流やQAチームで増員をかけ、より強力なパワーでプログラマーのケツを叩き続ける現場を目にすることがある。
しかし、少なくとも自分が携わったプロジェクト規模の範囲内でいうと、そういう状況を打破できるのは大抵、少数の強力なプログラマーだ。
特にプロダクトの品質が悪く、正常ルートがろくに機能しないような状況では、ブラックボックス的なテストでいくら不具合を抽出したところで、こっちを消したらあっちが燃えるを繰り返し、全員が疲弊していく。
どうせ何度もリグレッションテストをやる羽目になるなら、ドメイン知識＆コーディングスキルのある人間が早々にコードレベルでインスペクションを行い、一度大きく手を入れてしまうほうが早い。
必ずしもウォーターフォールが悪者だとは思わないが、V字モデルの両端に注力すれば底の部分は誰に頼んだってうまくいくはずという戦略は明確に誤りだと体感した。
データ構造とか
少し前にどこかで、プロダクトを支配するのはデータ構造だ的な話を読んだ記憶があった。最近よく思い出しては、まったくその通りだと実感している。
まあとはいえ結局そのデータ構造も、それを読み書きするコーダのスキルに依って決まる部分が少なくないため、卵が先か鶏が先かと思わなくもない。
数値しか入らないはずのテーブルカラムが VARCHAR 型になっていて、なぜだと聞いたら、先頭0埋めで画面に表示するためだと返されたときには、もはやそのカラムを INTEGER にするか VARCHAR にするかだけを焦点にバトったところであまり意味はない。
それはさておき。
厄介なことに、最初から将来機能を見越し、変更が生じないようなデータ設計をするというのは難しい。
開発のバージョンアップが進むにつれてあるべきデータ構造も変わっていくし、また、変えられるようになっていないといけない。
具体的にいえばそれは、運用が開始した後もデータベースのテーブル構造を継続的に変えていけるかということで、つまりマイグレーションの仕組みが整備されていること。
これが気軽にテーブルスキーマを変更する体制ができていないと、テーブル設計の時点で全テーブルに謎の予備カラムがくっついていたり、 なんとかフラグという名前のカラムに 2 とか 3 とかいった値が入るようになる。
C# は雑多なタスク自動化ツール作成で活躍する
プロジェクトの進捗管理や課題・ドキュメントの管理においては、あっちの問処をこっちの問処に転記するとか、定時の報告資料を作成するとか、本質的でなくて全くリソースを割きたくないが、誰かがやらなきゃならないタスクというのがまま発生する。
そういうときに単純作業をさくっと自動化できる術を持っておくと重宝する。
自身でコードを書かないタイプの管理者が集まると、なぜか第一候補としてエクセルマクロを提案されるが、ここは全力で阻止せよ。
関数でできる以上のことをエクセルでやろうとすると不幸になる。
簡単なものはシェルスクリプトで事足りるケースもあるが、だれでも使えるツールとなると、どうしてもGUIになる。
いささか自分の知識に偏った意見にはなるが、こういうときに C# がすこぶる活躍する。
まだまだ日本企業の一般的な仕事用PCは Windows が大半である。
.exe ファイルとして実行モジュールを作成し、Windows 10 ならプリインストールされている .NET Framework のランタイムで、ダブルクリックで即実行できる GUIツールを作れる言語として、C# および .NET は非常に有用だ。
「開発環境がある人でないとメンテできないツールになるから、エクセルマクロのほうがいいのでは」と言ってくる人がいるかもしれないが、その人はどうせマクロであってもメンテしてくれないから無視して大丈夫だ。
ドキュメントとか
ドキュメントとして何が必要で、何が必要でないか。
どう書いて、どう参照し、どうメンテするか。
なかなかこれだという正解にたどり着けない問題。
外部設計書
ものすごく雑にくくると、外から見たふるまいを定義する外部設計書（画面設計書／画面仕様書）と、内部構造を定義する内部設計書（詳細設計書）に大別できるかと思う*1。
外部設計書は、システム作成の指示書としてではなく、全員でそのシステムのあるべき姿（＝挙動の正解）を共有する意味で、あったほうがいい。
またこれがないと、独立性の高いチームによるテスト設計が困難になる。
MS Word はもちろん使わない。選択肢に入れる理由がない。
全員で共有できるツールとして、やむなく Excel を使わざるを得ないケースはあると思うが、差分の確認と版数管理がつらい。
Google Drive とスプレッドシートなら、履歴管理を自動でやってくれるが、任意のタイミングで版数を更新しようとするとやや困難なので、結局自分で更新履歴シートを作る運用になったりする。
書く人・読む人が決まっているなら、Markdown で書けて版数管理もできる、GitHub や GitLab の Wiki は良い選択肢だと思う。
やろうと思えばリポジトリのブランチとしてメジャーバージョンを管理することもできるし、issueとのリンクもとりやすい。
画面単位・機能単位での設計書のほか、画面遷移図・ロール（権限）による制限・文字数上限や数値範囲の制限あたりはまとまった資料としてあるといい。
画面遷移図は、なかなかこれという方法を見つけられないが、今のところ PlantUML で書いて同様に Wiki で管理するのがいいかと思う。
ただ規模が大きくなるとどうしても分割したり、見やすくするために配置をいじったりという工夫が必要になるのが惜しい。
内部設計書
すべてのクラスやモジュールに関してメソッド単位とかで詳細設計書を作るなんてのは全然現実的じゃない。
よほどマンパワーに余裕のあるプロジェクトでもなければやってられない。
ソースコード内のAPIコメントからツールによって自動生成する類のものであればあってもいいが、形式上の目的以外で、本当にあれを必要とする人はいるのか？
あれを読みたいと思う人ならば、普通にソースを読むんじゃなかろうか。
しいていえば、チーム内で機能間の結合のためのI/F情報として利用できるケースはあるのかもしれないが。
RDBのテーブル設計は、Excel など表形式で記述したものからDDLを生成できると良い。
世にそのためのフレームワークやツールは数多あるんじゃなかろうかと思いつつ、自作している。
ER図も、RDB自体のテーブル構造から自動生成してくれるものがあるが、人が見てわかりやすい形にしようと思ったら、現状はどうしても自前で作るほうがいい。
これも今のところ PlantUML で書いている。
CRUD なんかも、ソースコードから自動生成できるんじゃなかろうか。
と思ってちょっとググった感じ、それっぽいフレームワークはありそうではある。機会があれば試したい。
絶対にエクセルをマージする作業を発生させてはならない
問題処理表、質問表、試験管理表の類をエクセルファイルとして作成し、作業者各人がローカルで更新したものをメールや共有ストレージでやり取りしながら最新版に手作業でマージする。この世で最もくだらない仕事のひとつである。
課題管理など、1項目がそのまま1タスクになるものは、エクセルではなく Redmine や GitHub issues などのチケット管理ツールを Master として扱い、必要なときだけエクスポートして一覧化すれば良い。
いちいちチケット化するほどでなくて、一覧表のままゴリゴリ書き込んでいきたいときは、スプレッドシートにして*2 Google Drive 上で最新版を全員が直接編集できるようにする。
Microsoft Teams でだって同じことはできる。
自社内に閉じた作業なら話は簡単だが、前述のようなマージの苦行が発生するのは、たいてい複数のベンダーや下請け会社が絡む現場での、会社間のやり取りにおいてである。
自社セキュリティやコンプライアンスの関係で、社外の人間と安全に共同編集を実現する方法を考える手間を惜しんだ結果として、○月○日版のファイルに追記したものを送付しますのでマージお願いします、になる。
追記した箇所は赤字、削除した箇所は打消し線になっているが、コピペの過程で全て失われる。
別のシートのセルを参照するリンクがあれば、これもコピペによって知らぬ間に別ファイルを参照するリンクとなり、送付した相手から「リンクが壊れていて見れません」と苦情が来る。
PPAP方式の是非を問う以前に、エクセルをメールで送りますと言われた時点で、誰かがそれに抗う努力をしなければならない。
テストのエビデンスは必要か
テスト仕様書・成績書の話を割愛して（手作業でマージだけはするな）、エビデンスの話。
テストでいうエビデンスというと、画面のキャプチャや通信の送受信ログだ。
異常ケースのエビデンスは、改修担当者に不具合の詳細を伝えるために必要となる。これはもちろんあったほうがいい。
正常ケースのエビデンスは、主に「ちゃんとテストやったんか」を監視する目的で使われているのが実態だと思う。
この目的であれば、やめられるならやめたほうがいい。テスト実行にそんな無駄な労力をかけるより、最初から信頼できる人にテストを依頼すれば解決する。
もうひとつの目的として、後々になって問題が発生した際に、この時点／この条件では正しく動いていたことを確認する手段として用いられることもある。
これは意味があるといえばあるが、メリットと天秤にかけたときに、テスト実行の工数に与える影響が大きすぎる。
正常動作のスナップショットだけであれば、Selenium や Puppeteer で自動テストとあわせてキャプチャを残すようにすることで代替できるし、そっちのほうが労力をかける価値があると思う。
以上
よいお年を。
