Webディレクターに求められるスキル
Webディレクターに求められるスキルって最近多すぎるよなってことで自分なりにまとめてみた。
もちろん全部が必要あるわけではなく、ここら辺の内容を色々な職種が掻い摘んでいる状態なことが多い。
企画・設計力
- 事前調査
- 提案
- ドキュメント作成
- プレゼンテーションスキル
- プロトタイプ周りの知識
- 情報設計力
クライアントや意思決定者の話を聞いて、要件定義をしていく時に必要となるスキル全般。要求を聞くだけではなく、こちらから提案をする力も必要。そのためターゲットとなる市場の事前調査。さらに要件をまとめ上げるために、プロトタイプの制作も必要になったりする。このタイミングからでも、そのWebサービスがどのような設計になっているかを仕分けできるようになっていると後が楽になる。
プロジェクト管理スキル
- 人員の確保
- コミュニケーションスキル
- 仕様書作成スキル
- ドキュメント作成
- プレゼン作成
- コンセプト設計
- サービスの文脈の整理
- ワイヤーフレームの作成
- プロジェクト進行管理
- スケジュールの管理
- 品質の管理
- 費用の管理
- 外注の進行管理
- プロジェクト管理全般の知見
クライアントと協議して要件定義を決めて、制作や開発者チームに自分たちが何をしたいかを伝えるフェーズで必要になるスキル。まず誰に作ってもらうかの判断と確保が必要。その後、チームに何を作るかを伝える。その時にわかりやすく伝えるコミュニケーション能力や仕様書の作成能力、プレゼン能力も必要になる。また、コンセプトの設計をしっかりすることで仕様の確度を上げる。
制作が始まった後に、プロジェクトが問題なく動いているかを管理する。その場合にチケット駆動開発などのツールの知見が必要になる。チーム内の情報の流れ方、運用フローも決めたりする。また、この管理にはスケジュールだけではなく、品質、費用も含まれている場合もある。
プロダクトの開発
- 法務周りの知見
- Web業界の知見
- App Store, Google Playなどのプラットフォームの仕様
- AD配信の知見
- SEO
- SSO
- 社内ルールの知見
- コンテンツ制作
- 中心となるサービス以外のコンテンツ作成
- LPやバナーなど
- 中心となるサービス以外のコンテンツ作成
- QA
- 手配 or 実行
- 開発ツールを使いこなせるツール
開発に関連する周辺環境の知見。課金や個人情報の取り扱いなど、会社の法務とやりとりをしていくために必要な知見。アプリならば、App Store, Google Playのルール。特にApp Storeは何をしたらリジェクトされるかなどのルールも頭の中に入れておいたほうが良いことも。Webならば、SEOなどの流入の方法の必要最低限の知見も。それ以外に社内のルールも把握し、適切に立ち回れる。
また場合によっては、もともとデザイナーだった人がWebディレクターになることも無くはないので、簡単な制作物はディレクターが行う人もいる。
制作・開発が完成したプロダクトの確認・チェックをする場合もある。
また、最近開発で使われるツールは多い。チケット管理、ドキュメント管理、チャットツール、デザイン管理ツール(InVisionとか)など、開発者に合わせて習得する必要がある。ツールは日進月歩で進化して、開発者も移り気で使いたいものが変わることもあるので、それに追随が必要なこともある。
解析・運用
- Google Analyticsやログなどのツールを扱うスキル
- 計測の設計
- どこに問題があるかを発展させる洞察力
- 解析した結果から次のアクションに起こすための提案力
リリース後に、まず解析の基盤システムなどを使いながらも自分たちのプロダクトがどのような状態かを読み取れる力。それとどの部分に問題があるかを見つける洞察力。それと次のアクションを行うために、まわりを説得できるまでの提案力。小回りのきくいわゆるグロースハッカー的な力の場合や、クライアントや意思決定者への提案など粒度はさまざま。
これら全体をマネジメントをする力
- コミュニケーションスキル
- マネジメントスキル
- 人・時間・お金の管理
企画から実現までのプロジェクトとPDCAを回す両方のマネジメントスキル。
もはや Webディレクターはコンサルである
第一線のプロがホンネで教える 超実践的 Webディレクターの教科書に
すでにディレクターへの期待値は「Webというマーケットを主軸としたビジネスのコンサルティング」に近い領域にまで達してきています。
と書いてあるけれど、もはや至る所でディレクターもはやコンサルみたいになっているみたい。
参考
標準ウェブ制作完全ガイド プランニングからデザイン、そしてシステム構築まで。Webの「仕事」がトータルに理解できるプロフェッショナル養成講座。
- 作者: MdN編集部,松岡清一
- 出版社/メーカー: MdN
- 発売日: 2010/02/23
- メディア: 単行本
- クリック: 138回
- この商品を含むブログ (2件) を見る
第一線のプロがホンネで教える 超実践的 Webディレクターの教科書
- 作者: 日本ディレクション協会会長中村健太,株式会社デスクトップワークス代表取締役田口真行,デジタルマーケティングオフィス DCHS 代表高瀬康次
- 出版社/メーカー: マイナビ
- 発売日: 2015/08/25
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (1件) を見る
APIドキュメントを支える技術 2016
1年くらい前に、APIドキュメントについて書いたけれど、最近また少し便利なことが増えてきている。
Swagger 2.0, API Blueprint が進歩してきている
Swagger – The World's Most Popular Framework for APIs. もライブラリが増えたり、エディタが進化したり、clientの生成が楽になったりと、ちょっと前に比べて使いやすくなってきている。
API Blueprintも Schema セクションを記述すればバリデーションにも使える。それにDockerもだいぶ浸透して、ドキュメント生成ライブラリのaglioのDocker imageも簡単に用意できる ので、生成の手間がものすごい減っている。
Validationは、ドキュメントにJSON Schemaを定義する
APIドキュメントに話を戻すと、ドキュメントの内容を使ってValidationをするときは、Swagger も API Blueprint も JSON Schemaを記載しておいて、テスト実行時にそれを使って検証をする。Swagger 2.0は、responseに記載が可能だし、Blueprint も上で書いたとおり、Schemaの記載ができる。
コードからドキュメントやクライアントを生成する
最近はコードから各種のクライアントライブラリを生成して運用するのでも問題ない状況になってきている。 https://github.com/goadesign/goa は、DSLめいた仕様を記載すれば、Goのモデル部分やswagger、jsのクライアントを生成してくれたりする。
それに grpc / grpc.io も浸透してきている。 これを導入できれば、Protocol Buffersを定義して、クライアントを生成して、それを呼び出し元に渡すという作業フローができる。API仕様書を各担当に渡して人の目で見て実装するという作業がだいぶ減る。
AWSのAPI GatewayもSwaggerサポート*1しているし、ドキュメントを書けばある程度サーバーの構築が完了し、後は裏のデータのやり取りなどの調整をするくらいになった。 どんどんサーバーアプリケーションサイドは楽になっていく。データの設計もクライアント側が考慮するようにすれば、サーバーアプリケーションサイドはほとんど必要もなくなるかもしれない。
コードリーディングの楽しみ方
コードリーディングは大事なことだとよく言われているけれど、コードを読むというのは案外負荷がかかること。一方で自分が直接関与していないプロジェクトのコードやGithubにある有名なリポジトリとかを習慣的に読んだりしている人もいる。
自分はコードを読むという習慣がつかない方。良くはないよなぁと思いながらも、興味がついていかなかったりする。
なので、ある機会にコードを読む習慣がある人にどういう風に読むのか聞いてみた。
その人はREADMEを読んで、それを参考に全体をなんとなく読む。 あとはプルリクをみて、「この人、全然この人の修正にLGTMしないなぁ」とか「この人とこの人は流派が違うなぁ」とかを汲み取って楽しんでいるそうだ。
それとissueなどの議論をみたりするのも楽しいらしい。例えば、しばらく前に UnderscoreとLodashの統合*1 についての議論とかは、それぞれの作者がどのような意見でどういう行動をしているのかを眺めて、ライブラリの見方が変わったりすることもあるらしい。
それ 市況かぶ全力2階建 の楽しみ方と一緒じゃないか!って話になった。
マイクロサービスでウェブサービスを構築するときにAPI Gatewayのことを頭にいれておいたほうが良いんじゃないか説
新規開発でAWS ECSを使ったマイクロサービス構成でサービスを運用しているけれど、そこで学んだことのひとつに、API Gateway のことについて早い段階で考慮したほうがいいっていうのがある。
ウェブサービスの新規開発の場合なら、最初はマイクロサービスで行こうぜってなったとしても、どれくらいトラフィック来るかもわからなかったり、スケジュールの制約もあるので、実際に細かく分けることはない。
Client → App → DB
Clientが、ネイティブアプリだったり、ウェブページの情報取ってくるところ(Nodeやらウェブページやら)。App がいわゆるAPI。DBのデータを取ってきたり操作したりするところ。
最初にマイクロサービスっぽくなるところは、例えば検索機能とかあった場合に、Appから検索用のAPI(Search)を呼び出す場合。Searchでは裏で検索indexとかを作っているマイクロサービスとして見ることができる。
Client → App → DB `- → Search
こんな感じで機能がどんどん増えて行くと、Appがいろいろなところを呼び出すようになっていく。
Client → App → DB `+ → Search `+ → 機能1 `- → 機能2
すると、Appの存在が最初のモノリスティックな状態から、各機能から受け取ったデータをどう素早く取得して、適切な形式で返すかという機能に集中していくことになる。これがAPI Gateway になる。
なので、次第にAppとGatewayを分離したくなってくる。
Client → Gateway → App → DB `+ → Search `+ → 機能1 `- → 機能2
このときに、初期のデータ設計で、分離された状態を想定できていなかった場合に、移行の難易度が跳ね上がる。もしくは、分離しても各マイクロサービス間でデータのやり取りが一気に増えてしまう可能性がある。
依存関係の設計に頭を使おう
考えることは、どこまで並列に処理を実行できるかと、どこで情報の関連性を構築するか。これがデプロイにも影響するので、パッケージ管理も含まれる。これが意外とサービス発展の早い段階で着手する必要が出てくるので、もし最初からマイクロサービス的なアーキテクチャにしていこうとする場合は、頭に入れておいたほうがいいと思う。
参考
The Netflix Tech Blog: Optimizing the Netflix API
SOFT SKILLS 読んだ
- 作者: ジョン・ソンメズ
- 出版社/メーカー: 日経BP社
- 発売日: 2016/06/02
- メディア: Kindle版
- この商品を含むブログを見る
読んだ。
生計を立てるためにコードを書くという世界に踏み出したときのあなたは、中世の街で店を準備している鍛冶屋と同じだ。時代は変わり、ほとんどのソフトウェア開発者は会社に属しているものの、私たちのスキルや取引は私たちのものであり、いつでもどこかの別の場所に店を出すことができる。
ソフトウェア開発者がどのようなことを考え、行動をしていくべきかの指南書。
キャリアパスの構築の仕方からお金の話、効率の良い時間の使い方、食事や健康についてと網羅的。
ソフトウェア開発者といえば、いわゆる典型的な引きこもりがちのギークを想像する人って未だに多いと思うけれど、コードを書く以外にもやらなきゃいけないことはいっぱいある。それらについてまとめられた一冊。面白かった。
ただし、アメリカのソフトウェア開発者向け。給与交渉とか国内だと考えづらい話が飛び交う。真に受けすぎずに、かい摘むくらいがちょうど良さそう。
ポモドーロテクニック
The Pomodoro Technique® - proudly developed by Francesco CirilloThe Pomodoro Technique®
この本でポモドーロテクニックを初めて知った。25分集中して5分休む。それを1日や1週間で何回できるかを把握して、自分の仕事のペースをつかんでいく。やらないよりやったほうが良い系のライフハック。実際に訳者のあとがきでもこのポモドーロテクニックに言及していて、実際に効果があったと書いてたりする。
そういえば同僚が Toggl - Free Time Tracking Software を使って自分の時間管理をしていた。こういう時間管理系アプリはいっぱいあるっぽい。試してみる価値はありそう。
phatmans after school 聴いてる
さいきんphatmans after school 聴いてる。軽くて良い。
GReeeeNと同じようにメンバーをいっさい出さないグループっぽい。
淡麗プラチナダブル|ビール・発泡酒・新ジャンル|商品情報|キリン
ところで、最近よく見かける電車広告に出ている米田課長の広告。
phatmans after school も難易度高め。
ポルカドットスティングレイ「テレキャスター・ストライプ」MV
ポルカドットスティングレイ/テレキャスター・ストライプ とか一見さんお断りな感じ。 LOVE PSYCHEDELICO という名をはじめてみたときの気分。
歳じゃなくて難易度が上がってるだけだと思う。
勉強会にタダ飯を食べに来る人がいる問題
ちょっと前に誰かから聞いた話だけど、勉強会にタダ飯目的のために潜り込む人がいるらしい。これが勉強会を運営する時の問題のひとつになるそうだ。
たしかにあまりチェックがされない勉強会に潜り込んで、ピザを食べて適当に回りの人に話合わせて帰る人は想像できる。運営側からすると、懇親会が親睦を深める場として用意しているので、問題視したくなるのもわかる。
お金がない人はエンジニアの勉強会に行くと良い って書いているけれど、本気でそうしている人もいるみたい。
一応名刺の提出とかで対策取っていることもあるみたいだけど、そもそも興味があったり本気で勉強する気がなければピザを食べてはならないってのもよくわからない話なので、線引きは難しそう。