今朝はいつもより目覚めが遅く、脱力感が。疲れが出たかな。

これからはHWコンポーネント評価と派生F/W開発の並行作業が必須の状況だ。行き当たりばったりでは乗り切れないだろうな。さてどうアプローチするべきか。

やっと不具合調査が片付いてきた。しかし、もともとがデバイス評価の出だし部分で起きたトラブルなので、この先に本評価がある。更に、本来は派生FW開発が主目的であり、ソースコード分析は進めているものの未だに変更要求仕様の作成にかかれていない。 ちょ…

簡単には上がるものじゃないな。特に夕方からは目に見えて落ちた。これでは長時間勤務もまるで意味がない。

自転車操業から脱したいので、時間を少しでもそちら方向に使うように…と考えると、やっぱり朝が良い気がする。しかし通勤時間を考えると、よほど早起きしないと中途半端か。週末の午前の勉強はなかなか良い感じだったが、平日はどう時間を作るかな。

[rakuten:tsukumo:391337:detail]それにしても金曜日にICが焼けた時は焦った。コネクタにテストピンを半田付けしたら起きたので、どこかミスしていたか。やるならしっかりやらないと、組込みソフトはハードあってのものだからなぁ。…というわけでフラックス…

AMのお勉強 「見積もりと進捗管理入門」Software People Vol.5 そういえば、失敗プロジェクトでは担当レベルの進捗管理が無くて、たまに 「大体いつ位になりそう？」 「そうですね…〜（悩む）〜…2週間程度かと」 というやり取りをリーダーが各担当と個別にす…

先行投資…この場合お金の投資を言うのではないのが難しいところだ。間違えないようにしないと。SEの仕事を楽しくしよう―こんなSEはだめになる作者: 清水吉男出版社/メーカー: ソフトリサーチセンター発売日: 2004/02メディア: 単行本購入: 3人 クリック: 18…

数年前、設計技術や開発プロセスに全く無知な「井の中の蛙」状態でデスマーチプロジェクトのF/W開発担当となって、非常に苦労した。スケジュールは遅れたし、やっと完成しても品質的に問題があって、いろいろ悔いが残る。その後、社命で参加した社内改善プロ…

GW明け3週目も不具合の真の解決を見ないまま終了。自分にとっては日々勉強になっているが、非力さを痛感させられることも多い。今日は原因不明のIC炎上が発生。状況証拠から、程度の低いミスの可能性が高い。だとすると結局無理な力勝負で突っ走ったツケとい…

なかなか時間をうまく使えない。やっぱり没頭癖がいけないような気がする。ある程度時間を決めて仕事するように変えてみるか。 この調子ではやりたいことが進まない。

一段落したら気が抜け気味。無理続きで疲れていることもあって、集中できなかった。やっぱり無理なペースでは続かないな。

不具合原因をH/W屋さんに判定してもらい、一応は納得できる区切りは付いた。しかし帯域不足の古い測定器を使用していたため有効なデータが取れていなかった。適切な測定器で確かなデータを取ってみたいところだな。あとはアナログの信号をまともに観察するス…

ようやく不具合の原因が見えてきつつあるが、単に信号にのったノイズに影響を受けているだけという線が有力になってきた。基本的な確認を端折って突っ走ったあげくに何という結末（笑）。 原因は焦り以外に無いな。あとH/Wの勉強不足もあるか。

以前、社内の改善活動的な会合で紹介されて買っては見たものの、ちゃんと読んでいなかった雑誌「Software People」を改めて読んでみる。自分が現場の当事者として問題に直面していると、内容の真実味がまるで違って感じられる。メディアを通して問題意識を世…

2週間盲目的に全力疾走してきて、気が付いたらいま何処にいて何処へ向かっているか良く分からなくなってしまった気がするな。過去の失敗プロジェクトを思い出すと、あまり目の前の作業に没頭し過ぎても意味がない気がどんどんしてきた。

連休中は長時間労働が続いて、勉強が一切進まなかった。業務は業務で勉強になっているのだが、さすがにちょっと極端すぎて良くない気もする。長時間会社にいても実は効率良くないしなぁ。少し意識して改めるか。

連休が明けて2週間経過してしまった。この間ほとんど、連休直前からの不具合調査しかできていない。 進展はしているが、すっきり片付けるまでにはもう一段壁があるなあ。全くふがいない。

なかなか不具合調査が片付かず。非常に勉強にはなっているが、他がお留守になってきている。

このところ目の前の問題に入れ込み過ぎて、視野狭窄気味になっている気がする。短納期開発のせいか、手元にある課題を一時保留する余裕が持てていない。上流で仕様化を詰めなければプロジェクトは失敗する、というのが業界常識だが…ひょっとすると今、デスマ…

測定器をあさってインターフェース信号を観察。目当てのタイミングを捉えるのに苦労したが、やっぱり有益だと感じた。 組込みのファームをやるのだから当たり前のことだが、今までできていなかった。

不具合の部位は押さえたが、原因がＨ/Ｗ要因の線も考えられて厄介。この際信号をしっかり追ってみるのも有益かも知れないが、スケジュールは平気なんだろうか（笑）。気が付けば、作業項目も要求仕様も完全放置で走り出しているが、まずくないのかな。

親戚に不幸があり法要のため遠出。帰宅後、最近控えている缶ビールを呑む。この週末は勉強していないが仕方ない。

「おうちでごはん」のかもちん風？きんぴらは茄子に応用しても案外おいしい。人参、ジャガイモ等硬い素材は細く切ると良いみたいだな。

教科書を参考に、ベース製品ソースコードの静的な構造を分析しているが、それだけでは苦しいと不具合調査中に度々感じた。RTOSのタスク間の動的な関連が把握できていないと、とんだ見落としや勘違いをやってしまう気がする。教科書でも後半に取り上げてある…

残る手掛かりを元にソースコード分析作業を進め、1日がかりで怪しい箇所に到達。ICEで張ったら当たりだった。システム停止時はRTOSルーチンに捕まっていたので問題箇所が見えなかったんだな。 さて、あとは真の原因を分析しないと。

これか！と思った対策が見事に空振り。分かってから冷静に考えれば妥当な結果なんだが、成果を焦るあまり冷静さを欠いている。また考え直しだな。

引き続き不具合調査。なかなか見えてこない。これまでの知識レベルでは解決は難しいかな。

これまでは規格書でコマンドインターフェースだけ参照していれば良かった（？）が、今の不具合や今後の保守を考えると、信号レベルからの理解が不可欠だと感じる。そうなると説明記述に乏しい規格書では辛いので、解説書が欲しくなった。ATA(IDE)/ATAPIの徹…

今日も不具合追い。行き詰まりが見えてきても柔軟な対応が出来ず、成果は上がらなかった。意固地というか、悪い癖だな。気を付けないと。