デザインとコーディングは同一業務？別業務？

当方Webについては独学で、発注させて頂く立場の者です。

フリーランスの方にWebサイト制作を外注させて頂く際、デザイン業務とコーディング業務を別々に発注すると言うのは、実際に制作される技術者様から視ると・・・

やり易い業務発注でしょうか？
それとも
やり辛い業務発注でしょうか？

また、もし可能ならなぜそうなの思われたのかご教示ください。



契約云々、金額云々、仕様の事前提示云々などの細かい点は全て技術者様のご意向に沿う発注であると一旦仮定して頂き、単純に業務を実施するという技術者視点からだけ視たご意見を頂けますと幸いです。

ぜひ、よろしくお願い致します。

No.1 回答者： nerimaok 回答日時： 2014/01/10 03:25

実際にコーディングする事を考えないデサイン作ってもいいんでしょうか?

デザインとコーディングを完全に分離させるとコーディングする方の力量も何も不明で
デザインしないといけないので凝った事は危なくて出来ません。

この回答への補足

＞実際にコーディングする事を考えないで
＞デサインを作ってもいいんでしょうか?

との事、さすがにそんなデザイナー様はいらっしゃらないでしょうし、まずそのような状況にはしません…。


＞デザインとコーディングを完全に分離させると
＞コーディングする方の力量も何も不明で
＞デザインしないといけないので
＞凝った事は危なくて出来ません。

との事、それを鑑みると、

(1)デザイナー様には
・全体デザイン
・パーツデザイン
・コーディング指示書
をそれぞれ作って頂き、

　↓

(2)それを元にマークアップできるコーダー様にコーディングをお願いする

という流れを取れば問題ないでしょうか？

補足日時：2014/01/11 18:28

この回答へのお礼

ご意見誠にありがとうございます。
参考になりました。

お礼日時：2014/01/11 18:13

No.2 回答者： ORUKA1951 回答日時： 2014/01/10 08:36

　HTML自体がきちんと作成(コーディング/マークアップ)されていますと、デザインの重度も高く、凝ったデザインも可能になります。

スタイルシートを書くのも楽になります。

　とっても良い例を・・
　⇒ナビゲーションリストを様々にデザインしてみよう。( http://www.ichiya.com/WebService/Howto/sample/HT … )
　たぶん、このページはソースを見ると分かるようにHTMLは、きちんと文書構造だけをコーディング--マークアップされていますね。そして、ブラウザ(Chromeを除く)の表示メニュー→スタイル(シート)で、スタイルを選択すると様々なデザイン（ウィンドウ幅に依存しないリキッド）で表示されますし、印刷ではリンクのURLも印刷されます。

　HTMLのソース自体も、デザインにかかわる事は一切書かれていないので、極めてシンプルでメンテナンスも容易でしょうし、プリンターは無論、点字端末や視覚障害者用のスクリーンリーダーも、検索エンジンも利用できるでしょう。デザインも自在に、また凝ったことも可能ですし、jQueryなどの導入も楽ですね。
　・・・この程度のHTMLのマークアップ/コーディングはあなた自身でもできるのじゃないかと思います。

　問題は、発注形態ではなく受注側の能力次第でしょう。ちゃんとしたHTML書けない人もたくさんいますし、シンプルなHTMLを与えられたら、デザインできないデザイナーもたくさんいます。まあ、セットで無いと受注できない人は除外ですかね。
・HTMLの作成能力で文法的なものは
　Another HTML-lint 5( http://www.htmllint.net/html-lint/htmllint.html )
　でチェックできますが、文書構造とマークアップの整合性はあなた自身が判断できる能力を持っていないとなりません。
・デザインは、完成したHTMLを提示して、指定された複数のデザインができるかどうかを試せばよい。HTMLに手を加えずにできるようなら、HTMLもデザイナーの能力もOKとなる。

　そうしておけば、ページの追加も内容の変更も、あなたができるはずですからね。

この回答への補足

＞この程度のHTMLのマークアップ/コーディングは
＞あなた自身でもできるのじゃないかと思います

との事、URL先のサイトを拝見させて頂きました。
おっしゃる通りキレイで理想的？なHTMLコーディングがなされておりました。



＞問題は、発注形態ではなく受注側の能力次第でしょう。
＞ちゃんとしたHTML書けない人もたくさんいますし、
＞シンプルなHTMLを与えられたら、
＞デザインできないデザイナーもたくさんいます。
～
＞そうしておけば、ページの追加も内容の変更も、
＞あなたができるはずですからね。

との事、まさにおっしゃる通りです。

私が別々に発注しようと考えたのは、
・デザインは得意だけどコーディングがグダグダ
・コーディングは得意だけどデザインはいまいち
という技術様がほとんどであるという【現実】を鑑みたためです。
これは何もWebに限った事ではなく、「職人の世界」は大概そういうものです。
両方とも素晴らしい技術者様はめったにおりません。

そのため、めったにいない低確率な技術者を探す労力より、どちらかを妥協て後々自分で修正する労力より、それぞれがお得意な事だけに全力集中して頂ける発注作業＝素晴らしいデザイナー様と素晴らしいコーダー様の間を取り持つ事に労力を割く方が良いのでは…？
との想いがあったためです。



＞問題は、発注形態ではなく受注側の能力次第

との事、それを鑑みると、制作者の能力を「図れる仕組み」を何かしら発注前に構築しておいたほうが良い、という事でしょうか？

補足日時：2014/01/11 18:45

この回答へのお礼

ご意見誠にありがとうございます。
参考になりました。

お礼日時：2014/01/11 18:18

No.3 回答者： ixkaito 回答日時： 2014/01/10 16:39

絶対とは言いませんが、HTMLだけを与えられてデザインをお願いされるWebデザイナー／コーダーなんていません。

素人がちょっと勉強したぐらいでプロのWebデザイナー／コーダーよりWebについて詳しくなるとは到底思えません。例えそれが３流だとしても。4流以下はそもそもプロじゃない。僕が思っている３流というのはおそらく質問者様が想像する並のプロよりもやや上です。

そもそも、文章構造、サイト構造だってデザインの内です。デザインは見た目だけの話ではありません。もちろん優秀なWebデザイナーならそれもきちんと考えられています。

そして優秀なコーダーなら、デザイナーの弱点をカバーしてくれますし、どんなデザインだろうとちゃんとしたコードにしてくれ。

以上で、ご自身でのHTMLマークアップをおすすめしない理由は長くなりましたが、本題の質問にお答えいたします。

別々で発注し、デザイナーとコーダー間で一切やりとりしないとしたら、コーダーはやり辛いと思う場合があるでしょう。まったくコーディングのことを考慮していないデザインなら苦労します。逆に、デザイナーはデザインしたあとは関係ありませんから。ただ、仕上がりを見て悲しむ可能性はあります。

デザイナーとコーダー間でやりとりしながら進める場合は、初めて一緒に仕事をするとしたら相手の力量が分からないので、お互い少しやりづらいでしょう。それがもしいつも一緒に仕事をしているデザイナーとコーダーなら、別々発注でもそうでなくても同じです。形式的な違いだけですので。

結局、デザインもコーディングもプログラミングも全部１流に熟すWebクリエイターにお願いするの一番ですが、確かにそういう人はなかなかいません。

この回答への補足

＞そもそも、文章構造、サイト構造だって
＞デザインの内です。
＞デザインは見た目だけの話ではありません。

との事、それは身を持って嫌というぐらい十二分に理解しております。


＞もちろん優秀なWebデザイナーなら
＞それもきちんと考えられています。
＞そして優秀なコーダーなら、
＞デザイナーの弱点をカバーしてくれますし、
＞どんなデザインだろうと
＞ちゃんとしたコードにしてくれます。
～
＞結局、デザインもコーディングもプログラミングも
＞全部１流に熟すWebクリエイターにお願いするのが
＞一番ですが、確かにそういう人はなかなかいません。

との事、そこです。私が一番憂慮しているのはその１点です。別々に発注しようと考えているのも、それが理由の1つでした。

おっしゃる事を鑑みれば、デザインが得意なデザイナー様とコーディングが得意なコーダー様が【一緒】である事が理想という事ですよね？
例えば一緒にいる企業様とか、両方できる1人の方とか。
そのような所や人様へ発注すれば、特になんの問題ない事だと思います。

ただ、私は故あってどうしてもフリーランス様への発注にこだわりたいのです。厳密に言えば副業されてる専門職の方と独立されたフリーランス様へ発注したいと強く想っております。

ただ、現実はixkaito様のおっしゃる通りどちらか一方に能力が偏る場合がほとんどです。
両方得意なのは非常に低確率です。そのような人だけ探すのは、少々非現実的…。

そのため、発注する立場である私の所で、デザイナー様とコーダー様の間を取り持つ上手い【仕組みをつくろう】と思っており、そのヒントが欲しくて本件のご質問をした次第です。

デザイナー様にはデザイン以外にも企画の終了段階あたりぐらいから本格的に携わって頂き、デザインそのものとコーダー様へのコーディング指示書も作って頂く事がベターかな？ぐらいが今思いついている段階で、全く足りません。

今まで外注をお願いさせて頂いたのは全てデザイナー様とコーダー様が【一緒にいる】企業様でした。
今後は、それを全てフリーランス様に変えたいんです。

ただ、私はしょせん独学でデザインとコーディングを学び、それを独学で実践してきたタイプなので、どうしても【本職】の方の気持ちや、実際の業務状況がわからないんです…。


難しいですね。

補足日時：2014/01/11 19:19

この回答へのお礼

ご意見誠にありがとうございます。
参考になりました。

お礼日時：2014/01/11 18:18

No.4 回答者： ORUKA1951 回答日時： 2014/01/15 16:31

No.2です。

補足を頂いたので
＞両方とも素晴らしい技術者様はめったにおりません。
　そんな事は無いと思います。HTMLを書くときには、スタイルシートの限界をしっかり把握している必要があります。スタイルシートを書くときは、HTMLのDOMを正確に読取れないとセレクタ自体が記述できません。一方に秀でた人は、他方も理解できているはずです。

　先日、
　⇒画像にマウスを乗せた時のJava Script設定 - JavaScript - 教えて！goo( http://oshiete.goo.ne.jp/qa/8427342.html )
　という質問で、サンプルを書いたのですが、全く異なるHTMLを３種類
・順不同リストとしてマークアップされている
　　<ul>
　　　　<li><img src="サムネイル
　　　　　　<p><img src="大きな画像"></p>
　　　　</li>

・定義リストとしてマークアップされている
　　<dl>
　　　　<dt><img src="サムネイル"></dt>
　　　　<dd><img src="大きな画像"></dd>

・単にdiv(section)で囲んであるだけ
　　<div class="secion">
　　　<h3>サムネイル</h3>
　　　<p><img src="大きな画像"></p>

のどれであっても、全く区別が付かない同じデザインにできる実例です。
　これは、【HTMLさえ、きちんと書かれていれば】どのようにもデザインできる例です。
★HTMLがめちゃくちゃだったり、デザインを目的に書かれていたら、他のデザインにすることも不可能と言うことを示しています。（その意味でマークアップもデザインのうちと言えるかもしれませんが・・・、根本的な意味が違う）

　今後、HTML5が普及していくでしょうがHTML5は、単に<VIDEO><AUDIO>といった要素やフォーム関連の要素や属性だけじゃなく、「文書内に埋め込まれた「意味」を明確にする( http://www.atmarkit.co.jp/ait/articles/1008/30/n … )」という大きな改善がされています。
　これは、HTMLの作成が極めて楽になることを意味しています。今までどのようなclass名やidをつけて<DIV>で囲もうかといった悩みが、一挙に解決するのですからね。
　HTML4.01で用意されていた要素に加え、<article> <section> <nav> <aside> <header> <footer> <figure> <figcaption> <main>を選択し、それで足りない時にはじめて<div>を使う。HTML4.01の時代に、『id属性及び class属性と併用することで、文書に構造を付加するため( http://www.asahi-net.or.jp/%7Esd5a-ucd/rec-html4 … )』にDIVを使ってきた人には、本当に朗報です。
　文章を読み取り、構成要素に分解して最適な要素を駆使してマークアップする。

　あとはプレゼンテーションを担うデザイナーに引き継げばよい。どんなに大きなデザイン変更があっても困らないでしょう。デザイナー側からすれば、これほど楽な仕事はありません。

　まあ、
・デザインは他社で行います。どのようなデザインも可能なようにシンプルなHTML策せいてきますか？
・他人が作ったHTMLを希望通りにデザインできますか？

　と注文すれば、概ね分かるかと(^^)

No.5 回答者： simpleweb 回答日時： 2014/01/31 20:26

サイト構築のためにデザイン・コーディング、どちらも兼務している者です。

発注も行っておりました。一意見としてご参考になればと思い、回答させて頂きます。

結論としては、当事者間でいかに緻密な連絡をとるかでやり易くもやりにくくもなります。
（結局、緻密な連絡ができず、兼務することになっているのですが・・・。）

長文となり申し訳ないのですが、ウェブ作成時の流れ概要、その段階ごとの困った点という流れで記載いたします。
・・・技術者視点か、と言われると微妙です・・・

当方のウェブ作成時の流れと困った点は大まかに下のような感じです。
（肝は両者間の連絡取り合いによるイメージの共有と、共有できるくらい土台の
知識があるかどうかかな？と感じております。）


１．コンセプト・目的・必要なページなどもろもろ土台を決めます。
　　（ここ大事です。目的が決まっていないと大変です。
　　とりあえず作って！だけではデザイン側もコーディング側も大弱りです。
　　一番出戻りコストが発生しやすい根本です。（失敗談あり。）
　　どんな目的で、何のために作るのか。その場合、どんなページが必要なのか、
　　と細かく決めていきます。
　　ページ階層やそれぞれの目的もあると楽です。

　　そしてこの段階からデザインの方と共有します。（できればコーダーの方とも。。。）
　　そうするとここはこんな感じのデザインになります、それではこんなコーディングが
　　良いですね、とアイディアをいっぱい出して頂けます。ラフ画レベルまで
　　この段階で作ったりしてます。）

　　→参考までに...
　　どんなことをどんな風に決めるか、
　　実際にWEB作成の流れを掴まれると良いと思います。
　　下記サイトは非常に参考になると思います。
　　http://webdesignrecipes.com/web-development-flow/
　　目的によってデザインも異なります。
　　基本をしっかり作ると、後々楽です。


２．デザインでラフ画から細かいレベルまで作成（デザイン編）
（ワイヤーフレームのみの設計図のみでは、コーディングの方に
　ウェブデザインも色も画像も全て自分で判断してね、というお話になります。
　コーディング者は泣きます。正直。もれなくイメージと違うサイトができあがります。
　2回程経験しました。）

→ある程度の解消法

ラフ画だけではなく、
色、ピクセル、使用する写真など、フレームワークレベルよりもさらに細かく、
全ページ端から端まで色を載せたものを作ります。
そうすることで、コーディング側業務でここは何ピクセル？とかここは何色？
どのフォントを使用するかとか、フォントは商用利用可能かとか、そんな疑問を解消します。
そしてそのデザインを共有します。
なぜこのデザインか、サイトの目的にあっているか、コーディングはできるか、等。
明るい色にして、とかもうちょっと暗く、とか。
ここは動かしたいとかどういう風に動かそうとか。
　　　
部分部分は良いパーツでも、全体に載せてみたらぐちゃぐちゃ、なんてこと多々あります。
フォントの数とか、色合いとか。まとめるためのコツがありますので・・・。
それを経験してから、デザインは上から下まで作ることにしました。
以来、お互いの認識違いによる戻り手間が解消しました。



３．そのサイトの目的に沿ってコーディング

メンテしやすく単純なものにする、キレッキレの最新コーディングにする、など
目的に応じて言語を使い分けしてもらいます。
今はメンテナンス必須ですので、メンテナンスのしやすい単純なコードを使ったりしています。
きれっきれのコードで書いて、理解できずに結局全部リニューアル時に全カット。
よくよく見たら不安定な動きだった。ブラウザによって総崩れ。
なんていうこともありましたので。
デザイン画に従ったコードをお願いします、と何度も・・・。
　　　
　　　→あとはプラスとして・・・
　　　稼働検証も必須です。Macの場合、Macの主要ブラウザでは？
　　　Windowsの主要ブラウザでは表示が崩れないか？など。
　　　対応OSによってバージョンも異なりますので、コーディング時、ここのブラウザに
　　　対応したコーディングをしてください、とします。
　　　ブラウザによっては結構崩れたコーディングで納品されて、手直し、
　　　なんてこともありました。
　　　


時々デザインが甘くてコーディング⇔デザインでいったりきたりします。
途中でこんな風にしたい、とか出てしまいます。（WEBは流れが速いので...）
そうした場合はまた3者で相談→改訂といいう流れになりますね。

如何に両者間の連絡を密にとり、お互いの認識を一致させるか、でだいぶ解消します。

連絡が潤滑ができれば、やり易い業務になるかと。
（結局、当方が数回デザイン～コーディングまで担当して、基本知識をつけました。
全て細かくデザインまでやって、コーディングも使用するコードを限定して、
という感じで差異を少なくしています。
あとはテストを繰り返してオープンしています。
オープン時に出る想定しなかった差異など、それでも出てしまう差異部分はこっちで直してます。）

ご参考になれば幸いです。


※余談
遠隔で離れている人との連絡は、下記ツールを使ったりしています。
タスクもあわせて管理できるので、楽です。
グループとなると有料ですが・・・。
http://www.chatwork.com/ja/