投稿者: route83

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

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

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

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

②改修方針

③改修の内容

④改修の妥当性

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

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

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

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

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

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

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

担当者の推しは、案１。

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

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

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

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

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

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

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



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

プログラマー回顧録



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

基本設計から詳細設計へ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

プログラマー回顧録



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

GW回顧録（ゆるく脱線

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

はずが、渋谷にいた。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

なぜバグを作り込んでしまったのか。なぜバグは見つからなかったのか。

システム誤作動。完全停止。現地復旧。対策会議。

怒涛の１日が終わり、改めて切られた２ヶ月のスケジュール。

まずは事象報告チームの一員として今回の事象の発生原因、流出原因をまとめて報告することとなった。

チーム構成としては、上長（プロジェクト責任者）が指揮をとり、俺（プロジェクトリーダー）、後輩（問題箇所の設計担当者）の３名からなる。

今回、報告資料として求められているものは大きく３つだ。

①当該事象報告書（発生事象、発生原因、流出原因の詳細分析）

②６ｗｈｙ分析結果（なぜなぜ分析）

③復旧操作を３度ミスしたことに対する報告書

①、②は関係者として粛々と事象を整理するとして。。。

だが、③はどうなのか。

昨日の対策本部の緊張感のなかで３度失敗したときの居心地の悪さよ。

是非とも、お聞かせ願いたいものだ。

まずは事象を整理するにあたり、当該案件（エンデベッドシステム開発）の流れをまとめておこうと思う。

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

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

システム開発費用でみるインパクト

ここまで我がプログラマー人生最悪の事象発生から１次復旧までを書き連ねてきた。

システム全台稼働停止、リリースモジュールの破棄、中期リカバリーの発生と前代未聞の事態となってしまった。

ここで少し目線を変え、今回の事象に対する費用の話を綴ろうと思う。

あくまでも３次請負企業のプロジェクトリーダーの立場として知り得る自社情報のみの話である。

企業間の免責や補償の取り決め、はたまた１次企業から通しての損失額は把握していないことを断っておく。

【とあるエンデベッドシステム開発】

開発内容：既存システムの改善、新機能追加

（新規機能の要求仕様検討から参画し、基本設計～検証～リリースまでをチーム開発する。）

開発期間：１年

開発工数：８０００ｈ（３次請負１社）

開発人数：１２人（３次請負１社、ピーク時）

単価：￥５ｋ（３次請負の契約単価）

これが我が３次請負企業の開発規模であった。

ちなみに利益率設定は３０％。

つまり工程が理想通りに進めば１２００万の利益となるわけである。

そして、開発終了時点の利益率はというと、３３％。

まさに順調であったのだ。

トラブルが起きるまでは。

そして、トラブル発生。

リカバリー期間２ヶ月の工数だけ換算しても８人×３６０ｈ×￥３ｋ。

約８６０万。

利益の大半が吹き飛んだのだ。

もちろん社員が費用を賄うわけではない。

だがしかし、プロジェクトリーダーとして、プログラマーとして品質、利益の２大目標の達成を粉々に打ち砕かれたわけであり、今となっても忘れられない最悪の事態だったのである。

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