「高品質」と感じたものの裏側を覗こうとしてみる~ジュジュツカイセン~

呪術廻戦、面白いですよね。

アニメはたまに見る程度の人間なのですが、呪術廻戦のアニメーションがかっこよくて、そこからハマってます。

ハンターハンターが好きなので、系統の近い呪術廻戦もハマるのは当然かもしれません。

今回の記事で言及したいのは、物語に関してではなく、アニメ(アニメーション・演出)のクオリティの高さについてです。

私は普段あまりアニメを見ない人間なので、色々なアニメを知っている上で「呪術廻戦がすごい」と言っているわけではないです。有識者からすると「こっちのほうがクオリティが高い」という意見が大多数かもしれません。その点あらかじめご了承下さい。

いきなり話が逸れますが...

ソフトウェアの品質について「こんな複雑なもの、本当に品質を高められるんだろうか?」と思ったことがあります。 何をもって品質が高いとするかを定義して、そこに向かって活動をすることはできると思います。ただ、ソフトウェアと対峙した瞬間「これは品質が高い」と直感的に思えるようなソフトウェアをつくることはほんとに可能なのだろうか?と。

他の人はどうかわかりませんが、私は普段から「これは品質が高い」と直感的に思えるようなソフトウェアにほとんどあったことがありません。 というか、ソフトウェアの品質への印象って、ソフトウェアそれ自体だけで構成されてなくて、ソフトウェアを使ったその人自身の体験・体感によって左右される気がしており、その体験をソフトウェアの作り手がどうこうできるのか。

ソフトウェアの品質が悪いのではなく、ソフトウェアを使った私(ユーザ)の体験・体感が良くなかったという話で、高品質だと思えなかった原因はソフトウェアではなく私(ユーザ)の中にある可能性もあるかなと。そんなことを考えていると、ソフトウェアの品質を高めるというのはなかなか難しいという冒頭で書いていたような気持になったわけです。

ソフトウェアと同じように実物は無いものの、品質の高いと感じるものの存在があることに気づきました。それがアニメです。 そんなアニメの制作工程や制作の考え方に、品質の高いソフトウェアを作るヒントが無いか、興味を持ちました。

最近見たアニメで特に品質が高いと感じた呪術廻戦の制作会社である MAPPA さんについて少しだけ調べてみました。

調べてまず分かったのは、MAPPA さんのアニメの品質が高いというのは、僕の主観だけではなく、世間的にもそのような評価になっているということでした。 また MAPPA さん自身、品質の高いアニメを制作することを理念の一つとされており、それを実現できているという状況のようでした。

MAPPA さんの理念に関しては、求人サイトで確認しました。

cgworld.jp

品質の高いアニメづくりを掲げ、そしてそれを実現できているというところで、意図的な戦略があるはずで、それを知りたいという欲求が沸き、代表の方のインタビューなど読みました。 読んでみて分かったのは、よりよいアニメを作るために、経営や資金調達の仕方から工夫が行われているという点でした。非常に興味深かったです。

natalie.mu

www.itmedia.co.jp

アニメをソフトウェアに近いものとして話を進めていましたが、決定的に違う点があることも感じています。それは用途です。 アニメはそれ自体が目的になりますが、ソフトウェアは目的を達成するための手段になります。こうして言葉にしてみると、アニメとソフトウェアでは高い品質を生むことの重要性が大きく違うことに気づきます。 ソフトウェアの品質は高い必要があるという前提で話を進めていましたが、実際は、目的を達成できればソフトウェア自体の品質はそこまで重要ではないのかもしれません。 が、おそらくそれは極端な整理で、競合とのシェア争いに勝つために、ソフトウェア自体の品質が重要という考え方もありえます。 アニメの品質を高める方法がどこまでソフトウェアの品質を高めるヒントとなるかはわかりませんが、これらの点は考慮しておいた方が良さそうです。

アニメの制作過程や制作の考え方に対しての追求が全然足りてないですが、ちょっと疲れてきたので切り上げようと思います。 引き続き、アニメの制作過程や制作の考え方に関して調べてみようと思います。

初めてマラソン大会に出場した

出た大会は以下。

greenpark.yaaas.run

この大会を初めて参加するマラソン大会に選んだのは、雰囲気が楽しそうだったことと、日程の都合がよかったから。

なぜ今更マラソン大会に出ようと思ったのかというと、日々のランニングのモチベーションを落とさないため。 体力不足解消のために年明けから走っているが、正直、走ること自体に楽しみをそこまで見出していない。体力もすぐにつくわけではないので、モチベーションの維持がむずかしかった。そんな状況を打開すべく、マラソン大会に申し込んでみた。

ラソン大会当日、会場に向かう。 三連休中、奇跡的にマラソン大会の日だけ快晴。もうこれだけでうれしい。

受付には人がたくさんいた。 さわやかな洋楽と健康な肉体をさらしている人々に突入していくのは、ちょっとハードルがあった。

受付を済ませて着替える。 何の気なしに自身が参加するコミュニティのTシャツを着ていったのだが、どうやら規約に引っかかるようで(許可されていない場合、宣伝に繋がる衣服がNG)、やべーと思いながらなんとかロゴをゼッケンで隠すことに成功。

そうこうしているうちに、ハーフ部門の人たちがスタートする。

youtu.be

しばらくして、ワンエイト(5kmくらいの距離)部門もスタートする。私が走る部門だ。 まぁ 5km くらいだったら、家のランニングマシーンで何度も走り切ったことあるし、もともと運動部だし、結構いい成績出せるんじゃないかなと思ってた。 列の前の方に移動し、スタートを待つ。

スタートの合図が鳴る。 同時に、Spotify で音楽を流す。 鍛えられた肉体の人と並走する。 ここまではかなり楽しかった。

結果。

スピードを出し過ぎて 1km 過ぎたあたりでかなりきつくなって歩いてしまった。 心臓がよくわからない動きをして、死ぬかと思った。

何とか途中で走りを再開できたのはよかった。

しかし結果はなかなか期待外れであった。

後生のため、ちょっと言い訳を書き残しておく。

まず、ランニングマシーンを使ったランニングと地を蹴るランニング、ものが違い過ぎた。 自分は日々のランニングを、室内のランニングマシーンで済ましていた。 室内のランニングマシーンで 5km を走れているから、マラソン大会の 5km もそんなに大きなハードルではないだろうと思っていた。

しかし実際は、ランニングマシーンを使ったランニングと地を蹴るランニングまったく別物で、私は後者に対する適正に全く到達していないことに気づかされた。

自分が足を止めると進みが止まるという事実。 メーターもなく、また周囲に他のランナーがいる状況でペースを維持の難しさ。 色々な気づきがあった。

結果は想像よりも悪かったが、ゴールのテープを切る経験が出来たり結果を記録してもらえたり、全体的な体験はとてもよかった。

今回の結果をスタート地点として、次も頑張ってみようと思う。 というわけで、3月もマラソン大会に出ることにした。楽しみ。

タカオネに行ってきた

タカオネ泊ってきました。 タカオネは高尾山口駅の近くにある宿泊施設です。 きれいな部屋と焚火に惹かれました。

takaone.jp

タカオネは単なる宿泊施設ではなく、研修施設も備わっていて、「活動ホテル」というコンセプトを掲げた施設です。

研修施設はこんな感じ。

予約がない時は、宿泊者向けのフリースペースエリアとして解放しているみたいです。

屋上もあります。

部屋はこんな感じ。いくつか種類があるのですが、写真はスタンダードルームです。今回利用する部屋でもあります。

壁に掛かっていた折りたたみ椅子とテーブルをセッティングします。

廊下にカードゲームがたくさん置いてあったので部屋に持ち込みます。

近くのコンビニでお酒を調達し、お酒を飲みながらカードゲームを楽しみました。この日は夕方まで部屋でダラダラ過ごしてました。

夕方、焚火をするため部屋を出ます。

晩御飯はインスタントのラーメンを薪で茹でて食べました。

youtu.be

そのあとはマシュマロ。

食料が無くなったあとは、燃える火をボンヤリ眺めていました。

その後、近くの温泉へ。

www.takaosan-onsen.jp

ぬるめの温泉や熱めの温泉が合わせて5つほどあり(いづれも露天)、色々と楽しめました。

部屋に戻り、次の日の支度をします。 高尾山山頂で日の出を見る予定があります。

23:00 に寝て 4:00 に起きました。睡眠が足りてない状態でしたが、何とかベッドから這い出て高尾山山頂に向かいます。

山頂までのルートはいくつかありますが今回は1号路で上りました。

道が整備されているので初心者向けと言われていますが、道がコンクリートで固められているためか、6号路(比較的整備されていない山道)を上った時よりも脚の負担が大きくしんどい気がしました。

また、暗い高尾山はかなり怖く、精神的に来るものがありました。

youtu.be

そんなこんなで、思ったよりもハードな登山となり、連れに対して申し訳ない気持ちになりました。

無事、山頂に到着。

道中、ランニングしている人を3人ほど見かけました。強者過ぎます。かっこいい。

先着の方が1組おられましたが、あとは我々だけでした。

弁当を食べながら日の出を待ちます。

待つこと30分ほど。周りには人が増え、とうとう太陽が顔を出します。

めっちゃまぶしい。でもギリギリ見えるくらいの明るさのため直視してしまうのですが、絶対目に良くないと思いました。

無事目的を果たすことができ、天気も良かったため、かなり気持ちがよかったです。

他の方角に目をやると、富士山も見えます。

都心から1時間以内で行ける山でこれだけの大自然を満喫出来るなんて感動です。

下山は思ったよりもきつく、身体が前に倒れないように姿勢を立てながら降りるのが一苦労でした。

道中、大きなリュックを背負った薄手のおじさんと雑談を交わし、元気と勇気を貰い、無事下山。

昨日行った温泉にまた行き、汗を流しました。

タカオネはホスピタリティに溢れており、とても居心地が良かったです(どうやってあのカルチャーを生み出しているのだろう)。

「活動ホテル」というコンセプトの通り、活動するためのキッカケがたくさんあります。

部屋での椅子・テーブル配置に始まり、カードゲームや研修室など。外に出れば高尾山もありますし、温泉もあります。

職場の人や仲の良い人を巻き込んで、イベントなどできると面白そうだと思いました。

一点気になったのが、2人部屋の入口なのですが、靴を置くスペースがほぼ扉の導線になっており、靴を脱ぐことと扉を締めることが同時に行えないのはちょっと大変でした。

あとは大満足です。

また遊びに行きます。

費用メモ

タカオネ

  • 大人2名 1泊2日 1泊2日 朝食付きプラン 部屋スタンダード 27,000円(税込み)

京王高尾山温泉

  • 大人1名 バスタオルレンタル + 手ぬぐい 1,750円(税込み)

WACATE 2022 冬 参加レポート (2/2)

前回の記事の続きです。2日目のレポートです。

 

当日のスケジュール
 WACATE2022 冬プログラム - WACATE

 

モーニングセッション(テストエンジニアのギアナ高地「システムアーキテクチャって何?」をつまむ) <30分>

 

セッション3(仕事に感情を持ち込んじゃおう!~弱さに寄りそえるQAエンジニアになるためのヒント)<90分>

  • 感想
    • 仕事は誰もが感情ではなく事業の目標や事実を重視して意思決定やコミュニケーションが行えることが理想という気持ちがあったので、感情を持ち込んで働くことを推奨するようなテーマに少し懐疑的なところはあった。しかしこのセクションで伝えられた最終的なメッセージは、感情をアクションに変える力を付けようというもので、これはすごく重要な力だと思った。上記で書いたような理想を自分は持ちつつも、やはり感情は無くしきれないので、感情が起こった時、それをどう建設的に処理できるか、改めて考えたいと思った。セクション中、内省する時間があったが、日ごろから内省している自分はそんなに新しい発見はないだろうと思ったが、新しい発見があった。内省を行う環境が変わると気づく内容も変化するのかもしれない。
  • memo
    • UEQ
    • EQPC

 

セッション4(品質とは何か?)<90分>

  • 感想
    • 場所移動に間に合わず、前半のお話をしっかり聞くことができず残念だった...。品質特性の使い方のお話が聞けて良かった。開発チームや PO と品質についての話をするとき、品質が指すものが多く、どうしても空中戦というか、とりとめのない話になりがちな印象なので、品質特性を地図のように扱い、議論できると良いかもと思った。品質の定義が時代によって変わっていくのは何でだろうと思った。ふと、ソフトウェア開発はビジネスだから。という理由を思いついた。品質の定義が変わるというのは、世の中のニーズが変わったことを意味しているのではないか。品質とニーズが切り離せないのは少し違和感がある。品質と聞くと、安心安全(ユーザのためにこちらが用意するもの)、みたいなものを連想する。だからニーズ(ユーザが求めているもの)と紐づいていることに違和感があるのか。ユーザのためにこちらが用意するもの、ユーザが求めているもの、どちらも品質の中で用意しようと思えば、品質エンジニアの業務はあまりに広い気がするが、そういうものなのだろうか。もしそうであれば、品質エンジニアはどのようなステップアップが存在するのだろう。QCD の話を聞いて思ったが、品質はかけたリソースに対して向上するという前提はあっているのか?
  • memo
    • 品質特性は地図みたいなもの。特性を識別できるようになることが重要。品質特性すべてを満たすのは目的ではない。
    • QCD
    • チームメンバーから聞いたお話「品質を良くせよ、と指令が出てまず行ったのはリグレッションテストの充実。デグレが頻出していたため」
    • 品質管理といった時、品質管理、品質マネージメント、どちらを指しているか、人によって異なる
    • 品質活動の歴史
      • 不良品を世の中に出さない
      • 不良品を作らない
      • 不良品を設計しない(イマココ)
    • プロセス品質
      • プロセスを尊守して安定した能力を発揮しているか
    • プロダクト品質
      • 成果物の要求事項・決められた基準を満たしているか
    • テストレベルに適したテストの実施が必要
    • 品質が十分である時、どうやって品質に着目するか→今よりコストをかけずに品質を十分にするにはどうするか考える

 

招待講演(スピードがなければ、生きていけない。品質が低ければ、生きていく資格がない。)<90分>

  • 感想
    • 以前聴講した"水銀中毒はAI羊の夢を見るか"に続いて、エキサイティングな例えが用いられた素敵な講演だった。エキサイティングなだけでなく、重厚な歴史とそれに紐づいた品質についての話が、分断なく上下左右に展開されて、色々な知識が自分の中で繋がっていき、面白い体験だった。これだけ品質について語ることができて、ようやく品質についての改善案を持ち出せるんじゃなかろうか、という感覚があった。今の自分は、現場で品質改善の案を提案し、全員に取り組んでもらうには、まだまだ品質についての理解が足らないように思えた。もっと勉強しないといけない。僕の勉強不足もあるが、品質というテーマがそもそもかなり深いもののように思える。
  • memo
    • 品質と民族は関係ない
    • 統計と品質管理は切っても切り離せない
    • 経営工学
    • 小難しい数学を使って企業で良いことをするのは QC だけじゃない
      • オペレーションリサーチ
      • 生産工学
      • トヨタ式生産
      • 信頼性工学
      • ...など、すべて統計を使う
    • 何をやろうとも、理想の現場をイメージできていなければうまくいかない
    • 品質管理はこれをやれば十分というものはない。だから「賞」はあるが、認証制度はない
    • SQC→(魔改造)→TQC
    • 品質の「品」は品物ではなくて品格を意味している(加納さんいわく)
    • 日本的品質管理は「品質とは」という深遠な問いに答えるために様々な進化をしてきた
      • 源流管理
      • 信頼性工学との融合
      • 設計品質・企画品質(品質は一品ものだから統計使えない)
      • 規格の適合度・顧客の要求に対する合致度・顧客満足度
      • ...
    • 価値が変わると品質保証手段も変わる
    • 「品質」は技術そのもの
    • 層別は層を分かりやすくして分析すること
    • 品質で重要なのは、物事を正確にとらえること
    • ロジックキューブを大きくして、原理原則を見つける
      • POや開発者がわからない点に気づける
    • コントロール
      • 予め決めた基準に合致させること
    • マネジメント
      • 目的を達成するためにあらゆることを上手に行うこと
    • MBOやOKRは上下が円滑に行き来できて納得感ができるのが大事
      • 落とし込みの上手さは重要ではない
    • カイゼンは変化する筋肉をつける
    • カイゼンサイクル(PDCA)は回すことが重要
    • AIはQAの技術が追い付いていない
      • 納得感を作るのが大事
    • (質疑応答)具体化抽象化がうまくなるには
      • 具体化抽象化能力の高い人のインプットとそこからのアウトプットを知り、自分との処理の差を知ってみる
      • 「なぜ」をたくさん考えると伸びる
    • (質疑応答)レベルの高い品質エンジニアがほかの企業より多いと感じる企業はあるか。また多い理由はどこになるのか
      • (製造業であれば)他の企業より多いと感じる企業はある
      • なぜなぜ分析が得意
        • なぜ得意なのかと言えば入社してから何度もする機会があるから
      • ねばちっこい。スマートな愚直。
      • ダメな企業はやれといったことがやれない
    • 現代品質管理総論(大事なことが全部書いてある本)

 

思ったことを感想に、講義内容で気になった箇所は memo に書いていきました。思い出し用のレポートとしては十分機能しそうです。より、詳細に内容を思い出したい時は、共有していただいた資料を見返したいと思います。楽しい2日間でした。運営の皆様、仲良くしてくださった皆様、ありがとうございました。

WACATE 2022 冬 参加レポート (1/2)

1年前に存在を知り、ずっと気になっていた WACATE にようやく参加してきました。
このブログは、研修中にやったことや学んだことを、自分が思い出せるようにするためのレポートになります。1日目と2日目でレポートを分けます。これは1日目のレポートです。

 

当日のスケジュール
WACATE2022 冬プログラム - WACATE

 

セクション:オープニング <20分>

  • 感想
    • WACATE のコンセプトを丁寧に教えていただいた。コンセプトが明確になった状態で活動に参加できたので、集中して課題に取り組むことができた気がする。人を巻き込んで何かするときは、自分もこれくらい丁寧に説明しないとダメだよなぁと感じながらお話を聞いていた。
  • memo
    • 若手が積極的に活躍できる場がないという課題感から WACATE は始まった
    • 毎年、夏と冬に開催され、夏は一つのテーマを掘り下げるスタイル。冬は広いテーマを扱うスタイル

 

セクション:ポジションペーパーセッション<70分>

  • 感想
    • 背景や現状、目指したいことが文章化されたポジションペーパーは、コミュニケーションをする上ですごく便利だった。自分以外にもこんなことを考えている人がいるんだとか、そんな課題もあるのかなど知ることができて面白かった。誰かの自己紹介で"旗振り役"というワードが出てきたが、リーダーという表現よりも良いなと思い、今後自己紹介の時に使おうかなと思った。自分は2回目の自己紹介に躓きやすいという"パターン"を見つけ今後気を付けようと思った。
  • memo
    • テストをしない QA の方が数名おられた。テストは開発者が行い、QA はテストが行われているか、良いテストができているのか(観点の評価)、といったところに関与するスタイルらしい。どんな感じの業務になるのかもっと知りたい。
    • 感情の扱いに関心を持っておられる参加者をよく見かけた

セクション:BPPセッション<30分>

  • 感想
    • WACATE で学んだことをちゃんと実際の現場で活かすよう動かれていて素晴らしいと思った。どのように活かそうとしてどのように活きたのかをレポートにされていて、ちゃんとされているなと思った。見習う。

 

セクション:セッション1 (テストプロセスを用いて、テストケース作成の思考を整理しよう)<90分>

  • 感想
    • テストケースをリバースして評価する手法を知ることができてよかった。各テストフェーズで何をしないといけないかも改めて学ぶことができて良かった。悪い例(?)として提示されたテストケースの問題点として、テストする観点が暗黙的かつ、観点に対して適したテスト技法を適用できていなかった(境界値やパターンの洗い出しができていなかった)がありそうだと思った。テストケースの整理も大事だが、機能の整理も大事かもと思った。
  •  memo
    • 例えば 8*7-32/4 の計算をした時など、人によってプロセス(過程・工程)が異なる。
    • プロセスが細かいとレビューがしやすい。
    • デシジョンテーブルは仕様漏れに気づきやすい。テストケースはどんなテストをすればいいか分かりやすい。
    • 各テストフェーズでやること
      • テスト分析
        • 「何をテストするか」を考える
        • 箇条書きやマインドマップなどを活用する
        • 分析結果(テスト対象)に適用するアプローチ(テスト手法)を考える
      • テスト設計
      • テスト実装
        • テストの実行に必要なすべてを準備する
        • テスト自動化などもこのタイミングで行う
    • 「どれだけテストするか」はテスト計画で考える
    • テストの粒度を考える時はテストレベルを参考にする。テストレベルに対応した機能は現場によって異なる

 

セクション:セッション2(状態遷移テスト) <90分>

  • 感想
    • 状態遷移図や状態遷移表の書き方をシンプルに教えていただき、わかりやすかった。実際に作るワークも良かった。例えば A という状態と、B という状態と、A と B の状態が重なっている C という状態がある時、状態遷移図をどのように書くと良いか分からなかった。とりあえず、状態遷移図を分けて書いたが、正しいアプローチだったかは不明。nスイッチカバレッジというワードを知ることができてよかった。
  • memo
    • 状態遷移テストはシステムが複数の状態を持ち、イベント発生時の状態によって遷移先が異なる場合に有効
    • どのような状態があるのか、どのようなトリガーで遷移するのかを見ることができる
    • 考慮が漏れているパターンなどを洗い出すことができる
    • 状態遷移テストのやり方
      • ①仕様から状態とイベントを抜き出す
      • ②図(状態遷移図)を書いてみる
        • システム全体を俯瞰するのに有効
        • できるだけシンプルにまとめるとよい(複雑な場合は粒度を上げてみる)
      • ③マトリクス図(状態遷移表)を作る
        • 動作を網羅的に確認するのに有効
        • イベントが発生しても何も起きない場合と、そもそもイベントが発生しない場合とでは、結果は似ているが異なる状態なので、区別してテストした方がいい
    • nスイッチカバレッジは、画面遷移のカバレッジを測る指標
    • テストは0スイッチカバレッジが基本
    •  nスイッチカバレッジのカウント方法
      • 画面遷移後、画面遷移が発生したら1スイッチ

 

セクション:夜の分科会 <120分>

  • 感想
    • ディスカッションのフォーマットが無かったので、どう話をしたらいいかなとドキドキしたが、誰かに話してみたいことは大体話せたので満足。話したことに対して、別の現場で品質に関する取り組みをしている人からリアクションやアドバイスをいただけて良かった。ありがとうございます。
  • memo
    • エンジニアが自分でテストすると偏りが出る
    • JSTQBシラバスには結構良いこと書いてある
    • バグをたくさん見つけるのではなくシステムの品質を向上させることを目的にテストする(開発者に嫌がられないバグ報告のノウハウ。「消防ホース」の話)
    • ASTER標準テキスト に書いてあることも良い
    • シフトレフトの施策でテストをしない QA というのもある
      • テストの代わりにすること 
        • 仕様のレビュー
        • 不具合発生原因の分析
        • など
    • テストの漏れや内容が心配な場合は、開発者とお互いに取り組んでいるテストの情報交換するとよい
    • プログラマーは QA にコードを書くことは求めていないかも
      • 求めていること
        • 価値提供に必要な品質を知っている
        • 事業に支障が出るような問題を知っている
        • プログラマーの)認知の外のことに気づいてもらう動き
        • プロダクトをどう良くするといいか知っている
        • プロダクトの仕様を詳しく知っている
        • ドメイン知識
        • プロダクトの運用フロー
        • など

 

1日目のレポートは以上です。