糖尿病のインスリン注射について自分なりのコツをメモ
残念なことに糖尿病と診断されてインスリン注射することになってしまった...。 何が不満と言って注射以外の手順がとても多い!
- 血糖計測機器の装着(2週に1回)
- 電子的血糖計測(1日8回)
- 物理的血糖計測(1日6回を2週間で3〜4回)
- 食事の記録(3回/日)
- 注射後の待機(3回/日)
- 糖尿病対策メニューのための買い出し・調理
- 低血糖症状への備え
記録結果は通院時に医療スタッフにチェックされるが、漏れがあると「うっかりさん」的な反応をされる...うっかりなのは正しいとはいえ、これを「面倒でない、100%できて当たり前」扱いされるのも納得いかんが?
これに加えて注射の諸々と主業務もあるのだが?
しかもここまでやってなお食べたいものを自由に食べることはできず、「食べるものを選べ(血糖値上がらないように)」と「もっと食べてもっと太れ」を1人の医師から同時に言われるのだ…(血糖値推移は個人の体質や体調、そのときの運動量など変動要因が多いため、この矛盾したTODOをこなすための「具体策」を提示してくれたりはしない。せいぜい軽運動の推奨・食事を小分けにして頻回に摂れレベル)
せめて物理的血糖計測/食事の記録の2つがなければまだ我慢できそうなのだが。
だが、最大の問題は「インスリン注射の痛み」である。
物理的血糖測定や計測機器の装着時の穿刺は一瞬であるため耐えやすく、かつ開始したら中断することはない(できない)ので打つ瞬間だけ覚悟すればよい。
が、インスリン注射は針の差し込み〜薬液注入〜抜くまでに10秒以上かかり(物理的には抜き・刺しを一瞬で行うことはできるだろうが…心理的には厳しい)、刺す場所がまずいとこの間「ずっと痛い」のである。
また、差し込みの途中で痛みのあまり針を抜いてしまうとやり直しである。この「中断できてしまう」=「複数回痛みに襲われうる」というのが痛みに弱い族としては辛い…「どんなに痛くても完遂できる」人種なら苦労しないのだが。
自分的インスリン注射のコツ
病院で or ネットで入手した情報を試した今のところベターな打ち方は以下。 (ネットの情報を信じるのもどうなのよ…と思うが病院では痛みや出血を避ける具体的な方法は教えてくれないし禁忌行為とは言われなかったのでもう知らん)
- 薬液中の気泡は内側の針カバーをつけた状態で注射器を机の角などに打ち付けて動かす(指で弾いても動かないし指が痛くなるだけ)
- 針を刺す前に針の先端で肌をつついて「明らかな痛点」を避ける
- これに時間をかけると針を意識してしまって「どこを刺しても痛い」モードに入ってしまうので「激痛でなければOK」の意識が大事
- 痛点の密度は 1mm 平方あたり数個らしいので、1cm 四方程度の範囲で最初に見つけたマシな点に打つ
- 皮膚を引っ張り上げるように持ち、垂直に打つ(これは多分病院で指導されているだろうが)
- 針を抜いた後の出血や薬液は拭き取らない(拭き取り時にせっかく注入した薬液が吸い出されてしまうことがあるとかないとか。苦労して打っているのに勿体無いので服が汚れる方がマシ)
これだけやっても2日に1回くらいは効いてないような血糖推移を見せるインスリン注射君…せめてうまく打てたのかどうかモニタリングできてほしい。
アリスクローゼット世界考察
アリスクローゼット
alice-closet.jp
キャラデザが種村有菜なので始めました。
マザーツリーから生まれたアリスという人形を着せ替えて美しさを競うクロージーという競技が普及している異世界:ワンダーランドに来てしまった主人公が元の世界に戻る手がかりを探しながら自らが目覚めさせた特別なアリスとの絆を深めていくゲーム。(長い)
ストーリー内ではワンダーランドの仕組みについては詳しく説明されない。まぁ多分関係無いしな...。
- マザーツリーと人間が共生する世界。
- ツリーは人間の「美しい」という感情を主なエネルギー源(=マナ?)として集め、対価として人間に加護を与えている?
- アリスは着飾ることで人間にマナを生じさせ、回収。一部を自分の活動源と成長(アリスはクロージーを通して能力が高まる)に、残りをツリーに送っている?
- 定期的な着せ替えが必要なのはそうしないと人間が飽きる = 感情が生まれないから。
- アリスは成長すると美しくなる = マナを効率的に発生・回収できるように自らを美化している。
- クロージーが強いアリスオーナーが社会的地位を得やすいのはそれだけツリーからの加護の重要性が高いから。
- オリジナルアリス = 原種?
- オリジナルは少数の高適合者(アリスに感情移入しやすく、情動 = マナが大きい)しか開花させられないため、普及に難がある。
- アリスの能力を制限することで適性が低い人間でも開花できるようにした。(能力は低いが数が爆発的に増やせる)
- 通常のアリスが感情・身体表現に乏しいのはその能力を削られているため?
- クロージーテーマをツリーが指示するのは欲しいマナの種類があるのかも?
- アリスのおてつだいは低効率なマナ回収手段?(24hクロージーしているわけにもいかないし)環境調査(何が美しいとされているか)の一環かも。
- 少ないとはいえ少年型のアリスがいるのはやっぱり少年にしか萌えない人もいるからだろう。分かる。
「要求を仕様化する技術 表現する技術」読書メモ - 第1部第2章 なぜ仕様のトラブルが起きるのか
それは「まともな要求仕様書」が書けていないからでは、という話。
ほんとこれな
仕様モレを見逃した本当の原因プロセスを改善しなければバグは発生し続ける
誰でもプロセスを「習慣」として身につけています。つまり、バグはその人の身につけている習慣(プロセス)がもたらしているのです。
一般に仕様モレは、いわゆる「不注意」でまとめてしまうことはできません。「注意」すれば防ぐことができるものではないのです。そこには、仕様書の構成などの「漏れる仕組み」や「発見できない仕組み」があるのです。
仕様FIXはうまくいかない
事前に要求仕様書のレビューを実施したにも関わらず、テストで発見されるバグのなかに仕様関係のバグが多く含まれていることは、そこにある要求仕様書はレビューでコメントが出せるものではなかったことを意味しています。
- 抽象的な記述の要求仕様書にFIXの承認は本来できない
- 「FIXしてくれないと実装が始められないので納期が遅れる」と言われて仕方なくFIXしているだけ
- 結局後で仕様モレが発覚し、「この記述は当然こういう意味だと思った」「書いてないのだから仕様追加だ」などと揉めることになる
仕様化に必要な時間を投入していない/できないのは各行程の見積もり精度に根拠がないから
「コーディングが間に合わない」という不安に押しつぶされ、コーディング以外の作業はことごとく省かれるのです。
仕様書レビューで問題が検出できない
- (要求)仕様書レビューで一番の障害はそこでの表現が「仕様」になっていないこと
- 抽象的な表現が残っていて、その表現のなかにどこまでの動きを含んでいるのか見えないため、モレを指摘するにも迷ってしまう
・(ネット販売)購入の確認操作では誤操作が入る余地を排除してほしい
・部屋の様子を映したビデオは、インターネットを介して顧客のPCの画面から自在に操作して見られるように
・設定データが変更されたときは、あとで再現できるように必要な情報と一緒に保存すること
- 特に仕様書の一部ではなく全体に抽象的な記述がある場合、全てを指摘するのはレビューコストがかかりすぎるため、結局「全てスルー」することになってしまう恐れがある
レビュータイミングの問題
- 最後にまとめてのレビューを設ける場合が多い
- 基本的には一回のレビューしか想定されていない
- ここでは多くの指摘がなされないことが前提になっている(仕様書に重大な欠陥があるケースを全く想定していない)
メモ
どんな問題が起きているのか?それは要求仕様書が原因か?
要求仕様書の書き方・構成が原因かもしれないトラブル
- 仕様関係のバグが多い
- 設計や実装の途中で仕様変更が多い(仕様不備を早期発見する仕組みが必要)
- 途中で設計者のほうから仕様の問い合わせが多く発生している
- テスト作業で仕様の確認が多く発生している(仕様書が「検証可能」な状態になっていない)
- バグとして上がったが現状の動きに合わせて仕様のほうを変更した件数が少なくない(仕様間の絡みが判断できない状態)
- 動いてからでないと何もコメントできない、と顧客や営業の人にいわれた
- 根本的なアーキテクチャ上の設計ミスが起きている(仕様間の絡みが見えないか、アーキテクチャ上の配慮の必要性が見えない状態)
そんなときは
- 暫定仕様がFIXしたときの対応を事前に考えておく
- 仕様の変更件数・変更率を計測する
- 問い合わせ件数と時期のデータで実態を把握
- どのような表現・構成なら読まれるのか読み手の意見を聞く
バグデータx何かで見えてくるもの
- 1000行あたりのバグ発生率 => プロジェクト全体の作業の品質の一面
- 機能別バグ発生率(1000行あたりのバグ発生率を機能で分けたもの) => 発生率の低い機能における作業方法が問題解決の糸口になるかも
- 機能別の仕様変更件数とバグ発生率との対比 => 仕様変更とバグに相関があるかどうか/仕様変更の少ない機能の仕様策定方法が参考になるかも
大事なことは、バグデータから自分たちの組織の問題を見つけるという姿勢を見せることです。
よくあるダメな要求仕様書
- カテゴリには分けられているものの、「要求」が表現されていない
- 「仕様」といわれているのに特定できない表現を含んでいる
- 仕様なのか説明なのか分からない表現
- ハードをコントロールするフローチャートが書かれていたりする
- 品質要求が書かれていない
- 「要求項目」「要件リスト」はあっても、仕様との対応させて扱っていない
- 要件リストの分類と仕様書の分類が異なる
memo:
「要求仕様書に要求が表現されていないために、その機能にはどのような仕様が含まれるべきか、どこまでの範囲の仕様が含まれるべきかが見えない」っていうのは分かるんだけど、どう表現すればよいのか、が書いてあるのはまだ先…。
「要求」なのか「仕様」なのか、あるいは「説明」なのかを明確にして、その扱いを定義しておかないとつまらないところで仕様のトラブルを招いてしまいます。
memo: どんなトラブル?要求/仕様/説明の定義は後々出てくる?
画面仕様書の問題
よくある記載事項:
- 画面遷移
- 個々の画面の要素配置図
- 表示域やボタンの簡単な説明
不足しているもの:
- 表示域についての詳しい仕様
- ボタンが押せない状況や、押したときの処理としてデータチェックやファイル保存、画面への反映などの仕様
それによって起きる問題の例:
- 表示条件や状況によって表示領域の表示パターンを変えなければいけないことに実装段階で気づく
- => 気づいた時点で対応する
- => 新たな仕様トラブルの種を埋め込んでいる!(他の画面との整合性が崩れる/対応内容が仕様書にフィードバックされないので、後日思い出すにはソースコードを読まないと分からない、などが起きる)
仕様化に必要な時間を投入していない/できないのはなぜ?
- そもそも仕様が明確になっていない状態での見積り工数には根拠がない
- さらに、仕様を詰めずに実装してしまうと後々の仕様変更で元の何倍もの工数を失ってしまうことを分かっていながらも、仕様化の時間を事前に組み入れられない
なぜか?
「コーディングが間に合わない」という不安に押しつぶされ、コーディング以外の作業はことごとく省かれるのです。
何が問題?
- 実装工数見積もりをしていない、または見積もりに自信が持つことができない
- 開発プロセスが曖昧で、スケジュールの根拠が薄い
どうすれば?
見積もりをしていない => 見積もろう
- ソースコードのサイズ
- 実装工数
見積もりに自信を持てない => 見積もりと実績を比較しよう
- ソースコードサイズ・実装工数などの見積りと実績を比較
- 比較結果を踏まえて見積もりを調整、精度を上げていく
レビューを実施しても後で問題が出てくるのはなぜ?
- 要求仕様書のレビューでレビュアーが仕様モレや仕様間の衝突などの欠陥・問題を発見するには、構成や書き方が適切でなければいけない
- 逆に適切な構成・書き方は、書き手にとっても仕様が漏れにくいもの
- 「要求仕様書作成ガイドライン」を(できれば設計チームの人が)作成し、要求仕様書作成時にそれに従うようにすると構成が安定する
レビューしやすい要求仕様書のポイント
- 設計や実装のイメージができるほどに具体的な表現であること(具体的)
- 仕様の記述が発散しないように「範囲」の中でグループ化され整理されていること(分類と整理)
構成に問題がある
「概要」と「詳細」の問題
5章 計測機能
[概要](ここに、この計測機能についての動作や代表的な振る舞いが書かれています)
[詳細](ここから、計測の開始方法、測定データの集め方、集めたデータの表示方法などの仕様が書かれています)
- [概要]内に[詳細]には書かれていない「仕様」が含まれていることがある
- 上記を回避しようとすると[概要]と[詳細]で記載内容が重複せざるをえない(つまり、この構成は筋が悪い)
特に「概要」という文字のついた文書または「節」はレビューに耐えられません。内容は表面的で不完全ですし、書き手も「概要」ということでレビューに耐えるものを想定していません。そのような性質を持った「概要」のところに、見落とされては困るような「仕様」が書かれているとすれば、あまりにも無神経な行為といわざるを得ません。
memo: う、やってしまっているかも…。
無秩序な記述
仕様の括り方や設定情報と絡む仕様の書き方、エラーに関する記述の扱いなどが人によって違っていることがある
また、一つの機能の中でも記述順に秩序がないと漏れている仕様に気づきにくくなってしまう
インク切れ監視機能
・残りの印刷枚数が10ページ未満のときは、PCに通知しないで、印刷処理を続行する
・残りの印刷枚数が10ページを超えるときは、PC側に「危険」を通知する
・インク残量が「警報レベル」を示しているときは「警告」をPCに通知して新しい印刷の編集を停止する
・PC側から「続行」の指示を確認すればインク残量をチェックし、交換されたことを確認できたときは編集・印刷を再開する
・PC側から「中止」の指示が届いたときは、未編集のデータを廃棄する
・10ページ印刷ごとにインク残量を確認し、残りのページ数との間でインク切れの危険性を判断する
memo:
構成を直すとしたらどうなるんだろう…
仕様の中で気になったのは以下だけど、他にもあるかな?
- 印刷開始時はインク残量確認する?
- 「10ページ」のカウントはどうやる?ドキュメントをまたぐ?
- インク残量のレベルは何段階?危険/警報はそれぞれどんな状態?
- 「続行」「中止」の指示はいつ出るのか?危険通知のときも出る?
- 「続行」指示後にインク交換が確認できなかったときは?
- 指示の後に何かPC側に表示する?
- PCに通知できなかったときはどうする?PCから応答がないときは?
レビューしにくい構成
- 機能の動作・表示に影響する多くの"パラメータ"は「設定」というカテゴリで説明されていることが多いが、記述があちこちに点在しているとレビューの障害になる
- エラーに関する記述も、機能ごとにまとめて書かれているケースと、それぞれの振る舞いの記述の箇所に配置されているケースがある(これはどちらも一長一短なので、両ケースが混在することが問題)
書き方に問題がある
「説明」か「仕様」か?
・予備バーナー点火ボタン
このボタンを押すと予備バーナーに点火する。予備バーナーは、タンクの温度があらかじめ定めた保温温度を下回ると自動的にメインバーナーの点火の種火ともなる。
- 前半は予備バーナーの仕様
- 予備バーナーの点火に条件はあるの?
- 点火中に発生する異常状態に対する処理はどうすれば?
- 後半はメインバーナーの仕様(メインバーナーはタンクの温度が下がると自動的に点火する。そのとき予備バーナーを種火とする)
仕様になりきっていない
要求仕様書レビューで一番の障害はそこでの表現が「仕様」になっていないこと
抽象的な表現が残っていて、その表現のなかにどこまでの動きを含んでいるのか見えないため、モレを指摘するにも迷ってしまう
・(ネット販売)購入の確認操作では誤操作が入る余地を排除してほしい
・部屋の様子を映したビデオは、インターネットを介して顧客のPCの画面から自在に操作して見られるように
・設定データが変更されたときは、あとで再現できるように必要な情報と一緒に保存すること
特に仕様書の一部ではなく全体に抽象的な記述がある場合、全てを指摘するのはレビューコストがかかりすぎるため、結局「全てスルー」することになってしまう恐れがある
レビューのタイミングも問題
- 最後にまとめてのレビューを設ける場合が多い
- 基本的には一回のレビューしか想定されていない
- ここでは多くの指摘がなされないことが前提になっている(仕様書に重大な欠陥があるケースを全く想定していない)
重大な欠陥の例:
- 根本的に仕様がまとまって抜けている
- エラーケースがほとんど書かれていない
- 関連するパラメータに対する振る舞いがほんの一部しか書かれていない
レビューには2種類ある
- 公式のレビュー:成果物の承認のためのレビュー
- 半公式のレビュー:成果物の欠陥を発見するためのレビュー
半公式の「逐次レビュー」がおすすめ/例えば以下のタイミングで実施
- 要求仕様書の全体構成を考えたとき
- 一つの主要機能の仕様構成イメージが固まったとき
- 一つの主要機能の仕様が書かれたとき
逐次レビューの危険
前回のレビュー範囲では問題なかったが、今回のレビュー範囲の中で以前に確認された仕様と矛盾するところが出てくる可能性がある
=>
レビュー範囲を「今回仕様化された範囲」に限定せず、「機能間の関連マトリクス」などを参考にしながら仕様の矛盾に気づく機会をつくる
仕様書を書くことに対する誤解
- 仕様間の絡みを解決し、きちんと「整理がついた状態」を表現するものと考えている
- 頭の中で絡み合う仕様をほぐしてから「完成した姿」を書こうとしている
- 依頼者から渡された「要求仕様書」に対して、設計者の方で不足している仕様を"補充する"という発想がなく、作業枠が確保されていない
「仕様化」は「決めていく」作業
- 順番に仕様として「決めて」いき、仕様の衝突や絡みが出てきたら戻って調整すればOK
- 仕様書がない場合、コーディングしながら「仕様を決めて」いるはず
- ただ、コーディングと仕様化を同時にやると次第に混乱してきてしまう(問い合わせに日数がかかったり、「戻って調整」するのが3週間後でもう記憶にない…などの問題が起きるため)
OVA クビキリサイクル 6 ネタバレ感想
いよいよだからか気合が入ったカットが多かった気が…てる子さんの裸眼顔は必見。
- 毎度だけどジャケット絵綺麗ですね。佐代野さんだんだん可愛くなってきた気がする
- なんで玖渚の髪の毛をこんなにキラキラさせてるんだろう…
- 冒頭のナイフとピストルで滑るシーンですが、まさかポーズまでついていたとは…
- 自然にポーズを取る19歳…普通に考えると痛い
- Bチームの4人、画面がよくまとまっているのはキャラデザの素晴らしさか
- 玲さんええ声やわぁもう…踏んで…!
- そうですね、ここのイリアさんは手袋してないとダメですね
- こうして聞いてみると、イリアさんと話しているときのいーちゃんの口調がばらばらで、ええなんていうか情緒不安定な人みたいですね
- イリアさん、口がωになってますよ
- 今巻もきました!いーちゃんのハラキリマゾのターン…!
- ところでてる子さんいーちゃんに触り過ぎ
- ところでどうして誰も座らないであろうパイプ椅子をこんなに並べているんだろう…
- てる子さん、零崎シリーズで再登場するのも納得のキャラの立ち方だよね
- 一里塚木の実といい、恋人でもない人に胸を触らせられるってそんなにない経験だよ
- 「死んだ方がいいんです」とかてる子さん至高の責め文句…!冷たいというより逆に激アツ
- 大笑いしながらもいーちゃんをガン見する真姫さん、そんなにいーちゃんのヘコんだ顔を見たいのか
- え、そのディスプレイ息吐きかけていいの…ていうかそんな原始的な掃除でいいのひかりさん
- 自分をいーちゃんと書く19歳、普通に痛いよいーちゃん!
- ケーキばっかり食べてるけど昼食に何を食べたのか知りたかったなぁ
- ところでこのケーキも佐代野さんが毎日作ってるんですかね。いいな…!
- じたばたする玖渚を猛烈に可愛いと思いながら無表情で対するいーちゃんであった
- 玖渚は死線の蒼のカットが一番気合い入ってるよね
- 今回のいーちゃんと玖渚の会話、間が大変よい
- 改めて佐代野さん、どうしてずっとこの島にい続けてるんだろう…
- 芝居がかった&思わせぶりな戯言遣いにノーリアクションな女性陣、この島にいるだけある
- そういえばEDの玖渚の部屋、いーちゃんが片付けた直後だよね
- あとここ、絶対京都じゃないのでは
- 副音声、瞳島か地濃だったら前者のがよくないか…?
ところで西尾維新大辞展 http://exhibition.ni.siois.in/ のトップ絵ですけど、これ絶対玖渚ちゃん着てない…着てないでしょ!?
「要求を仕様化する技術 表現する技術」読書メモ - 第1部第1章 要求仕様にまつわる問題
「改訂第2版 [入門+実践] 要求を仕様化する技術 表現する技術」(清水吉男著/技術評論社)
を読み始めました。読み切れるか大いに不安ですが、序盤からぐさぐさ刺さってきて周りの人に本当読ませたい。
第1部第1章ざっくりまとめ
- 問題プロジェクトあるある
- 実はバグの大半が要求仕様に関係している
- 開発者側に要求仕様書を書くスキルがないことが問題
ほんとこれな
残念なプロジェクト
今回のプロジェクトは納期も大きく遅れた上に、テストしてみると要求した機能も十分に達成していない、という状態はしばしば発生しています。特に、異常操作の対応や全体の操作性や応答性などの品質が悪く、とても完成したものとは認められないケースもあります。
いったん製品が市場に出ると、それが競争相手からターゲットにされるので、その状態で次々と新しい機能を組み込んだり短期間で機能を改良したりすることが求められます。それができなければ市場から退場させられるのです。
双方の機能が拮抗している状態では、的確なデリバリを実現できるだけで市場を獲得できることがあるのです。
それを支えるのは保守性などの品質要求を実現するための設計技術なのです。
設計や実装の工程で明らかになった「仕様」は要求仕様書に書き戻されることはない
仕様が曖昧な状態をカバーしてくれるような設計技術はありません。あるとすれば、設計中にそこで扱っている機能の仕様の曖昧さに"気づかせてくれる"程度です。そのときに気づいたことを仕様書に書き戻さなければ、他の仕様との衝突や不均衡には気づかないのです。
顧客にまともな要求仕様書を書く能力がない => 設計者が要求の仕様化技術を習得する必要がある
依頼者にはまともな要求仕様書をかけないと認識していながら、自分たち(設計者側)はそれをカバーする手段を持とうとせず、仕様変更で混乱する責任を依頼者のせいにしているように見えます。
(略)
確かに、設計者達は、効果的な要求仕様書の書き方を身につけていることはほとんどありません。少なくとも、そのような訓練を受けていないと思われます。
(略)
したがって、まずは設計者に要求の仕様化技術を習得してもらう必要があります。実際にそれを解釈しソースコードに変換するのは、ソフトウェアエンジニア(設計者)の方ですから。
品質要求を仕様化できない
機能要求に限らず品質要求も、仕様化されない要求は実現しないのです。
もともと、機能要求でもうまく仕様化できないために、多くのトラブルが発生しているのです。それは、要求を仕様化する技術が不足していることを意味しています。ましてや、品質要求なんて仕様化したことがないのです。
メモ
バグの過半数が要求仕様に関連するもの
- 仕様の記述モレ
- 読み手による仕様の誤解釈
- その仕様が自分に関係すると気付いていない
- テストの段階で検出される仕様間の衝突
- ((要求仕様の問題によって発生する)設計の遅れによって生じる)テスト不足
- (要求仕様が提示されない・または提示の遅れによる)テストの遅延・不足
memo: 自案件でも本当にそうか?は要分析。個人的印象では上記に該当するものは確かに多い。
バグの原因プロセスを分析する際、「設計プロセス」とする組織は多いが、設計エラーではなく仕様エラーとした方が解決しやすい場合がある
届けられたデータをチェックしないでそのまま使ったところ、たまたま不正データが入ったままのデータに遭遇したことでプログラムが暴走した
(略)
受け取ったデータをそのまま使用してはならないことを知らされていない状況では、設計エラーではなく、仕様エラーと分類
- 設計エラーとすると「設計者が気付く」か定期的に注意アナウンスするしかない(具体的な解決策がない)
- 仕様エラーの場合、気付くような書き方をする、という改善ができる
- 派生開発での変更モレはほとんどが設計エラーに分類されるが、これは「実装仕様の変更を変更仕様として書き出す」という考え方がないため
memo:
とはいえ、自然言語で書かれた要求仕様書に完璧はない。精々仕様モレなどの発生確率を許容範囲のレベルに下げるだけ、とのことですが。
顧客からの仕様変更 => 実は設計者が問い合わせたタイミングで発生することが多い
設計者がコーディングを進めていく中で仕様の曖昧な箇所に遭遇し、そこで依頼者に質問のメールや確認のメールを発したことが仕様変更のきっかけになっているのです。
- 依頼者は仕様と呼べるものを書けないことが多い
- 設計者も早い時期に仕様の不足をカバーできていない
- 仕様変更の多くは、設計者の問い合わせをきっかけに起きている
- しかも設計段階から実装段階にかけて多発しているために作業が混乱している
仕様戦争
- 終盤に発見された仕様の衝突は「(要求仕様の不備(=依頼者の責任)によって生じた)制限」として依頼者に提案される
- 依頼者は提案を受け入れる代わりに他の「追加仕様」をねじ込む
- 設計者側は提案タイミングが遅すぎることの気まずさから負荷の大きい追加仕様を受け入れざるをえない
- 「初期の段階で仕様不備に気づき、補足すること」はできない(設計者が要求仕様化スキルを持たないため)
要求を満たさない
今回のプロジェクトは納期も大きく遅れた上に、テストしてみると要求した機能も十分に達成していない、という状態はしばしば発生しています。特に、異常操作の対応や全体の操作性や応答性などの品質が悪く、とても完成したものとは認められないケースもあります。
この本でその最大理由として挙げられているのが、
- 「要求仕様書」が「仕様」といえるレベルに達していない
- 完成品として含まれるべき「品質要求」も記述されていない
- 関係者が、その不十分さに気づくためのスキルを持ち合わせていない
試作の弊害
- 「実現可能か分からない要求仕様」は細かい仕様に展開されず、試作で確認されることが多い
- しかし、安易な試作は仕様化・矛盾の検証などの不足につながる危険性がある
- 仮の要求仕様であっても、「それを実現する場合に必要な仕様」を決めることで「仕様衝突の検出」などできる
- 仕様には設計方法を誘導する力がある
派生開発のリスク
- 特に派生開発において、ソフトウェアの全体を理解して開発することは実質的に不可能
- 部分理解で対応せざるをえないにも関わらず、対応ミス・モレによる既存機能への悪影響は許されない
- また、他人のソースコードから元の要求・設計思想を理解するには新規開発より高い技術が求められる
- 一つの変更要求が複数の開発者に影響する場合、「関係することに気づかない(or伝えられない)」「(要求が曖昧な場合)人によって要求の解釈が違う」などが生じる可能性がある
memo:
1.8.3あたりの監視カメラの例は、この本ベースの勉強会するなら例題としてよさげ。
例えば
- 参加したばかりの派生開発プロジェクトでこの要求の対応見積もりを依頼された。どのようなことを考えるか?
- (隠れていた要求仕様を明らかにした後で)同様の事例を経験したことはあるか?
- このようなリスクがあることを踏まえて、見積もりをどのように扱うのがよいか?(対顧客・チーム内それぞれ)
とか。
設計フェーズの成果物が設計書ではなく要求仕様書になってしまう
- 本来の設計は(要求仕様をもとに)「データ構造・処理構造・制御構造」の3つの視点から(要求仕様の)実現方法を考えること
- 設計には「アーキテクチャ設計・タスク設計・関数設計」などの段階があり、それぞれで上記各視点を用いる
- 設計書とは設計の各段階で考えたこと、決めたこと(=仕様)が書かれたもの
- 各段階の仕様は「元となる要求仕様と対応する」が「元の仕様を補足するものではない」
- 設計の元になる要求仕様書が不完全な場合、設計の中で仕様が補われ、「設計書」としてまとめられる
memo:
設計には段階がある、というのはいわゆる外部設計・内部設計や詳細設計、などと読み替えてもよいのかも。
大事なのは 「設計書に書くべきなのは"元となる要求仕様の補足"ではなく"要求仕様に対応する(より低レイヤの)仕様"であり、そうなっていないなら元の要求仕様書に問題がある」 ということか
本には直接的に書かれていないけど、これによる問題は以下?
- 設計書内の要求仕様が要求仕様書にフィードバックされないので要求仕様として管理されない・仕様の衝突や誤解釈に気づかない・仕様が関係者に伝わらない
- 本来やるべき設計の時間が圧迫され、設計不備のリスクが増加
OVA クビキリサイクル 5 ネタバレ感想
今回はあんまり省略がないかな。
佐々さん好きです。
- キメ顔のてる子さんかわいい…。
- 玖渚に抱きつかれたまま真顔のいーちゃん流石
- 赤音さんの手に出ていたのは死斑…?
- ディンプルキーなのか
- ちゃんと赤音さん好みの和食(魚)を用意してあげる佐代野さん
- あれ、なんか佐代野さんが可愛いぞ…?
- 朝ごはん、結局イリアさんと怜さんくらいしか食べてないのでは?
- なんでイリアさんミニスカなんだろう
- 煽られるいーちゃんVSイリアさん感
- 水冷なんだか水をかけたんだか?
- 玖渚たんの黒タイツ!玖渚たんの黒タイツ!
- 無駄に青春風なの何故なんだ
- やっぱり窓が高すぎると思いますが
- 上下移動って、階段だけで坂道はいいのかなぁ
- 佐々さんのおかげか、副音声が比較的真面目だ?
- 次回予告、なかなかよい
OVA クビキリサイクル 4 ネタバレ感想
この巻の作画、なんか前までの巻と違う気がする…。
- 2.3GBのMOですよ皆さん!
- "ちぃくん"もそのイントネーションなんだ…
- 映像化されてよかったランキング上位確定、イリア嬢の生着替えは流石のクオリティですが努めて平静を装ういーちゃん
- それがどうかしましたか?(パンツ一枚で)
- イリアさんそのパンツの履き方は挑発的ですよ!
- つ・い・に・玲さんのセリフが来ましたよ!桑島さーん!
- 螺旋階段室壁際の彫像適当すぎるよっ
- 真姫さん見るなりレイプ目のいーちゃん激カワ
- しかしこの時の二人はどんな話をしていたんでしょうねぇ…
- 省力で作ったとは思えない中華…美味しそう…(佐代野さん今回セリフないですが)
- JISでもUSでもないキーボードにもっと触れてあげないといーちゃんが機械音痴みたいになっちゃうでしょ!
- 「風呂に入ってます」と言えばいいところ詳細を説明するあたりがなんていうか
- 倉庫前だったのかここ…。
- the post hoc fallacy
- さらっと真理先生暗唱するの普通じゃない
- 原作では気づかなかったけどこのシチュエーションで精神分析されるの辛いよね
- 基本的に?ER3のハラキリマゾが?
- 赤音さん着替えたの?
- 玖渚の髪色はかなり薄い…もっと青くていいんだよ!
- ひかりさんの前でつい格好つけちゃういーちゃん…!
- サドい玖渚たん
- spotted having lunch?
- 拒否します!
- 玖渚を疑念の目で見るいーちゃんマジ乙女
副音声は石丸小唄&哀川潤(頭から)なので全力過ぎて疲れた…。
- ひかりさんの照れ顔&昼食、見たかったけどカット(真姫さんとの絡みが多すぎるからか)
- ちぃくんの懲役周りとか健脚周りとかのエピソードはカット
- そういえば真姫さん喫煙設定はカットなのか
- 「君が女だったらよかったのに(意味深)」はカット
- ひかりさんの哀川さん性格情報もカット(まぁ副音声聞けば分かりすぎるほどに分かるが…)
- ちぃくんからのメールも余談部分はカット