サイトアイコン NegativeMindException

他人に水面下の苦労は見えない

以前書いたエントリがちょっと企画職の悪口っぽくなっちゃったのを反省しつつ、また似たようなことを書いてしまう。今回は「エンジニア職 VS 企画職」という切り口ではなく、自分と違う職種の作業負荷は見えるのか?って切り口で行こうと思う。

これ系の話をまたぶり返したのは、最近見たこのツイートがきっかけ。

このツイートのリツイートやお気に入りの数を見ると、どうやら発注者と開発者のやりとりあるある話のようだ。

このツイートをきっかけに、発注者と開発者の関係の愚痴(?)を綴ったブログ記事もいくつか書かれていて、どれも概ね共感する内容。 発注者「簡単なアプリです」エンジニア「簡単か否かを決めるのはお前じゃない」

これ、漫画家などのお話も含めて定期的に上がってくる……ということは、状況が日常茶飯事的な状態ってことなんだろうけど。数枚の完成予想図を提示して「こんな感じの家を創って。簡単でしょ?」と指図した上で、図版を引いて作り始めた後に、「僕の天才的な発想で、もう1階上の部屋を作って」とちゃぶ台返しをするようなもの。

まぁ住宅周りの話は極端な例かもしれないけど、スマホ関連のアプリ市場がかなりカオスな状況になっていることもあり、この類の無理難題、「簡単でしょ」「それを決めるのは貴方じゃない」的な話は、これからますます増えて来るんだろうなあ。例えば「艦これみたいな戦車戦ゲーム作って。すでに実物が例にあるから簡単でしょ?」みたいな感じで、さ。

例え話として建築みたいな物理的に規模が見えるものを引き合いに出すのは、それほどにアプリ開発や漫画、デザインなどの作業規模・負荷は目に見えないジャンルということだろうか。

専門外の仕事を頼むには?

この手の問題は「発注者があまりにも無知」と言ってしまえばそれまでだけど、試しにもうちょっと掘り下げてみたい。これをただの悪口大会で終わらせず、何か洞察が得られないかと。

例えば、自分が発注者側だったらどうだろう。自分の知らない分野の専門知識が必要な作業をお願いする場合だ。どうやってお願いすれば良いのだろうか。果たして、別の職種の人間を怒らせずに仕事をお願いできるだろうか。

ここでまた引用したいのが、島国さんのブログで出てきた水面下の工程の話。(図になっているので解りやすいのです)
企画ってどういう奴がやるといいんだろ

「作ろうとしているものの中身に詳しくないのに、指示が出来ると思ってるのはおこがましい」

 という話である。前回の水面下の話ともつながる。

     ロ           ←非開発者が見ている部分
   ロ ロロ
~~~~~~~~~~  ←水面
   ロ ロロ
  ロロロロロ ロ      ←水面下に積み上げられた仕様、プログラム、データ。
  ロロロロロロロ
 ロロロロロロロロロ
──────────  ←海底

 氷山の一角しか知らずに、氷山を作れると思うか?
 という話でもある。(周りが手厚くサポートすれば作れる)

 ゲームの現場は、プログラマが分業どころか、デザイナも企画も分業なので、なんとなく全体をフワっとつかめる能力が必要だと思っている。水面下もなんとなくわかる力。

 それがあれば自分に欠けるところもわかるし、プロジェクトに足りないものも解る。
「オレはここが苦手だ」
 と思っている箇所があれば素直に得意な人にハマってもらえばいい。


スポンサーリンク

 自分にその能力が無いことに気がつかない、水面下の氷山を見る能力が無い、見ないでいいと思っている。などが最悪だろう。
 偉くなるとそれを指摘されなくなるし、立場で仕事してると誰も突っ込んでくれない。

この手の話で企画職が槍玉に挙げられがちなのは、単純に「役割が上流工程に位置している」からだと思う。本人の経験が浅かろうが関係なくプロジェクト全体の上流で仕事をするので、小さな歪みが結果に大きく影響してしまうポジションなのだ。
(ちなみに、上流・下流という表現は、仕事の優劣というか、序列と誤解されそうなのであまり好きではないです。)

「周りが手厚くサポート」と言っているように、最初に気の利くメンバーと仕事をしてしまうと、実は善意でカバーしてもらっていた部分に気づかずに実績を積んでしまうこともあるだろう。気の利いたメンバーのおかげで、それを学習する機会を失ってしまっているわけでもある。別の職種の人と一緒に仕事をする時は、そこからそれぞれの職種の観点を学び取ることが重要だ。エンジニア職は総じて控え目で、黙って我慢しちゃう人が多いのかもしれないけど。

ちなみに昨今は下請法などが厳しいので、外部に発注すると、気の利いた作業はやってもらえず、破綻した指示通り、クソ仕様のまま納品されて、発注側の責任になることも増えているとか。仕事の頼み方を学ぶ上では、適切なフィードバックが得られる時代かもしれない。

「見えている粒度が違う」と意識するしかない

結論を言ってしまうと、仕事を頼む側もそれなりに勉強する必要があるのだ。自分の専門分野とそれ以外では、物事を見る深さ、粒度に違いが存在するということを意識しなければならない。
この考え方は割と汎用性が高いと思っていて、例えば上司とのコミュニケーションにも応用できると思っている。上司が認識している情報の粒度を考慮して報告なり相談をした方が話がスムーズになる。認識している粒度にズレがある場合には、密に相談した方が良いだろう。(それで解決するかは別だが。)

外部に発注するなら、見積りの内訳にどんな工程が必要なのか細かく示してくれる会社もあると思うけど、スマホアプリの開発だと、スタッフを何人、何日使う、とか人月でしか書けないことが多いのかな。

今後はもっと見えづらくなる…

ソフトウェア開発も、ゲームや映像などのクリエイティブ系の開発も、最近は統合開発・制作環境が普及してきていて、工程の分離ができない、分業しづらい状況に進んでいる気がする。一方通行なウォーターフォールではなく、手戻りし易い開発環境は確かに完成度を高める上で有難いのだが、負荷を読みづらくしている原因でもある。
とはいえ、オイラも開発・制作ツールの恩恵を受けているので、この進化は止まらず、より加速していくだろうことも予想できる。それに伴って、コミュニケーションコストは増大する一方だということも目に見えている。
その流れとは逆に、仕事の依頼がネット経由で出来たりと、IT化のおかげで専門分野の遠い人同士のマッチングは実に簡単になっている。
この手の「認識のズレが存在している」ということぐらいは教育でどうにかできないものかと思ったりする。こういうのこそ「コミュニケーション能力」というやつのはずなんだけど。

まあ、このまま開発・制作ツールが進化すれば、「欲しいと思った人が自分で作れるようになるんじゃね?」という疑問も出てくるけどさ。

最後に、同じ人の別のツイートを紹介。

こっちは仕事を取ってくる人、つまり営業職と制作・開発職の関係の話かな。これについてもいずれ書きたいところ。
今の時代、役割分担が実は上手くいってないって話かもしれないね。


スポンサーリンク

関連記事

  • 2020年11月 振り返り
  • マイケル・ベイの動画の感覚
  • 2017年5月 振り返り
  • BS-TBS 必見!就活リサーチ[再]「TBS編」
  • kotobankを使ってみた
  • 最高にカッコイイガラス細工
  • 2019年6月 行動振り返り
  • 書籍『クラッシャー上司 平気で部下を追い詰める人たち』読了
  • Windows Server 2008に触ってみた
  • 無能の作り方
  • 2020年9月 振り返り
  • 過程を晒す
  • 無料で学べる技術者向けeラーニングサービス「Webラーニングプラザ」
  • 書籍『人生は、運よりも実力よりも「勘違いさせる力」で決まっている』読了
  • 2022年4月 振り返り
  • アメブロをしばらく放置してみた
  • 世界で最も正確な性格テスト
  • Amazon Video Direct:自作の映像をAmazonで配信
  • 「自分が何を学んでいるか」を人に説明できない
  • 職場におけるセルフブランディング
  • FFS理論
  • 今年も「すいかキャンディ」の季節がやってきました
  • 人材輩出企業
  • 昨日これ見てきた 東京ゲームショウ2009
  • 2023年7月 振り返り
  • 犬が電柱におしっこするように、僕はセカイカメラでエアタグを貼る(初日の感想)
  • 2020年6月 振り返り
  • 2021年2月 振り返り
  • 企画とエンジニア 時間感覚の違い
  • 手軽な娯楽
  • 2023年12月 振り返り
  • プログラミングスキルとは何か?
  • 2020年7月 振り返り
  • 2024年4月 振り返り
  • 書籍『グラビアアイドルの仕事論』読了
  • 2021年12月 振り返り
  • ハードルの下げ方を学べば続けられる
  • 2017年8月 振り返り
  • 文章を書く時の相手との距離感
  • HackerスペースとMakerスペース
  • 2012 昨日のクローズアップ現代を見た
  • 書籍『鈴木さんにも分かるネットの未来』読了
  • モバイルバージョンを終了