As Sloth As Possible

可能な限りナマケモノでありたい

カテゴリ: 仕事

「スマートフォンについて何か喋ってよ」というかなり大雑把なネタ振りをされたので、第五回ライブドア・テクニカルセミナーでこんな感じの話をしてきました。

あとで動画や資料は公開されるはずですが、大変申し訳ないことにテンパりまくって見るに耐えない感じになっちゃってると思うので、一応何を言いたかったのかを補足しておきます。

iOSとAndroidは違うものだという話

開発環境の違いについてはまぁいいとして、例えばアプリの設計思想。iOSでは「まずアプリケーションという大きなプログラムがあって、その中で画面を表示したり通信したりしてる」って感じの構成になってるのだけど、Androidの場合「画面とかデータ管理機能とかそういう独立した部品があって、それらをまとめたものに名前を付けてアプリケーションという風に見せる」という感じになっていて、後者の方が若干まどろっこしい感じはある。一方でアプリ間でのやりとりについて考えてみるとiOSでは「openURLで他のアプリを起動する」とか「Keychainだとかアルバムだとかを使って(限定的に)データを共有する」とかその程度に留まっているのだけど、Androidの場合はOSが提供する機能も同じアプリ内の機能も他のアプリの機能も全て「部品」という形になっているので、きちんと設計しさえすればデータや機能をシームレスに連携させられて大分可能性が広がる。この考えかたの違いはアプリの作り方の違いにモロに出てくる。

それから、デバイスの違い。iOSの場合はiPhone/iPod touch系とiPad系の二系統しかなく、どちらもApple一社が開発しているので、OSや周辺サービスも含めたプラットフォーム全体のコンセプトから良くも悪くも外れない。一方のAndroidはと言うと、Googleが主導してはいるものの、端末メーカー各社それぞれがOSにカスタマイズを加えてたり、独自のハードウェア(キーボードが付いてたり、先行してFeliCa対応してたり、裸眼立体視ディスプレイが付いてたり、そう言えばゲームのコントローラが付いてたりするようなのも出るんだっけ?)を搭載してたり、小さな画面のものがあったり、横固定だったり、多種多様だ。ハードウェアの違いがソフトウェアに影響を与えないわけが無く、「使い易いアプリって何?」って問いの答えはiOSとAndroidでは当然違うし、Android端末間でも異なってくることもある。

ここまでは技術者視点だけど、当然ビジネス的にも文化的にも異なる展開をするだろうね。と、いうことを考えたら、アプリの企画や開発をするのに「iOSとAndroidは違うもの」って認識は当然持っておく必要はあるだろう。

iOSアプリとAndroidアプリはどっちが作り易いか

率直に言うと、最初のとっつき易さに関して言えばAndroidの方が圧倒的に上。僕の元々のお仕事はPerlやRubyでWebアプリケーションを開発することで、今もアプリ作りのかたわらWebやってるのだけど、そういう人が、ObjCとXcode/IBでアプリを作りクローズドなプラットフォームでお仕事するのと、JavaやJVM上で動く言語とEclipse+ADTでアプリを作りオープンなプラットフォームでお仕事するのとで、どっちが大変かなんてのは言うまでもない。

で、だからAndroidのが素晴しいって話になるのかというとそれはそれで違うんだよってのが、無茶苦茶RTされまくってハッシュタグを埋めてしまった件のスライド(本当にすいませんでした!)の意図。「最初は薔薇色の世界に見えるAndroidも作り続けて行くと段々難しさに気付いていく」「最初はとても理解できないと思ったiOSも作り続けて行くと良さに気付いていく」「だからつまり、最初のとっつき易さだけでどっちかが圧倒的に優れていると言えるわけではない、最初のハードルを越えたら別の問題が見えてくる」っていうのを(一部の人には)視覚的に分かってもらえるように、と思ってあのイラストを入れたんだけど、前日にまどか☆マギカの8話を観て「正直やりすぎた」と反省はしました。あのスライドを見て「きっとこの人はAndroidよりiPhone派で、あと赤い子が好きなんだろう」ってコメントしてる人がいて、いやうん割とその通り(「杏子に『食うかい?』って言ってもらう」ことを願って白い獣と契約しかねないです)だけど、いくらなんでもアレに例えなきゃいけないほどAndroidを悪くは思ってない。Androidが孵す卵はもう少し夢のあるものだって信じてますし、iOSのあの林檎を輝かせ続けるために何が犠牲になってるかに思い至らないわけでもないですし。

魔法少女の話は置いといて、じゃあその「別の問題」ってなんなの、という話でいうと、まず一つはマルチデバイス/OS対応。Androidは自由度の高さが最大の売りだけど最大の欠点でもあって、Androidに取り組んでるところは軒並「端末やキャリアによってお約束事が違い戸惑う」とか「バージョンアップしない端末があってどのバージョンのOSを対象にするか迷う」とかそういうことに悩んでいる。正直、Android開発に関わってない人が想像してる以上にデバイスごとの差異が大きいし、今後収束するどころかもっと個性的なものが増える方向に進むだろう、だってそれが一番の売りなんだから。それに真面目に対応していくことの面倒臭さは、iOSアプリの最初の学習コストを上回ると思う。iOSだってもちろんiPhoneとiPadで両対応ってのは凄く大変だし、最近はケータイだと思って買っていくので家にパソコンも無くアップデートしないみたいな人も増えてると聞くので、その問題からは無縁じゃないんだけど、それでも現時点ではAndroidよりは幾分マシだ。

それから、パフォーマンスチューニング。いくらスマートだスマートだって言ったって所詮はモバイルデバイスなので、タイトなリソースをやりくりしていかなきゃいけない。今まで組み込み機器やローレイヤーなところの開発をしてた人からすれば「何を贅沢な」「ゆとりめ」と冷笑されそうな話だけどさ。スマートフォンアプリに求められる「リッチさ」はどんどん上がって行く一方だけど手持ちの戦力は高性能な戦闘機と言ったところで、その気になれば空母の艦隊を投入できるサーバサイドの開発とは全然違う。これに関して言えばiOSでもAndroidでも同じで、そういう段階に至ったらどっちにしてもそれなりに「難しい」。

クロスプラットフォーム開発に関して思うこと

きっと伊藤直也さんが肯定的な文脈で言及するに違いないと思って(実際してた)内心ビクビクしながら話してたんだけど、どうしても言わざるを得なかったので言ってしまった。一つのコードで両方のプラットフォームに対応するのは、現時点ではあまり現実的じゃないと思う

もちろんアリだろうと思ってる領域もあって、例えばゲームエンジンみたいなものは、凄く効果が高いと思う。最近は一般的な携帯ゲーム機向けのものと同じくらいのクオリティの高いゲームがどんどん増えてるけど、ああいうのは大概UIから自前で作ってしまうし、中のロジックもiPhoneだからAndroidだからということも無いだろうから、細かい差異はライブラリに吸収させちゃうのが定石だろう。それから、コアな部分をHTML5+JSで作って、ブラウザ上でできないことやパフォーマンスが必要なことをやらせるためにネイティブのUIでWebViewをラップする、というハイブリッド戦略も良いと思う。SNSとかブラウザゲームとかだと期間限定のイベントがあったり速いペースで機能改善していったりする必要があって、それで言うとアプリ開発して(iOSならAppleの審査を通して)ユーザにアップデートしてもらう、というプロセスを通すと遅すぎて全然上手くいかない。うちで作ってるアプリだとロケタッチとかは部分的にそんなアプローチをしてるし、今後そういうアプリも増えると思う。

懐疑的なのはトランスレータとかミドルウェアとかの話。Titaniumとかが盛り上がってるのはもちろん知ってるし追ってるけど、最近だと「一つのコードで両方のプラットフォームに対応」みたいな話より「iPhone(or Android)のアプリ開発を楽にする」って文脈で語られることのが多くなってきてるかなーという印象を受ける。まだまだ発展途上でどっちかのプラットフォームのサポートは手厚いけどもう片方は追いついてないだけで、今後は次第に改善していくだろう、ってところもあったりするんだけど、それとは別に個人的には「これだけ"違い"があるんだから、無理して同じ扱いをするよりそれぞれに合ったやりかたをした方がいいんじゃないか」って思ってる。特にツール系のアプリはそうで、それぞれにUIのお作法があるのでちゃんとそれぞれの特性を活かしたUIにした方がよくて、そうなったときに内部のロジックだって無理に同じにしておくより別プロジェクトにしておいた方がかえってメンテしやすかったりする。将来的にどうなるかは分かんないけども、今現在両方のアプリを作ってての実感としてはそんなところ。

というところまで書いて

そんな話が全然出来てなかった自分の話下手っぷりに絶望したのでもう少し練習しないとな、と思いました。あたしって、ほんとバカ。

謝辞

キュゥべえドロイドくんはSENさんに、杏子の林檎はニチロさんに描いてもらいました。素敵なイラストありがとうございました!

ウープスデザインブログ >> デザイナとの打ち合わせってどうすればいいの?を読んで、ほー、と関心する一方で相当考え方が違ったので面白くなって書いてみる。仕事の進め方、プログラマ編。

あ、でも先に言っておくと、俺は「ベンチャーで、Webで、デザイナもディレクタも社内の人間で、自社サービス」っていう非常に限られた領域でしか仕事をしてきたことがないので、今から書くことがプログラマ一般に適用できる話だとは思ってません。タイトルはそういう意図。なので、あくまで上記の前提条件があった上での話だと思って読んでください。

1.やりたいことをある程度洗い出す

「なんかやりたい」とかいう漠然とした要望では流石に「で、俺は何作ればいいのよ」と答えたくもなるので、ある程度まとまるまでやりたいことを出してきて下さい。でも、ここで重要なのは全部洗い出す必要はないってことです。やりたいことがはっきり形になるまでには時間がかかるし、作ってる最中に絶対に軌道修正したくなります。あまつさえ方向転換したくなることもあります。最初から完璧な完成形が見えてる人なんていないんだから、当然です。

作ったものを修正しなきゃらななくなったとしても、無駄ではありません。思い付きであっちこっちフラフラするのはダメすぎますが、作ってる最中に、考えてるときには見えなかった問題にぶつかったり、より良い案が見つかったりすることは多々あります、というか無いことの方が珍しいです。そんなときに「でも、これだけ時間かけちゃったし、リリース予定日も近いし、今さら後戻りするわけには…」なんて言い出すくらいなら、最初から時間をかけなければいい。さくっと考えてさくっと作ってみて、直しては進め、進めてはまた考えていけばいい。1ステップにかける時間が少なければ、何度もステップを重ねられるし、どこかの時点までの作業が無駄になるとしても損失は少ない。

よく、気合いの入ったpptの画面設計書とか作ってくるディレクタさんがいますが、あれはやめて欲しい。プログラマ相手なら、顔付き合せて話して、その最中にホワイトボードに適当に絵でも書いてくれれば十分です。もし先にしっかりしたイメージを用意したいなら、デザイナさんにイメージを作ってもらうか、もっと言えばマークアップエンジニアさんにモック(システム的な部分は作り込まず、HTMLでガワだけ作ったもの)を用意してもらった方がありがたいけど、それだって時間がかかるので絶対必要なものではないです。パワポを書くのに時間を掛けるくらいなら、適当でもいいから動くもの作ってそれについてあれこれ議論した方が有意義です。要素だって、「その機能に必要なもの」を出してくれさえすればそれ以外はあとからどうとでもできる。細かい文言とか先に全部決めちゃっても後から直すはめになるのだから。

2.優先順位をつける

上記で羅列した内容に手書きで順番を付けるだけで構いません。初歩的なことですが、これをしておくと「どうでもいい機能を作り込んでしまったばかりに本質的なところが時間に追われて間に合わせになる」などおかしなコトにはならないハズです。さらに、優先順位がしっかりとプログラマに伝わるのでそれらの意図を組んだ上で機能的に分かりやすく意味付けしてくれるハズです。多分。

3.希望する見た目を添付する

まぁ、プログラマには、いらんと思います。競合になりそうなサービス、とかは勿論チェックしますが、あんまり「こういうの!」って言われるとそれを作っちゃうので注意です。「Twitterみたいの!」って言われるとTwitter作っちゃいます。いや、それは作る側の問題ではあるんだけど。

4.経緯、展望を話す

ここまでに何度となくプログラマとディレクタの打ち合わせはしてると思いますが、その中で経緯と展望を話すのを忘れないでください。つまり、経緯と展望を話すのを忘れないでください。大事なことなので二度言いました。ここまでの手順を踏んでいるだけでは、何も聞かされないで仕事を振られるよりはいい、程度の仕事ができるだけです。「何でそれを作りたいのか、それをどうしたいのか」が伝わっていないと、諸々の理由で見当違いのものができてくることが多々あります。バックグラウンドが共有されていれば、技術者として、作り手としてのアドバイスや新しいアイディアが出せるかもしれません。でも、ただ「これやって」だと、良くわかんないけどやっつけで作っちゃうとか、良かれと思って作り込んで明後日の方向に暴走するとか、結構な確率で起きてきます。

だから経緯と展望を話すのを忘れないでください。三度言いました。

5.質疑応答

ちょっとやっては直し、直しつつ考え、考えつつ作る、みたいなことをしてるとお互いが質問しあうのが日常になってると思いますが、億劫がらずに答えてあげて下さい。逆に、忙しそうだから聞いちゃ悪いかな、とか、こんな初歩的なこと聞くのもアレかな、とか、そんなこと思ってないでどんどん聞いて下さい。

こんなことを公言するのもどうかと思いますが、面倒臭いという理由で聞きたいことを後回しにしたり、質問されたときに「あとで確認しときます」とか答えたりするような悪癖を持ったfaultierとかfaulistとかとにかくfauがつくなんとかって人がいたりしますが、そういうのは悪いナマケモノなので、良いナマケモノに育つよう叱りつけてやって下さい。ごめんなさい。気をつけます。

最後に

こういった流れを踏んでおくと、物事が前後したり抜けたりしてもお互いスムーズに気持ちが良く仕事が出来るハズです。一緒に仕事をしてるディレクタさんですごく気持ちよく仕事ができる方がいますが、その人と仕事をしてるときは実際これに近いことをやってくれてたりします。

開発の作業は間違うとその損失を取り戻すのに長い時間がかかってしまうこともしばしばありますが、大抵そこに至るには「間違ったまま進んでしまった」ときです。それらは納期を脅かし、コストにも影響しますので、ついつい「しっかりやろう」としがちです。逆に考えるんだ。何回か間違えてもいいから、進むときはより良い方向に進む、こうすればいいじゃないか。最初に全部準備しようとか、一度決めた方針や納期は変えないとか、そういう鈍重さはWebサービス開発にはいらないと思うんだ。コストや納期のことを考えればこそ。

今回はfaultier目線で書いてしまったのですが、自分自身も相手の立場にたってより良い提案や先回りの仕事をしていきたいと思います。

重ねて言いますが、これが外注先とのやりとり、とかいう話だったら元記事の手順がきっと当然なのかもしれない(というかその世界を知らないのでなんとも言えない)。加えて元記事はデザイナの話で、俺はプログラマの話。仕事の流儀が違うことも多々あるかもしれない。とはいえ、少なくとも自社のWebサービス開発でディレクタもプログラマもデザイナもみんな社内の人間なんだったら、もう少し良いやりかたがあるんじゃないかと思って書いてみた次第です。

追記

危うくスルーするところだった。

プログラマ編。同じような手順を踏んでいて、違う目線で書いてあるので面白い。でも経緯と展望のところは一緒なんやね。表側(デザイン)と裏側(プログラム)の違いが良く分かる感じ。

違うよ。全然違うよ。違いは表側か裏側かなんかじゃないよ。少なくとも俺は自分が作ったシステムが「動き」になってどういう風にユーザの前に表われるかまで考えて作るし、デザイナだって「一枚絵」じゃなくてどう動くかまでを考えて描くでしょ。どちらかがどちらかしか見てないとすればそれはそれで大問題だよ。

本質的な違いはそこじゃない。何で「最初に万全に準備を整えて後のリスクを減らして下さい」に対して「最初にコストをかけようとしないで細かいステップで進んで下さい」っていう真逆の発想に至ったか、そこに横たわる溝がなんなのかを考えて欲しいなー。

会社で「何かとパワポのファイルでやりとりしたがる文化」がいかに害悪かという話をした。正直どこいっても何度となく出てくる話なので言う方も聞く方も「またか」とうんざりしてるんだけど、一向に撲滅される気配がないので気が滅入る。

言いたいことは一つだけ。少なくとも仕事の依頼を「詳細は添付のppt(もしくはxls、さもなくばdoc)をご覧ください」でしてこないで下さいお願いします。

勿論Officeツールを完全に否定する気はなくて、そりゃ誰でも簡単に使えてそこそこ見栄えが良くて、直感的にわかる資料を作れるって点は認めてもいい。もっと厳密に言うと「そういうことになってる」がつくと思うけど、まぁいいや。で、代替のモノが社内外を問わず爆発的に広がりでもしない限り、営業さんやディレクターさんが使うのを止めるとも思ってない。そりゃしかたない。

だからさ、例えば「上司や顧客に報告書やコンセプトの資料を提出する」ならありだと思う。同様のものをデザイナーさんに渡すのもありだと思う(とデザイナーさんが言ってた)。また、そういう資料を印刷して会議であーだこーだ言うのも悪くない。パッと見て分かるし、メモしたりも出来るし。まぁ、それなら手書き資料でブレストしてそれを元にデザイナーがモックを作る方がよっぽど効率的だとは思うけど。

ただね。ITSに「今回の案件の詳細とタスク一覧です」ってだけ書いてあって、「詳細は添付資料にて」とかなってると流石にイラッとするわけで。そのタスクを1トピックにしろと。その詳細をトピックに書けと。何の為のIssue Tracking Systemなんだと。

大体コード書くお仕事の僕らにとってはOfficeのファイルなんて、検索できねーし開くの重いし再利用しづらいしバージョン管理されないしディスク容量も表示領域も馬鹿食いするしでろくなもんじゃない。んで開いたらタスクが箇条書きしてある他には中途半端に綺麗な背景画像があるだけとかで、泣ける。作業中断してまで見たくなんかないよそんなの。悲しいかなどこの会社行ってもそんなで、文句言う相手によっては「それはエンジニアの我が儘だよね」的なリアクションをされたりするからやりきれない。流石に今の会社はこの例ほど酷くはないけど、程度の問題で、やっぱりそこかしこにMSOfficeスキーな人が跋扈してたりするわけで。

だから言いたいことは「何でもかんでも」Officeでやろうとしないで下さい、それにつきる。本当にOfficeでやるのが適当か最初に考えてからアプリケーションを立ち上げてくれと。頼むから。


先週末大学のサークルの同期と旅行に行ってきたときに、就職先の話題になって、意外とSEになる人が多いということを知った。先輩達もそうだけど、同期の皆も、世の中というものに疎い俺ですら聞いたことのある大企業に就職していく。ここで名前を挙げるのが憚られる程度には名の知れた大手SIerばかり。

タイムリーにもIT業界ってどうなのよ?って話題が盛り上がってるみたいだし、彼らが情報技術にとりたてて興味があったという話も聞いたことがなかったので、すこし気になった。で、何故その職を選んだのかとか、将来的にどうして行きたいのかとか聞いてみた。その彼らが口々に語る夢――より正確に言うならば、計画――を聞きながら、少しだけ暗澹とした気分になった。「最初は現場で1、2年プログラミングの経験を積んで、その後は出世して上流工程をしきるんだよ」「俺は金融の専門家になるんだ」「私、パソコンとか全然わかんないけどこの仕事になっちゃった」「ああ、俺も俺も。あんまよく知らん」「技術を極める人はすげぇと思うけど、別に俺はそれをやりたいとは思わないし、実装だけやってる人に将来性ないよね」「ていうか、実装は下請けの会社がやることで俺らがやることじゃないよな」…etc。

ああ。スーツの世界がそこに広がっているのが見えた。そこそこのネームバリューのある大学名を背負い、逸般人の俺なんかが持ち合わせていないコミュニケーション能力とやらを駆使して、彼らは社会を動かしていくんだ。技術的な素養も情熱も理解も無いままに、政治力と資金力とスーツがものを言う世界でさ。

いや、俺や俺の周囲の環境が(少なくとも今現在の日本では)特異なのは理解してる。Web系とSI系じゃやってることなんか全然違うだろうし、「趣味グラマが叶える夢」と「選択肢の一つとしての職業的SE」じゃ見据えてる将来も全然違うだろうし。それ以前に、「優秀な」彼等と「変人の」俺とはそもそも住む世界が違ってて、たまたま同じ時間同じ空間で歩んできた道が交わってしまっただけなんだろうし。だからそのとき感じた違和感や憤りやなんかをどうしたいとも、思わない。

けど。

ああ、こいつらとは一緒に仕事をしたくないな、と思ってしまった。まぁ多分一緒に仕事をしてくれと頼まれる日も来ないだろうとは思うけども。

追記

思ってた以上に反響が大きかったので多少の追記を。

まず、SIerなどと一括りにしたけど、もちろんSIerにもはりぼてのスーツばかりじゃなく素敵なエンジニアは山程いる。実際に面識のある方々は、ハッカーでギークでクリエイターで匠だった。多重孫請け構造の大手SIerや末端の零細下請け会社は酷いと「聞いて」はいる(もちろん見たわけじゃない)が、一方で自社に技術を抱えている中堅SIerは技術力もエンジニアの意識も高い「らしい」とは「聞いて」いる。

それから、WebとSIは違うと言ったけど、当然ながらWeb系でもどうしようもなく能力や意識の低い連中を見たこともある。というか、SIやら組み込みやらより技術的な敷居は低いんじゃないってブコメの指摘はもっともで、敷居が低い分下限も低かったりして、SI系が「なんとなく金になりそう、出世できそう」ならWeb系は「なんとなくカッコよさげ」って理由だけで入ってくる人もいるしピンキリって意味ではどっちもどっち。

たまたま俺は、マッドエンジニアを自認する師匠と出会えて、その背中を追うべき匠たちと交流を持たせてもらってる。今働かせてもらってる会社には、俺なんかじゃ足元にも及ばないような超人や超変人が跋扈していたり、刺身にタンポポを乗せるどころか自分で舟盛りでも作りかねないマークアップエンジニアがいたりする。そんな幸運を享受しているからこそ、彼らの発言を呆れたものと認識できたし、自分は意識を高く保っていようと自戒することができた。でも、もしそうじゃなかったら、もしかしたら彼らと同じようなことをのたまってたかもしれないし、あるいは彼らが乗っているレールから足を踏み外して、あごで使われてるかも知れない。

つまるところどっかがおかしいんだろうな。学生がアホなだけでなく、文鎮がじゃまなだけでなく、もっと全体的に根本的に。なんとかならないかな。なんとか、したい。「どうしたいとも、思わない」なんて言ってないで、状況を変えるために今後何かして行けたらな。

ここのところ、求人に応募してきたプログラマやシステムを手伝ってもらう外注先企業に、どんな質問をしたらいいかについて意見を求められることが度々ある。いや、そんなの俺みたいなワープア学生アルバイターなんかじゃなくてシステム部の偉い人か凄い人に聞いてくれよって話ではあるんだけども、欲しがってる人材がどうやら俺みたいな頭のネジが足りなかったり多すぎたり変なところにささってるような人らしいので、参考程度にしといてね、と念を押した上で考えてみる。

求人に応募した経緯とか、仕事に取り組むスタンスとか、待遇やらなんやらについての希望とか、は面接担当者が普通は聞くと思うので、俺が聞いてみたいとしたらこんな感じかなー。

  • よく使うWeb上のサービスは何?最近注目してるものはある?
  • 好きな言語は何?
  • 好きなOS/ブラウザは何?
  • 普段使ってる開発環境って何?

いやいやいや、もちろん面白いこと言ってる人がいたらお友達になりたいからオタクを探してるとかそういうことじゃなくてね。うん。趣味が合いそうな人を探してるとかじゃなくて。

一番最初のは、これからWeb上のサービスという素材で、アイディアと技術で勝負しようって会社にわざわざ来る人が、技術にも流行にも興味ないんじゃ話にもならないんで当然聞いておくべきだと思うこと。後の方は何て答えるかじゃなくてどういう答え方をするかが興味ある質問たち。数ある中から一つを「好き」になり、かつその理由を人に述べるまでに至る人は、その裏で他のいろんな技術・思想に触れてそのメリット・デメリットについて判断を下してると推測できるから、そういうことが出来る人は少なくとも「ある一つのこと以外を知らない、知ろうとしない、その現状を無批判に受け入れる」人よりは数段この仕事に向いてると思う。うちらがやる「仕事」は、決められた「作業」じゃない、問題解決と創造ですから。

あとはちょっと前に流行ったfizzbuzzでもやってもらったり、ちょっとボケてみてツッコミを見てみたりするかな。

以上、面接をすることはもちろん受けたことすらあんまりない、とあるナマケモノが妄想してました。みなさんは面接したとき/するとしたらどんなことを聞きますかね。

動画サイトの広告のことを考えていて、面白い話を聞いた。動画を解析して自動的にテキストベースのメタ情報に落として、それに対してコンテンツマッチさせるような広告システムはどうか、というアイディアがあるということ。どういう仕組みかは聞いてないけど、多分音声を解析してテキスト化するんだろうな。

率直な感想を言うと、面白いし今後はその程度の技術はあたりまえになるかもしれないけど、新しい広告の仕組みとしてはそんなに期待できなそうだな、というところ。単にメタ情報を付加するだけなら、コンテンツ提供者やサービスの側で用意すればいい。それを自動化できるんだよ、ってことなんだろうけど、それでもメタ情報を「こちら側」が用意してることによる限界は越えられてない。

例えば、ニコニコ市場が面白いのは「消費者側」が関連性があると判断したものを広告にできるところに他ならない。あれがどれだけ効果を上げているのかはちょっと判断しかねるけど、「提供者側」のカテゴライズや機械的な動画の解析ではまず思い付かないようなものが市場に並んで、かつそれが案外売れたりしてるところを見ると、単純に動画のメタ情報付加の効率化を計るだけのシステムよりは面白くなりそうな可能性が見えてくる。

SBMの流行とかでさんざん言われてると思うのでわざわざ繰り返す程のことでもないんだけど、あるコンテンツの意味やそれにまつわる暗黙の了解を正しく判断するのは今のところ人力の方が圧倒的に優れているし、ましてやそのメタな要素まで含めてコンテンツ化するなんてのはまだプログラムでは困難だろう。そんでもって、その「人間の労力」をサービスを利用するユーザから上手いこと得られれば、効率がいいのみならず提供者の予測を超えるものが生まれることが有りうる、ってことも分かった。Web2.0だのCGMだのって言うんなら、もっともっと積極的にその「力」を使ってみればいいのになぁと思う。前の会社でも今の会社でも、割と言ってるんだがあんまり理解してもらえないのだけど。

とは言え前時代的な広告システムでもなくニコニコ市場でもない広告の出しかたのアイディアがあるかと言われると、これと言って思い付かないんだけど。なんか思い付いたらどっかに売り込みにでも行こうかしら。

このあいだからハマっているモバイルサイトの件で、今度はデザインでハマっている。対象が比較的新しい端末だけってことなんで、最近のケータイブラウザも進化してるらしいからいろいろ凝ってやろうかと思って調べてみたところ、やっぱりというかなんというかCSSで躓いた。

一体なんなんだ、iモード対応XHTMLってのは。つか何で独自規格なのさ。それにCSSに対応って言いながら、

  • 外部からのCCS読み込みはできない
  • それどころか<style>要素も使えない
  • インラインで書けってそれじゃCSS何の意味もない

どうしろと… orz

まじめにやろうと思ったら、高精度のUA判別した上で何種類ものテンプレートを切替えて、なおかつそれらを多重管理しないで同期するようにして、とか考えてたらコストはかかるしバッドノウハウやアクロバット上等になるし、正直そこまでするに値するUIを作り込んでるのかっつーとそうでもない*1。素直にfontとかbgcolor=""とかでちまちまやるほうがよっぽどマシか。validな(X)HTMLとCSSでPCでもケータイでもその他の機器でも同じコンテンツを提供できるとか、まだ全然有り得ない話なんだなぁ。フルブラウザ&通信定額が当り前になるまでは。

*1:サイトの特性から言って必要なのは凝ったデザインじゃなくてシンプルさと機能性だから。でも、いかにも"携帯サイト"な安っぽいデザインにはしたくないんだけなぁ…

最近モバイルサイトを作っているのだけど、アンカータグのmailtoの問題に大ハマリしている。

やりたいことは、aタグのmailtoを使ってsubjectとbodyを指定して、リンクをクリックしたらメール作成画面を開かせたい、単にこれだけで、実際PC、au、Softbankでは期待通りの動作をしてくれる。だが。docomoのFOMAだけがタイトルも本文も入らないのだ。実体参照にしてみたり戻してみたり、大文字にしてみたり戻してみたり、独自タグ入れてみたり戻してみたりしてもダメ。にもかかわらずバグ情報も回避策も見つからない。てか、いくら調べても「使える」という情報しかないところをみると、使えるはずなんだよなぁ。

ちなみに俺のnine(WILLCOM)ではメーラーとブラウザを同時起動出来ないのでそもそもメールすら送れなかった。だからという訳じゃないんだけど、こんなので苦労するんならいっそメールフォームにしてしまえばいいのにと本気で思う。俺自身は入力デバイスとしてのケータイは最低だと思ってる人間だし*1、各端末の挙動の互換性なんてまるであてにしてないからなぁ。いやまぁ、mailtoの方がユーザーフレンドリーだって言うなら頑張って実装するけども。

というわけで誰か、解決策、あるいは実際にそんなことをやってるサイトを知ってる方いましたら教えてプリーズ。

*1:とか言いながらこれはケータイから打った。普段専ら短文メールのおじさんには拷問だよ…

一応所属部署の上司と一緒に働いてる皆には伝えたのでもうここに書いてもいいかな。昨年末からアルバイトとして働かせてもらっていたとあるITベンチャーを辞めることなりました。来月。関係者のみなさま、というかここ読んでる関係者の人なんてほとんどいないのでピンポイントで約一名の尊敬すべき師匠に宛ててるのだけども、本当に御世話になりました。ってそれはまだ早いか。

今度は某readerを作ってる会社に入ることになった。基礎固めのためにも中堅SIerとかで修行してきたら、とも言われていて、それも考えてはいたのだけど、次のアクションを起こす前に一番入りたかったところから使ってやると言ってもらえたので。決まったからにはそれはもう存分に暴れてきます。待て。暴れるな。

まぁ今色々と思うところはあるのだけども、それはまた別なときに書くことにしよう。

昨日、会社でかなりショッキングな事態が発生した。詳しくは言わない方が吉だろうな。

こんな言い方をすると、その「事態」の影響が直撃した人に対してもそれを免れた人に対しても失礼かなとは思うが、俺にとってはある意味でプラスの効果をもたらした。

会社を出る決意をした。その踏ん切りがついたから。

今後のことを考えたらまぁ多分出た方が自分にとってはいいんだろうな、でもここに残れば色んな種類の即効性の利益が得られるんだよね、それに俺が今いなくなったら困る人もいるんだよね、とかぐるぐる考えてたけど、事態が急変してしまった。結果として、後ろ髪を引くその見えない無数の手は弱くなった。今まで甘るな自惚れるなと自分に言い聞かせて越えようとしてた心理的な障壁が随分と低くなった。

ちょっとばかしスロースターター過ぎる就職活動。まぁいいさ。どのみち「まとも」な道なんてはなから俺が歩く道じゃないんだから。


ふぅー。言われたこっちが恐縮してしまうほどありがたい言葉をもらって色々と考えてしまった。


正直なところ、今のバイト先は非常に居心地がいい。仕事はそれなりに難しくてそれなりにやりがいがある。一緒にやってるメンバーはいい人ばかりだし、勝手に師と仰いでる、なんで俺なんかがこんな人と出会えてしまったんだろうというぐらい凄い人もいる。学生の身分にしては結構なお金を貰った上、結構好きにやらせてもらってる。煩わしい就活なんかも経験しないで済んでいる。親父や友人の話を聞く限りだと、多分これは割と得難い幸運なんだろうなと思う。


だからと言って今のままでいてはいけないことも自分でも薄々気付いてた。今の自分はまだ、贔屓目に見ても能力的にはせいぜい並のプログラマだし、経験や実績が足りないんだからまだまだ全然未熟だ。早くから自分の能力を発揮する場を与えられたことは幸運でもあるけど、本当なら「溜め」のフェーズであってもいい時間を自分から手放しているわけだし。今のままでもおだてられれば木ぐらいは登れるし、日々鍛錬を怠らなければそのうち屋久杉みたいな大木にも登るかもね。だけど、まぁ空を飛ぶのは無理でしょう。じゃあ溜めをたっぷり作れば空を飛べるんかというと、そんな保証はない。だから心のどこかでそれでもいいかなと甘えてたのは否めない。


ああ、だから一旦ここを離れてしっかり鍛えてもらってからにすればいいんじゃないなんて指摘は、まったくもって正しくて反論の余地もない。おまけにそれを、俺に対しての期待を込めて言ってくれてるんだから、聞き流しようがないじゃないか。


とりあえずは外を見てみよう。話はそれから。幸いなことに、俺の不精と上司の不精が連鎖して(笑)、今の会社とは口約束以上の話は何もしてない。ここで頑張るにせよ他で頑張るにせよ、選択肢は沢山あっても今のところ損にはならない、か。




↑このページのトップヘ