仕様を超えていけ
ヘッダーの写真は「時のしずく」のお掘りを乗り越えたところ。関係ないけど関係ある写真。
今日書こうとしてることは、前にX（Twitter）に書いた気がするが、今日は改めて書いてみようと思う。大事なことなんでそのうち自分の個人サイトにも書く。
仕様とはなにか
ChatGPT4に聞いてみました。
Q : 一般的に言う「仕様書」とはなんですか？簡潔に説明してください。
「仕様書」とは、製品やサービス、システムなどが満たすべき要件や機能、性能を詳細に記述した文書のことです。開発プロジェクトにおいて、設計者や開発者が目標とする基準を明確にし、クライアントや利用者が期待する内容が具体的に満たされるようにするために用います。仕様書は、製品の品質を保証し、開発プロセスをスムーズに進行させるための重要なツールです。
つまり、上記の言葉からもわかるように「仕様書」というものをなんらかのタイミングで誰かが書き、それをある意味共通言語として様々な立場や職能の人が連携して何かを制作するということになります。とても重要なものですね。
ワークフロー
通常、上記のような「仕様書」が存在するので、工程を管理して納期までに順調に開発や制作がすすむように進めていくことになります。もう少し具体的に言うと、我々の業界の仕事だと、簡潔に書くと以下のような登場人物がいます。
クライアント
仕事を発注してくれた依頼主
プロデューサー
プロデューサーはクライアントの要望を受けて、それを実現可能なプロジェクト計画に落とし込みます。どういう座組で対応するかを検討するような役割も担います。費用の配分も担当するので見積もりとかも担当することになります
ディレクター
ディレクターは仕様書に基づき、クリエイティブな方向性や技術的なアプローチを定めます。彼らはこの仕様書を参考にして、プロジェクトのビジュアルや機能性を指導します。
プロジェクトマネージャー（PM）
PMはプロジェクトの各段階で仕様書通りに完成するように管理します。タスクの配分、スケジュール管理を行い、仕様書通りにプロジェクトが進行するよう調整します。
各職能のプロたち
デザイナ
エンジニア
作品を作る時の話
自分は、もともとメディア・アートのプロジェクトなど数多く関わってきました。そういう制作の場合はどうでしょうか。
※対比がわかりやすい方が良いので、自分が過去にエンジニアとして作品のコラボレーター的に入った場合の構成を書いてみます。
自分はエンジニアだったので、その目線で書きます。
作家（アーティストであり依頼者）
作りたいものを発案した人
クライアントであり、プロデューサーであり、ディレクターである
作家によってはPMもやってくれる
エンジニア（自分）
必要な技術を使って作家のつくりたいものを実現するために様々なことをする
思い返すとテクニカルディレクションをしていた
必要な人をアサインすることもあるのでプロデューサー的な動きもする
割とPM的な役割も担いがち
超シンプルで、2人でやってたりします。なので、役割は二人に分担されていく形になります。そして、「仕様書」はというとそんなものはたいていありません。
え？
仕様はどんどん変わる
自分が作品を作る場合は、仕様書は書かないんですが、それはなんでかと言うと「どんどん変わる」からです。なので、ゴールイメージを描いたメモはあるかもしれませんが、作ろうとしていろいろな実験を重ねるうちに仕様はどんどん変わります。それこそ、時のしずくの制作プロセスをみるとわかると思います。ゴールイメージはあるものの、デザインも機構も考えながら作っていくんです。
siroの制作工程ではどうか
仕様書はクライアントとのコミュニケーションとかで必要なので、書くこともありますが、できるだけ明記したくないと思ってぼかして書いたりします。なぜかと言うと、手を動かしていくうちに最適なゴールは変化してくからです。なので、保証できないので詳細には書きたくないんです。
通常のワークフローでは、ゴールを先に決めて、そこに向かって工程を刻んで、それを順にこなしていくことで管理しようとします。でも、自分に言わせると、仕様書なんて仮の姿でしかないので、それをゴールに設定するのはいいこととは思えません。
作っていくうちに「ここはこうするともっと良くなる」とか「これじゃ全然面白くないものになる」とかわかってきます。その時に柔軟に方針を検討して設計を更新していくことができないといいものが作れないケースが増えていきます。
見たことがあるものをもう一回作るのならそういうリテイクは少ないと思いますが、見たことがないようなもの、作ったことがないような新しいものを作る場合は、必ず上記のような方針転換が発生すると思います。
どうやって管理するのか
以前書いたときよりも今日の整理によって明確になってきました。
自分が管理されたくないから管理しないと思ってやってましたが、これはワークフローの違いですね。「仕様書を超えていくためのワークフロー」を考えると、管理を下手にすると失敗するということなんだと思います。
ただし、注意としては、チームのひとりひとりがこういう制作工程をある程度理解していないといけないし、納期に間に合わせるために息を合わせる必要があります。「こだわりすぎて間に合わない」というのはデザイン工程などにありがちな話ですが、実際プログラミングだってなんだってこだわり過ぎたら間に合いません。こだわりすぎる人が割合多いのがデザインなだけですね。
まだ正確な答えは出てない
ワークフローの正解はまだ見つかってません。たぶんチームメンバーの構成や案件の内容によってアプローチも様々なんで、一定したワークフローなんてないのかも知れません。そういうワークフローごとワンオフでデザインして、ワンオフのものを作る。いわば研究開発に近い作業。それは作品を作る作業と似ている。
明確に言えるのは、人数が多いと結構難しいということです。少数精鋭で仕事をするのはこういう特殊なワークフローをうまく進めるうえでのコツなんだろうと思います。
でも、大きなプロジェクトは人がたくさん関わるのはしょうが無いです。その大所帯になったときにこの空気をどうやって維持するのか。これが今自分が取り組んでいる課題です。
わかったこと
あと、逆説的にわかったこととしては、一般的なワークフローや一般的な組織構造はだいたい仕様書を超えられない構造になっています。クライアントとの取引のワークフローもそうです。
要望から提案を作る時に仕様書を書いて工程を設計する。関わる人員と工数から見積を積み上げ、契約を結ぶ。（ここで仕様と金額を決めてしまう）
で制作をするときは、契約にあるので仕様通りものを作ることになります。検収時にチェックする項目も仕様から割り出されていきます。
つまり、初期のある意味ぼんやりとした仕様設計をし「それ」を実現するために工程が組まれていくわけです。
ウォーターフォールとアジャイル
ウォーターフォールとアジャイルで語られている内容になってきてるとおもいますが「展示の仕事」をアジャイル開発の工程でやってる事例は今まで遭遇したことがないです。ワークフローの改革が業種によっては広がっておらず、それによる問題でしょうか。
いや、そもそも予算を初期で決めにくい真のアジャイル開発に取り組めているところはクライアントワークでは少ない気がします。自社ですべて開発しているとしても予算管理は必要なわけで、とても難しい問題なんだろうと予想します。（ベンチャーで資金が潤沢なところはイテレーション回しまくってるかもしれないけど）
目指す形
自分がやろうとしてる（すでに実践している）ワークフローはウォーターフォールのふりをしながら、アジャイルっぽい。でもアジャイルで語られているほどのイテレーションはない。制作のつくり手ひとりひとりが「作りながら考える」ことによって一見すると一発で仕留めたように見えるようなリテイクの少ない状態なんだと思います。ただ、仕様書は超えちゃっててそこそこ煮詰まったクオリティになっている。
めちゃくちゃに見える
自分がやってることとか、自分がいいと思う工程の形はきっと「めちゃくちゃ」に見えると思うんです。「やっぱりこうします」みたいな「やっぱり」とか「だって」とか気分でやってるように見えるような流れでやっていくわけですから、そりゃそう見えるかも知れません。
でも仕上がりはいい。そういう事例を沢山積んで、仕事の進め方についても自信と信頼を獲得し、より強いチームになりたいんだなと再確認しました。