愛車:マツダアテンザ
Webを中心とした、ビジネス&テクノロジーに関する思いつき
by F-shin
[ このサイトについて ] [ F-shinについて ] [ トップ ]
iPhoneアプリ
author:えふしん
photo_20.jpg
藤川真一について


初代モバツイ開発者
想創社再創業 / KMD博士課程
著書〜100万人から教わったウェブサービスの極意―「モバツイ」開発1268日の知恵と視点 [Kindle版]
お求めやすい夏休み特価!
このカテゴリ[Web系]の最新30件
本ブログは移転しました インターネットの遊び方を身につけよう ネットでの選挙活動と投票率 Web2.0がうまくいかなかったワケ WebにおけるMVCアーキテクチャの勃興と変遷 何故、PCはブラウザ、スマホはアプリなのか。 言っとくけどスマホは退化でもあるからな。 アイコン5000円とか、Web受注(発注)価格について。 残念なWeb論の骨子 HTMLってホントよく出来てるな。 「やまもといちろう×イケダハヤト対談イベント」のログを読んで ネットサービスの成功者は「とりあえず受託」という言葉使うのやめません? 全収集型RSSリーダーの終焉とソーシャル化するWeb 頑張ると報われるプログラマーの社会とは。 Perlが○○な話 アメリカ製品のすごさと不思議とワイヤフレーム どの人件費を考えても絶対にお得!利用規約ナイトがきっかけの本が出ます。 クラウドやモバイルを、もっと仕事で活用したいけど、どうやって会社を説得したら良いかわからない! スマホアプリらしいUXとは。 インターネットの変化に対して起こるモヤモヤすることを考え、整理する活動 Facebookは見なくてもいい情報が出てくるSNS 「あなたは影響力があるから、そんなことを言っちゃいけません」の問題点 Facebookに時間を取られすぎる対策 Paypalの本人確認がむかつく件 ネット系イベントがとても主催しやすくなった件 モバイルファーストが失敗なハズはないが、今はまだ時期尚早 やりがいはソートできない…非情なデータベース社会 2012年までのふりかえりと2013年へ ブラウザという平面の限界 ブログ記事の流通の難しさ
[このカテゴリをもっと見る]
Powered by
Movable Type

February 08, 2009

スポンサーリンク

先日、お昼ご飯の際に仕事の話をしていたら、

「開発者として一生懸命書いたUIの制御コードを、デザイナーが全部入れ替えちゃったんだよ」

という話を冗談で話をしていた。

なかなかビジネス的にお客様に伝えるのが難しい概念だったので、どのように表現するか?を本人なりに考えてコードに落としたが、よりわかりやすいビジュアル表現に、ばっさり入れ替えられたということ。

冗談とは言え、それが話に出てくる以上は、相応に気にしていたのだろう。

逆に、僕が昔怒られた例として、Flashのデザインに組み込まれたインタラクションの制御コード(Action Scirpt)にサーバサイドの制御を加える作業で、基本となるデータ管理のコードを全部書き換えたら怒られたということがある。

当時はまだモダンプログラム的なことを意識していないと、オブジェクトのアクセサなどを使った効率的なプログラミングをFlashデザイナーが行うというのは難しくて、割と場当たり的なコードになるのがFlashの特徴だったが、サーバサイド制御の効率性を含めて、そこはこちらの都合の良いように書き換えた。

とはいえ、彼のインタラクションデザインの設計思想は当然そのまま使っていて、互換は当然取ったまま、コアのコードだけを全部入れ替えだけなのだが、コードが書き換えられたこと自体が気に入らなかったという次第である。

おそらく冒頭の話もデザイナーの人も、ビジネス要件となる根本となる思想は維持したまま、よりエンドユーザーにわかりやすい形でブラッシュアップしたということだろうけど、そこに書いてある制御コードが書き換えられたことで、言葉は悪いが踏みにじられた感というのが出てきたのだろう。

その人の成果物として、どこまでが重要なところで、どこまでが枝葉の部分なのか?というのを判断するのはなかなか難しい。

僕個人の考え方からすると、コンピューターのプログラムに一番大事なのは、そこにあるビジュアルデザイン、設計思想やアーキテクチャから醸し出される空気(コンテキスト)に宿るのであって、コードそのものに宿るのではないと思っている。

もしかしたら先頭を走るプログラマやデザイナはそうは考えないかもしれないが、少なくともチームで後から何かをする人にとって、一番大事なのは元にある世界観を踏襲したまま新しいフィーチャーを組み込んでいくことであって、二番手以下の工程の人というのは、常にオリジナルの空気を読みつつも、うまくやるにはどうしたら良いだろうと考えているということを知って欲しいところではある。

じゃなきゃ恐れ多くてリファクタリングもできなければ、機能拡張もできない、という理屈になってしまう。

しかし、今までいろんな人に聞いた話を総合すると、開発者がこれぐらいは問題なかろうと思ってやったことが、思わぬところでオリジナルの成果物を作った人を傷つけていることはあると思うので、どこまでがOKでどこからがNGかと言う判断はなかなか難しい。

これぐらいはOKだろと思うレベルが人やシチュエーションによって違う。

とりわけビジュアルデザインについては難しく、極論だが1pxでも改変されることを許さない人が出てくるケースはありうる、というのが経験論である。HTMLコードも同じかもしれない。Strictなコードクオリティを心情とする人が、開発者がカジュアルに埋め込んだHTMLに憤慨するケースは少なくないだろう。お客さんに納品したら運用でめちゃくちゃにされた、という文脈もこの辺に関連してくる。

デザイナーに関して言うと、そのコダワリがあるからこそ1px単位のデザインができるわけなのだが、とはいえ、開発の現場で、それをどこまで尊重可能かという都合の部分は、いろいろな立場や状況によって違うだろうなぁとは思うところ。少なくともアーティスト作品を改造する人はいないだろうし、「Webアプリ」や「Webサービス」であれば、後から仕様そのものが変わることは少なくない。成果物が目指す目標に対して、より良い方向に進むのであれば、例え誰が不満に思おうと変えることを許さないわけにはいかない。

解決法はシンプルで、とりあえず後からやりたいことがあったら、オリジナルを作った人に相談してみるというのが一番大事なことかもしれない。しかし、他社に発注していて、お金が発生してしまうケースだとどうしても解決できないこともあるかもしれないが、成果物への意識が強ければ調整も不可能ではないかもしれない。とりあえず相談してみるというのは大事だと思う。開発側は開発側で、そんな時間ないよ!という声も聞こえてきそうだけど。


ちなみにここではデザインとか書いてみたけど、「文章」にも全く同じことが言えるので要注意。メルマガの文章などを複数の人がいじりだすとまず破綻します。改変する人は、元の人以上の文章力が必要なハズなので、気軽にいじるのではなく、気に入らないところがあったら、最初に書いた人にフィードバックして直してもらうのが良いでしょう。

建築の壁や塗装を第三者がいじることはそうそうないけど、HTML、画像、文章などの改変が容易なデジタルデータだからこそ、注意しなくてはいけない点、とも言えますね。

スポンサーリンク
■同じカテゴリ[Web系]のエントリー
<<前の記事 jQuery PluginのDate Pickerで、日付が1月なのに、2月になっちゃったりする不具合について。
>>次の記事 価格.com出店店舗の価格調整bot
■このblogの書き込み最新3件
本ブログは移転しました インターネットの遊び方を身につけよう トトロが陽なら、『風立ちぬ』は陰?〜『風立ちぬ』の感想
この記事への提案、提言一覧
この記事への提案、提言









あなたの情報を保存しますか?