iwalog

なんだかブログに復帰してからのエントリが時事放談状態なのでネットの話。最近のネットはギークと呼ばれる人たちがウェブサービスを作るのがブームなのか何か知らないけれど、ポンポンと似たようなサービスが雨後の竹の子のように乱立していて、競争が激しくて結構なことだと思う。

ただ、ふつうに仕事をしながらネットをしている立場からするとちょっと飽和状態で、発信するためのツールだけあってもそんなに発信する情報とかないし、そもそも発信を全くしない受け身な人がマジョリティであるとおもう。テレビで慣れてるし。

アルファブロガーとかも結構な事だけれど、なんだかんだ言ってテレビのニュースキャスターが一言失言する方が遙かに影響力が大きい。OpenIDだインタレストマッチだっつったって僕を含む一部の物好き(アーリーアダプターですか)が追いかけてるだけで、正直実生活にはどーでもいい事だったりする(意義は分かってるけどあえて)。

と、なんかイノベーションを否定するような事を書いたけれど、別に冷めてるわけではなく、いろいろ高度な技術やアイデアを駆使してるけどそれって限りなく少ない人たち(それもほとんど東京在住)がネットの中で盛り上がってるだけなような気が正直する。なんというか、もっと実生活に根ざした事って出来ないもんですかね、と最近マジメに考えているのです。

筑紫氏の死去に対する久米氏のコメントが、「久米宏のテレビってヤツは!?」で流れていた。ラジオでちょっとコメントしたのは聞いたんだけれどあまり詳しく触れていなかったが、さっきのテレビでは目頭を熱くしながら語っていた。

番組での発言とか彼らのスタンスはちょっと横に置いておいて。同じ18年半という長い間、隣り合わせに近い時間帯で同じ報道番組をやれた彼らは、仕事仲間というか同士というか、そういう関係としてとても恵まれていたんだろうなぁと思う。

今のようにインターネットがなく新聞とテレビが権力をふるっていた時代に、罪悪は別としてそのメディアをある意味では利用し、制限はあるだろうが自分の言葉で自分の主張をすることは、とても意義のある仕事だったんだろうと思う。

「ご冥福をなんて言えない。冥福されちゃ困る。生まれ変わってもう一回筑紫哲也をやって欲しい。」と最後に久米氏が語ったけれども、きっと彼はその後に、「そして、僕もまた久米宏をやりたい。」と言いたかったのではないかと、勝手に邪推した。仕事仲間としての彼らの関係が、ちょっとうらやましかったので。

受託開発の極意
–変化はあなたから始まる。現場から学ぶ実践手法
岡島 幸男 (著)

要件を定義するには、ユーザと同じ視点を持つ必要があります。つまり、どうやって作るか(How)ではなく、何を作るか(What)、なぜ作るのか(Why)という意識をもたなくてはいけません。

開発者は視点を切り替えなくてはいけません。システムを作る立場ではなく使う立場で考え、お客様と一緒に考えを整理していく必要があります。

そこに必要なのは広い意味での問題解決能力であり、プログラミングや設計のスキルだけでは足りません。業務に対する知識はもちろんのこと、要件を引き出すために高いコミュニケーションスキルが必要となります。

同じ福井の永和さんの本。ちょっと前にネットの中でもいくつか取り上げられていたので、受託の現場に帰ってきたら読もうと思っていた。「SEの教科書」とだいたいの主張は同じなんだけれど、クライアントとの接し方、見積もりの作り方、要件定義の仕方と具体論に踏み込んでいる。

こういういろんな本を読んでいると、あるべき受託開発へのイメージがだいぶハッキリしてくる。今の時点でイメージしているのは「結果に責任を持って物も作るコンサル」といったところ。コンサルと書いたのは、コンサルって口だけなイメージがあるので(失礼)、実際にそれをクライアントと一緒に作っていくサービス業のようなイメージ。

クライアントから言われたシステムをクライアントから言われたとおりに作ったり、いかに他社より安い金額で開発するかに心血を注いだり、自分たちのやりたい技術のエゴを振り回してクライアントを放っておくのではなく。クライアントの求める物と自分たちが持っている技術の間を探り、必要とされているニーズを解決する事が、本来の受託開発という仕事なんじゃないのかなぁという気がする。

この本では最終的には組織を変える事にまで言及しているけれど、できればクライアントを変えるという所にまで踏み込んで欲しかった。安かろう悪かろうのシステムを求めるクライアントは最終的にクライアント自身が損をして、システム開発に対するイメージがどんどん悪くなって次の案件でも同じような事を繰り返してしまう、というのはどう解決したもんだろうか。

SEの教科書2
~成功するSEのプロジェクト計画・運営術
深沢 隆司 (著)

読者の皆さんの会社のプロジェクトが、必ずと言うほど遅延したりコストオーバーになったり、多くの仕様変更やバグが発生しているとして、それを読者自身が「仕事とは、プロジェクトとは、そういうものだ」と考えているとしたら、あなたの脳の仕事で使っている部分は、すでに誰か他人のものになっている(あなたの思考パターンではない)かもしれませんので、そう自覚してください。(中略)

そして、これが行われていないために、本来は頭脳労働のはずが、実際には体力勝負、頭脳勝負の業界になってしまっているのではないかと思います。

前作のSEの教科書を借りて読んですごく面白かった記憶があったので、本屋でこれを見かけて即買ってみた。前回に引き続き結構面白くて、スケジュールを立てるタイミングやその組み立て方は参考になった。

これを読んでいると、SEとかプログラマーに必要なスキルというのは、もちろん技術も必要なんだけれど、コミュニケーション能力な気がしてくる。まあコミュニケーション能力はどんな仕事でも大事なんだけれど、SEやプログラマは他の業種に比べてその辺を軽視しているような気がしてくる。

陳腐な例だけど、クライアントがとんでもない要求をしてきてその実現方法を必死に考えていたのに、営業がシンプルに実現できる代替え案を提示したらあっさりOKをもらってしまったりと、技術だけ、自分たちだけで考えてしまう傾向があるように思う。

そこで大事なのは、やっぱりクライアントが何を求めているのか、どういった課題を解決したいのかという「何が問題なのか、どうしたいのか」を技術手法ではなくニーズというレベルで把握する事なのかなぁと思う。

プログラマとコミュニケーションの取れるディレクターになるには – あと味

静的Webで通用した時代と違い、今はプログラマとコミュニケーションが取れるスキルは必須です。技術について朝までプログラマと語り合えるぐらいの知識を持っていた方が、私は良いと思っています。技術なくして提案はできない。

id:jdgがプログラマとディレクタの関係について面白い事を書いているので、補足というか、別視点というかそういう事を超上から目線で自分への戒めも含めて考えている事を書いてみる。新潟の方のダムが好きなプログラマから「よくお前が言えるな」といわれそうだけれどとりあえず書く(汗。

そもそも、「プログラマとコミュニケーションの取れるディレクター」というのは間違ってはいないのだけれど、それをちょっと誤って解釈すると「プログラマと仲良くなる」というような解釈になってしまいそうなので、「ディレクタはクライアントとプログラマ(orデザイナ)の通訳であるべきだ」と解釈した方が正確ではないかと思う。

で、id:jgdか量を書いて主張している「何を使えば何ができるかだけ把握し使用方法は捨てる。」には同意。「できることと出来ない事」についてはかなりの精度で把握している必要があり、仮にどれだけ時間かかってもいいから自分(ディレクタ)でやってみろと言われたときに出来る事の範囲で案件を着地させなければならない。

それから、ディレクタはプログラマやクライアントと常にフラットな立場であるべきだと思う。時にはプログラマが要件を満たした後でも納期を考えずクオリティを追求したり、クライアントのニーズを考えずに技術トレンドに走りたがったりしたときに、客観的に判断して制御しないといけない。

とはいえ、それはプログラマに対して高圧的になると言う意味ではない。プログラマが納期がこれだけかかるといわれればそれを問答無用で納期を理由にハードワークさせるのではなくクライアントと要件を調整する責任がある。じゃなきゃ伝書鳩だ。まあこれは当たり前ですが、けっこう無視されているのも事実。

具体論に進むと、プログラマほど属人的な性格が高い仕事もないのではないかとおもう。ある人が10日かかる事もある人は1日で出来たりする。なのでディレクタとしては、「プログラマ」として認識し人区勘定するのではなく、「プログラマのAさん」「プログラマのB」さんと別の職種のようなレベルで区分けをし、その人の得意な分野や好きな事、苦手な分野を把握してアサインする必要がある。要はプログラマはプログラマというファンクションではないという事。

また、前にやった案件の焼き直しでは、優秀なプログラマほど飽きる。クライアントのニーズを前提として、技術トレンドやその人の志向にそった「燃える」ワンポイントな機能や技術を盛り込んだりして、プログラマ(orデザイナ)を楽しませる事も、ディレクタのとても大切な仕事のひとつだと思う。

細かい話としては、プログラマにはまずワークフローを共有しお互い納得するまで議論する。本人が意識していないレベルでフォーターフォールを前提に考えて仕事をしている人が多いので、ウェブには沿わないのではないかという事は説明する。なので、要件を伝えるときには、「決まっている事」「決まっていない事」「変わる可能性がある事」をきちんと説明する。そうすれば優秀な人ほどいい意味で手を抜きながら開発をスタートしてくれる。

以上書き散らかしましたが、これがまったく出来ていない時に僕の無茶に答えてくれた新潟のダムが好きなプログラマや、なんだかんだでつきあいの長いインプレッサが好きなプログラマに全て教わったことです。心から感謝しています(棒読み)。というわけで、ツッコミ大歓迎。(酔った頭で書いています。その点ご考慮下さい。)

佐藤可士和の超整理術
佐藤 可士和 (著)

整理して新しい視点を見つけるという事は、それまで見えなかったものが見えてきて、視界がクリアになるという事。新鮮な気分になったり、インパクトを与える切り口が見つかったり、人を感動させるポイントが把握できたり、ポジティブな発見がたくさんあります。つまり、視点を見つけたその時点で、アイデアの糸口になっているはずなのです。

クリエイティブなイメージの佐藤可士和いう単語と、地味でロジカルな整理という単語の組み合わせが新鮮で買ってみたら、いい意味で裏切られた。本の中でも書いているけれど、本人は自分の事を「自己表現をしているアーティスト」ではなく「クライアントを診療し問題を解決していくドクター」と捉えているらしく、それを聞いたら納得。

クライアントが見えていないところまで客観的に対象を分析し、グループ化したり優先順位を付けながら何が問題なのかを見極め、その問題に対処するアイディアや表現方法、情報構造を考えるという著者の思考プロセスを、著名な作品を上げながら解説する。

これは自分でも実感していた事だけれど、「何が問題なのか」を見極めクライアントと意識を合わせる事が一番重要で大変だと感じる。「問題を20日で解決しなければならないとしたら私は19日かけてその問題を定義する。」と言ったのはアインシュタインらしいですが、問題さえ定義されれればあとは何とかなる気が最近している。そういう意味では、要件(道具の形)が定義されているプロポーザル方式っておかしいんだよね。その道具で問題が解決できるか分かってもいないのに道具の形を指定してるって。

ひとつ残念だったのは、「本当に商品価値のない商品の場合どういったディレクションをしているのか」という点については、「残念ながらいかんともしがたい」とあっさり切り捨てられていたこと。地方で仕事していく中ではそういうクライアントの場合も結構あると思うんだけど、簡単に切り捨てる事も出来ないし。。。

数年ぶりにウェブサイト制作の仕事に戻ってきてまずしたことは、全てを疑う事でした。別に、ひねくれた訳ではありません。ちょうどタイミングよくあるクライアントからのサイトリニューアルの案件を担当する事になり、そのサイトを作る上で、必然的にそこを考える必要が出てきたのです。

「なぜサイトをリニューアルする必要があるのか」「なぜ現状のサイトではだめなのか」「そもそもそのクライアントって何なのか」「そのクライアントは社会に必要なのか」「そのクライアントは別のものでは代替えが効かないのか」「なぜ現状のようなしくみのなかでそのクライアントが存在しているのか」「そのクライアントってそもそもいらないんじゃないか」と。

それは、なにもクライアントを否定しているのではなく、上記の質問を繰り返していると、不思議とそのクライアントの存在価値、存在意義が浮き彫りになってきます。そこを見ないでおいたまま、サイトのリニューアルなんて出来ない、と思ったのです。

同じ会社の人からは、そこまで考えなくてもいいんじゃないかと言われたのですが、逆にここを考えずに出来る人がいたらすごいと思います。大げさかもしれないけれど、僕はウェブサイトというものを作る事でそのクライアントを変え、そのクライアントのユーザをも変える事が出来ると信じているからです。自分が出来る事と、社会に必要とされる事、そのクロスする部分が、僕にとってのネットであるから。

都合1ヶ月半ほどお休みしていましたが、今日からまたブログを再開することにします。この1ヶ月半は、ブログもしないし、RSSも全部購読解除するし、メッセも起動しないしと、かなり意図的にネットから距離を置いてみました。今では少しずつそれぞれのサービスを利用し始めてますが、以前よりいい距離感で使えているので、ブログもそろそろ再開してみる事にしました。

ブログを閉じたのは、また4〜5年前にやっていた受託でのウェブサイト制作という業界に戻ってきて仕事をし始めたときに、自分がその4〜5年前の知識や経験をベースに仕事をしている事に気づいたからです。

それはけして悪い事ばかりではないと思うんですが、ゼロから考える事をしないという悪い面だけが出ているように思い、この再スタートする時期に一度リセットして、過去に自分が学んだ事でも現在それは本当に正しいのかと疑って再構築しないと、過去をずっとひきずってやっていってしまうように思ったからです。そのときに、過去の蓄積の象徴であるブログがとてもじゃまなものに思えました。

「それって本当に正しいの？」と前提条件を疑う事はとてもしんどいもので、答えが出るかどうか分からない暗闇の中をずっと進むような感じに似ています。今も全ての答えは出ていませんが、ある程度足腰の部分は見えてきたように思うので、またこのブログで自分との対話、読んでくれる人との対話がしたいと思えるようになりました。また宜しくお願いします。

今日から、株式会社いづるに入りました。8月中からちょこちょこ行っていたので、入社日といっても朝一から行ったというだけで特に感慨に耽るような事もなく普通の一日だったのですが、PC環境設定したり、早速仕事ふられたり、メールアカウント発行したりといった感じ。

ちなみにメールは会社のPOPをGmailに転送して、iPhone、MacBook Air、会社のWindowsVistaに設定したら、どの環境でも同じ状態で見れ、1カ所の変更が全てに反映されてかなり便利。IMAPって概念としては便利と分かりつつもいまいち実感がなかったんだけど、複数のデバイスを持つようになってはっきり分かった。

前職の約1,500人の職場から一気に僕を入れて6人の会社に移ったわけですが、一人でやれる作業の範囲が広く、お客さんの顔がきちんと見えている環境というのはやっぱり楽しい。これまでの経験を生かして、楽しく働ける会社になっていけるよう少しでも力になれればなぁと思う。

前々職時代にお世話になった人ともいろいろ仕事が出来そうなので、楽しみ。とりあえずはコーディングやディレクションでお金を稼ぎつつ、サーバやプログラミングをきちんと覚えてそっち方面のスキルをきちんと身につけていきたいところです。なにとぞ。

明日から仕事なので、テスト前の学生よろしく部屋中をひっくり返して大掃除をしていたら、過去に使っていた携帯端末が出るわ出るわ。元々ガジェット好きなので機種変しても捨てない人なのですが、充電器までほぼ完璧にコンプリートしていたので、全部充電して写真に収めてみた。実際には、一番最初に使い始めた「DoCoMo N502i(NEC)@2001」と、「DoCoMo SO503i(Sony)@2001.03」の次に使った「DoCoMo SO504i(Sony)@2002.06」と、初代CLIEの後に買い換えた「CLIE PEG-T600C(SONY)@2001」があるのですが、N501iとSO504iはたぶん壊れて捨てて、CLIEは誰かにあげたような気がするのでこの撮影には参加できなかった。

■DoCoMo SO503i(Sony)@2001.03

前のN502iは緑の単色液晶だったのですが、256色程度のカラーになった。N502iの時に十字キーが使いづらかったのでジョグダイヤルがほしかったのと、POPBoxという予測変換機能に惹かれて買った。あと、これでも液晶は当時のラインナップ中では最大というのもポイントだった。

が、折りたたみを閉じたときにボタンが液晶に当たってしまい液晶が傷つくという欠陥があって、対応がなされた機種に無償交換になった。その後乗り換えたSO504iを使っている時、夜中に車で事故った時に衝突の衝撃でジョグダイヤルが壊れてしまい、電話帳をスクロールできなくなり、事故った時という一番携帯が必要なときに電話が出来ないという経験をし、もう二度とジョグダイヤルは使わないと決意した。

■DoCoMo F505i(Fujitsu)@2003.07

もうジョグダイヤルは使わないと決意した僕が次に惹かれたのが、このモデルが搭載した携帯初の指紋認証機能(0キーの下にあるちっこい枠に指を当てる)。が、認識性能が悪く、結局テンキーで暗証番号を打った方がはやいという結果に。しかも、当時の僕には指紋認証を使ってまで守らなければいけないようなデータも持ち合わせていなかった事に気づいたのは、買った後だった。

■au talby(SANYO)@2004.11

auがオレンジ色のコーポレートカラーを採用し、浅野忠信と豊川悦司のCMで一気にカッコイイブランドとなりドコモを使う事が嫌になってきた頃、数年前に「au design project」でコンセプトモデルが発表されていたtalbyが実際に発売される事になり、MNP(モバイルナンバーポータビリティ)もない時代なので普通にDoCoMo解約→au新規契約で乗り換えた。

カメラは低画質、外部メモリスロット無し、新規格WIN売り出し中なのに旧規格のCDMA 1Xという当時のラインナップとしては性能は貧弱な部類に入る端末だったけど、事前に予約までしてて手に入れた。iPhone以外の日本のケータイの中では一番好きだった。

■au W41CA(CASIO)@2006.02

talbyもかなり使い込んで傷だらけになり、PCサイトビューアーやEZアプリなど続々と投入される新サービスにだんだん我慢できなくなり機種変を決意。当時投入されていたサービスをほぼ網羅しつつも同機能の端末と比較すると圧倒的に薄かったのが決め手。この機種は発売から19周連続でau内のNO1端末となり、僕のまわりにも僕以外で3人の人が使っていた。

さらに、プリセットとして「アデリーペンギン」というかわいいキャラクターが至る所に登場するスキンが選べたのも決め手。GPSあり、おサイフケータイありと前機種talbyからの圧倒的な高機能を楽しみまくった。

■au W52SH(SHARP)@2007.07

一度欲望に火が付くと止まらないもので、ワンゼグがリリースされたのを見てガマンできずに買ったのがこの機種。前機種は当時は薄い方に入ったのですが、その後どんどんリリースされる超薄型の機種に惹かれて、ワンセグとおサイフケータイ搭載の中で一番薄いやつ、という基準で選んだ。

僕は当時(今もですが)テレビを置いていなかったので、これがあれば臨時ニュースとかの時だけ家でテレビが見得れるとバカみたいに喜んで買って帰ったら、自宅ではワンセグが映らなかった。F505iの指紋認証の件から何も学んでいなかった。

■SoftBank iPhone 3G(Apple)@2008.07

アメリカで初代iPhoneが発売されたときは全然関心がなかったのですが、K氏にiPod touchを見せびらかされてカッとなってiPod touchを買ってその楽しさとすばらしさに気づいて以来、早くWiFi以外の環境でもネットがしたくて待ち望んでいた。その後の顛末はこのブログでもさんざん書いているとおり、だめなところもあるけれどものすごくいいところもたくさんあるので、これまでの端末の中で一番満足している。

■CLIE PEG-S300/D(SONY)@2000.09

番外編として、ソニーが発売したPalm端末CLIE。電子手帳とかそういうのが大好きなのでPalmは以前から注目していたのですが、なにぶん端末のデザインがダサイ。そんなマーケットにSONYが参入し、Palm機初のジョグダイヤル搭載ということで、初物も初物に手を出してしまう(この端末はSONYがPalm互換機市場に参入した最初の端末)。

モノクロの画面、遅いCPU，正直なところ使いずらいスタイラス(タッチペン)という三重苦であったけれど、僕はアーリーアダプターだというガジェットオタおきまりの強引な自分への説得で使い続けた。ある日ポケットに入れていたら写真の通り液晶画面が割れてしまったところへタイミングよく発売されたカラー端末も買ってしまったが、SONYは2005年にめでたくPalm互換機市場から撤退した。

こうしてみるとDoCoMo→au→SoftBankとシェアと電波網の低いキャリアに向かって順番に乗り換えている。ここには書かなかったけど、WILLCOMのAIR-EDGEというデータ通信カードを使っていた時期もあったので、主要なキャリアは制覇。

結局今はiPhoneに落ち着いているわけですが、iPhoneが一番しっくり来る所って、これまで一番身近なデジタルがジェットである携帯電話だけ独立したシステムが構築されていてPCやネットの空間と自由に行き来できなかったものが、iPhoneによって携帯電話までネットや自分のPCの一部として管理できるってことかもしれないと思い始めた。

今日の結論。「デジタルガジェットは、欲しいと思ったときが買い時。」