ウープスデザインブログ >> デザイナとの打ち合わせってどうすればいいの?を読んで、ほー、と関心する一方で相当考え方が違ったので面白くなって書いてみる。仕事の進め方、プログラマ編。

あ、でも先に言っておくと、俺は「ベンチャーで、Webで、デザイナもディレクタも社内の人間で、自社サービス」っていう非常に限られた領域でしか仕事をしてきたことがないので、今から書くことがプログラマ一般に適用できる話だとは思ってません。タイトルはそういう意図。なので、あくまで上記の前提条件があった上での話だと思って読んでください。

1.やりたいことをある程度洗い出す

「なんかやりたい」とかいう漠然とした要望では流石に「で、俺は何作ればいいのよ」と答えたくもなるので、ある程度まとまるまでやりたいことを出してきて下さい。でも、ここで重要なのは全部洗い出す必要はないってことです。やりたいことがはっきり形になるまでには時間がかかるし、作ってる最中に絶対に軌道修正したくなります。あまつさえ方向転換したくなることもあります。最初から完璧な完成形が見えてる人なんていないんだから、当然です。

作ったものを修正しなきゃらななくなったとしても、無駄ではありません。思い付きであっちこっちフラフラするのはダメすぎますが、作ってる最中に、考えてるときには見えなかった問題にぶつかったり、より良い案が見つかったりすることは多々あります、というか無いことの方が珍しいです。そんなときに「でも、これだけ時間かけちゃったし、リリース予定日も近いし、今さら後戻りするわけには…」なんて言い出すくらいなら、最初から時間をかけなければいい。さくっと考えてさくっと作ってみて、直しては進め、進めてはまた考えていけばいい。1ステップにかける時間が少なければ、何度もステップを重ねられるし、どこかの時点までの作業が無駄になるとしても損失は少ない。

よく、気合いの入ったpptの画面設計書とか作ってくるディレクタさんがいますが、あれはやめて欲しい。プログラマ相手なら、顔付き合せて話して、その最中にホワイトボードに適当に絵でも書いてくれれば十分です。もし先にしっかりしたイメージを用意したいなら、デザイナさんにイメージを作ってもらうか、もっと言えばマークアップエンジニアさんにモック(システム的な部分は作り込まず、HTMLでガワだけ作ったもの)を用意してもらった方がありがたいけど、それだって時間がかかるので絶対必要なものではないです。パワポを書くのに時間を掛けるくらいなら、適当でもいいから動くもの作ってそれについてあれこれ議論した方が有意義です。要素だって、「その機能に必要なもの」を出してくれさえすればそれ以外はあとからどうとでもできる。細かい文言とか先に全部決めちゃっても後から直すはめになるのだから。

2.優先順位をつける

上記で羅列した内容に手書きで順番を付けるだけで構いません。初歩的なことですが、これをしておくと「どうでもいい機能を作り込んでしまったばかりに本質的なところが時間に追われて間に合わせになる」などおかしなコトにはならないハズです。さらに、優先順位がしっかりとプログラマに伝わるのでそれらの意図を組んだ上で機能的に分かりやすく意味付けしてくれるハズです。多分。

3.希望する見た目を添付する

まぁ、プログラマには、いらんと思います。競合になりそうなサービス、とかは勿論チェックしますが、あんまり「こういうの!」って言われるとそれを作っちゃうので注意です。「Twitterみたいの!」って言われるとTwitter作っちゃいます。いや、それは作る側の問題ではあるんだけど。

4.経緯、展望を話す

ここまでに何度となくプログラマとディレクタの打ち合わせはしてると思いますが、その中で経緯と展望を話すのを忘れないでください。つまり、経緯と展望を話すのを忘れないでください。大事なことなので二度言いました。ここまでの手順を踏んでいるだけでは、何も聞かされないで仕事を振られるよりはいい、程度の仕事ができるだけです。「何でそれを作りたいのか、それをどうしたいのか」が伝わっていないと、諸々の理由で見当違いのものができてくることが多々あります。バックグラウンドが共有されていれば、技術者として、作り手としてのアドバイスや新しいアイディアが出せるかもしれません。でも、ただ「これやって」だと、良くわかんないけどやっつけで作っちゃうとか、良かれと思って作り込んで明後日の方向に暴走するとか、結構な確率で起きてきます。

だから経緯と展望を話すのを忘れないでください。三度言いました。

5.質疑応答

ちょっとやっては直し、直しつつ考え、考えつつ作る、みたいなことをしてるとお互いが質問しあうのが日常になってると思いますが、億劫がらずに答えてあげて下さい。逆に、忙しそうだから聞いちゃ悪いかな、とか、こんな初歩的なこと聞くのもアレかな、とか、そんなこと思ってないでどんどん聞いて下さい。

こんなことを公言するのもどうかと思いますが、面倒臭いという理由で聞きたいことを後回しにしたり、質問されたときに「あとで確認しときます」とか答えたりするような悪癖を持ったfaultierとかfaulistとかとにかくfauがつくなんとかって人がいたりしますが、そういうのは悪いナマケモノなので、良いナマケモノに育つよう叱りつけてやって下さい。ごめんなさい。気をつけます。

最後に

こういった流れを踏んでおくと、物事が前後したり抜けたりしてもお互いスムーズに気持ちが良く仕事が出来るハズです。一緒に仕事をしてるディレクタさんですごく気持ちよく仕事ができる方がいますが、その人と仕事をしてるときは実際これに近いことをやってくれてたりします。

開発の作業は間違うとその損失を取り戻すのに長い時間がかかってしまうこともしばしばありますが、大抵そこに至るには「間違ったまま進んでしまった」ときです。それらは納期を脅かし、コストにも影響しますので、ついつい「しっかりやろう」としがちです。逆に考えるんだ。何回か間違えてもいいから、進むときはより良い方向に進む、こうすればいいじゃないか。最初に全部準備しようとか、一度決めた方針や納期は変えないとか、そういう鈍重さはWebサービス開発にはいらないと思うんだ。コストや納期のことを考えればこそ。

今回はfaultier目線で書いてしまったのですが、自分自身も相手の立場にたってより良い提案や先回りの仕事をしていきたいと思います。

重ねて言いますが、これが外注先とのやりとり、とかいう話だったら元記事の手順がきっと当然なのかもしれない(というかその世界を知らないのでなんとも言えない)。加えて元記事はデザイナの話で、俺はプログラマの話。仕事の流儀が違うことも多々あるかもしれない。とはいえ、少なくとも自社のWebサービス開発でディレクタもプログラマもデザイナもみんな社内の人間なんだったら、もう少し良いやりかたがあるんじゃないかと思って書いてみた次第です。

追記

危うくスルーするところだった。

プログラマ編。同じような手順を踏んでいて、違う目線で書いてあるので面白い。でも経緯と展望のところは一緒なんやね。表側(デザイン)と裏側(プログラム)の違いが良く分かる感じ。

違うよ。全然違うよ。違いは表側か裏側かなんかじゃないよ。少なくとも俺は自分が作ったシステムが「動き」になってどういう風にユーザの前に表われるかまで考えて作るし、デザイナだって「一枚絵」じゃなくてどう動くかまでを考えて描くでしょ。どちらかがどちらかしか見てないとすればそれはそれで大問題だよ。

本質的な違いはそこじゃない。何で「最初に万全に準備を整えて後のリスクを減らして下さい」に対して「最初にコストをかけようとしないで細かいステップで進んで下さい」っていう真逆の発想に至ったか、そこに横たわる溝がなんなのかを考えて欲しいなー。