TL;DR
- ソフトウェア開発は、アニメ制作と似ている
- なのでアニメ制作現場を劇画したSHIROBAKOはソフトウェア開発の劇画ともいえる
- 観たら、必ず考えよう
知ってた
知ってる方は、多分思ってること同じだと思います。ナカーマ😃
そもそも「SHIROBAKO」とは
アニメの制作現場を描いたアニメです。2期24話です。
いろいろなところから評価されています。
エンジニア界隈でも、仕事について考える素材としてよく取り上げられます。 こんなのも存在するくらいです。
アドベントカレンダーについてはこちら
SHIROBAKOの良さについて、エモい話はアドベントカレンダーに任せるとして、私からはシンプルな理論で、なぜ決まりなのかを書きます。
なぜアニメの制作現場が、ウォーターフォール開発の参考になるか
ウォーターフォール開発とアニメ制作には、大きく２つの類似点があります。
制作工程の類似点
制作者（開発者）の類似点
制作工程の類似点
それは「一連で完成する成果物を、粗い単位から細かい単位までドリルダウンで作る」と言う点です。
ウォーターフォール開発では、次のような工程を経てシステムができあがっていきますね。
- 基本設計（概要設計）
- 外部設計
- 内部設計
- ロジック設計
- コーディング
各工程の詳細は省くとして、それぞれの工程は、全く別の物を作っているわけではなく、それぞれ上流工程の成果物をもとに、より具体的な成果物を作る、ということになります。
これを図にすると、次のような感じです。
では次に、アニメの制作の工程をみてみましょう。
- 脚本
- 絵コンテ
- 原画
- 動画
- 撮影などの具体化（本職じゃないのでアバウトですが・・・）
テレビのアニメを見ていて、脚本がその文字のままテレビ画面に表示されることはないですよね。 同じように、絵コンテもそのまんまの絵がテレビ画面に表示されることはないです。 最終的に撮影などの具体化工程を経た成果物が、テレビ画面に表示されています。
つまり、アニメの制作も、図にすると全く同じようになるわけです。
となると、より良い成果物をつくるための注意点というのは、自然と似通ってきます。
- 次の工程の作業がしやすい成果物をつくること
- 打ち合わせなどによって意図を正しく伝えること
こういったところが、SHIROBAKOでも着目するポイントになってくるというわけです。
制作者（開発者）の類似点
アニメの制作にあたっては、「創造」がひとつ大事な要素だと思います。
「製造」ではありませんので、工場のように「機械を設定すればあとはOK」というものではありません。
自分の手を使って微妙な曲線を引く、目で加減をチェックしながら着色する、一つ一つの作業が存在しないものを「生み出す」ことになるわけです。
デジタル化により道具は便利になっていますが、最終的に成果物にGOを出すのも人間の目です。
では、システム開発者のほうはどうでしょうか。
「プログラム開発は、製造ではなく設計である」とは、色々なところでよく言われます。
私もそう思っています。
いくらロジック設計（プログラム設計）とコーディングの工程を分離して、コーダを雇ったところで、変数の定義名ひとつとっても後々の運用・保守まで影響してくる大事なものです。
コードを打ち込むその瞬間まで、プログラムというものはこの世界に存在していません。その開発者の脳が生み出しているわけです。
コードレビューを経るとはいえ、そのレビューに提示するコードに対してGOを出しているのは、開発者本人です。
そのため、上の工程でいうところの基本設計から、最後のコーディングまで全て「製造」ではなく「創造」であると、説明できるわけです。
だからこそ、システム開発（開発者という側面では、ウォーターフォール以外のプロセスでも同じことがいえます）も、アニメ制作と同様に次のようなことが大事になってきます。
そしてこれらについての意見も、SHIROBAKOの作中で提案されています。
自分たちの現場について、想いを馳せるポイントですね。
アニメの制作と異なる点
上の2点から、「SHIROBAKO」がウォーターフォール開発の参考になる、というのが私の意見です。
ですが、全てが同じかというともちろんそんなわけありません。
アニメの制作と大きく違う、そして、ウォーターフォール（ソフトウェア）開発の一番の問題とも言えるポイントが、１つあります。
システムは芸術作品ではない
ということです。
わかりやすくするために、さらに２つに分割して説明します。
仕上がりによってマイナスが発生するかどうか
あまり違った解釈をされそうな言い方はしたくはないですが、うまく表現できないので、次のような言い方になってしまいますが。。。
アニメは、文芸・美術などと同様で、「芸術」と分類することができると思います。もしその作品がうまく出来上がらなかったとしても、文化的には「マイナス」はないわけです。
対して、システムはいわば「仕事道具」です。もし、仕上がりが悪いと、その仕事がうまくまわらないことによる損失が発生します。その効率の悪い仕事文化が根付くことで、文化的な「マイナス」となるわけです。
もちろん、制作コストに対する売り上げ、という意味では芸術もシステムも同様のビジネス効果は検証されますが、その成果物の行く先に違いがあるわけですね。
成果物に対する意欲があるかどうか
これは上のものよりも、よりみなさんにとっても身近で、より如実に品質に影響するものです。
端的に言いますと、アニメは成果物にワクワクしますが、システムは成果物にワクワクしない人の方が多いです。
一つの芸術作品に向かう制作者の意欲のベクトルと、一つの仕事道具に向かう意欲のベクトルでは、前者の方が勝る場合の方が多いはずです。
システム開発において、自社製品を開発する場合と、請負開発をする場合とでも差が発生するのは言うまでもありません。
意欲のベクトルの違いが、さまざまなIT現場の問題に直結しているわけです。
- 改善の意欲がない管理者
- スキルアップの意欲がない開発者
などなど。。。
まとめ
類似点から、アニメの制作現場を描いたSHIROBAKOが、ウォーターフォール開発の参考になることがわかりました。
実際に、作中で描かれる劇画的なトラブルですが、決して現実離れてしていなくて、実際に私自身システム開発の現場で目撃・体験したものと同様のものもあり、かなり現実の問題を考える参考になります。
対して、アニメの制作との相違点もあります。
それを認識した上で鑑賞すると、現実の仕事の現場をふりかえる、すばらしいきっかけ・材料になります。
正直なところ、新人研修として鑑賞というのは、かなり本気で考えています。
実際、私が個人的にBlu-ray BOXを持っていて、現在、会社の後輩に貸し出しています。
もちろん、この記事に記載している「なぜ参考になるか」というのを説明したうえで、です。
一度離れて俯瞰したり、全く違う世界を知って参考にする／考えるきっかけにする、というのが、イノベーションの基本だと思います。
と、アニメ鑑賞を正当化して、今日の話はおしまいです。
最後まで読んていただいた方、ありがとうございます。
ずかちゃんが一番好きです。
