『葬送のフリーレン』は、あのITエンジニア本大賞に似ている || プログラマーとしての姿勢と心構えについて
10年以上職業プログラマーをしている。
人並に技術書も読んできた。あくまでも仕事のためであり、その読書は技術を身に着けるためのものだった。
そんななか、これまでにはない読書体験の技術書を読んだ。
プログラマーとしての姿勢と心構えを改めて考えさせられる、骨身に染みる読書だった。
その技術書は『葬送のフリーレン』だ。
※『葬送のフリーレン』のネタバレを含みます。
『葬送のフリーレン』は技術書である
『葬送のフリーレン』は、週刊少年サンデーにて連載中の魔王討伐後の世界を旅するエルフのファンタジーマンガである。2021年にITエンジニア本大賞・・・ではなく、マンガ大賞を受賞している。
一般的には魔法使いのフリーレンが人間を知ろうとする物語である。
しかし、本作をただの面白いファンタジーマンガとして楽しむのはもったいない。いや、それはプログラマーにとって大きな損失であると言ってよい。
読み味としては『プロダクトマネジメントのすべて』に似ている。
『プロダクトマネジメントのすべて』はその名の通り、プロダクトマネジメントに関する知識・スキル・方法論・マインドセットを網羅している。
この本は網羅性にて多くの支持を受けていると感じるが、実はかなりの部分をマインドセットにページを割いている。
まえがきの抜粋。
フリーレンも同じである。
勇者一行の魔法使いというプロフェッショナルで、魔法のスキルについては超一流である。そして、「人間を知る」という強い意志でまた旅に出るのがこの物語だ。
『葬送のフリーレン』は、システム開発やプロジェクト運営、そしてプロダクトマネジメントにおける重要な教訓を内包しており、エンジニアにとってはただの物語以上の価値を持っている。
まさしく技術書である。
ここからは『葬送のフリーレン』が技術書として描かれたとされる論拠を3つ挙げていく。そして作者である山田鐘人先生の主張はどこにあったのかを探っていくこととする。
論拠1:現代のプログラマーは魔法使いである
プログラミングは、しばしば「魔法」にたとえられる。
単純ではあるが、重要なアナロジーである。
登場するキャラクターたちの魔法も、エンジニアの日常的な問題解決の姿勢に通じる部分が多い。
たとえば第3話、勇者ヒンメルの銅像の錆取りの仕事を受ける場面。フリーレンは顧客であるおばあさんの要望をヒアリングする。そして、問題の根本を突く。
銅像が放置され錆びついてしまうのは、銅像を建てることを断らなかったヒンメルが悪い
顧客がいる前で発言してしまうのはサイコパス味があり、プログラマー的である。「バグの温床であり自己満足でしかない無駄なアニメーションを盛り込む仕様が悪い」とのたまうプログラマーと同じだ。
とはいえ結局錆取りもするし、追加注文となった彩りのための花畑も手伝う。サラリーマンプログラマーそのものである。
この錆取りの話を「顧客の満足が私の満足だ」という単純な話でとらえてしまうと、ただのお仕事マンガである。
サラリーマンプログラマーは、なぜ疑問に思いながら銅像の錆取りと彩りを加える花畑をデプロイするのか。
それはプログラマーになることを諦めなかったからだ。
いや、一人で生きていける力さえ手に入れればなんでもよかったかもしれない。
別にプログラムじゃなくたって…
でもプログラムを選んだ。
論拠2:プロジェクトとプロダクトの違いを描写している
プロジェクトとプロダクトの大きな違いは、時間軸である。
プロジェクト定義は明確に定義された目標があり、開始時点と終了時点があることだ。
魔王討伐の旅は、まさにプロジェクトである。
魔王を討伐するというのは明確な目標であるし、討伐の旅の開始時点と終了時点も本作で明確に描かれている。
そして、対比として描かれるのが魔王討伐後の世界。
討伐後は「人間を知ろうとする」という、とてもじゃないが明確とはいえない目標である。終了時点も全くもって不明確だ。
そう、魔王討伐の前と後の違いを描いたのが『葬送のフリーレン』なのだ。
魔王討伐前の旅: プロジェクト的
魔王討伐後の旅: プロダクト的
その時間軸の違いを象徴するのが勇者ヒンメルのセリフである。
「帰ったら仕事を探さないとな…」「フリーレン、君のこの先の人生は僕たちに想像もできないほど、長いものになるんだろうね」。
これを第一話冒頭に描いたのだ。
週刊連載のマンガで最も大事である、第一話書き出しがプロジェクトとプロダクトの違いなのだ。描きたかったのは、まさにプロジェクトとプロダクトの本質的な違いそのものである、これは断言してもいい。
そう考えるとヒンメルのプロジェクトマネージャーとしての優秀さが見えてくる。
ドラクエ的世界観では、魔物との戦闘こそが冒険のハイライトだ。
思い出すのはロンダルキア洞窟後のブリザードにザラキで惨殺されたことや、イシスの砂漠でスクルトを連発するカニを倒すのに30分かかったこと、そしてエスタークを10ターン以内で倒そうと試行錯誤するシーンである。
しかし、本作ではヒンメルが戦闘するシーンは全くもって描かれない。フリーレンが回想するのはくだらないやり取りのみである。
そこで描かれるヒンメルは、先頭に立って魔物の討伐をする姿ではない。メンバーの背中を押したり鼓舞するマネージャーの姿だ。そう、ヒンメルはサーバント型の優秀なプロジェクトマネージャーなのだ。
対してフリーレンはプロダクトマネージャーである。いや、プロダクトマネージャーになろうとする物語である。
『葬送のフリーレン』はプロジェクト的なものを対比とし、プロダクト的な物語を描く、という現代のプログラム開発の潮流の構造に沿ったマンガなのである。
論拠3:システム開発終了後も不具合は出る、魔物の残党がいるように
物語の舞台となる魔王討伐後の世界は、大規模システムのリリース後の運用・保守フェーズに類似している。
魔王討伐はプロジェクトである、と前項で述べた。在庫管理業務を効率化しようとした場合のシステム開発に相当するプロジェクトである。
しかし、在庫管理業務の効率化はシステム開発をすれば終わりではない。むしろシステム導入後が効率化の始まりであり、圧倒的に長い時間をかける取り組みとなるはずだ。
魔王を倒した後に残る魔族たちは、まさにシステム運用後に発生する不具合やバグに重なる部分だ。一見平和そうに見える世界であっても、凶悪なモンスターは存在している。大規模システムにバグが付きものであるように。
第5話、腐敗の賢老クヴァールとの戦闘で思い出すのは、2000年問題だ。
当時の技術ではクヴァールを倒すことができなかった。そのため封印する、という言ってしまえば問題を先送りにする手段をとる。
2000年問題も明らかにプログラムに不備があることは分かっていたはずだ。しかしシステム開発当時の技術では、数十年先の問題を想像し対処することは割に合わずに問題を先送りにした。不具合を封印したのだ。
クヴァールは封印後80年経って封印が解かれた。そしてクヴァールを討伐するという根本解決にいたる。
マンガではサラッとしているが、クヴァール討伐には魔法研究のたゆまぬ努力と発展が描かれている。それが大きな問題であるばあるほど、必死に対処を検討し解決を図るのだ。
2000年問題に直面したプログラマーたちと同様に。
本作に登場する魔族は腐敗の賢老クヴァールだけではない。首切り役人リュグナーや断頭台のアウラなど、数は多くないが人類の敵として魔族が登場する。
その対処について高度なスキルと多大な努力があるはずだ。映画『ロッキー』のテーマが流れるほど劇的であるはずだ。『プロフェッショナル 仕事の流儀』のようなエモさがあるはずだ。
だがフリーレンたちは淡々と、まるでドラマ性がまったく存在しないかのように処理していく。
プログラマーにとっての不具合対処と同じように。
あまりにドラクエ的な世界観に慣れてしまい忘れがちであるが、魔王討伐後の世界のほうが圧倒的に長い。ゾーマやデスピサロ・ミルドラースを倒しても、世界はずっと続くのである。
『葬送のフリーレン』はシステム開発後も世界はずっと続くことを思い出させてくれるマンガ技術書である。作って終わりではない。その後にも物語が存在することを、このように表現した技術書は他にあっただろうか。
ITエンジニアが持つべき距離感と心構え
ここまで読めば、『葬送のフリーレン』が技術書であることを疑う余地はもうないだろう。プログラマー向けの書であるし、システム開発後の世界を描き、プロジェクトとプロダクトの違いを明確に示していることが分かった。
では、作者が本当に描きたかったことは何だろうか。
それは「プログラムとプログラマーの距離感」と「プロダクトマネージャーとしての心構え」である。
プログラムとの適切な距離感
プログラマーにとってプログラムは、単なるコード以上のものだ。問題を解決し、世界をより良くするための力――まさに魔法のような道具である。
フリーレンの魔法に対する情熱を、弟子であるフェルンはこう評する。
フリーレン様の魔法に対する執着は異常です。
このままでは何年でも何十年でも探し続けてしまう。
他者からの評価は、しばしば本人の評価とは異なるものだ。私たち読者から見ても、フリーレンの魔法に対するパッションは非常に強いものに映る。
しかし魔法がどのくらい好きか、フリーレンの自己認識は「ほどほど」である。フェルンと同じで。
何十年も何百年も魔法を収集し魔法と向き合いながら、自分ではほどほどだと思っている。素晴らしいバランス感覚だと思わないか。
しばしばプログラマーはシステムに寄った発言をしがちである。
だが、技術もプログラムも万能ではない。
多くの課題は、システムそのものではすべて解決しない。真の解決は、システムをどう運用するかで決まる。
まず、利用規約を定め、オンボーディングを通じて使い方をしっかりと浸透させる。システムの根底にある思想や目的は、地道な啓蒙活動によって利用者の意識に根付かせる。システムが役に立つのは、それを支える運用と理解があってこそなのだ。
プログラマーとして、ITエンジニアとして、プログラムやテクノロジーに対する適切な距離感。『葬送のフリーレン』はそんなクールで知的な態度を私たちに教えてくれるのだ。
プロダクトマネージャーとしての心構え
『プロダクトマネジメントのすべて』によると、プロダクトマネージャーに必要な領域は3つある。
ビジネス
テクノロジー
UX
である。
プログラマーやソフトウェアエンジニア出身であれば、テクノロジーに明るい方が多いであろう。しかし、プログラムとの適切な距離感があることは前項で述べた通りだ。
では、ほかの領域にも精通するにはどうしたらいいのか。
これも『プロダクトマネジメントのすべて』に記載がある。
広さと深さ、そして強度。
この主張自体は真っ当で、それゆえに目新しさもない。よくある3軸である。「好奇心」の部分を「交友関係」や「味」にしても成り立つ式である。
とはいえ、こうも思う。「どうすれば好奇心を養えるのか」と。
その答えが書いてあるのが『葬送のフリーレン』なのだ。
第6話、中央諸国グランツ海峡にて。この海峡では1年に1回の新年祭にて透き通るような海に反射する美しい日の出が見れる。しかし海岸にはゴミが流れつき荒れてしまっていた。この海岸清掃の仕事を請け負うのがフリーレンと弟子のフェルンだ。
この仕事にフェルンはネガティブな反応を示す。さらに、早起きが苦手なフリーレンが果たして太陽が昇る前に起きれるのか疑問を呈す。
フェルンの「そこまでして日の出が見たいのですか?」に、フリーレンが返すセリフが秀逸である。
正直興味はないよ。だから確かめるんだ。
この場面は私が最も好きなシーン。そして、「どうすれば好奇心を養えるのか」に対する答えでもある。
興味はないが行動する、というのは一見矛盾する行為である。行動するには興味という動機が必要そうに思うからだ。ここだけ抜き出すと、少し斜に構えた答え方をした、という見かたもあるかもしれない。
しかしマンガをしっかり読んでいくと、フリーレンは本当に正直に返答していると感じるはずだ。
どうすれば好奇心を養えるのか、その答えは興味がないことを確かめようとする心構えである。この心構えこそプロダクトマネージャーとしてのスキル向上につながるし、プログラマーにも求められる態度だ。
「人間を知る」というプロダクトのためにフリーレンは好奇心と向き合っている。弟子のフェルンにもそのマインドを伝えようとしている。
そして読者である私にも伝えたい、という作者主張に思えるのだ。プログラマーであり、プロダクトマネージャーを目指す私に向けて。
『葬送のフリーレン』全員読むべし
『葬送のフリーレン』は技術書である。論拠は以下の3つ。
魔法使いはプログラマーのアナロジー
プロジェクトとプロダクトの違いの描写
物語の舞台はシステム開発後の世界
技術書としての主張としては以下のとおりだ。
プログラムとの適切な距離感は「ほどほど」がよい
興味がないことを確かめる心構えが、好奇心を養う態度である
つまり『葬送のフリーレン』はプログラマー全員読むべきであるし、ITエンジニアにとって必読の技術書である。
一つ難点を言っておく。
1シーン1シーンが深すぎてなかなか読み進められないのだ。
執筆時点で13巻まで発売されているが、私は5巻までしか読み進められてない。この記事でも『葬送のフリーレン』の第1巻にしか言及していない。
その点では哲学書っぽさもある。
未読でしたらぜひ読んで欲しいと思う。
マンガITエンジニア哲学本大賞を受賞すべき作品であるから。
では、また!
この記事が気に入ったらサポートをしてみませんか?