Help
RSS
API
Feed
Maltego
Contact
Domain > 108tunes.com
×
More information on this domain is in
AlienVault OTX
Is this malicious?
Yes
No
DNS Resolutions
Date
IP Address
2016-11-06
157.7.107.108
(
ClassC
)
2019-07-22
157.7.107.200
(
ClassC
)
2024-10-31
163.44.185.239
(
ClassC
)
Port 80
HTTP/1.1 200 OKDate: Thu, 31 Oct 2024 07:38:21 GMTContent-Type: text/html; charsetUTF-8Transfer-Encoding: chunkedConnection: keep-aliveServer: LiteSpeedx-powered-by: PHP/7.3.33link: https://108tunes.com/wp-json/>; relhttps://api.w.org/x-turbo-charged-by: LiteSpeed !DOCTYPE html>html langja classno-js>head> meta charsetUTF-8> meta nameviewport contentwidthdevice-width> link relprofile hrefhttp://gmpg.org/xfn/11>!-- Google Tag Manager -->script>(function(w,d,s,l,i){wlwl||;wl.push({gtm.start:new Date().getTime(),event:gtm.js});var fd.getElementsByTagName(s)0,jd.createElement(s),dll!dataLayer?&l+l:;j.asynctrue;j.srchttps://www.googletagmanager.com/gtm.js?id+i+dl;f.parentNode.insertBefore(j,f);})(window,document,script,dataLayer,GTM-M8TQBW9);/script>!-- End Google Tag Manager --> link relpingback hrefhttp://108tunes.com/wp/xmlrpc.php> !--if lt IE 9> script srchttp://108tunes.com/wp/wp-content/themes/twentyfifteen/js/html5.js>/script> !endif--> script>(function(html){html.className html.className.replace(/\bno-js\b/,js)})(document.documentElement);/script>title>Webディレクターの徒然/title>meta namerobots contentmax-image-preview:large />link reldns-prefetch href//fonts.googleapis.com />link reldns-prefetch href//s.w.org />link hrefhttps://fonts.gstatic.com crossorigin relpreconnect />link relalternate typeapplication/rss+xml titleWebディレクターの徒然 » フィード hrefhttps://108tunes.com/feed/ />link relalternate typeapplication/rss+xml titleWebディレクターの徒然 » コメントフィード hrefhttps://108tunes.com/comments/feed/ /> script> window._wpemojiSettings {baseUrl:https:\/\/s.w.org\/images\/core\/emoji\/13.0.1\/72x72\/,ext:.png,svgUrl:https:\/\/s.w.org\/images\/core\/emoji\/13.0.1\/svg\/,svgExt:.svg,source:{concatemoji:http:\/\/108tunes.com\/wp\/wp-includes\/js\/wp-emoji-release.min.js?ver5.7.12}}; !function(e,a,t){var n,r,o,ia.createElement(canvas),pi.getContext&&i.getContext(2d);function s(e,t){var aString.fromCharCode;p.clearRect(0,0,i.width,i.height),p.fillText(a.apply(this,e),0,0);ei.toDataURL();return p.clearRect(0,0,i.width,i.height),p.fillText(a.apply(this,t),0,0),ei.toDataURL()}function c(e){var ta.createElement(script);t.srce,t.defert.typetext/javascript,a.getElementsByTagName(head)0.appendChild(t)}for(oArray(flag,emoji),t.supports{everything:!0,everythingExceptFlag:!0},r0;ro.length;r++)t.supportsorfunction(e){if(!p||!p.fillText)return!1;switch(p.textBaselinetop,p.font600 32px Arial,e){caseflag:return s(127987,65039,8205,9895,65039,127987,65039,8203,9895,65039)?!1:!s(55356,56826,55356,56819,55356,56826,8203,55356,56819)&&!s(55356,57332,56128,56423,56128,56418,56128,56421,56128,56430,56128,56423,56128,56447,55356,57332,8203,56128,56423,8203,56128,56418,8203,56128,56421,8203,56128,56430,8203,56128,56423,8203,56128,56447);caseemoji:return!s(55357,56424,8205,55356,57212,55357,56424,8203,55356,57212)}return!1}(or),t.supports.everythingt.supports.everything&&t.supportsor,flag!or&&(t.supports.everythingExceptFlagt.supports.everythingExceptFlag&&t.supportsor);t.supports.everythingExceptFlagt.supports.everythingExceptFlag&&!t.supports.flag,t.DOMReady!1,t.readyCallbackfunction(){t.DOMReady!0},t.supports.everything||(nfunction(){t.readyCallback()},a.addEventListener?(a.addEventListener(DOMContentLoaded,n,!1),e.addEventListener(load,n,!1)):(e.attachEvent(onload,n),a.attachEvent(onreadystatechange,function(){completea.readyState&&t.readyCallback()})),(nt.source||{}).concatemoji?c(n.concatemoji):n.wpemoji&&n.twemoji&&(c(n.twemoji),c(n.wpemoji)))}(window,document,window._wpemojiSettings); /script> style>img.wp-smiley,img.emoji { display: inline !important; border: none !important; box-shadow: none !important; height: 1em !important; width: 1em !important; margin: 0 .07em !important; vertical-align: -0.1em !important; background: none !important; padding: 0 !important;}/style> link relstylesheet idwp-block-library-css hrefhttp://108tunes.com/wp/wp-includes/css/dist/block-library/style.min.css?ver5.7.12 mediaall />link relstylesheet idwp-block-library-theme-css hrefhttp://108tunes.com/wp/wp-includes/css/dist/block-library/theme.min.css?ver5.7.12 mediaall />link relstylesheet idparent-style-css hrefhttp://108tunes.com/wp/wp-content/themes/twentyfifteen/style.css?ver5.7.12 mediaall />link relstylesheet idtwentyfifteen-fonts-css hrefhttps://fonts.googleapis.com/css?familyNoto+Sans%3A400italic%2C700italic%2C400%2C700%7CNoto+Serif%3A400italic%2C700italic%2C400%2C700%7CInconsolata%3A400%2C700&subsetlatin%2Clatin-ext&displayfallback mediaall />link relstylesheet idgenericons-css hrefhttp://108tunes.com/wp/wp-content/themes/twentyfifteen/genericons/genericons.css?ver20201208 mediaall />link relstylesheet idtwentyfifteen-style-css hrefhttp://108tunes.com/wp/wp-content/themes/108tunes/style.css?ver20201208 mediaall />link relstylesheet idtwentyfifteen-block-style-css hrefhttp://108tunes.com/wp/wp-content/themes/twentyfifteen/css/blocks.css?ver20190102 mediaall />!--if lt IE 9>link relstylesheet idtwentyfifteen-ie-css hrefhttp://108tunes.com/wp/wp-content/themes/twentyfifteen/css/ie.css?ver20170916 mediaall />!endif-->!--if lt IE 8>link relstylesheet idtwentyfifteen-ie7-css hrefhttp://108tunes.com/wp/wp-content/themes/twentyfifteen/css/ie7.css?ver20141210 mediaall />!endif-->script srchttp://108tunes.com/wp/wp-includes/js/jquery/jquery.min.js?ver3.5.1 idjquery-core-js>/script>script srchttp://108tunes.com/wp/wp-includes/js/jquery/jquery-migrate.min.js?ver3.3.2 idjquery-migrate-js>/script>link relhttps://api.w.org/ hrefhttps://108tunes.com/wp-json/ />link relEditURI typeapplication/rsd+xml titleRSD hrefhttps://108tunes.com/wp/xmlrpc.php?rsd />link relwlwmanifest typeapplication/wlwmanifest+xml hrefhttp://108tunes.com/wp/wp-includes/wlwmanifest.xml /> meta namegenerator contentWordPress 5.7.12 />/head>body classhome blog wp-embed-responsive>!-- Google Tag Manager (noscript) -->noscript>iframe srchttps://www.googletagmanager.com/ns.html?idGTM-M8TQBW9height0 width0 styledisplay:none;visibility:hidden>/iframe>/noscript>!-- End Google Tag Manager (noscript) -->div idpage classhfeed site> a classskip-link screen-reader-text href#content>コンテンツへスキップ/a> div idsidebar classsidebar> header idmasthead classsite-header rolebanner> div classsite-branding> h1 classsite-title>a hrefhttps://108tunes.com/ relhome>Webディレクターの徒然/a>/h1> button classsecondary-toggle>メニューとウィジェット/button> /div>!-- .site-branding --> /header>!-- .site-header --> div idsecondary classsecondary> div idwidget-area classwidget-area rolecomplementary> aside idsearch-2 classwidget widget_search>form rolesearch methodget classsearch-form actionhttps://108tunes.com/> label> span classscreen-reader-text>検索:/span> input typesearch classsearch-field placeholder検索… value names /> /label> input typesubmit classsearch-submit screen-reader-text value検索 /> /form>/aside> aside idrecent-posts-2 classwidget widget_recent_entries> h2 classwidget-title>最近の投稿/h2>nav rolenavigation aria-label最近の投稿> ul> li> a hrefhttps://108tunes.com/2011/05/19/a-smartphone-may-be-suitable-for-reading/>スマートフォンは読み物に向いているかもしれない/a> /li> li> a hrefhttps://108tunes.com/2010/09/23/internet-cafe-is-recommended/>集中したいときはネットカフェがオススメ/a> /li> li> a hrefhttps://108tunes.com/2010/08/17/direction-at-banner-production/>バナー制作時のディレクション/a> /li> li> a hrefhttps://108tunes.com/2010/08/16/action-to-be-taken-when-understanding-can-not-be-obtained/>理解を得られないときの対処/a> /li> li> a hrefhttps://108tunes.com/2010/08/15/how-to-respond-when-it-is-likely-to-be-behind-delivery-schedule/>納期に遅れそうな時の対応方法/a> /li> /ul> /nav>/aside>aside idarchives-2 classwidget widget_archive>h2 classwidget-title>アーカイブ/h2>nav rolenavigation aria-labelアーカイブ> ul> li>a hrefhttps://108tunes.com/2011/05/>2011年5月/a>/li> li>a hrefhttps://108tunes.com/2010/09/>2010年9月/a>/li> li>a hrefhttps://108tunes.com/2010/08/>2010年8月/a>/li> li>a hrefhttps://108tunes.com/2010/07/>2010年7月/a>/li> li>a hrefhttps://108tunes.com/2010/06/>2010年6月/a>/li> li>a hrefhttps://108tunes.com/2010/03/>2010年3月/a>/li> li>a hrefhttps://108tunes.com/2010/02/>2010年2月/a>/li> /ul> /nav>/aside>aside idcategories-2 classwidget widget_categories>h2 classwidget-title>カテゴリー/h2>nav rolenavigation aria-labelカテゴリー> ul> li classcat-item cat-item-2>a hrefhttps://108tunes.com/category/direction/>direction/a>/li> li classcat-item cat-item-3>a hrefhttps://108tunes.com/category/memo/>memo/a>/li> li classcat-item cat-item-5>a hrefhttps://108tunes.com/category/z-other/>other/a>/li> li classcat-item cat-item-6>a hrefhttps://108tunes.com/category/tech/>tech/a>/li> /ul> /nav>/aside> /div>!-- .widget-area --> /div>!-- .secondary --> /div>!-- .sidebar --> div idcontent classsite-content> div idprimary classcontent-area> main idmain classsite-main rolemain> article idpost-157 classpost-157 post type-post status-publish format-standard hentry category-z-other> header classentry-header> h2 classentry-title>a hrefhttps://108tunes.com/2011/05/19/a-smartphone-may-be-suitable-for-reading/ relbookmark>スマートフォンは読み物に向いているかもしれない/a>/h2> /header>!-- .entry-header --> div classentry-content> p>同じコンテンツを、PCサイト、スマートフォンサイト、携帯サイトに展開する際、表示領域が異なるため、レイアウトやナビゲーションを工夫するのは当たり前ですが、スマートフォンは画面サイズ以外に、操作性が考慮のポイントになりそうです。/p>p>指で直感的に、表示領域の拡大/縮小ができるので、広告やナビゲーションなど、コンテンツを読むのに余分な要素をカットできます。商用ブログやポータルサイト系の読み物は、広告が表示されたり、そわそわする要素が多くて記事に集中出来ないことがあります。延々とループされるテレビCMのような広告だと、ブラウザサイズを調整したり、テキストエディタに記事をコピー＆ペーストして読むこともありました。br />またスクロールが簡単なので、ページ送りが自分の感覚とマッチしていると思います。PCではマウスのホイールが実装されたときは大変便利になったと感じましたが、MacBook のスライドパットを使い始めて、サイトを閲覧する際にはマウスより使いやすいことが実感できました。/p>p>さらに、スマートフォンでは画面上を指でスライドさせる操作が、本を読んでいる感覚に近くて、メールや記事を読むには親和性がよいのではと感じています。br />携帯（ガラケー）サイトも表示領域の制限で、テキストのみの記事が多いのですが、スクロールさせる操作感や不自然な半角文字に慣れることができず（ケータイ小説はどうしても読む気にはなれませんでしたが慣れかもしれません）、いまだに外出時の非常手段程度にしか利用していません。br />少し前までスマートフォンは移動中にチェックするデバイスとして利用していましたが、最近では自宅のリビングでメールをチェックしたり、ブラウザで調べ物も行うようになりました。br />スマートフォンの出現で、Flashなどリッチコンテンツのあり方も見直しされていますし、これからもインターフェイスも進化していくはずなので、制作に関わる人間として、情報を伝えるベストプラクティスを模索しつづけることが大切と思います。/p> /div>!-- .entry-content --> footer classentry-footer> span classposted-on>span classscreen-reader-text>投稿日: /span>a hrefhttps://108tunes.com/2011/05/19/a-smartphone-may-be-suitable-for-reading/ relbookmark>time classentry-date published updated datetime2011-05-19T15:01:50+09:00>2011-05-19/time>/a>/span>span classcat-links>span classscreen-reader-text>カテゴリー /span>a hrefhttps://108tunes.com/category/z-other/ relcategory tag>other/a>/span> /footer>!-- .entry-footer -->/article>!-- #post-157 -->article idpost-151 classpost-151 post type-post status-publish format-standard hentry category-memo> header classentry-header> h2 classentry-title>a hrefhttps://108tunes.com/2010/09/23/internet-cafe-is-recommended/ relbookmark>集中したいときはネットカフェがオススメ/a>/h2> /header>!-- .entry-header --> div classentry-content> p> /p>p>Webのディレクションとは直接関係ない話だが、Webディレクターの活動として最近気付いたことなので紹介します。/p>p>オフィスでは話掛けられたり電話がなったりと、気が散る要素がたくさんあります。/p>p>ディレクターの仕事上、コミュニケーションは大事なのですが、考え事をすることが多いです。br />特にプランニングしたり情報を整理しているときなど、集中したいのですが、ちょっとした雑音や中断で、考えていたことが消えてしまうことがあります。br />考え事をするときは、ヘッドフォンをすることが多いのですが、やっぱり落ち着かないです。/p>p>そんな時は、カフェなど外部スペースを利用しています。/p>p>電源が使えて無線LAN環境があるa hrefhttp://www.ginza-renoir.co.jp/renoir/index.htm target_blank relnoopener noreferrer>ルノアール/a>を使っています。br />隣の席と余裕があって打合せもできるし、コーヒーを注文した後、適宜お茶など出してくれたりするので、割と長時間居られるので重宝しています。br />ただ1人で数時間居座るのは、ちょっと気が引けてきますし、アイスコーヒー1杯560円なので数杯注文するのも、ちょっと辛い感じです。/p>p>隣のうるさかったり、壁際に座れないと後ろが気になったり、落ち着けない状況になることもありました。br />あと、セキュリティ上、資料が広げにくかったりと気になる要素はあります。/p>p>最近ではネットカフェを利用しています。/p>p>昔は趣味で「まんが喫茶」に行ってました。その頃は、インターネット回線や個室もなく、マンガを読むこと＆ちょっとした仮眠程度の利用でした。br />その後、「ネットカフェ難民」などのコトバも出てきて、ネガティブな印象でした。br />知り合いに、静かなネットカフェもあると聞いて、試しにa hrefhttp://www.bagus-99.com/netcafe/store/yasukuni.html target_blank relnoopener noreferrer>グラン・サイバーカフェ：靖国通り店/a>を利用したところ、とても良かったです。/p>p>個室で仕切りがあって、椅子も座り心地がよく（フラットシートもある）、電源も使えて、ドリンク飲み放題。br />1時間400円で、3時間パックで1000円程度。br />何といっても、とても静か。キーボードのタッチ音が気になるくらい静かです。/p>p>インターネット端末はもちろん、無線LANもありますが、ウイルス感染やパスワード漏洩などが怖いので、持ち込みのノートパソコンとPocket Wifiを使っています。/p>p>他のネットカフェも試してますが、上記の店が綺麗（他の店はタバコやいろんな匂いが・・・）だし、一番良さそうです。/p>p>あとは、移動タイミングなどで、少しネットを使いたいときなど使えそうです。br />30分180円というネットカフェもありました。/p>p>これからも利用が増えそうなので、調査したいと思います。/p>p>サテライトオフィスを考えている方、固定費が掛からないネットカフェも意外と使えるかもしれません。/p> /div>!-- .entry-content --> footer classentry-footer> span classposted-on>span classscreen-reader-text>投稿日: /span>a hrefhttps://108tunes.com/2010/09/23/internet-cafe-is-recommended/ relbookmark>time classentry-date published updated datetime2010-09-23T18:52:04+09:00>2010-09-23/time>/a>/span>span classcat-links>span classscreen-reader-text>カテゴリー /span>a hrefhttps://108tunes.com/category/memo/ relcategory tag>memo/a>/span> /footer>!-- .entry-footer -->/article>!-- #post-151 -->article idpost-146 classpost-146 post type-post status-publish format-standard hentry category-direction> header classentry-header> h2 classentry-title>a hrefhttps://108tunes.com/2010/08/17/direction-at-banner-production/ relbookmark>バナー制作時のディレクション/a>/h2> /header>!-- .entry-header --> div classentry-content> p>シンプルな制作案件でも押さえるポイントがあります。br />広告バナーをたくさん制作するという案件を例にします。/p>p>前提として、メディア展開プランや構成要素のFIXを代理店側で対応し、静止画やFlashを作成する、という案件を想定しています。/p>p>作業や品質の大部分はデザイナーの力量に掛かってしまいますが、ディレクターとして気にするポイントは以下です。/p>p>・納期を確認するbr />・要件を確認するbr />・素材を確認する/p>p>「納期を確認する」/p>p>代理店から依頼がある制作案件は、スケジュールが非常にタイトなことがあります。制作側の感覚では、早く伝えてくれればよいのに、、、と思うことがしばしばありますが、制作サイドに落ちてくる前に沢山の調整があったりで時間を要することが当たり前のようです。br />メディア枠の購入が急遽決まることもあるため、バナー制作案件は、タイトなスケジュール前提で心構えをしていた方がよいと思います。/p>p>まず依頼された段階で、制作ボリュームとスケジュールを比較して対応可能かどうかの判断が必要です。/p>p>無理なスケジュールは断ることも選択肢ですが、納期を調整できる場合があります。br />通常は、以下のようなやりとりです。br />制作ベンダー ←→ 代理店 ←→ クライアント＆メディア/p>p>代理店やクライアント側で納期までのスケジュールに余裕をもっている場合があります。/p>p>メディアの納期は、掲載期間との兼ね合いがあるため、調整できないことが普通なのですが、br />代理店＆クライアントとメディアのパワーバランスで調整して頂く事もあります。/p>p>制作側としては、提示されたスケジュールに調整の余地があるかどうか、まず確認した方がよいです。/p>p>「要件を確認する」/p>p>ここでの「要件」とは、制作内容そのものなので、シンプルなのですが、注意すべきポイントがあります。/p>p>まず、提示された構成要素や指示内容が確定内容なのか把握しておくことです。br />何と代理店側の見切りで依頼がくることがあります。/p>p>明らかに指示が曖昧な場合は、すぐに分かりますが、指示内容から読み取れないこともあります。br />イメージの認識あわせのためにも、確認ポイントがあり、br />・バナーをクリックした際の遷移先ページのデザインbr />・他のメディアとの連動キャンペーンの場合のトーン＆マナーbr />・一番訴求したい要素は何か？br />をヒアリングします。/p>p>代理店担当に矛盾があったり、考えがブレていたら要注意です。br />作り込みをする前にラフで組んでみて、方針を確認した方が全体工数が低減できますし、修正負荷によるクリエーターのストレス度合いもおさえられます。/p>p>また大事なポイントは、広告のレギュレーションの確認です。br />サイズ、容量、フォーマット、枠線の有無・色・幅、ブランドロゴ・商品名の掲載、文字の可読性など、媒体によって様々です。br />Yahoo！の広告規定は公開されており、他の媒体のベースになっていることがあるので目を通しておくと、他の媒体にも応用できると思います。br />改訂されることもあるので、最新版かどうか、レギュレーションの適用期間など確認した方がよいです。br />特に、Flashバナーについては細かい規定があるので、制作前にクリエーターに理解してもらわないと制作できません。br />Yahoo！の場合は、チェックツールが提供されているほか、実際にFlaファイルレベルでチェックされることもあるようです。/p>p>モバイルサイトのバナー制作は、容量との勝負になることが多いです。br />MacとWindowsの計算違いによりNGとなったことがあります。Windowsのファイル容量を基準とした方が無難です。/p>p>バナーの構成要素がレギュレーションを満たしてないことがあるので、早めの確認が必要です。/p>p>「素材を確認する」/p>p>バナー制作で素材の確認は必須です。br />代理店から提供されることが大前提ですが、細かくチェックしてないこともあるため、何となく揃っているような気分で制作を開始すると足りないことがあります。ほとんどの場合、制作期間がタイトなので慌てます。/p>p>画像は見てすぐ分かるのですが、フォントについては見逃すことがあります。br />ロゴのように使われてる場合は同じフォントが必要ですし、ない場合はアウトライン化して提供してもらわないといけません。br />似たフォントの代用でもOKな場合もあるため、文字要素の確認は必要です。/p>p>継続的にバナー制作案件を受注する場合は、事前に必要なフォントを確認した方が良いと思います。/p>p>以上のポイントを押さえたら、あとの作業は、クリエーターの力量に依存します。br />制作会社のディレクターの好みで中途半端にディレクションすると、時間が足りなくなることが多いため、最低減の確認に留め、代理店からのフィードバックを待った方がよいと思っています。（これはディレクターの流儀で個人差があると思います）/p>p>代理店に提出する前に確認するポイントは、br />・レギュレーションを守っているかbr />・構成要素に過不足はないかbr />・文字や画像の可読性は大丈夫かbr />です。/p>p>上記を満たしていれば、デザイン上、多少気になる箇所を見つけても、代理店に確認に出した方がよいです。br />自分の主観かもしれないし、代理店やクライアントは別の意図があるのかもしれません。br />どうしても気になる場合は、懸念点や迷った点を伝えた上で、判断を求めた方がスムーズに行くと思います。/p>p>ディレクターとして避けたいのは、何度も何度も修正を行って、クリエーターを疲弊させることです。br />微妙な指示を繰り替えすと、クリエーターは考えることを止めて、指示通りに手を動かすだけになってしまいます。br />最終段階の微調整は仕方ないですが、なるべくクリエーターが楽しく取り組める状況を保持することが大切と思います。/p> /div>!-- .entry-content --> footer classentry-footer> span classposted-on>span classscreen-reader-text>投稿日: /span>a hrefhttps://108tunes.com/2010/08/17/direction-at-banner-production/ relbookmark>time classentry-date published updated datetime2010-08-17T02:12:16+09:00>2010-08-17/time>/a>/span>span classcat-links>span classscreen-reader-text>カテゴリー /span>a hrefhttps://108tunes.com/category/direction/ relcategory tag>direction/a>/span> /footer>!-- .entry-footer -->/article>!-- #post-146 -->article idpost-140 classpost-140 post type-post status-publish format-standard hentry category-direction> header classentry-header> h2 classentry-title>a hrefhttps://108tunes.com/2010/08/16/action-to-be-taken-when-understanding-can-not-be-obtained/ relbookmark>理解を得られないときの対処/a>/h2> /header>!-- .entry-header --> div classentry-content> p>仕事に限らず、他人から理解を得られないときがあります。/p>p>理解してもらう努力をするのは当然ですが、根本的に価値観が違っている場合は、理解を得ることが難しい場合があります。（私の場合は、理解されないケースが多い自覚があります（笑））/p>p>特に、Web制作においては、最初からクライアントの理解を得られないことがあると思います。完成のイメージができてない、または完成後の影響度について想像が追いつかないことがあるからです。/p>p>クライアントによかれ、だったり、認識違いによる双方のリスクヘッジのために、制作前に理解を得ようとするのは当たり前なのですが、しつこくやると「ガツガツしている」とか、理解できないことへのストレスからネガティブな印象を持たれて、後の進行に影響を及ぼすことがあります。/p>p>「説明責任」という言葉があり、説明することは大事なのですが、理解を得るのとは別のことだと思います。双方、納得できるのが理想の状態ですが、必ずしも実現できるとは限りません。/p>p>Web制作の例で考えてみると、「SEO対策に最適なサイト構築」という命題があった場合、本来であればHTML構造も重要で、記述の順序についても、事前の理解が必要です。なぜなら、SEO対策は検索エンジンに依存する部分があり、恒久的な対策は難しく、実施範囲やその効果について理解を得られないと、クレームがくることが予想されるからです。また、外部対策を得意とするベンダーと内部対策を得意とするベンダーではアプローチが異なり、クライアントの担当者が余程勉強していない限り、すべてを理解してもらうことは難しいです。/p>p>あとは、実質的に工数の問題があると思います。説明して納得してもらうのも工数が掛かるのですが、営業行為として認めてくれないケースもあります。継続的に運用案件や改修案件をいただくことがあるので、状況により判断する必要があります。/p>p>いろいろな状況がある前提なのですが、理解を得られず煮詰まるほど苦しい時があります。/p>p>プロジェクトを進めることができなかったり、煮詰まりすぎて精神や体調にまで影響を及ぼす場合は、対処策を考えないと自滅してしまいます。/p>p>以下のように考えてみます。/p>p>「なぜ理解されないんだろう？」/p>p>これは考えても無駄かも。理解されないんだから。自分なりにやり尽くした感があれば、先には進まない事が多いです。/p>p>「理解を得ると何が嬉しいか？」/p>p>理解された先に何が待っているのか考えてみます。よく考えると、自己顕示欲だったり自己満足だったりすることがあります。/p>p>相手にとって価値がない（と信じている）ことは、理解する努力をしてくれないことも多いです。/p>p>「どこまで理解される必要があるか？」/p>p>大切なポイントです。通常の状態でも１００％の理解を得るのはそもそも困難です。/p>p>なぜ理解をして欲しいのか、が明確になれば、どこまで理解されると支障がないのか線引きが見えてくるはずです。/p>p>理解されないとリスクが大きい場合は、プロジェクトを止めたり、案件そのものを辞退する必要もあります。/p>p>「いつまでに理解を得る必要があるのか？」/p>p>理解してもらう為には、共通の経験が必要だと思っています。/p>p>まず独自でやってみて、計画的に情報を小出しにして、段階的に理解を得るのがよいかもしれません。/p>p>時間が解決してくれることもありますし、拒絶された場合は、最終的に理解を得られなくても、実現できることもあります。/p>p>まとめると、理解を得たい側が、理解を得る行為の価値を判断して、完成時、完成後の影響度がイメージすることが重要です。/p>p>以下、煮詰まった時の対処方法について、キーワードをピックアップします。/p>p>煮詰まった状況を打開するには多角的に検討する必要があり、以下に含まれるネガティブな単語はあくまで推奨ではありません。/p>p>それぞれの行為を行ったときに、どのような結果になるのか想像できることが大事だと思います。/p>p>・コミュニケーションを深める/p>p>・説得する/p>p>・根気強く説明する/p>p>・うまく説明する/p>p>・教育する/p>p>・手をかえる/p>p>・時間が解決するのを待つ/p>p>・妥協点を探る/p>p>・表面上、話をあわせる/p>p>・ごまかす/p>p>・諦める/p>p>・離れる/p>p>・無視する/p>p>・そっとしておく/p>p>・他のことをする/p> /div>!-- .entry-content --> footer classentry-footer> span classposted-on>span classscreen-reader-text>投稿日: /span>a hrefhttps://108tunes.com/2010/08/16/action-to-be-taken-when-understanding-can-not-be-obtained/ relbookmark>time classentry-date published updated datetime2010-08-16T07:00:40+09:00>2010-08-16/time>/a>/span>span classcat-links>span classscreen-reader-text>カテゴリー /span>a hrefhttps://108tunes.com/category/direction/ relcategory tag>direction/a>/span> /footer>!-- .entry-footer -->/article>!-- #post-140 -->article idpost-120 classpost-120 post type-post status-publish format-standard hentry category-direction> header classentry-header> h2 classentry-title>a hrefhttps://108tunes.com/2010/08/15/how-to-respond-when-it-is-likely-to-be-behind-delivery-schedule/ relbookmark>納期に遅れそうな時の対応方法/a>/h2> /header>!-- .entry-header --> div classentry-content> p>Web制作に限らないと思いますが、受託業務では、納期に遅れそうなことが起きてしまいます。理由は様々ですが、特にWeb制作に関しては、公開間近までクライアント側と制作者との完成イメージのズレから、ほぼ出来た状態から修正が発生することが多いと思います。/p>p>納期が遅れそうな場合、制作ディレクターが調整をすることになります。br />この調整の仕方により、クライアントやクリエーターからの評価が大きく分かれると思っていますし、ディレクターの手腕の見せ所のひとつです。br />本来は遅れないことがベストなのですが、作業度合いによっては、如何ともしがたい場合があります。/p>p>顧客至上主義のタイプだったり、調整が苦手なディレクターだったりすると、100％クライアントの要求を実現すべく、クリエーターに圧力を掛けることがありますが、根性論では乗り切れない事態に対する策は必要です。/p>p>私の経験上、いくつか押さえるポイントがあります。/p>p>まずは制作側の現状を正確に把握しましょう。br />現時点でどのくらいできているのか、要件を満たすまでにどのくらいの作業が残っているのか、いつ頃だったら完成できるのか、遅れた要因は何だったのか、懸念点は何なのか、そもそも完成できるスキルを持っているのか、、、、などです。br />一般的なプロジェクト管理では、定期的に進捗を確認しながら問題は早期発見というのが理想なのですが、制作側から正しい情報が報告されているとは限りません。特に、プログラム開発プロジェクトより、Web制作については、工数の読みが甘かったり、担当者のスキルに依存する部分が多く、納期前に判明することが多い気がします。/p>p>この時点では、感情論で何とかなる余地はなく、冷静に現状把握に全力を入れます。br />クリエーター側から「あと少しで何とかする」という回答のみで、現状を公開しないタイプもいます。ですが、余程信頼しているクリエーターでない限り、一旦作業を止めさせて、現状ヒアリングした方がよいと思います。/p>p>情報を集めた時点で、ボンヤリとでも、スケジュール感、完成イメージと段階リリースの構想を作っておくことが重要です。次に述べる、クライアントとの調整前に、現プロジェクトの潜在力を掴んでおかないと、調整後も同じ失敗をすることがあります。/p>p>次に、クライアントが最低減到達したい内容を把握します。br />納期が遅れる非を謝罪しつつも、クライアント側の要求に無理がある旨を説明します。br />たいていの担当者は怒りますが冷静になるまで待ち、ヒアリングします。納期ギリギリに遅延連絡をすると対応策の選択肢がなくなるため、危ないなあと感じた時点で早めに情報を伝えることが大事です。/p>p>優先度を確認しましょう。br />公開期日を守るのが優先なのか、要件を万全にするのが優先なのか、など状況によって異なります。br />製品発表のニュースリリースなど、Web以外の要因と絡んでいる場合は、公開期日が最優先です。ほとんどの場合、タイミングを遅延させることはNGです。br />開発絡みでサービス品質を重視するプロジェクトは、多少公開を遅らせても要件を満たすことが最優先となることもあります。またクライアント側の試験運用期間がある場合は、運用側が習得すべき内容を把握して、期日と機能を調整していきます。/p>p>クライアントと優先度の認識共有ができたら、段階リリースについて相談をしましょう。br />Webサービスは、公開までのスピード感が早いので、完全版を一気に公開しなくてもクライアントの要件を満たすことが多いです。残念ながら、双方にこの認識があるため、直前の修正や仮納品、公開後の差し替えなどが一般化していると思うのですが、そういう文化なのかもしれないと感じています。受託のプロとしては失格かもしれませんが、案件の内容が複雑化していて工数が読みづらかったり、クライアントの発注責任上の相応の知識が不足している場合があり、完全に受託側が悪い、という状況ではないケースが多いような気がします。br />段階リリースは、クライアントの要件を満たす策としてはアリなのですが、よくあるパターンとして、要望が追加されたり、更新が発生して公開時の確認工数が増えたり、制作側の工数が増えてしまうことがあるので、案件のコントロールが重要です。最初から嫌な予感がするプロジェクトは、工数算出する際に積んでおくことも一つの解決策です。/p>p>状況によっては、クライアント窓口担当の上司・社長向けの報告・パフォーマンス向けに、報告書などの作成が必要になる場合があります。この場合は、クリエーターの資源を使うのは本末転倒なので、ディレクターが対応すべきです。例えクリエーターの責任で遅延した場合でも、ディレクターが対応することのメリットがあります。プロジェクト全体としての進行が止まらないこと、クリエーターとの関係性が良くなることが多いことです。/p>p>優先度を確認したら、クリエーター（コーディング、プログラムなど関係者一同）に対して、クライアントとの調整結果を共有します。br />妥当なスケジュールだった場合は、関係者一同で頑張るだけですが、その策に無理がある場合も予想されます。br />無理が判明した時点で、クライアントに相談します。ここで時間を空けてしまうと最悪な事態になります。対応が後手後手になってしまうと、クライアントに迷惑を掛けてしまうだけでなく、プロジェクトのモチベーション低下、品質が悪くなったり、公開後に瑕疵責任という形で無償対応を余儀なくされたり、賠償問題を持ちかけられたり、、、と悪い方向になります。br />スケジュールが妥当かどうか確信がもてない場合は、クライアントとコミットするのは避けましょう。持ち帰り判断とさせてもらうか、その場でクリエーターに確認した方がよいです。/p>p>クライアント側、制作側と調整ができたら、再度情報を共有します。br />スケジュール表でもテキストでもよいので、関係者にメールでを展開するのは一般的ですが、一方的な連絡事項として投げっぱなしにすると、トラブルになることがあります。br />調整役のディレクターが思っているほど、クライアントも制作側も認識していないことが多い気がします。br />証拠としてメールを送るのは重要ですが、最重要なのは認識してもらうことです。br />特にメールの返信にて、重要な箇所に触れてないことがあります。見てないのか、潜在意識が働いて見てないフリをしている場合もあるので、危ないなあ、と思う場合は、打合せや電話で確認した方がよいです。/p>p>関係者一同が共通認識が持てたら、納期調整のディレクションは完了です。br />あとは品質チェックを甘くしないように気を配りながら、納品までプロジェクトをコントロールします。/p>p>納期調整も一種のトラブルシューティングですが、ディレクターとしては日頃から気をつけておくことがあります。br />クライアントの要件を把握するのは当たり前ですが、クリエーターとの信頼関係が重要です。br />重要なプロジェクトで組むクリエーターの実力を把握しておいたり、他のプロジェクトを掛け持ちしている場合の稼働時間や、完成させるまでのプロセスのクセ（設計重視だったり、作りながら考えるタイプだったり様々）を掴んでおくと、いざというときに安心して取り組むことができます。/p>p>番外編として、br />実際に見たよくない例を紹介します。br />クライアント側の担当者が遅延を気にして社内報告（おそらく上司）のためだけに、制作ディレクターに問い合わせをbr />するのは当然ですが、連絡頻度が半端ではなく、30分毎に確認をしていました。受けたディレクターは、その度にクリエーターに「いつできる？」と確認の電話を続け、クライアント側へ報告していました。笑い話のようですが、プレッシャーに耐えられないディレクターはそのような行動を取ってしまいます。br />結果的に、クリエーターの作業を分断することになります。クリエーターの作業を分断することは、単純に時間の切り取りでは計れません。集中力を再構築したり、アタマの中の構想が消えてしまったりと、分断前の状態に戻すのに時間が掛かります。フロント側のディレクターがクリエーターの環境を考慮すべきです。br />クリエーターが遅れている場合に責任転嫁したい気持ちは分かりますが、報告するだけの確認行為は、余程重要なタイミングではない限り無意味なので、ディレクターとしては避けたいものです。/p> /div>!-- .entry-content --> footer classentry-footer> span classposted-on>span classscreen-reader-text>投稿日: /span>a hrefhttps://108tunes.com/2010/08/15/how-to-respond-when-it-is-likely-to-be-behind-delivery-schedule/ relbookmark>time classentry-date published updated datetime2010-08-15T17:17:16+09:00>2010-08-15/time>/a>/span>span classcat-links>span classscreen-reader-text>カテゴリー /span>a hrefhttps://108tunes.com/category/direction/ relcategory tag>direction/a>/span> /footer>!-- .entry-footer -->/article>!-- #post-120 -->article idpost-107 classpost-107 post type-post status-publish format-standard hentry category-direction> header classentry-header> h2 classentry-title>a hrefhttps://108tunes.com/2010/07/17/the-problem-to-be-solved-is-something-in-the-first-place/ relbookmark>解決すべき問題はそもそも何かを考える/a>/h2> /header>!-- .entry-header --> div classentry-content> p>大前研一 BOT（@ohmaebot）で、以下のつぶやきがあった。/p>blockquote>p>日本人は「どこか自分の外側に答がある」と勘違いしている。そのため、何か困ったことに突き当たると、最初から「この問題の答はどこにあるのか、何なのか」と考えてしまう。自分が「解決すべき問題はそもそも何か」を考えずに、目先の問題への答えばかりを見つけようとする。/p>/blockquote>p>なるほどなあ、自省。/p> /div>!-- .entry-content --> footer classentry-footer> span classposted-on>span classscreen-reader-text>投稿日: /span>a hrefhttps://108tunes.com/2010/07/17/the-problem-to-be-solved-is-something-in-the-first-place/ relbookmark>time classentry-date published updated datetime2010-07-17T00:55:26+09:00>2010-07-17/time>/a>/span>span classcat-links>span classscreen-reader-text>カテゴリー /span>a hrefhttps://108tunes.com/category/direction/ relcategory tag>direction/a>/span> /footer>!-- .entry-footer -->/article>!-- #post-107 -->article idpost-104 classpost-104 post type-post status-publish format-standard hentry category-direction> header classentry-header> h2 classentry-title>a hrefhttps://108tunes.com/2010/07/05/be-careful-with-hearing/ relbookmark>ヒアリングで気をつけること/a>/h2> /header>!-- .entry-header --> div classentry-content> p>ヒアリングをするときは、相手の意図を確認する事が重要。発言内容の表面だけを要件として受け止めてしまうと、後々ズレてくることが多い。というのは、相手が自分の意図を正しく伝える技術を持っていない事が多いからだ。/p>p>相手の発言を聞いた際、自分の経験を思い返して違和感があれば、早めに解消した方がよい。たぶん、相手のやりたいことを具体的にイメージした上で伝えているわけでなく、具現化していく課程で認識が間違っていることに気付くことが多いはず。/p>p>そんなときは、自分なりの解釈を加えて、相手との問答を想定しながら組み立てていく。自分の意図を説明した上で、認識あわせをするのがよいと思う。説明するのに要する労力は掛かってしまうが、ズレに気付いて後から修正するより総体的に見て近道となる。/p>p>相手の意図を確認する、というのは想像力が必要となる。質問の仕方や自分の知識などテクニカルな要素は必要であるが、基本は、/p>ul>li>なぜ、そのような事を言っているのか？/li>li>具現化していくと何が起きるのか？/li>/ul>p>を突き詰めていくと、意図が見えてくると思う。/p>p>さらに、意図の理由固めを行うことでより強固になる/p>ul>li>一般論/li>li>業界、同業他社、類似案件/li>li>特殊性/li>/ul>p>など、いくつかの切り口で裏を取る作業を行うと、対外的な説得力が増すので、認識のズレを解消できる。/p>p>話の意図が見えない場合は、案件としての目的が定まってなかったり、個人的見解に偏っていることが多い。個人的見解も大事だが、他人に受け入れられないことが多い。/p>p>ヒアリング段階で、単に相手の話を聞くことが着地点ではなく、ヒアリング後のアクションをイメージしながら、足りない要素を引き出し、場合によってはその場で作り上げる行為ができるとよい。後工程がやりやすくなる。/p> /div>!-- .entry-content --> footer classentry-footer> span classposted-on>span classscreen-reader-text>投稿日: /span>a hrefhttps://108tunes.com/2010/07/05/be-careful-with-hearing/ relbookmark>time classentry-date published updated datetime2010-07-05T13:53:46+09:00>2010-07-05/time>/a>/span>span classcat-links>span classscreen-reader-text>カテゴリー /span>a hrefhttps://108tunes.com/category/direction/ relcategory tag>direction/a>/span> /footer>!-- .entry-footer -->/article>!-- #post-104 -->article idpost-103 classpost-103 post type-post status-publish format-standard hentry category-direction> header classentry-header> h2 classentry-title>a hrefhttps://108tunes.com/2010/06/18/when-requirement-becomes-complicated/ relbookmark>要件が複雑になるとき/a>/h2> /header>!-- .entry-header --> div classentry-content> p>要件が必要以上に複雑になるなあ、と感じるのは受託業務をしていてよくある風景である。/p>p>何かやりたい（状況的にやらざるを得ないとき）が、目的が不明瞭か、内向き（上司や社内）にある場合、機能拡充に目を向ける傾向があると思う。/p>p>必要性に質問すると、ニッチな状況を例として挙げて「こういう場合、どのような対策をお考えですか？」と逆質問で切り替えされることが多い。注意文や免責文など掲載したり、発生確率が少なければ人的対応の余地を残しておいても問題ない範囲、と私は思ったりするのだが、全自動化にこだわる担当もいらっしゃる。/p>p>IT技術が好きで、熱心に勉強されている担当者がこの傾向にあるように思う。「ITのプロに発注するけど、自分の方がよく知っている」というオーラを全面に出す方もいる。用語をよくご存じで、この時期だったら「HTML５を使った面白い提案はないですか？」というツール決め打ちで、考えを組み立てる傾向があったりする。/p>p>勉強熱心だったり、利用想定を細かく洗い出す想像力は素晴らしいのであるが、サイトやシステムを構築する目的や運用まで加味した費用対効果、関係者（発注側は当然、受注側も含まれる）のリソース配分などを総体的にみると、こだわるポイントではないなあ、と感じることがある。/p>p>受託側の立場でいうのも何だが、IT技術は何かをするためのツールでしかないので、目的が不明瞭な要件については、実現手段は何でもよいと思っている。制作したツールを使って何を実現したいか？ではなくツールを制作する行為自体が目的になっている場合は、要件定義を曖昧のまま設計の話題で盛り上がるのだが、何か出来てきて、リリース間近になるとブレ始めて、リリース前から追加や改修依頼が発生してしまう。/p>p>要件が途中で変動しない場合でも、受注側が「ズレている」と感じるポイントにコダワリが強いと、制作側のモチベーションが堅くなるので、ちょっとしたサービス提案を控えてしまうことになる。「言われた通りにやったけど、イマイチ何をしたいのか分からないし、やっぱり微妙〜」と思いながらリリースを迎えることになる。/p>p>でも発注側（というか多くの場合、窓口担当者）が満足すればよい、という概念が双方にあるため、受注側は意見があっても言わないことが多い。代わりに、要件が少しでも増えると拒絶をすることになる。「1ページ増えたから、○○円かかります」とかつまらない交渉になる。/p>p>要件確認の際、実施内容の目的や成功の定義を、受発注双方で共有することが幸せな展開になるのは間違いない。ただシステム化を伴わないウェブサイトは効果を数量化するのが難しいので、アクセス解析やコンバージョンなどという考え方を意識してもらい、リリース後にも関与できるような取り組み方をするのがよい。当初は要件をシンプルにして、本当に必要な部分だけをリリースし、様子を見つつ次の段階を一緒に考えるような取り組み方が、ウェブをつかったツールには合っていると思う。/p> /div>!-- .entry-content --> footer classentry-footer> span classposted-on>span classscreen-reader-text>投稿日: /span>a hrefhttps://108tunes.com/2010/06/18/when-requirement-becomes-complicated/ relbookmark>time classentry-date published updated datetime2010-06-18T16:45:18+09:00>2010-06-18/time>/a>/span>span classcat-links>span classscreen-reader-text>カテゴリー /span>a hrefhttps://108tunes.com/category/direction/ relcategory tag>direction/a>/span> /footer>!-- .entry-footer -->/article>!-- #post-103 -->article idpost-102 classpost-102 post type-post status-publish format-standard hentry category-tech> header classentry-header> h2 classentry-title>a hrefhttps://108tunes.com/2010/06/18/longitude-latitude/ relbookmark>緯度経度/a>/h2> /header>!-- .entry-header --> div classentry-content> p>緯度経度の測定方法には、日本測地系と世界測地系というのがあるらしい。/p>p>また、表記方法にも、度／度分秒／秒などあるので、ややこしい。/p>p>「秒」で書かれた日本測地系のリストから、世界測地系に変換する際、国土地理院のa hrefhttp://vldb.gsi.go.jp/sokuchi/tky2jgd/ target_blank relnoopener noreferrer>Web版TKY2JGD/a>というサイトを使ってみた。/p>p>そのまま秒を入れると、NG。/p>p>—————br />計算結果/p>ul>li>北緯の値が適当でありません。/li>li>東経の値が適当でありません。/li>/ul>p>—————/p>p>秒を、度にするため3600で割って入力したら、同じエラー画面が。。。/p>p>よく見ると/p>p>—————/p>p>緯度経度の入力例：/p>pre> 35°12′15.3″ → 351215.3 141°29′35.4″ → 1412935.4/pre>p>—————/p>p>っと、とてもわかりづらい。/p>p>まあ、専門家がみれば分かるんだろうけど、興味を持った素人にはハードルが高いなあ。/p> /div>!-- .entry-content --> footer classentry-footer> span classposted-on>span classscreen-reader-text>投稿日: /span>a hrefhttps://108tunes.com/2010/06/18/longitude-latitude/ relbookmark>time classentry-date published updated datetime2010-06-18T12:33:44+09:00>2010-06-18/time>/a>/span>span classcat-links>span classscreen-reader-text>カテゴリー /span>a hrefhttps://108tunes.com/category/tech/ relcategory tag>tech/a>/span> /footer>!-- .entry-footer -->/article>!-- #post-102 -->article idpost-101 classpost-101 post type-post status-publish format-standard hentry category-direction> header classentry-header> h2 classentry-title>a hrefhttps://108tunes.com/2010/03/12/how-to-check-if-it-is-transmitted/ relbookmark>伝わっているか確認する方法/a>/h2> /header>!-- .entry-header --> div classentry-content> p>メール、電話、対面、理解度を試す質問、議事録br />繰り返し、チェック方法、スキルの見極め、言語の見極め、本人にとっての重要度、相手にとっての重要度。優先度、価値観。/p> /div>!-- .entry-content --> footer classentry-footer> span classposted-on>span classscreen-reader-text>投稿日: /span>a hrefhttps://108tunes.com/2010/03/12/how-to-check-if-it-is-transmitted/ relbookmark>time classentry-date published updated datetime2010-03-12T16:16:12+09:00>2010-03-12/time>/a>/span>span classcat-links>span classscreen-reader-text>カテゴリー /span>a hrefhttps://108tunes.com/category/direction/ relcategory tag>direction/a>/span> /footer>!-- .entry-footer -->/article>!-- #post-101 --> nav classnavigation pagination rolenavigation aria-label投稿> h2 classscreen-reader-text>投稿ナビゲーション/h2> div classnav-links>span aria-currentpage classpage-numbers current>span classmeta-nav screen-reader-text>ページ /span>1/span>a classpage-numbers hrefhttps://108tunes.com/page/2/>span classmeta-nav screen-reader-text>ページ /span>2/a>a classnext page-numbers hrefhttps://108tunes.com/page/2/>次ページ/a>/div> /nav> /main>!-- .site-main --> /div>!-- .content-area --> /div>!-- .site-content --> footer idcolophon classsite-footer rolecontentinfo> div classsite-info> a hrefhttps://ja.wordpress.org/ classimprint> Proudly powered by WordPress /a> /div>!-- .site-info --> /footer>!-- .site-footer -->/div>!-- .site -->script srchttp://108tunes.com/wp/wp-content/themes/twentyfifteen/js/skip-link-focus-fix.js?ver20141028 idtwentyfifteen-skip-link-focus-fix-js>/script>script idtwentyfifteen-script-js-extra>var screenReaderText {expand:span class\screen-reader-text\>\u30b5\u30d6\u30e1\u30cb\u30e5\u30fc\u3092\u5c55\u958b\/span>,collapse:span class\screen-reader-text\>\u30b5\u30d6\u30e1\u30cb\u30e5\u30fc\u3092\u9589\u3058\u308b\/span>};/script>script srchttp://108tunes.com/wp/wp-content/themes/twentyfifteen/js/functions.js?ver20171218 idtwentyfifteen-script-js>/script>script srchttp://108tunes.com/wp/wp-includes/js/wp-embed.min.js?ver5.7.12 idwp-embed-js>/script>/body>/html>
Port 443
HTTP/1.1 200 OKDate: Thu, 31 Oct 2024 07:38:22 GMTContent-Type: text/html; charsetUTF-8Transfer-Encoding: chunkedConnection: keep-aliveServer: LiteSpeedx-powered-by: PHP/7.3.33link: https://108tunes.com/wp-json/>; relhttps://api.w.org/x-turbo-charged-by: LiteSpeed !DOCTYPE html>html langja classno-js>head> meta charsetUTF-8> meta nameviewport contentwidthdevice-width> link relprofile hrefhttp://gmpg.org/xfn/11>!-- Google Tag Manager -->script>(function(w,d,s,l,i){wlwl||;wl.push({gtm.start:new Date().getTime(),event:gtm.js});var fd.getElementsByTagName(s)0,jd.createElement(s),dll!dataLayer?&l+l:;j.asynctrue;j.srchttps://www.googletagmanager.com/gtm.js?id+i+dl;f.parentNode.insertBefore(j,f);})(window,document,script,dataLayer,GTM-M8TQBW9);/script>!-- End Google Tag Manager --> link relpingback hrefhttps://108tunes.com/wp/xmlrpc.php> !--if lt IE 9> script srchttps://108tunes.com/wp/wp-content/themes/twentyfifteen/js/html5.js>/script> !endif--> script>(function(html){html.className html.className.replace(/\bno-js\b/,js)})(document.documentElement);/script>title>Webディレクターの徒然/title>meta namerobots contentmax-image-preview:large />link reldns-prefetch href//fonts.googleapis.com />link reldns-prefetch href//s.w.org />link hrefhttps://fonts.gstatic.com crossorigin relpreconnect />link relalternate typeapplication/rss+xml titleWebディレクターの徒然 » フィード hrefhttps://108tunes.com/feed/ />link relalternate typeapplication/rss+xml titleWebディレクターの徒然 » コメントフィード hrefhttps://108tunes.com/comments/feed/ /> script> window._wpemojiSettings {baseUrl:https:\/\/s.w.org\/images\/core\/emoji\/13.0.1\/72x72\/,ext:.png,svgUrl:https:\/\/s.w.org\/images\/core\/emoji\/13.0.1\/svg\/,svgExt:.svg,source:{concatemoji:https:\/\/108tunes.com\/wp\/wp-includes\/js\/wp-emoji-release.min.js?ver5.7.12}}; !function(e,a,t){var n,r,o,ia.createElement(canvas),pi.getContext&&i.getContext(2d);function s(e,t){var aString.fromCharCode;p.clearRect(0,0,i.width,i.height),p.fillText(a.apply(this,e),0,0);ei.toDataURL();return p.clearRect(0,0,i.width,i.height),p.fillText(a.apply(this,t),0,0),ei.toDataURL()}function c(e){var ta.createElement(script);t.srce,t.defert.typetext/javascript,a.getElementsByTagName(head)0.appendChild(t)}for(oArray(flag,emoji),t.supports{everything:!0,everythingExceptFlag:!0},r0;ro.length;r++)t.supportsorfunction(e){if(!p||!p.fillText)return!1;switch(p.textBaselinetop,p.font600 32px Arial,e){caseflag:return s(127987,65039,8205,9895,65039,127987,65039,8203,9895,65039)?!1:!s(55356,56826,55356,56819,55356,56826,8203,55356,56819)&&!s(55356,57332,56128,56423,56128,56418,56128,56421,56128,56430,56128,56423,56128,56447,55356,57332,8203,56128,56423,8203,56128,56418,8203,56128,56421,8203,56128,56430,8203,56128,56423,8203,56128,56447);caseemoji:return!s(55357,56424,8205,55356,57212,55357,56424,8203,55356,57212)}return!1}(or),t.supports.everythingt.supports.everything&&t.supportsor,flag!or&&(t.supports.everythingExceptFlagt.supports.everythingExceptFlag&&t.supportsor);t.supports.everythingExceptFlagt.supports.everythingExceptFlag&&!t.supports.flag,t.DOMReady!1,t.readyCallbackfunction(){t.DOMReady!0},t.supports.everything||(nfunction(){t.readyCallback()},a.addEventListener?(a.addEventListener(DOMContentLoaded,n,!1),e.addEventListener(load,n,!1)):(e.attachEvent(onload,n),a.attachEvent(onreadystatechange,function(){completea.readyState&&t.readyCallback()})),(nt.source||{}).concatemoji?c(n.concatemoji):n.wpemoji&&n.twemoji&&(c(n.twemoji),c(n.wpemoji)))}(window,document,window._wpemojiSettings); /script> style>img.wp-smiley,img.emoji { display: inline !important; border: none !important; box-shadow: none !important; height: 1em !important; width: 1em !important; margin: 0 .07em !important; vertical-align: -0.1em !important; background: none !important; padding: 0 !important;}/style> link relstylesheet idwp-block-library-css hrefhttps://108tunes.com/wp/wp-includes/css/dist/block-library/style.min.css?ver5.7.12 mediaall />link relstylesheet idwp-block-library-theme-css hrefhttps://108tunes.com/wp/wp-includes/css/dist/block-library/theme.min.css?ver5.7.12 mediaall />link relstylesheet idparent-style-css hrefhttps://108tunes.com/wp/wp-content/themes/twentyfifteen/style.css?ver5.7.12 mediaall />link relstylesheet idtwentyfifteen-fonts-css hrefhttps://fonts.googleapis.com/css?familyNoto+Sans%3A400italic%2C700italic%2C400%2C700%7CNoto+Serif%3A400italic%2C700italic%2C400%2C700%7CInconsolata%3A400%2C700&subsetlatin%2Clatin-ext&displayfallback mediaall />link relstylesheet idgenericons-css hrefhttps://108tunes.com/wp/wp-content/themes/twentyfifteen/genericons/genericons.css?ver20201208 mediaall />link relstylesheet idtwentyfifteen-style-css hrefhttps://108tunes.com/wp/wp-content/themes/108tunes/style.css?ver20201208 mediaall />link relstylesheet idtwentyfifteen-block-style-css hrefhttps://108tunes.com/wp/wp-content/themes/twentyfifteen/css/blocks.css?ver20190102 mediaall />!--if lt IE 9>link relstylesheet idtwentyfifteen-ie-css hrefhttps://108tunes.com/wp/wp-content/themes/twentyfifteen/css/ie.css?ver20170916 mediaall />!endif-->!--if lt IE 8>link relstylesheet idtwentyfifteen-ie7-css hrefhttps://108tunes.com/wp/wp-content/themes/twentyfifteen/css/ie7.css?ver20141210 mediaall />!endif-->script srchttps://108tunes.com/wp/wp-includes/js/jquery/jquery.min.js?ver3.5.1 idjquery-core-js>/script>script srchttps://108tunes.com/wp/wp-includes/js/jquery/jquery-migrate.min.js?ver3.3.2 idjquery-migrate-js>/script>link relhttps://api.w.org/ hrefhttps://108tunes.com/wp-json/ />link relEditURI typeapplication/rsd+xml titleRSD hrefhttps://108tunes.com/wp/xmlrpc.php?rsd />link relwlwmanifest typeapplication/wlwmanifest+xml hrefhttps://108tunes.com/wp/wp-includes/wlwmanifest.xml /> meta namegenerator contentWordPress 5.7.12 />/head>body classhome blog wp-embed-responsive>!-- Google Tag Manager (noscript) -->noscript>iframe srchttps://www.googletagmanager.com/ns.html?idGTM-M8TQBW9height0 width0 styledisplay:none;visibility:hidden>/iframe>/noscript>!-- End Google Tag Manager (noscript) -->div idpage classhfeed site> a classskip-link screen-reader-text href#content>コンテンツへスキップ/a> div idsidebar classsidebar> header idmasthead classsite-header rolebanner> div classsite-branding> h1 classsite-title>a hrefhttps://108tunes.com/ relhome>Webディレクターの徒然/a>/h1> button classsecondary-toggle>メニューとウィジェット/button> /div>!-- .site-branding --> /header>!-- .site-header --> div idsecondary classsecondary> div idwidget-area classwidget-area rolecomplementary> aside idsearch-2 classwidget widget_search>form rolesearch methodget classsearch-form actionhttps://108tunes.com/> label> span classscreen-reader-text>検索:/span> input typesearch classsearch-field placeholder検索… value names /> /label> input typesubmit classsearch-submit screen-reader-text value検索 /> /form>/aside> aside idrecent-posts-2 classwidget widget_recent_entries> h2 classwidget-title>最近の投稿/h2>nav rolenavigation aria-label最近の投稿> ul> li> a hrefhttps://108tunes.com/2011/05/19/a-smartphone-may-be-suitable-for-reading/>スマートフォンは読み物に向いているかもしれない/a> /li> li> a hrefhttps://108tunes.com/2010/09/23/internet-cafe-is-recommended/>集中したいときはネットカフェがオススメ/a> /li> li> a hrefhttps://108tunes.com/2010/08/17/direction-at-banner-production/>バナー制作時のディレクション/a> /li> li> a hrefhttps://108tunes.com/2010/08/16/action-to-be-taken-when-understanding-can-not-be-obtained/>理解を得られないときの対処/a> /li> li> a hrefhttps://108tunes.com/2010/08/15/how-to-respond-when-it-is-likely-to-be-behind-delivery-schedule/>納期に遅れそうな時の対応方法/a> /li> /ul> /nav>/aside>aside idarchives-2 classwidget widget_archive>h2 classwidget-title>アーカイブ/h2>nav rolenavigation aria-labelアーカイブ> ul> li>a hrefhttps://108tunes.com/2011/05/>2011年5月/a>/li> li>a hrefhttps://108tunes.com/2010/09/>2010年9月/a>/li> li>a hrefhttps://108tunes.com/2010/08/>2010年8月/a>/li> li>a hrefhttps://108tunes.com/2010/07/>2010年7月/a>/li> li>a hrefhttps://108tunes.com/2010/06/>2010年6月/a>/li> li>a hrefhttps://108tunes.com/2010/03/>2010年3月/a>/li> li>a hrefhttps://108tunes.com/2010/02/>2010年2月/a>/li> /ul> /nav>/aside>aside idcategories-2 classwidget widget_categories>h2 classwidget-title>カテゴリー/h2>nav rolenavigation aria-labelカテゴリー> ul> li classcat-item cat-item-2>a hrefhttps://108tunes.com/category/direction/>direction/a>/li> li classcat-item cat-item-3>a hrefhttps://108tunes.com/category/memo/>memo/a>/li> li classcat-item cat-item-5>a hrefhttps://108tunes.com/category/z-other/>other/a>/li> li classcat-item cat-item-6>a hrefhttps://108tunes.com/category/tech/>tech/a>/li> /ul> /nav>/aside> /div>!-- .widget-area --> /div>!-- .secondary --> /div>!-- .sidebar --> div idcontent classsite-content> div idprimary classcontent-area> main idmain classsite-main rolemain> article idpost-157 classpost-157 post type-post status-publish format-standard hentry category-z-other> header classentry-header> h2 classentry-title>a hrefhttps://108tunes.com/2011/05/19/a-smartphone-may-be-suitable-for-reading/ relbookmark>スマートフォンは読み物に向いているかもしれない/a>/h2> /header>!-- .entry-header --> div classentry-content> p>同じコンテンツを、PCサイト、スマートフォンサイト、携帯サイトに展開する際、表示領域が異なるため、レイアウトやナビゲーションを工夫するのは当たり前ですが、スマートフォンは画面サイズ以外に、操作性が考慮のポイントになりそうです。/p>p>指で直感的に、表示領域の拡大/縮小ができるので、広告やナビゲーションなど、コンテンツを読むのに余分な要素をカットできます。商用ブログやポータルサイト系の読み物は、広告が表示されたり、そわそわする要素が多くて記事に集中出来ないことがあります。延々とループされるテレビCMのような広告だと、ブラウザサイズを調整したり、テキストエディタに記事をコピー＆ペーストして読むこともありました。br />またスクロールが簡単なので、ページ送りが自分の感覚とマッチしていると思います。PCではマウスのホイールが実装されたときは大変便利になったと感じましたが、MacBook のスライドパットを使い始めて、サイトを閲覧する際にはマウスより使いやすいことが実感できました。/p>p>さらに、スマートフォンでは画面上を指でスライドさせる操作が、本を読んでいる感覚に近くて、メールや記事を読むには親和性がよいのではと感じています。br />携帯（ガラケー）サイトも表示領域の制限で、テキストのみの記事が多いのですが、スクロールさせる操作感や不自然な半角文字に慣れることができず（ケータイ小説はどうしても読む気にはなれませんでしたが慣れかもしれません）、いまだに外出時の非常手段程度にしか利用していません。br />少し前までスマートフォンは移動中にチェックするデバイスとして利用していましたが、最近では自宅のリビングでメールをチェックしたり、ブラウザで調べ物も行うようになりました。br />スマートフォンの出現で、Flashなどリッチコンテンツのあり方も見直しされていますし、これからもインターフェイスも進化していくはずなので、制作に関わる人間として、情報を伝えるベストプラクティスを模索しつづけることが大切と思います。/p> /div>!-- .entry-content --> footer classentry-footer> span classposted-on>span classscreen-reader-text>投稿日: /span>a hrefhttps://108tunes.com/2011/05/19/a-smartphone-may-be-suitable-for-reading/ relbookmark>time classentry-date published updated datetime2011-05-19T15:01:50+09:00>2011-05-19/time>/a>/span>span classcat-links>span classscreen-reader-text>カテゴリー /span>a hrefhttps://108tunes.com/category/z-other/ relcategory tag>other/a>/span> /footer>!-- .entry-footer -->/article>!-- #post-157 -->article idpost-151 classpost-151 post type-post status-publish format-standard hentry category-memo> header classentry-header> h2 classentry-title>a hrefhttps://108tunes.com/2010/09/23/internet-cafe-is-recommended/ relbookmark>集中したいときはネットカフェがオススメ/a>/h2> /header>!-- .entry-header --> div classentry-content> p> /p>p>Webのディレクションとは直接関係ない話だが、Webディレクターの活動として最近気付いたことなので紹介します。/p>p>オフィスでは話掛けられたり電話がなったりと、気が散る要素がたくさんあります。/p>p>ディレクターの仕事上、コミュニケーションは大事なのですが、考え事をすることが多いです。br />特にプランニングしたり情報を整理しているときなど、集中したいのですが、ちょっとした雑音や中断で、考えていたことが消えてしまうことがあります。br />考え事をするときは、ヘッドフォンをすることが多いのですが、やっぱり落ち着かないです。/p>p>そんな時は、カフェなど外部スペースを利用しています。/p>p>電源が使えて無線LAN環境があるa hrefhttp://www.ginza-renoir.co.jp/renoir/index.htm target_blank relnoopener noreferrer>ルノアール/a>を使っています。br />隣の席と余裕があって打合せもできるし、コーヒーを注文した後、適宜お茶など出してくれたりするので、割と長時間居られるので重宝しています。br />ただ1人で数時間居座るのは、ちょっと気が引けてきますし、アイスコーヒー1杯560円なので数杯注文するのも、ちょっと辛い感じです。/p>p>隣のうるさかったり、壁際に座れないと後ろが気になったり、落ち着けない状況になることもありました。br />あと、セキュリティ上、資料が広げにくかったりと気になる要素はあります。/p>p>最近ではネットカフェを利用しています。/p>p>昔は趣味で「まんが喫茶」に行ってました。その頃は、インターネット回線や個室もなく、マンガを読むこと＆ちょっとした仮眠程度の利用でした。br />その後、「ネットカフェ難民」などのコトバも出てきて、ネガティブな印象でした。br />知り合いに、静かなネットカフェもあると聞いて、試しにa hrefhttp://www.bagus-99.com/netcafe/store/yasukuni.html target_blank relnoopener noreferrer>グラン・サイバーカフェ：靖国通り店/a>を利用したところ、とても良かったです。/p>p>個室で仕切りがあって、椅子も座り心地がよく（フラットシートもある）、電源も使えて、ドリンク飲み放題。br />1時間400円で、3時間パックで1000円程度。br />何といっても、とても静か。キーボードのタッチ音が気になるくらい静かです。/p>p>インターネット端末はもちろん、無線LANもありますが、ウイルス感染やパスワード漏洩などが怖いので、持ち込みのノートパソコンとPocket Wifiを使っています。/p>p>他のネットカフェも試してますが、上記の店が綺麗（他の店はタバコやいろんな匂いが・・・）だし、一番良さそうです。/p>p>あとは、移動タイミングなどで、少しネットを使いたいときなど使えそうです。br />30分180円というネットカフェもありました。/p>p>これからも利用が増えそうなので、調査したいと思います。/p>p>サテライトオフィスを考えている方、固定費が掛からないネットカフェも意外と使えるかもしれません。/p> /div>!-- .entry-content --> footer classentry-footer> span classposted-on>span classscreen-reader-text>投稿日: /span>a hrefhttps://108tunes.com/2010/09/23/internet-cafe-is-recommended/ relbookmark>time classentry-date published updated datetime2010-09-23T18:52:04+09:00>2010-09-23/time>/a>/span>span classcat-links>span classscreen-reader-text>カテゴリー /span>a hrefhttps://108tunes.com/category/memo/ relcategory tag>memo/a>/span> /footer>!-- .entry-footer -->/article>!-- #post-151 -->article idpost-146 classpost-146 post type-post status-publish format-standard hentry category-direction> header classentry-header> h2 classentry-title>a hrefhttps://108tunes.com/2010/08/17/direction-at-banner-production/ relbookmark>バナー制作時のディレクション/a>/h2> /header>!-- .entry-header --> div classentry-content> p>シンプルな制作案件でも押さえるポイントがあります。br />広告バナーをたくさん制作するという案件を例にします。/p>p>前提として、メディア展開プランや構成要素のFIXを代理店側で対応し、静止画やFlashを作成する、という案件を想定しています。/p>p>作業や品質の大部分はデザイナーの力量に掛かってしまいますが、ディレクターとして気にするポイントは以下です。/p>p>・納期を確認するbr />・要件を確認するbr />・素材を確認する/p>p>「納期を確認する」/p>p>代理店から依頼がある制作案件は、スケジュールが非常にタイトなことがあります。制作側の感覚では、早く伝えてくれればよいのに、、、と思うことがしばしばありますが、制作サイドに落ちてくる前に沢山の調整があったりで時間を要することが当たり前のようです。br />メディア枠の購入が急遽決まることもあるため、バナー制作案件は、タイトなスケジュール前提で心構えをしていた方がよいと思います。/p>p>まず依頼された段階で、制作ボリュームとスケジュールを比較して対応可能かどうかの判断が必要です。/p>p>無理なスケジュールは断ることも選択肢ですが、納期を調整できる場合があります。br />通常は、以下のようなやりとりです。br />制作ベンダー ←→ 代理店 ←→ クライアント＆メディア/p>p>代理店やクライアント側で納期までのスケジュールに余裕をもっている場合があります。/p>p>メディアの納期は、掲載期間との兼ね合いがあるため、調整できないことが普通なのですが、br />代理店＆クライアントとメディアのパワーバランスで調整して頂く事もあります。/p>p>制作側としては、提示されたスケジュールに調整の余地があるかどうか、まず確認した方がよいです。/p>p>「要件を確認する」/p>p>ここでの「要件」とは、制作内容そのものなので、シンプルなのですが、注意すべきポイントがあります。/p>p>まず、提示された構成要素や指示内容が確定内容なのか把握しておくことです。br />何と代理店側の見切りで依頼がくることがあります。/p>p>明らかに指示が曖昧な場合は、すぐに分かりますが、指示内容から読み取れないこともあります。br />イメージの認識あわせのためにも、確認ポイントがあり、br />・バナーをクリックした際の遷移先ページのデザインbr />・他のメディアとの連動キャンペーンの場合のトーン＆マナーbr />・一番訴求したい要素は何か？br />をヒアリングします。/p>p>代理店担当に矛盾があったり、考えがブレていたら要注意です。br />作り込みをする前にラフで組んでみて、方針を確認した方が全体工数が低減できますし、修正負荷によるクリエーターのストレス度合いもおさえられます。/p>p>また大事なポイントは、広告のレギュレーションの確認です。br />サイズ、容量、フォーマット、枠線の有無・色・幅、ブランドロゴ・商品名の掲載、文字の可読性など、媒体によって様々です。br />Yahoo！の広告規定は公開されており、他の媒体のベースになっていることがあるので目を通しておくと、他の媒体にも応用できると思います。br />改訂されることもあるので、最新版かどうか、レギュレーションの適用期間など確認した方がよいです。br />特に、Flashバナーについては細かい規定があるので、制作前にクリエーターに理解してもらわないと制作できません。br />Yahoo！の場合は、チェックツールが提供されているほか、実際にFlaファイルレベルでチェックされることもあるようです。/p>p>モバイルサイトのバナー制作は、容量との勝負になることが多いです。br />MacとWindowsの計算違いによりNGとなったことがあります。Windowsのファイル容量を基準とした方が無難です。/p>p>バナーの構成要素がレギュレーションを満たしてないことがあるので、早めの確認が必要です。/p>p>「素材を確認する」/p>p>バナー制作で素材の確認は必須です。br />代理店から提供されることが大前提ですが、細かくチェックしてないこともあるため、何となく揃っているような気分で制作を開始すると足りないことがあります。ほとんどの場合、制作期間がタイトなので慌てます。/p>p>画像は見てすぐ分かるのですが、フォントについては見逃すことがあります。br />ロゴのように使われてる場合は同じフォントが必要ですし、ない場合はアウトライン化して提供してもらわないといけません。br />似たフォントの代用でもOKな場合もあるため、文字要素の確認は必要です。/p>p>継続的にバナー制作案件を受注する場合は、事前に必要なフォントを確認した方が良いと思います。/p>p>以上のポイントを押さえたら、あとの作業は、クリエーターの力量に依存します。br />制作会社のディレクターの好みで中途半端にディレクションすると、時間が足りなくなることが多いため、最低減の確認に留め、代理店からのフィードバックを待った方がよいと思っています。（これはディレクターの流儀で個人差があると思います）/p>p>代理店に提出する前に確認するポイントは、br />・レギュレーションを守っているかbr />・構成要素に過不足はないかbr />・文字や画像の可読性は大丈夫かbr />です。/p>p>上記を満たしていれば、デザイン上、多少気になる箇所を見つけても、代理店に確認に出した方がよいです。br />自分の主観かもしれないし、代理店やクライアントは別の意図があるのかもしれません。br />どうしても気になる場合は、懸念点や迷った点を伝えた上で、判断を求めた方がスムーズに行くと思います。/p>p>ディレクターとして避けたいのは、何度も何度も修正を行って、クリエーターを疲弊させることです。br />微妙な指示を繰り替えすと、クリエーターは考えることを止めて、指示通りに手を動かすだけになってしまいます。br />最終段階の微調整は仕方ないですが、なるべくクリエーターが楽しく取り組める状況を保持することが大切と思います。/p> /div>!-- .entry-content --> footer classentry-footer> span classposted-on>span classscreen-reader-text>投稿日: /span>a hrefhttps://108tunes.com/2010/08/17/direction-at-banner-production/ relbookmark>time classentry-date published updated datetime2010-08-17T02:12:16+09:00>2010-08-17/time>/a>/span>span classcat-links>span classscreen-reader-text>カテゴリー /span>a hrefhttps://108tunes.com/category/direction/ relcategory tag>direction/a>/span> /footer>!-- .entry-footer -->/article>!-- #post-146 -->article idpost-140 classpost-140 post type-post status-publish format-standard hentry category-direction> header classentry-header> h2 classentry-title>a hrefhttps://108tunes.com/2010/08/16/action-to-be-taken-when-understanding-can-not-be-obtained/ relbookmark>理解を得られないときの対処/a>/h2> /header>!-- .entry-header --> div classentry-content> p>仕事に限らず、他人から理解を得られないときがあります。/p>p>理解してもらう努力をするのは当然ですが、根本的に価値観が違っている場合は、理解を得ることが難しい場合があります。（私の場合は、理解されないケースが多い自覚があります（笑））/p>p>特に、Web制作においては、最初からクライアントの理解を得られないことがあると思います。完成のイメージができてない、または完成後の影響度について想像が追いつかないことがあるからです。/p>p>クライアントによかれ、だったり、認識違いによる双方のリスクヘッジのために、制作前に理解を得ようとするのは当たり前なのですが、しつこくやると「ガツガツしている」とか、理解できないことへのストレスからネガティブな印象を持たれて、後の進行に影響を及ぼすことがあります。/p>p>「説明責任」という言葉があり、説明することは大事なのですが、理解を得るのとは別のことだと思います。双方、納得できるのが理想の状態ですが、必ずしも実現できるとは限りません。/p>p>Web制作の例で考えてみると、「SEO対策に最適なサイト構築」という命題があった場合、本来であればHTML構造も重要で、記述の順序についても、事前の理解が必要です。なぜなら、SEO対策は検索エンジンに依存する部分があり、恒久的な対策は難しく、実施範囲やその効果について理解を得られないと、クレームがくることが予想されるからです。また、外部対策を得意とするベンダーと内部対策を得意とするベンダーではアプローチが異なり、クライアントの担当者が余程勉強していない限り、すべてを理解してもらうことは難しいです。/p>p>あとは、実質的に工数の問題があると思います。説明して納得してもらうのも工数が掛かるのですが、営業行為として認めてくれないケースもあります。継続的に運用案件や改修案件をいただくことがあるので、状況により判断する必要があります。/p>p>いろいろな状況がある前提なのですが、理解を得られず煮詰まるほど苦しい時があります。/p>p>プロジェクトを進めることができなかったり、煮詰まりすぎて精神や体調にまで影響を及ぼす場合は、対処策を考えないと自滅してしまいます。/p>p>以下のように考えてみます。/p>p>「なぜ理解されないんだろう？」/p>p>これは考えても無駄かも。理解されないんだから。自分なりにやり尽くした感があれば、先には進まない事が多いです。/p>p>「理解を得ると何が嬉しいか？」/p>p>理解された先に何が待っているのか考えてみます。よく考えると、自己顕示欲だったり自己満足だったりすることがあります。/p>p>相手にとって価値がない（と信じている）ことは、理解する努力をしてくれないことも多いです。/p>p>「どこまで理解される必要があるか？」/p>p>大切なポイントです。通常の状態でも１００％の理解を得るのはそもそも困難です。/p>p>なぜ理解をして欲しいのか、が明確になれば、どこまで理解されると支障がないのか線引きが見えてくるはずです。/p>p>理解されないとリスクが大きい場合は、プロジェクトを止めたり、案件そのものを辞退する必要もあります。/p>p>「いつまでに理解を得る必要があるのか？」/p>p>理解してもらう為には、共通の経験が必要だと思っています。/p>p>まず独自でやってみて、計画的に情報を小出しにして、段階的に理解を得るのがよいかもしれません。/p>p>時間が解決してくれることもありますし、拒絶された場合は、最終的に理解を得られなくても、実現できることもあります。/p>p>まとめると、理解を得たい側が、理解を得る行為の価値を判断して、完成時、完成後の影響度がイメージすることが重要です。/p>p>以下、煮詰まった時の対処方法について、キーワードをピックアップします。/p>p>煮詰まった状況を打開するには多角的に検討する必要があり、以下に含まれるネガティブな単語はあくまで推奨ではありません。/p>p>それぞれの行為を行ったときに、どのような結果になるのか想像できることが大事だと思います。/p>p>・コミュニケーションを深める/p>p>・説得する/p>p>・根気強く説明する/p>p>・うまく説明する/p>p>・教育する/p>p>・手をかえる/p>p>・時間が解決するのを待つ/p>p>・妥協点を探る/p>p>・表面上、話をあわせる/p>p>・ごまかす/p>p>・諦める/p>p>・離れる/p>p>・無視する/p>p>・そっとしておく/p>p>・他のことをする/p> /div>!-- .entry-content --> footer classentry-footer> span classposted-on>span classscreen-reader-text>投稿日: /span>a hrefhttps://108tunes.com/2010/08/16/action-to-be-taken-when-understanding-can-not-be-obtained/ relbookmark>time classentry-date published updated datetime2010-08-16T07:00:40+09:00>2010-08-16/time>/a>/span>span classcat-links>span classscreen-reader-text>カテゴリー /span>a hrefhttps://108tunes.com/category/direction/ relcategory tag>direction/a>/span> /footer>!-- .entry-footer -->/article>!-- #post-140 -->article idpost-120 classpost-120 post type-post status-publish format-standard hentry category-direction> header classentry-header> h2 classentry-title>a hrefhttps://108tunes.com/2010/08/15/how-to-respond-when-it-is-likely-to-be-behind-delivery-schedule/ relbookmark>納期に遅れそうな時の対応方法/a>/h2> /header>!-- .entry-header --> div classentry-content> p>Web制作に限らないと思いますが、受託業務では、納期に遅れそうなことが起きてしまいます。理由は様々ですが、特にWeb制作に関しては、公開間近までクライアント側と制作者との完成イメージのズレから、ほぼ出来た状態から修正が発生することが多いと思います。/p>p>納期が遅れそうな場合、制作ディレクターが調整をすることになります。br />この調整の仕方により、クライアントやクリエーターからの評価が大きく分かれると思っていますし、ディレクターの手腕の見せ所のひとつです。br />本来は遅れないことがベストなのですが、作業度合いによっては、如何ともしがたい場合があります。/p>p>顧客至上主義のタイプだったり、調整が苦手なディレクターだったりすると、100％クライアントの要求を実現すべく、クリエーターに圧力を掛けることがありますが、根性論では乗り切れない事態に対する策は必要です。/p>p>私の経験上、いくつか押さえるポイントがあります。/p>p>まずは制作側の現状を正確に把握しましょう。br />現時点でどのくらいできているのか、要件を満たすまでにどのくらいの作業が残っているのか、いつ頃だったら完成できるのか、遅れた要因は何だったのか、懸念点は何なのか、そもそも完成できるスキルを持っているのか、、、、などです。br />一般的なプロジェクト管理では、定期的に進捗を確認しながら問題は早期発見というのが理想なのですが、制作側から正しい情報が報告されているとは限りません。特に、プログラム開発プロジェクトより、Web制作については、工数の読みが甘かったり、担当者のスキルに依存する部分が多く、納期前に判明することが多い気がします。/p>p>この時点では、感情論で何とかなる余地はなく、冷静に現状把握に全力を入れます。br />クリエーター側から「あと少しで何とかする」という回答のみで、現状を公開しないタイプもいます。ですが、余程信頼しているクリエーターでない限り、一旦作業を止めさせて、現状ヒアリングした方がよいと思います。/p>p>情報を集めた時点で、ボンヤリとでも、スケジュール感、完成イメージと段階リリースの構想を作っておくことが重要です。次に述べる、クライアントとの調整前に、現プロジェクトの潜在力を掴んでおかないと、調整後も同じ失敗をすることがあります。/p>p>次に、クライアントが最低減到達したい内容を把握します。br />納期が遅れる非を謝罪しつつも、クライアント側の要求に無理がある旨を説明します。br />たいていの担当者は怒りますが冷静になるまで待ち、ヒアリングします。納期ギリギリに遅延連絡をすると対応策の選択肢がなくなるため、危ないなあと感じた時点で早めに情報を伝えることが大事です。/p>p>優先度を確認しましょう。br />公開期日を守るのが優先なのか、要件を万全にするのが優先なのか、など状況によって異なります。br />製品発表のニュースリリースなど、Web以外の要因と絡んでいる場合は、公開期日が最優先です。ほとんどの場合、タイミングを遅延させることはNGです。br />開発絡みでサービス品質を重視するプロジェクトは、多少公開を遅らせても要件を満たすことが最優先となることもあります。またクライアント側の試験運用期間がある場合は、運用側が習得すべき内容を把握して、期日と機能を調整していきます。/p>p>クライアントと優先度の認識共有ができたら、段階リリースについて相談をしましょう。br />Webサービスは、公開までのスピード感が早いので、完全版を一気に公開しなくてもクライアントの要件を満たすことが多いです。残念ながら、双方にこの認識があるため、直前の修正や仮納品、公開後の差し替えなどが一般化していると思うのですが、そういう文化なのかもしれないと感じています。受託のプロとしては失格かもしれませんが、案件の内容が複雑化していて工数が読みづらかったり、クライアントの発注責任上の相応の知識が不足している場合があり、完全に受託側が悪い、という状況ではないケースが多いような気がします。br />段階リリースは、クライアントの要件を満たす策としてはアリなのですが、よくあるパターンとして、要望が追加されたり、更新が発生して公開時の確認工数が増えたり、制作側の工数が増えてしまうことがあるので、案件のコントロールが重要です。最初から嫌な予感がするプロジェクトは、工数算出する際に積んでおくことも一つの解決策です。/p>p>状況によっては、クライアント窓口担当の上司・社長向けの報告・パフォーマンス向けに、報告書などの作成が必要になる場合があります。この場合は、クリエーターの資源を使うのは本末転倒なので、ディレクターが対応すべきです。例えクリエーターの責任で遅延した場合でも、ディレクターが対応することのメリットがあります。プロジェクト全体としての進行が止まらないこと、クリエーターとの関係性が良くなることが多いことです。/p>p>優先度を確認したら、クリエーター（コーディング、プログラムなど関係者一同）に対して、クライアントとの調整結果を共有します。br />妥当なスケジュールだった場合は、関係者一同で頑張るだけですが、その策に無理がある場合も予想されます。br />無理が判明した時点で、クライアントに相談します。ここで時間を空けてしまうと最悪な事態になります。対応が後手後手になってしまうと、クライアントに迷惑を掛けてしまうだけでなく、プロジェクトのモチベーション低下、品質が悪くなったり、公開後に瑕疵責任という形で無償対応を余儀なくされたり、賠償問題を持ちかけられたり、、、と悪い方向になります。br />スケジュールが妥当かどうか確信がもてない場合は、クライアントとコミットするのは避けましょう。持ち帰り判断とさせてもらうか、その場でクリエーターに確認した方がよいです。/p>p>クライアント側、制作側と調整ができたら、再度情報を共有します。br />スケジュール表でもテキストでもよいので、関係者にメールでを展開するのは一般的ですが、一方的な連絡事項として投げっぱなしにすると、トラブルになることがあります。br />調整役のディレクターが思っているほど、クライアントも制作側も認識していないことが多い気がします。br />証拠としてメールを送るのは重要ですが、最重要なのは認識してもらうことです。br />特にメールの返信にて、重要な箇所に触れてないことがあります。見てないのか、潜在意識が働いて見てないフリをしている場合もあるので、危ないなあ、と思う場合は、打合せや電話で確認した方がよいです。/p>p>関係者一同が共通認識が持てたら、納期調整のディレクションは完了です。br />あとは品質チェックを甘くしないように気を配りながら、納品までプロジェクトをコントロールします。/p>p>納期調整も一種のトラブルシューティングですが、ディレクターとしては日頃から気をつけておくことがあります。br />クライアントの要件を把握するのは当たり前ですが、クリエーターとの信頼関係が重要です。br />重要なプロジェクトで組むクリエーターの実力を把握しておいたり、他のプロジェクトを掛け持ちしている場合の稼働時間や、完成させるまでのプロセスのクセ（設計重視だったり、作りながら考えるタイプだったり様々）を掴んでおくと、いざというときに安心して取り組むことができます。/p>p>番外編として、br />実際に見たよくない例を紹介します。br />クライアント側の担当者が遅延を気にして社内報告（おそらく上司）のためだけに、制作ディレクターに問い合わせをbr />するのは当然ですが、連絡頻度が半端ではなく、30分毎に確認をしていました。受けたディレクターは、その度にクリエーターに「いつできる？」と確認の電話を続け、クライアント側へ報告していました。笑い話のようですが、プレッシャーに耐えられないディレクターはそのような行動を取ってしまいます。br />結果的に、クリエーターの作業を分断することになります。クリエーターの作業を分断することは、単純に時間の切り取りでは計れません。集中力を再構築したり、アタマの中の構想が消えてしまったりと、分断前の状態に戻すのに時間が掛かります。フロント側のディレクターがクリエーターの環境を考慮すべきです。br />クリエーターが遅れている場合に責任転嫁したい気持ちは分かりますが、報告するだけの確認行為は、余程重要なタイミングではない限り無意味なので、ディレクターとしては避けたいものです。/p> /div>!-- .entry-content --> footer classentry-footer> span classposted-on>span classscreen-reader-text>投稿日: /span>a hrefhttps://108tunes.com/2010/08/15/how-to-respond-when-it-is-likely-to-be-behind-delivery-schedule/ relbookmark>time classentry-date published updated datetime2010-08-15T17:17:16+09:00>2010-08-15/time>/a>/span>span classcat-links>span classscreen-reader-text>カテゴリー /span>a hrefhttps://108tunes.com/category/direction/ relcategory tag>direction/a>/span> /footer>!-- .entry-footer -->/article>!-- #post-120 -->article idpost-107 classpost-107 post type-post status-publish format-standard hentry category-direction> header classentry-header> h2 classentry-title>a hrefhttps://108tunes.com/2010/07/17/the-problem-to-be-solved-is-something-in-the-first-place/ relbookmark>解決すべき問題はそもそも何かを考える/a>/h2> /header>!-- .entry-header --> div classentry-content> p>大前研一 BOT（@ohmaebot）で、以下のつぶやきがあった。/p>blockquote>p>日本人は「どこか自分の外側に答がある」と勘違いしている。そのため、何か困ったことに突き当たると、最初から「この問題の答はどこにあるのか、何なのか」と考えてしまう。自分が「解決すべき問題はそもそも何か」を考えずに、目先の問題への答えばかりを見つけようとする。/p>/blockquote>p>なるほどなあ、自省。/p> /div>!-- .entry-content --> footer classentry-footer> span classposted-on>span classscreen-reader-text>投稿日: /span>a hrefhttps://108tunes.com/2010/07/17/the-problem-to-be-solved-is-something-in-the-first-place/ relbookmark>time classentry-date published updated datetime2010-07-17T00:55:26+09:00>2010-07-17/time>/a>/span>span classcat-links>span classscreen-reader-text>カテゴリー /span>a hrefhttps://108tunes.com/category/direction/ relcategory tag>direction/a>/span> /footer>!-- .entry-footer -->/article>!-- #post-107 -->article idpost-104 classpost-104 post type-post status-publish format-standard hentry category-direction> header classentry-header> h2 classentry-title>a hrefhttps://108tunes.com/2010/07/05/be-careful-with-hearing/ relbookmark>ヒアリングで気をつけること/a>/h2> /header>!-- .entry-header --> div classentry-content> p>ヒアリングをするときは、相手の意図を確認する事が重要。発言内容の表面だけを要件として受け止めてしまうと、後々ズレてくることが多い。というのは、相手が自分の意図を正しく伝える技術を持っていない事が多いからだ。/p>p>相手の発言を聞いた際、自分の経験を思い返して違和感があれば、早めに解消した方がよい。たぶん、相手のやりたいことを具体的にイメージした上で伝えているわけでなく、具現化していく課程で認識が間違っていることに気付くことが多いはず。/p>p>そんなときは、自分なりの解釈を加えて、相手との問答を想定しながら組み立てていく。自分の意図を説明した上で、認識あわせをするのがよいと思う。説明するのに要する労力は掛かってしまうが、ズレに気付いて後から修正するより総体的に見て近道となる。/p>p>相手の意図を確認する、というのは想像力が必要となる。質問の仕方や自分の知識などテクニカルな要素は必要であるが、基本は、/p>ul>li>なぜ、そのような事を言っているのか？/li>li>具現化していくと何が起きるのか？/li>/ul>p>を突き詰めていくと、意図が見えてくると思う。/p>p>さらに、意図の理由固めを行うことでより強固になる/p>ul>li>一般論/li>li>業界、同業他社、類似案件/li>li>特殊性/li>/ul>p>など、いくつかの切り口で裏を取る作業を行うと、対外的な説得力が増すので、認識のズレを解消できる。/p>p>話の意図が見えない場合は、案件としての目的が定まってなかったり、個人的見解に偏っていることが多い。個人的見解も大事だが、他人に受け入れられないことが多い。/p>p>ヒアリング段階で、単に相手の話を聞くことが着地点ではなく、ヒアリング後のアクションをイメージしながら、足りない要素を引き出し、場合によってはその場で作り上げる行為ができるとよい。後工程がやりやすくなる。/p> /div>!-- .entry-content --> footer classentry-footer> span classposted-on>span classscreen-reader-text>投稿日: /span>a hrefhttps://108tunes.com/2010/07/05/be-careful-with-hearing/ relbookmark>time classentry-date published updated datetime2010-07-05T13:53:46+09:00>2010-07-05/time>/a>/span>span classcat-links>span classscreen-reader-text>カテゴリー /span>a hrefhttps://108tunes.com/category/direction/ relcategory tag>direction/a>/span> /footer>!-- .entry-footer -->/article>!-- #post-104 -->article idpost-103 classpost-103 post type-post status-publish format-standard hentry category-direction> header classentry-header> h2 classentry-title>a hrefhttps://108tunes.com/2010/06/18/when-requirement-becomes-complicated/ relbookmark>要件が複雑になるとき/a>/h2> /header>!-- .entry-header --> div classentry-content> p>要件が必要以上に複雑になるなあ、と感じるのは受託業務をしていてよくある風景である。/p>p>何かやりたい（状況的にやらざるを得ないとき）が、目的が不明瞭か、内向き（上司や社内）にある場合、機能拡充に目を向ける傾向があると思う。/p>p>必要性に質問すると、ニッチな状況を例として挙げて「こういう場合、どのような対策をお考えですか？」と逆質問で切り替えされることが多い。注意文や免責文など掲載したり、発生確率が少なければ人的対応の余地を残しておいても問題ない範囲、と私は思ったりするのだが、全自動化にこだわる担当もいらっしゃる。/p>p>IT技術が好きで、熱心に勉強されている担当者がこの傾向にあるように思う。「ITのプロに発注するけど、自分の方がよく知っている」というオーラを全面に出す方もいる。用語をよくご存じで、この時期だったら「HTML５を使った面白い提案はないですか？」というツール決め打ちで、考えを組み立てる傾向があったりする。/p>p>勉強熱心だったり、利用想定を細かく洗い出す想像力は素晴らしいのであるが、サイトやシステムを構築する目的や運用まで加味した費用対効果、関係者（発注側は当然、受注側も含まれる）のリソース配分などを総体的にみると、こだわるポイントではないなあ、と感じることがある。/p>p>受託側の立場でいうのも何だが、IT技術は何かをするためのツールでしかないので、目的が不明瞭な要件については、実現手段は何でもよいと思っている。制作したツールを使って何を実現したいか？ではなくツールを制作する行為自体が目的になっている場合は、要件定義を曖昧のまま設計の話題で盛り上がるのだが、何か出来てきて、リリース間近になるとブレ始めて、リリース前から追加や改修依頼が発生してしまう。/p>p>要件が途中で変動しない場合でも、受注側が「ズレている」と感じるポイントにコダワリが強いと、制作側のモチベーションが堅くなるので、ちょっとしたサービス提案を控えてしまうことになる。「言われた通りにやったけど、イマイチ何をしたいのか分からないし、やっぱり微妙〜」と思いながらリリースを迎えることになる。/p>p>でも発注側（というか多くの場合、窓口担当者）が満足すればよい、という概念が双方にあるため、受注側は意見があっても言わないことが多い。代わりに、要件が少しでも増えると拒絶をすることになる。「1ページ増えたから、○○円かかります」とかつまらない交渉になる。/p>p>要件確認の際、実施内容の目的や成功の定義を、受発注双方で共有することが幸せな展開になるのは間違いない。ただシステム化を伴わないウェブサイトは効果を数量化するのが難しいので、アクセス解析やコンバージョンなどという考え方を意識してもらい、リリース後にも関与できるような取り組み方をするのがよい。当初は要件をシンプルにして、本当に必要な部分だけをリリースし、様子を見つつ次の段階を一緒に考えるような取り組み方が、ウェブをつかったツールには合っていると思う。/p> /div>!-- .entry-content --> footer classentry-footer> span classposted-on>span classscreen-reader-text>投稿日: /span>a hrefhttps://108tunes.com/2010/06/18/when-requirement-becomes-complicated/ relbookmark>time classentry-date published updated datetime2010-06-18T16:45:18+09:00>2010-06-18/time>/a>/span>span classcat-links>span classscreen-reader-text>カテゴリー /span>a hrefhttps://108tunes.com/category/direction/ relcategory tag>direction/a>/span> /footer>!-- .entry-footer -->/article>!-- #post-103 -->article idpost-102 classpost-102 post type-post status-publish format-standard hentry category-tech> header classentry-header> h2 classentry-title>a hrefhttps://108tunes.com/2010/06/18/longitude-latitude/ relbookmark>緯度経度/a>/h2> /header>!-- .entry-header --> div classentry-content> p>緯度経度の測定方法には、日本測地系と世界測地系というのがあるらしい。/p>p>また、表記方法にも、度／度分秒／秒などあるので、ややこしい。/p>p>「秒」で書かれた日本測地系のリストから、世界測地系に変換する際、国土地理院のa hrefhttp://vldb.gsi.go.jp/sokuchi/tky2jgd/ target_blank relnoopener noreferrer>Web版TKY2JGD/a>というサイトを使ってみた。/p>p>そのまま秒を入れると、NG。/p>p>—————br />計算結果/p>ul>li>北緯の値が適当でありません。/li>li>東経の値が適当でありません。/li>/ul>p>—————/p>p>秒を、度にするため3600で割って入力したら、同じエラー画面が。。。/p>p>よく見ると/p>p>—————/p>p>緯度経度の入力例：/p>pre> 35°12′15.3″ → 351215.3 141°29′35.4″ → 1412935.4/pre>p>—————/p>p>っと、とてもわかりづらい。/p>p>まあ、専門家がみれば分かるんだろうけど、興味を持った素人にはハードルが高いなあ。/p> /div>!-- .entry-content --> footer classentry-footer> span classposted-on>span classscreen-reader-text>投稿日: /span>a hrefhttps://108tunes.com/2010/06/18/longitude-latitude/ relbookmark>time classentry-date published updated datetime2010-06-18T12:33:44+09:00>2010-06-18/time>/a>/span>span classcat-links>span classscreen-reader-text>カテゴリー /span>a hrefhttps://108tunes.com/category/tech/ relcategory tag>tech/a>/span> /footer>!-- .entry-footer -->/article>!-- #post-102 -->article idpost-101 classpost-101 post type-post status-publish format-standard hentry category-direction> header classentry-header> h2 classentry-title>a hrefhttps://108tunes.com/2010/03/12/how-to-check-if-it-is-transmitted/ relbookmark>伝わっているか確認する方法/a>/h2> /header>!-- .entry-header --> div classentry-content> p>メール、電話、対面、理解度を試す質問、議事録br />繰り返し、チェック方法、スキルの見極め、言語の見極め、本人にとっての重要度、相手にとっての重要度。優先度、価値観。/p> /div>!-- .entry-content --> footer classentry-footer> span classposted-on>span classscreen-reader-text>投稿日: /span>a hrefhttps://108tunes.com/2010/03/12/how-to-check-if-it-is-transmitted/ relbookmark>time classentry-date published updated datetime2010-03-12T16:16:12+09:00>2010-03-12/time>/a>/span>span classcat-links>span classscreen-reader-text>カテゴリー /span>a hrefhttps://108tunes.com/category/direction/ relcategory tag>direction/a>/span> /footer>!-- .entry-footer -->/article>!-- #post-101 --> nav classnavigation pagination rolenavigation aria-label投稿> h2 classscreen-reader-text>投稿ナビゲーション/h2> div classnav-links>span aria-currentpage classpage-numbers current>span classmeta-nav screen-reader-text>ページ /span>1/span>a classpage-numbers hrefhttps://108tunes.com/page/2/>span classmeta-nav screen-reader-text>ページ /span>2/a>a classnext page-numbers hrefhttps://108tunes.com/page/2/>次ページ/a>/div> /nav> /main>!-- .site-main --> /div>!-- .content-area --> /div>!-- .site-content --> footer idcolophon classsite-footer rolecontentinfo> div classsite-info> a hrefhttps://ja.wordpress.org/ classimprint> Proudly powered by WordPress /a> /div>!-- .site-info --> /footer>!-- .site-footer -->/div>!-- .site -->script srchttps://108tunes.com/wp/wp-content/themes/twentyfifteen/js/skip-link-focus-fix.js?ver20141028 idtwentyfifteen-skip-link-focus-fix-js>/script>script idtwentyfifteen-script-js-extra>var screenReaderText {expand:span class\screen-reader-text\>\u30b5\u30d6\u30e1\u30cb\u30e5\u30fc\u3092\u5c55\u958b\/span>,collapse:span class\screen-reader-text\>\u30b5\u30d6\u30e1\u30cb\u30e5\u30fc\u3092\u9589\u3058\u308b\/span>};/script>script srchttps://108tunes.com/wp/wp-content/themes/twentyfifteen/js/functions.js?ver20171218 idtwentyfifteen-script-js>/script>script srchttps://108tunes.com/wp/wp-includes/js/wp-embed.min.js?ver5.7.12 idwp-embed-js>/script>/body>/html>
View on OTX
|
View on ThreatMiner
Please enable JavaScript to view the
comments powered by Disqus.
Data with thanks to
AlienVault OTX
,
VirusTotal
,
Malwr
and
others
. [
Sitemap
]