カテゴリー: プログラマー回顧録

～　エンデベッドシステム開発経験を回顧する　～

キミはなぜ間違いを犯したのか。

事象報告の核となる原因、対策を開発工程に基づき、振り返ってみた。

報告書はそれらを踏まえ、報告書の定型に落とし込むとして、次に待ち受けるのは６ｗｈｙだ。

６ｗｈｙ、なぜなぜ分析。

事象を源流とし、なぜそうなったかをブレークダウンしていくことで改善策を導く手段である。

よくある笑い話でどんな事象でもなぜなぜの行きつく先は「担当者の疲労」、対策は「よく寝る」になる。

なんて話もあるが、客先に提出する資料であるのでネタに走るわけにもいかない。

これが意外とパターンというものがなく、なぜを進めるのが難しかったりもするのだ。

今回の件だと事象「設定の切り替えを行った後、メイン機能が動作しなくなった。」が源流となり、なぜそうなったのか、問答を始める。

１段階進めると「メイン機能が切り替え後の設定を参照したため」となり、

もう１段階進めると「メイン機能が設定を参照することを見落としていた」となる。

この段階から事象の核心へと進み始め、更に深堀りしていくことになる。

また、理由が複数ある場合は枝分かれするため、なぜがなぜを呼ぶ展開となる。

最終的には明確な要因が浮き彫りになり、それに対する改善案を提起できれば完了となるのだが、

こんなことを１日中やっていると思考崩壊となるわけで、

なぜこんなことになったのかと自問せずにはいられないのもあるあるではないだろうか。

これは個人的体験談を元にした回顧録です。企業名、人名などは架空の名称です。
毎週日曜日更新。
随時、加筆、修正を行います。

投稿日

2022.07.31

更新日

0000.00.00

プログラマー回顧録

～　エンデベッドシステム開発経験を回顧する　～

総合試験でバグを見つけるには。

結合試験で流出したバグをせき止める最後の砦、総合試験。

総合試験ではどのような試験を行うべきなのだろうか？

基本的に総合試験の試験内容はどのような対応をしようが同じであるはずなのだ。

なぜなら総合試験の検証範囲は機能全体であり、どのような対応を行おうが、新機能の検証（要求仕様確認）と従来通りの機能の検証（デグレード確認）に要約されるからである。

◎要求仕様確認

仕様書をベースに要求仕様が全て満たされていることを確認する試験。

テスターは要求仕様の意図を完全に把握している必要がある。

◎デグレード確認

標準動作を一通り実施し、対応前と後で差異がないことを確認する試験。

基本的には対応前後の出力データの突合をもってデグレードの検知を行う。

さて、それではなぜ総合試験でバグは流出したのだろうか？

今回流出したバグの性質を見るとデグレードだ。

つまりデグレード確認で検知できなかった、ということであり、

デグレード確認のなかで行った標準動作では検証しきれていない機能が存在した、ということであった。

そこで標準動作を見直すことにした。

標準動作を縦軸に、機能を横軸にしたマトリクスを作成し、機能の網羅性を確認したのだ。

すると今までの標準動作では検証できていない機能が浮き彫りになったのである。

そう、それはまさに今回のバグ発生の手順となった動作であった。

こうして見落とした機能の検証を標準動作として組み込み、デグレード試験の質を高めること。

これをもって対策を終えたわけである。

これは個人的体験談を元にした回顧録です。企業名、人名などは架空の名称です。
毎週日曜日更新。
随時、加筆、修正を行います。

投稿日

2022.07.17

更新日

0000.00.00

プログラマー回顧録

～　エンデベッドシステム開発経験を回顧する　～

結合試験で流れ出るバグ

詳細設計では「サーバーから受信したデータをメモリに展開する」対応としたわけだ。

では、それに対し、どのような結合試験を行ったのだろうか？

２つの観点に基づき結合試験項目は作成されていた。

（観点１．データフロー）

・データがセットされていない場合、されている場合、２つの状態においてサーバーから受信したデータがメモリに展開されること

改修機能全般を確認する試験であり、サーバーとの通信からメモリ管理まで、データフローに着目した試験である。

（観点２．データ参照）

・データエリアが参照できること

メモリに展開されたデータ群の１ブロック目と最終ブロック（新たに定義されたデータの１つ手前）を参照する機能を抜粋し、その機能に対するデグレードを確認する試験である。

以上が結合試験の内容であった。

詳細設計において予備エリアに新たにセットされたデータを参照する機能がないと結論付けていた。

その結果、結合試験の試験設計において「予備エリアを参照する機能の動作確認」という観点が抽出できなかったわけである。

どうすれば結合試験でバグの流出を防げただろうか？

参照する機能がない（と実は勘違いしていた）データエリアを参照する機能のデグレードを結合試験で炙り出すのは不可能ではないか。

結合試験の限界との結論に至ったのであった。

だがしかし、検証でバグを流出させるわけにはいかないわけで。

結果として総合試験の見直しに至ったのである。

これは個人的体験談を元にした回顧録です。企業名、人名などは架空の名称です。
毎週日曜日更新。
随時、加筆、修正を行います。

投稿日

2022.07.03

更新日

0000.00.00

プログラマー回顧録

～　エンデベッドシステム開発経験を回顧する　～

バグ流出を防ぐ３つのテスト

バグを作り込む。

システム設計をするうえで避けては通れない問題だろう。

そこでV字モデルによる開発ではバグ流出を３つのテストで防ぐこととなる。

コーディングによるバグは単体試験で流出を防ぐ。

詳細設計によるバグは結合試験で流出を防ぐ。

基本設計によるバグは総合試験で流出を防ぐ。

開発フローが開発と検証（試験）で相対しあうようになっており、そこがV字と言われるゆえんでもある。

ちなみに各試験ではどのような試験を行うのか？

単体試験ではカバレッジを考慮した関数、メソッド単位でのIN／OUTの確認を行う。

SDKで動作確認を行い、コーディング時のタイピングミスや処理フローの見落としなどを防ぐ。

結合試験では改修ロジックをシステムに反映させ、システムを操作して確認を行う。

試験内容は、指定の条件、操作に対して改修機能が想定通りに動作するか、また、改修機能の関連機能がデグレードしていないかの確認がメインとなる。

総合試験では全ての機能を盛り込み、システム全体を操作して確認を行う。

試験内容は、要求仕様を満たしていることの確認や基本機能に対するデグレード確認などである。

それでは、今回の問題はどの試験で防げたのか？

詳細設計フェーズにおいてバグの作り込みを行っているため、

流出を防ぐとすれば結合試験だろう。

では、結合試験の試験内容はどのようになっていたのだろうか。

これは個人的体験談を元にした回顧録です。企業名、人名などは架空の名称です。
毎週日曜日更新。
随時、加筆、修正を行います。

投稿日

2022.06.26

更新日

0000.00.00

プログラマー回顧録



～　エンデベッドシステム開発経験を回顧する　～

詳細設計レビューまで時を戻せるならどうする？

詳細設計で提案された２案。

１つは修羅場へと続く道。そして、もう１つは平穏な日常が続く道。

振り返ると大きな分岐点であったわけである。

では、この２案。

レビュー当時、どうすれば正しい選択肢へと導けたのだろうか？

少なくとも選択肢としてピックアップできていたのだ。

修羅場を回避できた可能性はあったはずだ。

そうなると、選択の拠り所となった妥当性の判断に対して指摘できたのか、

がポイントになるだろう。

データの参照先がいるか、どうか。

選択肢の判断材料となるその問いに対し、設計担当者は「いない」と述べた。

だがしかし、結果としてデータの参照先が「いた」わけだ。

その参照先が誤作動を起こし、機能停止となったのだから。

つまり、担当者は参照先の検索の仕方に誤りがあり、参照先を見落とした。

参照先が「いない」と判断した経緯を明確にする必要があった、ということだ。

そのためにはまずどう検索したかを明確にするため、検索ワードを明記する。

「検索ワード「XXX（変数名）」で検索した結果、参照先はいませんでした。」

この発言を引き出し、それに対し、誤りに気付けるかどうかだったのだ。

今回の誤りは、C言語としてありがちな「キャストによるメモリの参照」。

これが検索できておらず、参照先を見落としたのだった。

検索ワードとして「○○○（アドレス名）」の検索までしていれば正しい選択肢へとたどり着いたのではなかろうか、

そういう結論に至った次第である。

続いて流出原因の見直しとなる。



これは個人的体験談を元にした回顧録です。企業名、人名などは架空の名称です。
毎週日曜日更新。
随時、加筆、修正を行います。

投稿日

2022.06.19

更新日

0000.00.00

プログラマー回顧録



～　エンデベッドシステム開発経験を回顧する　～

詳細設計完了。レビューで提示された２つ案。

詳細設計で言及することは以下４点。

①要求仕様に基づく当該機能の改修理由

②改修方針

③改修の内容

④改修の妥当性

①～④までを明確に文章化することで初めてソースコードを改修できる、コーディングフェーズに移行できるわけである。

そして、詳細設計からコーディングへとフェーズ移行するときもレビューは必須。

その参加者は、２人だった。

レビュアー、俺。レビューイ、担当者。

このとき、改修方針として提案されたのが２案。

案１）サーバーから取得した設定値群（１ブロックのデータ）を全てメモリに格納する。新しい設定値は後々参照できるよう構造体メンバに追加する。

案２）サーバーから取得した設定値群（１ブロックのデータ）を現在使われている分だけメモリに格納する。新しい設定値に関する構造体メンバの追加は行わない。

担当者の推しは、案１。

通知されたのだから取り込んでおけばよい。

妥当性としては、ソースコードを全て検索した結果、新たに格納したデータを参照する機能はないのでメモリに格納しても安全、とのこと。

絶対的な安全策でいえば案２なのだ。

だが、確かにデータを参照する機能がないのであれば案１でも問題ない。

担当者の推しもあり、案１を採用することでレビューを閉じたのであった。

振り返ってみるとここでバグが埋め込まれたわけである。

そう、振り返れば分かるのだ、何が間違っていたか。



これは個人的体験談を元にした回顧録です。企業名、人名などは架空の名称です。
毎週日曜日更新。
随時、加筆、修正を行います。

投稿日

2022.06.12

更新日

0000.00.00

プログラマー回顧録



～　エンデベッドシステム開発経験を回顧する　～

基本設計から詳細設計へ

V字モデルとして、基本設計、詳細設計、製作、単体試験、結合試験、総合試験と開発を進めるにあたり、基本設計の役割とは何か？

要求仕様に対し、どの機能を改修するのか、また、どのような改修方針とするのか、この点を明確にする。

これが基本設計の役割との認識である。

つまり、影響のある機能を洗い出し、改修方針を立て、改修が及ぼす影響を予め把握するわけである。

本プロジェクトにおける要求仕様検討から基本設計作成までの担当は１人。

プロジェクトリーダーの俺の担当というわけです。

基本設計フェーズまでは１人で黙々とプロジェクトを進めることになります。

そして、基本設計が完成すると次から詳細設計フェーズへ。

ここで作業分担を行うわけですが、その入り口となるのが基本設計レビューの実施。

詳細設計フェーズから各機能に知見のある担当者に引き継ぐわけですが、

ここで基本設計レビューを行い、詳細設計担当者との意識合わせをするわけです。

改修すべき機能の漏れ、改修方針の妥当性などを検討、精査し、ここでバトンタッチ。

「サーバーから通知された設定値を（必要もなく）参照したことによってメインシステムの一部が機能しなくなった」問題。

この問題で登場する機能は以下。

①サーバーとの通信を担う機能（Windowsで動くモジュール）

②サーバー通信機能と連携するデータ管理機能（Linuxで動くモジュール）

③サーバーからの受信データを参照するメイン機能（Linuxで動くモジュール）

今回は、サーバーから通知される設定値群（１ブロックのデータ）のなかの予備エリアに新たに１つ設定値が追加されるという要求仕様。

そこで基本設計としては機能①の改修は行わず、機能②を改修する方針としました。

基本設計レビューで担当者と共に確認を行い、いざ、バトンタッチ。

詳細設計はどうなったのか？

これは個人的体験談を元にした回顧録です。企業名、人名などは架空の名称です。
毎週日曜日更新。
随時、加筆、修正を行います。

投稿日

2022.06.05

更新日

2022.06.12

プログラマー回顧録



～　エンデベッドシステム開発経験を回顧する　～

バグの原因と流出と対策と

ウォーターフォール型のシステム開発の利点はなんといっても品質だろう。

仕様が確定しているからこそ、設計に冗長性を持たせる必要もなく、

設計から検証に至るまで安定した工程が組めるし、バグの排除に注力できる。

「バグは早いフェーズで潰した方がコストが安い。」とはよく言ったもので、

基本設計、詳細設計、製作、単体試験、結合試験、総合試験と

各フェーズの移行タイミングでのレビュー（有識者がレビュアー、担当者がレビューイの対面式の改修方針の説明会のようなもの）は必須であったし、

総合試験でのバグ件数０を目標にバグの抽出管理も徹底していたわけである。

もちろん、今回の改修対応も同様に作業工程を厳守して開発したのだ。

それにも関わらず、バグは流出した。

「サーバーから通知された設定値を（必要もなく）参照したことによってメインシステムの一部が機能しなくなった」問題。

まずはこの問題が作り込まれたフェーズ「詳細設計」。

この「詳細設計」を掘り下げてみる。

これは個人的体験談を元にした回顧録です。企業名、人名などは架空の名称です。
毎週日曜日更新。
随時、加筆、修正を行います。

投稿日

2022.05.08

更新日

0000.00.00

～　エンデベッドシステム開発経験を回顧する　～

GW回顧録（ゆるく脱線

世間はGWまっただ中である。

せっかくの連休である、少し業務の話から逸れてみることにしよう。

GWの記憶を遡ってみると思い出すのは入社１年目のGWだ。

入社当時は横浜にある田園都市線沿いの会社の寮に住んでいた。

その時の同期とはよく遊び、よく飲んだものだ。

仕事終わりや休日などは寮のロビーにたむろしては時間を潰したものである。

そんな入社１年目の俺はGWになにをする当てもなく途方に暮れていた。

予定もなく部屋を出て、ロビーに向かうと奴らはいた。

同じように当てのない同期５人である。

「ちょっと出かけてみる？」

誰かが発した一言をきっかけに男６人のドライブが始まったのである。

レンタカーを借りて最初に向かったのは鎌倉。

結局、拝観時間に間に合わず、大仏の頭を眺めて後にした。

次に向かったのが御殿場だ。

時刻も夕方になり、ご飯を食べようと辿り着いたのがビアホールだった。

ナビゲーターは手配の上手い同期にお任せだったのでどこだったか記憶にないのだが、

ここで出会ったビールが人生史上No.1であり、いまだに忘れられない味になった。

種類はヴァイツェン、そこにレモンを絞って飲むのだが、この爽やかなこと。

個人的に苦味より軽快な味が好きというのもあるが、いまだにこの時に飲んだビールより美味いビールに出会ったことがない。

ワイワイガヤガヤと食事を堪能した後に向かったのは湘南。

波の音を聞いているといつのまにか０時を超えていた。

そろそろ帰宅するかと寮に向かった。

はずが、渋谷にいた。

誰かが一蘭が食べたいと言い出したのだ。

朝５時ぐらいだったか、ようやく着いた渋谷で一蘭を食べ、長いGWの１日を締めたのである。

今思うとずっと運転していた下戸の同期には感謝しかないな。

これは個人的体験談を元にした回顧録です。企業名、人名などは架空の名称です。
毎週日曜日更新。
随時、加筆、修正を行います。

投稿日

2022.05.01

更新日

0000.00.00

～　エンデベッドシステム開発経験を回顧する　～

とあるエンデベッドシステムの開発工程

初期開発が終わり、現地運用も安定している。

その中で毎年、新機能追加案件があり、年度末に現地展開する。

そんなエンデベッドシステムの開発工程とはどのようなものか。

典型的なウォーターフォール型、V字モデルの開発工程である。

様々な要求仕様があるなかで対応要・不要を取捨選択し、該当システムに落とし込み、仕様を策定する。

その仕様をもとに基本設計→詳細設計→コーディングと開発を進め、

単体試験→結合試験→総合試験と検証を行う。

ここでプロジェクトの受注側として品質を保証してリリースとなる。

あとは受入検査として発注側の品質検査が行われるわけである。

たがしかし、要求仕様というものは得てしてすんなり決まるものではなく、

１年を通して２度、この工程を繰り返すのが常であった。

（第１期を８月にリリースし、第２期を１月にリリースする。）

従ってプロジェクトの人の流れもこれに沿うものとなり、年に２度ある詳細設計→結合試験の工程で開発者が集約しては解散するを繰り返すのである。

はてさて、では今回の事象の原因となった「サーバーから通知された設定値を必要もなく参照してしまう」問題は本来どの工程で解決すべきであったのだろうか。

ちなみにサーバーからの通知を受け入れる仕様が確定したのは１１月である。

これは個人的体験談を元にした回顧録です。企業名、人名などは架空の名称です。
毎週日曜日更新。
随時、加筆、修正を行います。

投稿日

2022.04.24

更新日

0000.00.00