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

組み込み系開発のあれこれを回顧するカテゴリー

投稿日:

プログラマー回顧録（１３）

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

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

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

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

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

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

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

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

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

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

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

だが、③はどうなのか。

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

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

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

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

投稿日2022.04.17更新日0000.00.00

投稿日:

プログラマー回顧録（１２）

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

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

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

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

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

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

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

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

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

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

開発期間：１年

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

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

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

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

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

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

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

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

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

そして、トラブル発生。

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

約８６０万。

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

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

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

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

投稿日2022.04.10更新日0000.00.00

投稿日:

プログラマー回顧録（１１）

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

日は明け、そして、動き出す。

ようやく１次戦線から解放され、事務所に着いたころには日付が変わっていた。

事務所はもぬけの殻だった。

もう１日、２日ではどうにもならない問題が起こったのである。

スケジュールを組み、ある程度のスパンで動かざるおえないのだ。

２４時間フル稼働になることはない。

それにしても、ここまでの手戻りが発生する事態は初めてであった。

現地で問題が発生したときのインパクトは身に染みて理解していた。

それが、今回、リリース初日に、しかも、縮退で回避できない致命的な問題が起きたのだ。

・・・

これ以上考えるのはよそう。

家に帰り、すぐにベッドに倒れ込んだ。

久しぶりの睡眠である。一瞬で眠りについた。

翌朝、出社する。

すでに大工程が引かれていた。

２ヶ月。それが今回の問題をリカバリーするのに与えられて時間であった。

チーム編成は３チーム、８人。

事象報告チーム、類似調査チーム、再リリースチームである。

俺は報告書作成のため、事象報告チームの作業となった。

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

投稿日2022.04.03更新日0000.00.00

投稿日:

プログラマー回顧録（１０）

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

後処理は果てしなく続くのである

旧モジュールでの安定稼働を見守る。

時刻は１４時を過ぎていた。

「食事に行こう。」

２次請負企業のプロジェクト責任補佐に声を掛けられた。

システムは復旧した。

だが１年前の状態に戻しただけである。

これからもう１度、最新の状態にしなければ終わらない。

最新モジュールを再度リリースする。

この過程がどれほど大変か。。。

ビルを出て近くの牛丼屋に入る。

「すみませんでした。」

謝る俺に補佐はこう言った。

「起きてしまったものは仕方ないさ。今できることをやろう。」

急いで牛丼を掻き込み、足早にビルに戻る。

ビルに戻ると事象の原因について議論されていた。

今回の事象の発生原因が判明したのだ。

原因を要約すると以下となる。

システムは起動時にサーバーから制御情報を受け取っている。

切り替え当日以降、制御情報に新機能のサービスのON／OFFの指示が追加で設定されることになっていた。

そして、システムのメイン機能はその情報を使用しない。

使用しないのだがメモリへの格納を許容することにしたのだ。

これが問題だった。

実はその格納していた値を見ている機能がいたのだ。

それがメイン機能の一機能である媒体管理機能だった。

媒体管理機能は制御値ゼロを期待していたが、サービスONが設定された結果、期待値ではなくなり、制御不能となったのだ。

そもそもメモリの参照など機能改修時の最も考慮すべき点。

なぜ見落としていたのか？

それは問題となった媒体管理機能が変数参照ではなく、キャストによるメモリ参照をしており、設計担当者は参照されないことに気付かなかったのである。

（これはこの後もう少し掘り下げて書いていこうと思う。）

これで原因は特定された。

この後何をするのか。

目に見える影響はあった。それ以外に影響はないのか？

同じような間違いをしている箇所はないのか？

被害を受けたユーザーはどれほどいたのか？

どう改修するのか？

幾つも挙げられる課題に対し、チーム編成され、課題に取り掛かる。

時間が過ぎていった。

旧モジュールに切り替えて以降、問題は発生しなかった。

終電が近づく。

「君はもう帰りなさい。」

２次請負企業のプロジェクト責任補佐に声をかけられ、帰宅することとなった。

夜勤として出社してからの稼働時間は２６時間になろうとしていた。

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

投稿日2022.03.27更新日0000.00.00

投稿日:

プログラマー回顧録（９）

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

try and try and …

システムに組み込んだモジュール切り替え機能は優秀だ。

モジュールの妥当性判定、ロールバック機能、トレース機能。

切り替えに必要となる機能は網羅している。

間違いのないモジュールさえ用意すれば安心して切り替えできるのだ。

だがしかし目の前で起こっている現実は切り替え失敗だった。

用意した旧モジュールが妥当ではない、サム値が間違っていると判断されたようだ。

夜勤として出社してすでに１２時間が過ぎようとしている。

切り替えモジュールの作成を担当している後輩にも疲労と焦りがあるのだろう。

切り替え失敗の報告を受けた後輩がもう１度、作り直す。

３０分ほど経過してまたモジュールが送られてきた。

再度、配信。

そして、切り替える。

「またダメです。」

配信担当者たちもさすがにいらだちがつのる。

「もう失敗はなしにしてくれ。」

こちらもそう願ってはいるのだ。

だが、こちらから誰に電話をしても一向につながらない。

検証室でも切り替えの動作確認はできるのだ。

なぜ切り替えが失敗するモジュールを送ってくるのか？

現場でフォローできないもどかしさを感じながら待つしかなかった。

３回目のモジュールが送られてきた。

失敗だ。

ここでようやく応援が入り、後輩に代わってモジュール作成を熟知した有識者がモジュール作成することになった。

そして、４回目の配信。

「成功しました。」

ついに、ついに旧モジュールで稼働が復帰した。

問題発生の一報を受けてから約７時間後、切り替え前の状態、言えば１年前にリリースしたモジュールで稼働を再開したのである。

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

投稿日2022.03.20更新日2022.03.27

投稿日:

プログラマー回顧録（８）

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

ハレーションを食い止めろ！

「まずは稼働を回復させましょう。」

１次請負企業の担当者が現状の動きと今後の方針を話す。

システムは全支店完全停止。

新機能のサービス開始は一端保留となり、まずは旧モジュールで稼働の復帰を目指す。

そうなるとまず自分たちができること。

それは旧モジュールの切り替え媒体を用意することだ。

電車で新宿に向かっている間に指示を受けた後輩が媒体作成にとりかかっていた。

俺は対策本部で新モジュールから旧モジュールに戻すことに対して対処すべき問題点のヒアリングを受ける。

気を付けなければならないのはシステムの誤作動と稼働データの整合性である。

その点について特別な手順は必要なく、切り替えが成功すれば通常に稼働できると回答した。

ほどなくして復旧モジュールが電子メールで送られてきた。

配信担当者たちが一斉に準備を始める。

「配信始めます。」

全支店に一斉に旧モジュールが送信される。

「切り替えます。」

息をのむ。

「ダメです。切り替え異常が発生しました。」

嘘だろ。。。

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

投稿日2022.03.13更新日0000.00.00

投稿日:

プログラマー回顧録（７）

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

事象、対策、リカバリー全てにおいて想定を超える

通常、問題が発生したときにはどう対処するだろうか？

問題に遭遇したユーザーに対するお詫びの対応がある。

それとは並行してこれ以上ユーザーが機能を使わないよう問題の機能を停止するわけだ。

機能を停止するパターンとしては大きく２つあるだろう。

それは、システム自体を停止するパターン。

それと、システムの問題機能のみを制限し、縮退状態で稼働を続けるパターンである。

現在稼働しているこのシステムも一定のシェアを誇っており、できれば稼働を停めたくはないはずだ。

だがしかし、この事象は縮退では回避できないのである。

そうなると稼働を続けるために残された対策としては１つ。

プログラムを旧バージョンに戻すしかない。

だがこのとき、１度切り替えに成功したプログラムを旧バージョンに戻す仕組みがなかったのである。

（このときの教訓をもとに翌年以降、旧バージョンに戻す仕組みを事前に用意することになった）

ユーザーの投入物を返却できない事象、縮退で回避できないメイン機能の問題、存在しないシステムの復帰手段。

八方ふさがりとはこのことであり、また絶望の淵に立つとはこのことであった。

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

投稿日2022.03.06更新日0000.00.00

投稿日:

プログラマー回顧録（６）

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

一瞬にして血の気が引く、これが絶望の始まり。

「問題ありませんでした。」

確認結果を急いで担当者に報告する。

「そうですか。」

担当者も首をかしげ、問い合わせ先に確認結果を報告する。

確かに言われた操作手順で何も問題は起きなかった。

だが。

何かがおかしい。胸騒ぎがするのは確かだ。

後輩はそのまま再現試験を続け、そして、俺はソースコードを追うことにした。

しばらくして問い合わせの勢いが増して来た。

あらゆる支店から問い合わせがきているそうだ。

担当者が再度やってきた。

「サーバーとの通信にこの設定を入れてください。」

手順が追加となる。

先ほどから検証室で動作確認をしている後輩に連絡を入れ、自らも検証室に向かう。

言われた通り、手順を追加する。

そして、操作してみると。

システムが止まった。

再現したのだ。

これはやばい。

このやばさを理解したと同時に一瞬にして血の気が引くのが分かった。

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

投稿日2022.02.27更新日0000.00.00
投稿日:

プログラマー回顧録（５）

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

ひとときの休息、そして、崩れ去る平穏

まずはプログラムの切り替えが成功した。

これで１つ目のハードルを越えたわけだ。

あとは実際にユーザーがシステムを使い、正常に稼働するか、だが。

このリリースに向け、幾度となく検証が行われてきた。

よほどのことがないかぎり問題など起こるはずがない。

安定運用の報告を聞いて、９時ぐらいには帰宅できればいいかな、などと予定を立てる。

「今回はとくに暇ですね～。」

後輩が背もたれを倒しながらつぶやく。

初期開発から携わったこのシステム開発も何年目だろうか。

ここ３年ほどは１年スパンでの新機能追加案件を受注しており、

作業もルーティーン化され、慣れがある。

今後の動きもある程度は予想できるのだ。

６時を過ぎた頃だろうか。

突如、プロジェクト担当者に矢継ぎ早に問い合わせがはいった。

急いで外注エリアに駆け込んでくる。

「すみません、この手順でシステムを操作してください。」

俺と後輩は急いで検証室に向かい、指示された通りの操作を行う。

どうやらその手順で操作をするとシステムが反応しなくなるそうだ。

２人で顔を見合わせる。

何も問題がないんだが。

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

投稿日2022.02.20更新日0000.00.00
投稿日:

プログラマー回顧録（４）

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

静寂の深夜待機、リリースの瞬間を待つ

「おはよう。それじゃあ、準備しようか。」

後輩と軽く言葉をかわす。

「はい。」

後輩は勢いよく検証室へと向かっていった。

リリースで問題が起こった際に再現確認できるよう現地と同じ環境を用意し、リリースの時を待つのである。

後輩が去った後、別のエリアで待機している２次請負企業のプロジェクト担当者に挨拶に行く。

「おはようございます。よろしくお願いします。」

「おはようございます。なにごともなければいいですね。」

軽く談笑する。

２次請負企業の社員で深夜待機に参加しているのはソフトウェア担当とプロジェクトマネージャー、プロジェクト責任者補佐の計３名。

そして、更に１次請負企業の対策本部に営業１名が出向き、リリースに備えていた。

３次請負企業の待機メンバーは俺と後輩の２名だ。

良く言えば選抜メンバーとなるが、実態はハードワーカーである。

とはいえ、それ以外の開発メンバーは何をしているかと言うと通常の日勤を終えたうえで電話待機である。

それはそれで大変だ。

現地リリース、１年に１回のこの日ばかりは問題が発生すれば電話一本でいつでも駆け付けるスクランブル状態となる。

何も起きなければ問題ないのだが。

検証室での作業を終え、後輩が戻ってくる。

時は刻々と進んでいた。

ときどきリリース手順に関する問い合わせが入っていたようだが特段の動きはない。

AM３時を迎えた。

しばらくの沈黙が続き、一報が入る。

プロジェクトマネージャーから報告を受ける。

「プログラム切り替えが成功しました。」

待機メンバーに安堵が訪れ、まばらな拍手が起こる。

このときにはまだこの後に最悪の事態が起こることなど知る由もなかった。

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

投稿日2022.02.13更新日0000.00.00