Web Initiative Center と社内的な所信表明

Web Initiative Center

4月から社内の Web Initiative Center ( 以下 WIC ) というグループで、新しい業務に取り組み始めました。社内メールに放流することを前提として書いているので、社内向けの内容です。すみません。

2016/11/03 追記: 開局6か月/900万DL突破の「AbemaTV」、急成長するウェブサービスを支えるフロントエンドエンジニアの舞台裏:CodeZine(コードジン) の取材の中でも Web Initiative Center について話をしました。

活動

  • Web のプロダクト品質を横断的に向上させる
  • Web 技術を使ったチャレンジがしやすい環境をつくる

この2つが活動の主旨であり、これらを通して Web によるユーザー体験を向上させることが目的です。

活動は CyberAgent 全社ではなくメディア系の部門内にひとまず限られますが、この中にはアメブロAmeba Ownd、先日リリースされた AbemaTV など相応の規模をもった Web のプロダクトがあります。いずれも私が作ったわけではないので完全に他人のフンドシなのですが、これらをもっと良くすることができれば日本の Web にとっても少なくないプラスになると確信しています。

このような目的を実現するため、まずは主要な現場の Web に対して意識の高い各位に、兼務で WIC に参加してもらって意見交換をするところから始めています。

Web のプロダクト品質を横断的に向上させる

当社のビジョンは「21世紀を代表する会社を創る」です。いざそのような規模の事業が育ったら、もしくはそのような事業の種が今あるとして、それに相応しい品質の Web を提供できているか?という開発者としての自問に基づき品質の向上を目指します。

主語がでかくなったので早々に着地させますが、当面はパフォーマンスとアクセシビリティの向上を中心に活動します。パフォーマンスもアクセシビリティも、やりたくない開発者は誰もいません。(と信じています)

そうであるにも関わらず、これらが疎かになるのはエンジニアの手元だけでは本質的に解決できない問題であることが大きな要因です。現場でおもむろに問題提起をしても、なぜか他職種との利害対立になってしまったり、そもそも開発の時間がとれなかったりしがちで前に進みません。

「パフォーマンスとアクセシビリティの推進」とだけ言ってしまうとエンジニアだけ息巻いているように見えてしまいがちです。そこで WIC では「高速に動作して快適に使える Web」と「誰もが利用しやすい Web」をいろいろな職責に合わせた理解に落とし込み、それぞれの目的を果たすための共通手段としてパフォーマンスやアクセシビリティを大事にするというコンセンサスを形成するように取り組みます。それによって、一過性のテコ入れでない継続的なプロセスとして品質と向き合う体制づくりを目指します。

品質の向上は事業的にもインパクトがあります。パフォーマンスは言うまでもなく KPI にも好影響を与えることが期待されます。また例えばですが(いや、ほんと例えばね...)アメブロがアクセシビリティ指針を公開し、2017年度中に JIS X 8341-3:2016 シングルA に準拠することを掲げ実行できれば CSR の観点からも有意義でしょう。

Web 技術を使ったチャレンジがしやすい環境をつくる

Web 技術は、まだまだチャレンジできる課題を数多く残しています。チャレンジを実行するには2通りのアプローチがあって、ひとつは「研究開発 をトップダウンで実行する」方法。もうひとつは「現場が独断でぶち込んだ結果がボトムアップ(されたりされなかったり)する」方法です。

Web Assembly や VR、動画技術のように中長期でコトを構えたほうが良さそうな課題は、研究開発的な動きをしても良いと思います。一方、実際の現場がやりたいチャレンジは最近だと Service Worker を使ったユーザー体験の向上だとか、Isomorphic アーキテクチャの実現や、新しいフレームワーク/ライブラリの導入です。

どのみち WIC には研究開発をする人的リソースはありません。よって「現場が独断でぶち込んだ結果がボトムアップされる」をバックアップしていきたいと考えています。ある現場のチャレンジがよその現場にも伝われば、なんとなくチャレンジする攻めの姿勢は伝播していくものです。

これに関して現状で具体的にどうするというプランは持っていません。まずは前述の兼務してもらったメンバー間で、Service Worker どうする? Angular 2 誰かやる?みたいに日常的な悪巧みをしつつ、誰かのチャレンジがみんなにとってのチャレンジになる文化の実現を考えていきます。

余談

社内の開発組織は良くも悪くもチームの独立性が高く、余所のチームのチャレンジが見えづらい傾向にあります。あるプロジェクトが導入を検討していた何かを、他のプロダクトでは既に導入済みで痛い目にもあっていた、なんてこともよくある話です。いわゆるチームの経験が開発組織に還元されない現象です。

こうした開発組織の状況をマネジメントしようとすると、人はレビュープロセスを設けたり、利用技術の承認ステップを設けたりしてしまいがちなのですが、そういうのはチャレンジを萎縮させてしまいがちで個人的に好きな方法ではありません。ことクライアントサイドに限っては、どんどんチャレンジしなければ変化に対応できなくなってしまう恐れすらあります。よってコミュニケーションの流通量を増やすことで対応していきたいと考えています。いよいよ Web 関係ないですね。

まとめ

雑にまとめるとこうです。

  • パフォーマンスとアクセシビリティを軸とした品質向上のコンセンサスとプロセスを構築します
  • 現場同士が助け合いながら、互いにチャレンジしやすくしていきましょう

WIC が自分を含めてあえて専任を設けていないのは「WIC で何かやってるらしいよ。しらんけど」って言われるような透明性が低い組織になりたくない意図と、現場での実行をケツモチできるメンバーがいないと結局なにも成せなくなる恐れがあるという過去の経験によるものです。活動は地味ですが、実行性の高さをウリにしたいとおもいます。

あらためて Web 開発がんばろうな!

以上です。今後ともよろしくお願いいたします。

P.S.

|-`) このブログをご覧の方でこういう取り組みに興味ある方がいらしたら社内外問わず意見交換、転職のご相談などなどお声がけくださいませ。動画技術に明るい方も絶賛募集中...。

P.S. その2

#times_ahomu を社内 Slack ではじめました。