Fe and Ni

戯言だよ

「要求を仕様化する技術 表現する技術」読書メモ - 第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?
  • 拒否します!
  • 玖渚を疑念の目で見るいーちゃんマジ乙女

副音声は石丸小唄&哀川潤(頭から)なので全力過ぎて疲れた…。

  • ひかりさんの照れ顔&昼食、見たかったけどカット(真姫さんとの絡みが多すぎるからか)
  • ちぃくんの懲役周りとか健脚周りとかのエピソードはカット
  • そういえば真姫さん喫煙設定はカットなのか
  • 「君が女だったらよかったのに(意味深)」はカット
  • ひかりさんの哀川さん性格情報もカット(まぁ副音声聞けば分かりすぎるほどに分かるが…)
  • ちぃくんからのメールも余談部分はカット

OVA クビキリサイクル 3 ネタバレ感想

今回は小休止というか幕間というか、書くことが少ない…。
いーちゃんがいちいち可愛すぎる。

  • ジャケットの真姫ちゃん可愛すぎるでしょう
  • いーちゃんの絵、この後もらったんでしたっけ?
  • わかってた。全裸はないよね
  • しかしこんなに広かったら走り幅跳びも普通にできると思うんですよ
  • 4月とはいえ半袖は寒くないですか
  • 玖渚のデフォルメ顔がなんともいえぬ
  • いーちゃんは目玉焼き+ご飯派/真姫ちゃんは飲兵衛らしく味噌汁+水
  • 何気に佐代野さんが一番食べている
  • 台詞をかぶせてくるイリアさん、若い
  • 玲さん頬杖でもなく、微妙なポーズ
  • 25時就寝05時起床って辛くないですか
  • メイド服のブローチで見分けがつくのか(赤:あかりちゃん/青:ひかりちゃん)
  • 赤音さん、何気に黒づくめですね
  • 警察は嫌いなんですよねー
  • 桜の枝を持ってきたのは三つ子メイドなのかな?
  • 潤さん早く来てー
  • 回転チェアで倒立後方回転とか無理くないですか
  • いーちゃん、腕時計したりしなかったり
  • イーゼルに絵の具が付いてないの、おかしいよね
  • 血が付きますよ、玖渚さん
  • 皆よく黒い服持ってるね
  • 4月にキャミソールワンピは寒くないですか

OVA クビキリサイクル 2 ネタバレ感想

赤音さんとの飛車角金銀抜きチェス将棋はやっぱりカットだった…!
今回は作画が気合入っているカットとそうでないカットでムラがある感じ。

  • いい感じにいーちゃんの中二感が演出されている
  • イリアさん声可愛いなぁ。しかし全体的に皆胸が大きい…
  • OPのイリアさんは魔性な感じがよく出ている
  • 群青世界、SAOかな?と思うくらい爽やかだ
  • キャーテルコサンカッコイー
  • ようやく弥生さんの料理が結構出てきたよ!いーちゃんは子羊の王冠風のローストと卵入りポテトサラダしか食べてないけど。どれが誰の好物なんだろう。それぞれのキャラが食べてるものかな?
  • 弥生さんの色素が薄い感じ可愛い。自然に手を舐めてくるところがいい
  • 玖渚は哀川さんと会いたくなかった?なぜ?
  • "いつでもどこでもどこまでも楽しい"とか玖渚の異常さをもっと出していこうよ!
  • かなみさんと赤音さんの言い争いは普通に聞き苦しいよね
  • 言い争いを笑顔で見てるイリアさん腹黒
  • 玖渚が止めに入るシーンはもうちょっとたっぷりやった方が死線の蒼っぽかったのでは
  • 真姫さんの予言にwktkしてるイリアさんの横でニコニコしてる玲さんマジ可愛い
  • 真姫さんのいーちゃんいじりは本気でいーちゃんが哀れになってくるレベル
  • いーちゃんのキレ方が中二感あるよ
  • 風呂上がりいーちゃん最高。なぜか挿入されたセクシーポーズ。うにょい
  • コーラの蓋が赤くなりました
  • 地球温暖化のくだりあたり、玖渚が竹さんの絵に近い、気がする
  • 痛々しいところだったねぇ…
  • 深夜さん、無駄に格好いいという点でいーちゃんとは一線を画している
  • 真姫さんのいーちゃんいじりは本気でいーちゃんが哀れになってくるレベル(二回目)
  • いーちゃんのレイプ目がなんとも言えない味がある
  • ここの会話は結構かなみさんのキャラ出しに重要な気がするが結構カットされている
  • 思い出のコートにジェラっちゃういーちゃん可愛い
  • コートのサイズ、大きくなった?
  • 原作を読んだ時、玖渚のコートの下は裸だと思ってた (だって下に着てるって描写なかったし)。いよいよ次の巻で真相が明らかに!

真姫さんのいーちゃんいじめが全開過ぎていーちゃんがガリガリ消耗していく様子が最大の見所になっている…どう見ても尺が優遇されている…。
真姫さんどんだけいーちゃん嫌いなんだ。