少し前にコミュニティに関連して翻訳レビューに参加させてもらったClean Architectureという書籍が７月末に出版されたようです。
このClean Architectureという本は、アジャイルソフトウェア開発で著名なRobert C. Martinさんが書かれた本です。
訳者である角さんがあとがきでも記述しているのと同じように、少々クセがあったり、すっきりしない部分もあると思っています。
しかし、提唱されているClean Architectureのみならず、そこに至る考え方、例えばアーキテクチャは何のためにあるか、のような筆者の考え方、なぜそう考えるのか、という説明は、多くの学びを得ることができる本だと思っています。
電子書籍も出ています（達人出版会）
tatsu-zine.com
Vimで`*`や`?`を使って検索してハイライトするのだけれど、検索先へジャンプしてしまう。
また、複数の文字列をハイライトできない。
そんな時に有効なコマンド。
:match Search /{string}/
SHIROBAKOは言わずもがな、アニメーションを作ることをテーマとしたアニメーションだ。そこから、自分のお仕事や夢などに重ね合わせて語られることも多い。しかしながら、ここはやはりSHIROBAKOの内容に沿い、私がアニメーションを作ることについて感じていたことを書いてみようと思う。
時々、疑問に思うことがある。アニメーションは、どういう産業なのだろうか、と。モノを作るから工業なのだろうか。
作る人の構成から見てみると、アニメーションを作る現場を描いたSHIROBAKO、登場人物に字幕をあてるほどに関係者が多い。
それは、エンディングに流れるスタッフロールを見ても明らかだ。広報や総務のような間接的にかかわる人を抜いても、テレビ作品１つに対してだって10人や20人ではない。 ２人集まればチーム、なんて話を聞いたことがあるが、これだけの人数がいると間違いなくチームとなる。だからこそそれをまとめる制作が必要となる。
そして、作業を見てみると、それぞれのセクションで分業化が進む。
第９話「何を伝えたかったんだと思う」では、監督のスランプと並行して、美沙の３Ｄ業務が語られる。クルマの部品の３Ｄをひたすら作るのだ。特に、美沙は日々タイヤと格闘している。
そして、同僚に問う。「明日も明後日も、１年後も２年後も車ですよね」
同じようなものを日々作っている、と言いたかったのかもしれない。
ここまで見ると、確かに工業に近い要素を持つ気がする。しかし、それは機械のような工業と違う側面を持つ。例えば、芸能に近い側面を強く持つと感じる。
例えば、原画。絵コンテという上位の指示はあるものの、キャラクターを動かすのは原画マンだ。 それは俳優が脚本や監督の指示に従って、アクションするのと非常によく似ていると思うのだ。
アニメーターがキャラクターの動作を考え、キャラクターを絵の上で演じさせる。自分自身の体を動かすか絵の上の体を動かすかという御する対象の違いはあれど本当によく似ている。
第７話「ネコでリテイク」では、アニメーターの絵麻がネコを描くのに苦悩する。
これを、俳優基準で考えると、自分がネコになり、ネコの動作をするということに近い。アニメーターは時として人間以外も演じるのだ。
表題とは全く関係ないことだが、絵麻かわいいよ、絵麻。
この工業的な側面と芸能的な側面がアニメーションを作り続けることの難しさにつながっているように感じる。
例えば、近年、アニメーションは業務時間や収入面で良くない話題が多い。SHIROBAKOの中でも深夜に及ぶ作業が幾度となく描かれている。収入面も問題が赤裸々に描かれていないものの、一流のアニメーターといってよい瀬川さんでさえ小さいアパート住まいである。
これが頭脳労働者、ホワイトカラー、ビジネスマンのような視点で見ると、業務時間がおかしい、収入が釣り合わない、となるのだろう。しかし例えば、芸人、役者の視点で見てみるとどうなのだろう、とも思うのだ。売れていない芸人が前座をたくさん努めたから、その時間単位の給料をもらってはいないし、それに対して批判する人は少ない気がする。
実は、私はソフトウェア開発を生業としているが、近い場所にアニメーション制作がある。最近少し遠くなったが、制作の現場は変わっていっているのだと感じる。アニメーション関係なく、組織はそう簡単には変わらないのが常であるが、アニメーション制作は変わっていっているように感じるのだ。時折、アニメーションを作ることはソフトウェア開発と似ているように感じることがある。妻とその類似性について話したことがあるが、またどこかで話すことができたらと思う。
SHIROBAKOにエンタメとして描かれたことは、今後どう変わっていくのだろうか。今後アニメーションはどう作られていくのだろうか。
エンタメに昇華させた方々に拍手を送りながら、未来を期待してSHIROBAKOを今夜は見ている。
ICONIXプロセスはユースケースから駆動する開発手法で以下の本が詳しい。
www.shoeisha.co.jp
この開発手法で、ユースケース（分析）と設計の狭間にロバストネス図を使ったプロセスが存在する。
これをUMLツール（astah*）でやってみた。
分析の過程でシステムを意識しすぎると、設計の幅を狭めてしまう。
そのために、システムを意識せずに分析したとする。
ここで、アーキテクチャ設計をしようとすると分析と設計の間に溝ができてしまう。
分析とアーキテクチャ設計の間にもう１つ設計（名称はロバストネス「分析」だが）を挟む。
ロバストネス図専用のダイアグラムはないので、コミュニケーション図で書く。
書籍と少し異なるが、目的は達成できる。また、見た目もあまり変わらない。
さらに、UIやActorをパッケージでまとめるとこんな感じで構造ができる。
UIとそこで実行可能な機能になっている。このまま機能仕様書の章立てになりそう。
UIテスト*1のライブラリを触ってみた。
GitHub - Codeer-Software/Friendly.Windows
業務でUIテストを手動でやっていて、少し辛い。"Be Lazy."の言葉に従って自動化のF/Wやライブラリを触ってみている。
Google検索で見つけてひょっとしたら良いカモ、と思ったので。
NuGetでダウンロードして、テストコードを書く。
[TestMethod] public void TestMethod1() { var app = new WindowsAppFriend(Process.Start("UITestSample.exe")); var process = Process.GetProcessById(app.ProcessId); dynamic form = app.Type<Control>().FromHandle(process.MainWindowHandle); form.SetTextBoxText("HELLO"); string text = form.GetTextBoxText(); Assert.AreEqual("HELLO", text); process.CloseMainWindow(); app.Dispose(); }
UIにメッセージ送って動作させる物ではないのでUIテストっぽくない。
プロセスに対して操作するので、結合テスト用には使えるかも。
