20150530...

2015/05/30 春のフロントエンド祭り

無名の会社が、

大規模サイト（スマホ対応）相手に、構築・運用でやってること

株式会社大塚ビジネスサービス上野裕樹

春のフロントエンドまつり


この発表のまとめ（和田あずみさんにグラレコしてもらいましたー）


上野裕樹札幌出身～国立音楽大学～

産業技術大学院大学人間中心デザイン2012

妻と娘（2）、息子（0）４人で暮らしてます。

メーカーとか商社とか。

制作会社とかコンサルとか


○書籍等

サービスデザイン（翻訳） [丸善出版]


流れ

【1.準備段階】大規模サイトをスマホ対応するために

まずはじめにやったこと。

【2.構築段階】諦めることも重要な選択

【3.リリース】ドタバタ劇

【4.運用開始】でるわでるわ、次から次の難題。


【1.準備段階】大規模サイトをスマホ対応するために

まずはじめにやったこと。


【1.準備段階】大規模サイトをスマホ対応するためにまずはじめにやったこと。

○技術の制約を確認した。ユーザー視点、ビジネス視点、マネジメント視点も大事だが、まず、技術視点の制約を調べた・スマホ対応のネック、「表と図」

他にも、・セキュリティ・CMSの種類、特性・iso / JIS ・W3C などなど



○次に「実際に運用できるか？」を考えた。・運用者のレベル感・社内のステークホルダー状態、関係性、・状況、状態、予想、実績。適切な運用技術レベルを設定する。



○ビジネス視点の要求・サイトの品質要求の確認と、運用品質レベルとのつきあわせ SEO,a11y,ユーザビリティ、ガイドラインなどなど・・・。



○確認のため、ユーザー視点は最重要ユーザーのサイトの利用状況が、上記制約の中で組まれるサイトの技術要件で、満たせているか。 →ここで大きな気づき。結局王道な作りが、最も堅実で使いやすい。



○“議論”（？）は大体延長戦。

・色々な会社と連携する上では、コミュニケーションコストを払いきれないケースも多々。内部でさえ、コンセンサスはとりづらい。正直、ユーザー視点、技術視点、運用視点で、おかしいだろっていうことも、諦めるポイントは多々ある。残念と思わない。明日への布石。じゃないと、やってられない。。



→スマホ対応は、特にデジタルイミグラント・アナログネイティブ世代にとって、本当に"想像ができない"みたい。 →制作メンバー内でさえ、スマホ対応するときの考え方は、追いつかない人も実際いる。でも仕方ない。難しいもの。なので、70点目指して頑張る。ポイントは、コンテンツ領域部分は、構造と運用ルール死守。いや、死守できないことも多いけど。正直、テンプレート部分は、後でなんとかなることが多い。



○デッドラインがわかったら。要件定義なんて、もうしない。切り捨てる。無理無理。「間に合わなくていいですね？（^^)」の一言で、全部黙らせる関係性が必要。ただし、断固たる決意で作り上げる。リファクタリングはできないので、、一発で完成系をイメージし、作り上げられる技術者必須。 IAさんとエンジニアさんは、もう一蓮托生。ヒャッハー。



■メモ：トリガークラス

<body> <#wrap .トリガークラスA>

<#main-containar .トリガークラスB> <#main> <h1>大見出し

<#side>

.トリガークラスA .トリガークラスB #main{}

段階に応じて



○「確認してください」というムチャブリ。これは、ビジネス上の責任の擦り付け合い。定型業務。制作者はなんともいえない気持ちになるけど、仕事なのでやっとく。ただそれだけ。



○エラー？「いいえ、仕様です。」と言おうと思ってたが、、公開して、不具合ってほとんどなかった。奇跡？いいえ、実力です。（どや）

現存のサイトを大体把握（設計視点、ビジネス視点、技術視点）

していて、構築段階と構築時にやる気がある人が一人と、

その周辺に優秀な（信頼できる）仲間がいれば、なんとかなる。

そりゃそうか。



○CSS一枚でやろうとして、できなかったこと。複数プロジェクトを平行で稼働し、リリースさせるためには、ある一定の領域毎に、切っておいた方がいい。正直、"なんじゃこれ"も出てくるけど、後で改修。



○後で改修、っつったって、簡単じゃない。コンテンツが多くて、改修もすごい大変。新規構築ならまだいいけど、壊して作るのは、なかなか至難。ただそれも慣れてくるから恐ろしい。



○気づかなかった、不思議系コンテンツ大体把握してても、細部まで全部記憶できる人間なんていない。やっぱり、「ここどうするべ・・・」はあって当然。 "ナニコレ珍百景"的な構えで挑む。


★ここまでのフェーズでクリティカルにやばいこと。



コードの整合性がとれなくなる状態やとにかくやばい。後工程でのリファクタリングが鬼畜になるし、状況確認のための、データ解析がとてもしにくくなる。 CSSやJSがどこで使われているかわからなくなるから、コンポーネントの容量が増えて、重いし、なにより、読みにくい。単純なミスも増えてくる。



ルールレベルによるけれど、 CSSとかjsとか、どんなにガイドラインを定めても、よっぽどコミュニケーションがとれて、今までずっと一緒に仕事をしてきている仲間じゃなきゃ、大体難しい。プロマネあたりが言います。「外注して効率よく」そんなにうまくいったら、世の中平和です。でも、実コードを書いてないので、内容を理解する気はさらさらないと思っていた方がよい。


■■最後に■■

困ったときは、ユーザーに問いかける。技術的内容は半分、政治的内容は半分、と割り切る。


ありがとうございました

株式会社大塚ビジネスサービス上野

20150530...

Business