[PHP-users 2434] Re: プログラマとデザイナーの分担

Wed, 3 Oct 2001 17:49:28 +0900

もり です。

「ゲッ、表題が長い」って事で、表題短くしました。

## 長い(桁数の多い行もありますが、ちょっとしかないのでその為に見難い人は
## ちょっと我慢してねぇ!)

表題: [PHP-users 2377] Re: プログラムの知識がまったくない人でもデザインを作成できなければ
日付: Mon, 01 Oct 2001 17:14:51 +0900
ID:   <20011001171451#3#H'S@itboost.co.jp>
<mats@itboost.co.jp>(松嶋祥文)さんの書かれた上記メールに関してです。

反論ではないです。(はじめに断わっておきます)

> ロジックというのがそのぐらいのことであればおっしゃる通りに簡
> 単な話ですが、ループなどの制御構造が入ると難しいですね。
>
> 例えば、このページには、データベースの hoge テーブルの行数分
> だけ table を作成し、その中身のデータは foo テーブルにありま
> す、でも、テーブルの色や配置はデザイナがやります、てな場合は
> もり様の方法ではかなり苦しい気がします。
> 決して特殊な例ではないと思います。

どんな形に対応するかははじめに決めるお約束次第だと思います。
その程度の事迄なら、デザイナさんには同様な事をして貰いできない事ではない
ですが、どこ迄の事が簡単にできると言うかはプログラマさんの経験だとか、
別の要素にも係わってくる事ですね。

データベースを見ないと行数がわからないのだと、そのままデザイナーさん
だけではできない気がします。デザイナーさんにこの表は何行から何行に
成り得るので、その間で適当に見える様にデザインしてねとお願いする時点で
私が書いた様な骨組みを作ったり約束する事は難しいわけではありません。
変換する道具は例のものよりはほんの少し複雑に成る(少くとも多くの人が
すぐに思い付く位に容易ではあると)と思いますが。

> また、実際にやってみると HTML のタグについている属性（主にデ
> ザインには関係ない部分です）や あるタグに挟まれている部分を
> プログラムから変更したり、追加したりしなければならなかったり
> しますし。
> ということもやろうとすると、単純な方法ではすぐに破綻します。

逆にいうと単純な方法で破綻しない場合には単純な方法を使えば良いという
事でもありますよね。また、どこ迄なら簡単にできるというのも参加している
メンバーによって違ってくるでしょうし。
まぁ、色々な面でバランスを考え(プログラマさんの知識・経験やデザイナー
さんの知識・経験も含めて)、マネージャさんが考える事ではあるのでしょう
が。(幾つかは兼任かも知れないけど)

> | > JSP や FastTemplate もそうですが、一つのファイル中に構文レベ
> | > ルでは *ML と同じでも、そこにはいわゆる HTML によるデザイン
> | > とは違う記述が混在してしまうと、並行作業という観点からすると、
> | > 非常に作業しにくい印象があります。

FastTemplateは使った事がないのですが、一人でない作業にはそう言った面は
必ずありますね。ルールもありますが、根底にある常識自体が個々のメンバーに
よって違う場合も多いので、何らかの方法で調停しながら作業する必要がありま
すね。
時には非現実的な話をすると、人選の前にどんな能力を求めるかを明確にできれば
非常に旨く並行作業のできるチームを作れる可能性はある気がします。
多くの成果は様々な要素の集まった結果だと思いますし、旨く設計すれば多くの
部分が単純な作業者に分担させ得る場合が多い様に思います。(誰でもできる事を
[面白くない]ちまちま嫌な思いをしながらやる事も多いですが。)

> | > 非常に作業しにくい印象があります。誰かが必要な記述を消してし
> | > まったり、ファイルの同期をとったりするのが実際上難しかったり
> | > するんじゃないかなーという、まぁ単なる予想です。^^;

一見、言い得ている様に見えます。実際はどうなんでしょうね。コメントじゃなく
「ここはプログラマさんが実際のデータを挿入してくれるので消しちゃダメ」等と
見せる様にしておく(お約束として; <? echo ... ?>のかわりに等)とかする
と、そんな事は避けられそうに思いますが。

## 人は約束を全て守れるわけではありませんからね。不注意や忘れている事
## だってあるし。忘れられてもわかるような手段を講じる事は不可能ではない
## 気がします。そこはアイデア次第という事で。

> | それは、作業手順を考えないからじゃないかな。私はそれなりにできると思いま
> | すよ。
> 現状は内向けシステムを主として作っているので、デザイナーが絡
> むことはあまりないです。で、作業もこっちのやり方でできるので
> すが、作業手順は業務によって異なり得る要素なので、できれば工
> 程に多くの制約を課さない方法が望ましいと思っています。

おっしゃるとおりです。
お約束と能率向上分は天秤に掛けても良いと思うし、決めておけば簡単にできる
お約束位は作ったり使ったりする事を考慮しても良いとは思いますが。
まぁ、すべきがそうでないかは、現場の事情も考慮する必要はあるでしょうし。
(全てができる人にやってもらうのが理想なのでしょうね。)

> 例えば、デザイナとプログラマが固有の「ファイル」に対していろ
> いろ打ち合わせするのではなく、お互い最初に決めた「ルール」に
> 従って独立で作業をして、最後にそれぞれの仕事結果をガチャっと
> 自動結合すれば、ズバっと動くようなイメージですね。

例としては簡単すぎた様ですがそういうイメージを持ってました。
まぁ、単純な場合にしかできんと書かれてしまったけど、複雑な場合でもできる
様にしようと思えばそれなりに手間が掛かるよ程度に思います。
その手間は多大になるかも知れないし、そうでもないかもしれない。
具体的にやりたい事がはっきりしていれば、その成約の中で十分検討に値する
場合もある(とうぜん、手間掛かりすぎって事もあり得る)って感じでしょうか。

> | 例えば、dreamwaverの挿入するコメント行を使えば、デザイナさんにお願いする
> | 方法もデザイナさんが慣れた方法でできるかも知れないですしね。
> 
> そうなんですが、FastTemplate 方式だと、例えばそのコメントを
> 挿入する位置がファイル中で一行違えばプログラムは正しく動作し
> ませんよね。私がデザイナーだったら、出来上がる HTML のデザイ
> ンに命をかけたいので、HTMLファイルの中身のこの位置にあのコメ
> ント書かないと、とか気にしたくないなーって思いました（が、こ
> こは個人的な印象なのであまりポイントではないかも です）。

デザイナーだったらという仮定、そうですね。デザイナーさんってその環境で良く
見えるページというか、実際に見えているものに対する思い入れが強いですからね。
## 目の前にデザイナーさんがいると(特にページを見せる)目の悪い人は大きな
## フォントでないと見えないかもとは言い難い雰囲気がありますよね。

> # それに比べてタグに id つけるのがどうかといわれるとアレですが。^^;
> # id をつけることはロジックを構築することの一部ではないかな？と。
> # ミスがあった場合も、ミスの発見者であるプログラマ側の変更だけで
> # 対応できる場合が多いですし。

それも、ルールの一つではと思います。
私はわざわざ分けては考えてませんでした。
そもそもプログラマさんがお願いする事はどれもロジックの一部だと思います。
例えば、<? echo $aisatu_str ?>入れといてっていうのも含めて。

## でも、簡単な事についてのみ安易に書きすぎたきらいはありますね。(to わたし)
## 反省します。