5ヶ月ぶりの記事ポスト。ここのところもっぱら裏方担当(ひきこもり)ディレクターのtknrです。
今回は、ざっくり言うと、
そんなことを書こうと思います。
まずはじめにお断りを。
エンジニアならぬ人間の勝手な持論ですので、プロの方々、何を偉そうに、と言わず、そのフシはどうかスルーください...。
MONSTER DIVE(MD)の各メンバーが書いているブログにも見られる通り、Webのクリエイティブもテクノロジも、各分野が細分化され、どんどん進化・深化しているなか、ここ1〜2年、どうもディレクターである僕の主戦場が"システムサイド"になってきたように感じます。
これは、MDがお仕事させていただいているクライアントの皆様が、たまたまそういうシステム刷新系の時期なのか、TEAM MDのフォーメーション(人事体制)の都合なのか、はたまた歳を重ねるごとにコミュ症が加速する僕の性格が招いた結果なのか、と、業務を担当させていただけることに感謝しつつも、戸惑いがあったります。
1990年代後半からインターネットの世界に潜んでいる僕にとって、Webプロダクションのシゴトといえば、企画設計からデザイン、プロモーション、サーバサイドまで、ある程度ひとりでまかなうことが前提と言いますか、浅く広くなんとなーく様々な工程に触れてきた結果、ディレクターという立場に落ち着いたのが10年ほど前になります。
で、TEAM MDのなかでは技術的なディレクションやシステム構築系のプロジェクトを担当することが多いのですが、実はエンジニアやプログラマとして勤務したことも無いですし、きちんとスクールでお作法を習ったことも無いですし、数学どころか算数も苦手どころか学んだ記憶すらありません。
そんな僕がやっているディレクションって、はたして何なんだろうかと、うーん、ほんとに正しい方向に整理出来ているのだろうかと、三十路を過ぎてから中二のように悩むわけです。
システムサイドのお仕事に携わることが増えた状況、その理由を調べてみました。どうやら、僕に限った話ではなく、時代環境的な影響もあって、"古参の人間がシステム寄りの工程にアサインされる"ってケースが増えているようです。
世界的に、コードを書けるヒト、システムを描けるヒトが足りていない、というお話ですね。
Webサイトの制作やWebサービス/アプリケーションの開発という側面だけでなく、広告宣伝はもちろん、業務や販売・生産の管理に至るまで、"企業がやりたいコト"には、Webテクノロジを含め情報を扱う技術が常に必要とされる時代。残念ながら企業の「やりたい!」という声に対して「おれがやるよ!」と手を挙げられるヒトが少ないのです。
このアンバランスな状況は、NewsPickで見かけた『「コードを書かなくなったら一人前」、そんな業界構造を変えたい - Increments 及川卓也プロダクトマネージャ』(IT Pro)という記事に対して寄せられていた「最近、プログラマーのコストが高すぎるので、簡単なコードなら自分で書いてしまうこともあるよ」といったコメントからも感じられました。
本来であれば、Webディレクターやプロジェクトマネージャーの職域は、アニメーション業界でいうところの『SHIROBAKO』の宮森ちゃんのごとく、"制作進行管理"が本分だと思います、変な話。
上流から下流まで、各工程を生業としていらっしゃるプロフェッショナルの方々に、キレイにモノゴトをお任せする。そんなチームを組閣・運営するのが美しいディレクション業なのですが、冒頭に書いたように、現代のWeb業界は職種が細かく分かれ、各職種では各々の言語といいますか、話すコトバが異なる状況です。
そこに"システムを描けるヒトが足りていない"という環境が相まって、Webディレクター職にはシステム設計・開発領域での活動が求められるようになっているのかなと考えています。
さて、今回のブログの主題です。
この記事を読んでいただいているアナタ、Web業界の方だと思いますが、
こういった立場の方だとしたら、「システム」ということに、抵抗があったりしませんか? むつかしそう、自分には分からない世界...そんな心理的ハードルがあったり、しますよね? はい、僕はずっとそのコンプレックスを抱いて生きてきました。
ペライチのページ構成を作るだけならまだしも、入力フォームやら双方向性のある機能を考えて!とお題目を与えられたときに、きちんとエンジニアサイドに意図を伝えられているかどうか。
長い前段で書いたように、僕も非エンジニアなのですが、コードを書くヒトと意図や認識を共有するには、努力が必要だなぁと常日頃感じてるわけです。
で、その努力とはどんな努力なのかなぁと自分で思考を辿ってみますと、最も注意深く行っている工程、それは"翻訳"のような取り組みでした。
クライアント企業の担当者さんからいただいたお題やプランナーが企画したゴールを、「システム」の枠組みに当てはめるために、そのストーリーをふつうの日本語で著し、添削し、文章中の単語を各職種の方々に伝わるように翻訳する。どうもそんな工程が、テクニカルなディレクションてもののようです。
昨年、MDでは初の新卒採用メンバーをお迎えしたこともあり、OJT的な取り組みを行いました。
その機会に先輩メンバーから、
こんなレクチャーがありました。
生粋のエンジニアさんとお話ししていると、もう会話の上で処理を妄想してらっしゃるのを感じ取ることがありますが、Web言語のネイティブスピーカーならぬ僕らは、例えばトラベラーズイングリッシュのレベルで英会話をするように、まずは頭のなかで日本語の文章を作り、それを自分が知っている単語と文法に置き換えてどうにか翻訳して声に発する、といった順序で「システム」に向き合うのが良いのではないかと。
システムサイドは他人事じゃない!
非エンジニアの方も、もっとシステムを描くことに参加してもらいたい!
という想いから、今回はその翻訳的な工程の一端をご紹介してみることにしました。少しでも、Webのモノづくりの本質に、多くの方が多くの時間を割いていただけるようになればと願いつつ。
"翻訳"というコトバを使った意図を説明するために、システムを描くとてもとても基本的なところ、条件分岐、と書くとまた難しそうなので、「もしも◯◯が◯◯であれば◯◯する」という作文を、いくつかのWeb言語に置き換えて、書いていきます。
言語ごとにどんな違いがあるのか、見ていきましょう。
ざっくり見てみれば、きっと「システム」に向き合うハードルがちょっとだけ低くなる、かも!?
まずはMDのサーバサイドシステムの構築で最も多く採用されている言語、PHPです。
もうイマドキじゃない!なんていう声もありますが、慣れとは恐ろしいもので、個人的にはそうやすやすと乗り換えられません。なんだかんだいって、便利です。そう言っているヒトが多いんです、きっと。そうそう、CMSの有名なパッケージ「Wordpress」もこの言語で作られているのです。
言語が日本語だったら 「こんにちわ、コンニチワ、どーも!」って言いたい。 それ以外の言語だったら 「Hello, Hi, Howdy!」と言う感じで、ひとまず英語にしておこう。
$language = "Japanese"; if ($language === "Japanese") { echo "こんにちわ、コンニチワ、どーも!"; } else { echo "Hello, Hi, Howdy!"; }
どうでしょう、なんとなくイメージできますかね。
なお、PHPでも最近のバージョンではもっとスマートな書き方があるようですが、なにぶん古いニンゲンなもので、こんな感じで。
クライアントサイドの処理(ブラウザ側で実行される処理)といえばコレ。つまり、ユーザがブラウザでそのページを開いた時に、処理が実行されるというヤツです。表示演出系の処理のみならず、現代のWebサイトでは様々な用途で使われています。
Webサイトのシステムについて「ブラウザやOS環境に依存するから〜」という話の類は、たいていこのJSやCSSにまつわる処理について、です。
ハマグリを食べたのなら、 「今年もハマグリ食べたよ」って書きたい。 食べてなかったら、 「ハマグリ食べてない。来年は食べたい。」と書きたい。
var hamaguri = "食べた"; if (hamaguri === "食べた") { alert("今年もハマグリ食べたよ"); } else { alert("ハマグリ食べてない。来年は食べたい。"); }
みんなだいすき「Movable Type」はこの言語で作られています。
むかしむかしの話で言えばWeb業界のプログラマといえば「Perlが書けるヒト」を指すのが当たり前だった時期もあるそうです。
最近ではあえてこの言語で開発するということは、MDでは、ほぼ無いですね。でも、歴史的な経緯を含めて、システムというものを把握するためには、この言語の概要は知っておくと良いのではないでしょうか。
お財布におカネがたくさんあったら、 焼き肉を食べたい。 そうでなければ、 もはやもやしを食べるしかない。
$wallet = "おカネがたくさん"; if ($wallet eq "おカネがたくさん") { print "たくさんおカネがある!焼き肉食べる!"; } else { print "あんまりおカネがないからもやし食べる"; }
ナウでヤングな言語、Rubyですが、僕はほとんど実務では触ったことはありません。恐縮です。
以下、こんな感じらしいです。へー。
飲み物はビール? 飲みたいなら、「あぁビール飲みたい!」と声を上げよう。 そうでなければ、「いまはビールの気分じゃないなぁ」とつぶやく。
drink = "beer" if drink == "beer" print("あぁビール飲みたい!") else print("いまはビールの気分じゃないなぁ...") end
MDではモバイルデバイス向けのアプリ開発・運営も行っています。
JavaはAndroid用のアプリを開発するときに基本的に使われている、ネイティブ言語というやつです。僕もあまりソースレベルの実務経験は無いのですが、どうやらこんな感じで書くようです。
珈琲はブラックですか? ブラックで飲みたいヒト→「やっぱり珈琲はブラックだね」 そうでないヒト→「お砂糖がなきゃ珈琲は苦くて飲めないよ」
String coffee = "ブラック"; if (coffee.equals("ブラック")){ Log.d("やっぱり珈琲はブラックだね"); } else { Log.d("お砂糖がなきゃ珈琲は苦くて飲めないよ"); }
iPhone/iPad向けのアプリを作りたい!というときに使われる言語です。
最近ではSwiftという新しい言語が使われるケースも多いようですが、個人的にちょっとだけ触ったことがあるのは、このObjective-Cというものになります。
PHPとMTMLに慣れ親しんだ僕としては、非常にとっつきにくく、苦手意識の強い言語ではありますが、今回のお題のような「もしも」の処理をログに出すだけであれば、こんなふうにシンプルに書けるんですね。へぇ。
MDでは社員旅行(Company Retreat)がありますが、 今年はどこに行けるんでしょうか。 今年もグアムですかね?
NSString *companyRetreat = @"グアム"; if([companyRetreat isEqualToString:@"グアム"]){ NSLog(@"MONSTER DIVEの社員旅行はグアム!"); } else { NSLog(@"今年の社員旅行は未定。。"); }
Web言語という定義で言えばPHPに含まれるのですが、CMS的なシステムを構築するときに使われる、Smartyというテンプレートエンジンがあります。"フロントエンドの担当とサーバサイドの担当とで、触るファイルを分けておけたい"、そんなニーズに応えるものです。
このSmartyのテンプレートには、MTMLのような独自の記法がありまして、こんな感じでテンプレートの中で「もしも」の処理を書くことが出来ます。
あなたの職業はエンジニアですか? もしそうであれば、そうはっきり言いなさいよ、もう!
{assign var="myJob" value="エンジニア"} {if $myJob eq "エンジニア"}僕の職業はエンジニアですよ
{else}いや、エンジニアではないんですってば、ほんと。
{/if}
#実務的には、上記のようにテンプレート側で処理を書くのは、スマートではないと思いますが、ま、あくまで例として...。
さて、最後にMTのマークアップ言語をご紹介しておきましょう。
CSSやJSを担当するフロントエンドエンジニアでもCMSが組めるという点が最大の強みです。そのため、「日本語をシステムの言語に書き直す」という意味では最も分かりやすい(読み解きやすい)と言ってもいいかもしれません。はい、趣味の問題ですね、そうですね。
イケメンならイージーモード、 イケメン以外にとってはハードモード。
<$mt:SetVar name="me" value="イケメン"$> <mt:If name="me" eq="イケメン"> <p>イージーモードだわ</p> <mt:Else> <p>難易度、高すぎるわ</p> </mt:Else> </mt:If>
また、前述のとおりPerlで作られているエンジンですので、Perl的な記法である「Unless」(〜で無い限り)が用意されているというのも特徴ですね。
<$mt:SetVar name="me" value="イケメン"$> <mt:Unless name="me" eq="イケメン"> <p>ただしイケメンに限る。</p> <mt:Else> <p>meはイケメンざんす。</p> </mt:Else> </mt:Unless>
実例の始めに「言語ごとにどんな違いがあるのか」と書きましたが、どうでしょう、このように見比べてみると、あまり違いは無いことに気付きませんか。
もちろんこんな簡単な処理だけでシステムは成り立ちません。
しかしながら、小さな処理の積み重ねがプログラムになり、そのプログラムが連なった結果ひとつのシステムが出来上がるのです。
そう考えると、どんな言語で作ろうと、まずは(日本人であれば)日本語でやりたいコトを著すこと、それをチームのメンバーに伝わるよう訳していくことが、設計や開発を推し進めるきっかけになるハズです。
では、Webの処理やシステムを考える工程、整理しましょう。
3の工程も重要です。
例えば「街角に少女が佇んでいる。」という作文があるとします。
この文章は、どんな少女がどんな街角に立っているのか、読み手の想像力によってイメージされますが、映像化しようとしたら、
少女の服装は?
髪型は?
郊外なのか都市部なのか?
細かく決定していく必要があります。
システムを作るときも同じように、ふわっとしたイメージを具現化するために、「設定」つまり「条件」を決めていきます。
映像化という例で言えば、
「青い服を着ていて欲しい。髪型は決めかねているので、ヘアメイクさんに決めてもらいたい」
そんな進め方もアリでしょう。
システムに限らずデザインのディレクションでも同じコトが言えますが、ふわっとしたままの事柄があったとしたら、それは何故ふわっとしたまま設定が定義出来ていないのか、明らかになっていて、チームのメンバーが認識を共有していれば、プロジェクトは前に進むことが出来ます。
「これつくりたーい」とエンジニアサイドに投げっぱなしにするのではなく、関係するメンバーみんながそんな意識を持つ。それだけできっとより効率的で適切な進行が出来るハズです。
もしも自分がプログラマスキルを持っていたら、こんな難儀な工程を踏まず、Web言語でネイティブに設計構築できるのにな...どうしてあのころ「Hello, World」と打って挫折してしまったのだろう...と、ifの未来を嘆きつつ、elseのイマを生きている方も多いハズです。僕はそうです。w
ディレクター職に限らず、そんな方々がもっと「描くこと」のフェーズに参戦していただければ、きっとこの需要と供給がアンバランスななかでも、もっと良いモノづくりが出来るハズ、そう思っています。
というわけで、最終的には扇動的な「ハズ論」になってしまいましたが、とにかく、MDでは、ディレクター、クリエイター、大募集中なのです。詳しくはJOBのページまで。是非!