人間のあるべき姿の探索

思索・人形・エンジニアリング

人形を作る為のプロジェクト管理

人形になるぞ!

godiva-frappuccino.hatenablog.com

 ということで製作をしているのですが、趣向を少し変えてプロダクトではなくプロジェクト管理の話をします。本業でソフトウェア開発をしているので予算とか納期とか色々気になるのですが、人形になる為の試みは予定管理が非常に難しいです。一般的な人形制作においても、一度胴体を作って満足しても寝て起きてみたらひどくバランスの崩れた体に見えてしまうこともあります。特に凝り性の方はずっと作業に没頭してしまうこともありますが、ここでタイムボックスで切って作業を完了としてしまうと、納得のいかないクオリティで打ち切ることになります。完成を目指す為には打ち切る必要はありますが、展示の締め切りの様な納期を別にして、時間で区切ってはいけないと感じました。区切るなら時間ではなく期間で、追い込まれたらひたすら時間を費やすバッファがあると良いですね。そのバッファは消えます。

 そして、新しく何かを作るにあたっては、その時間の不確実性が増します。今回は機構を3Dで印刷する、等身大サイズのトルソーを作る、粘土用の型を3Dプリントするといった不確定要素がいくつもありました。そういった作業はPoC(Proof of Concept、概念実証)のフェーズが必要になります。これはプロダクトの価値とは別にそもそも実現可能か?どの程度のクオリティで実現できるか?という問いから始まりますし、その結果によって最終的なアウトプットのイメージにも影響するため、かなりプロジェクト管理が大変になります。そこで、二つの軸、WBSを諦める、完成イメージのパターンを場合分けするという方針を採用しました。

WBSを諦める

 まず、WBSを諦めることについて、WBS(Work Breakdown Stracture)とはプロダクトの作成を計画するにあたって作業を管理する為に細かく分割したもので、例えばタスクAはn月m日~o日、タスクBはn月o日~p日で先行タスクがタスクA、みたいな線表を引いていくことで管理します。これによって、いつまでにどの作業ができているかといったことが明確になります。しかし、今回の人形制作はほとんどがPoCと呼べるものでした。特に美術系でアウトプットの形が最後まで工夫できるものは、一つの作業が終わった後にもう一度他の作業を思い返してみて、やり直す…といったことがしばしば発生します。つまり、順番に進むのではなく、幅優先探索ですべてのクオリティをだんだんと上げていく作業になります。

 ということで、タスク一覧のみを洗い出して順番に作業していきます。簡単な優先度をつけるために、ステータス管理をToDo,In Progress, Done, PendingのほかにASAP(As soon as Possible)をつけたステータスを作り、直近での作業を決めました。これはタグでも良いです。しかし、これらは複雑に絡み合っています。眼球のモデリングと頭部のモデリングは干渉しかねないので同時に、そして頭部のモデリングをしているうちにモデリングの共通点で機構の形へのアイデアに寄与することもあります。設計項目はよく木構造で表されますが、実際にはそれなりに密なグラフ構造になっているわけです。このグラフ構造を意識する為に、見た目上は緩い管理をしつつその関連を常に頭の中に浮かべるようにしました。そして、作業については脳内の一次キャッシュとして本当にシンプルなToDo表に落とし込まれました。タスク一覧の管理とToDo管理は別になります。

完成イメージのパターンを場合分けする

 PoCの中で、できるか分からないものはたくさんあります。例えば、今回は首を動かす予定で人間の様に振り向き、頷き、傾げる三方向に動かせることを目標としたのですが、実際にはそれを安定して実現する仕組みが作れず、半年程検討したところで一度首を傾げる方向を削った形で終了することにしました。最終的には納得いかずにもう数か月検討して三方向に動くようになったのですが、ここで必要なのが、まず、最終的なイメージがそれでよいか?を考えることです。どうしても実現しないといけないコンセプトの中心であれば妥協はできません。そもそも首が動かないとなれば動く人形ではなく操作による没入感が極端に低減してしまいますが、傾げる方向は最悪無くても視線は動かせるため、没入感が得られるかもしれません。そこの不確実性は早めに解消する必要がありますが、最終的なアウトプットとして問題がなければ諦めることも可能です。そして、パターンを想定する必要があります。今回だと二方向にしか動かないか、三方向に動くかのパターンがあります。それら全てを検討しつくして、どのパターンであれば納得できるか考えます。

 そして、オプションとしてステップを分けて第二ステップとして三方向に首を動かす実装にアップデートするプロジェクト方針にすることが可能です。ここで必要なのが、後から拡張可能であることです。二方向に動かす機構がピッタリはまるような仕組みを作ったところで、後から三方向に動かす機構ができてもそれが大きすぎて人形の骨格に入らないようであれば意味がありません。実現できた際に差し替え可能か?ということだけでも考えておく必要があります。そこで、可変になりうる部分は差し替え可能にしておく、ということが必要になります。他の例だと、眼球にWebカメラを仕込むかどうか検討中で、一旦シンプルな半球で眼球を作るだけに留めようと思うのですが、眼窩のパーツをシンプルな眼球用に作りこんでしまうと、Webカメラを仕込んで大きくなった眼球を眼窩に納めることができません。そこで、眼窩から差し替えができるように、眼窩パーツをはめ込むための金属部品だけを人形の方には設置しておいて、後から眼窩を設計できるようにしていました。

 これはかなりプログラミングにおけるインターフェースの考えに影響をうけており、業務でパソコンをカタカタしていてよかったと感じたことの一つでした。この辺りの考え方は実装的な意味合いで以前まとめたのですが、これがプロジェクト管理のしやすさにもつながるわけです。

godiva-frappuccino.hatenablog.com

終わりに

 といった感じで、不確実性の高いプロジェクトの管理の話でした。一般的なシステム開発だと実際はある程度線を引いて顧客へのスケジュール説明をして…といった感じになると思いますが、アートの面白いところは締め切りのギリギリに思いついたアイデアが根本からコンセプトを覆しうる、最終的なアウトプットを変えうるインパクトを持つため、それを大切にする必要がある点だと思います。そうなるとプロジェクト管理手法が厳しく押さえつけるのは難しいのですが、緩くガイドラインを引いてやるのがちょうどよい塩梅なのかもしれません。