サイテック社の中の人とお話してきました

http://blog.cytech.bz/

■ことのあらすじ
BPStudy（http://beproud.jp/bpstudy/）に参加する
↓
懇親会に行く
↓
自分が座る席がない
↓
社長席グループになる＞＜
↓
F-Quest（http://www.f-quest.com/）のCEOの人と話す
↓
iPhoneとか好きだから！とか言うと、じゃあいい会社があるのでぜひ会ってみてくださいと勧められる
↓
行ってみた（今ココ）


ということで、サイテック株式会社の中の人とたっぷり終電までお話してきました。
人生哲学、今後の技術動向、iPhone開発について、日本の文化についてなど、たくさんのことを学ばせていただいて、本当にありがとうございます！
お二人とも大変聡明で、そして何より精神的に強いです。独立しています。ちょっとうらやましい。

• 自分とは考え方が180度異なる人を認められるようになるためには、そういう人たちと利害関係を持つ経験をすること
• 利害関係が発生しない状態は悪い状態、競争相手・ブレーキをかけてくれる存在を持つこと
• iPhone開発は金にならない、今のApp Storeは供給過多すぎてビジネスとして成立していない
• iPhoneアプリはどう視覚的に訴えかけるか、要するにデザインが大事
• 今やりたいと思っていることを信じ続けることができるか
• 日本の文化は強みになる、日本の文化を翻訳して展開する

といったあたりが今の自分に凄く響きました。iPhone開発者懇親会に行ったときにも同じような考えの方が多数いらっしゃったのを思いだして、現在のトッププレーヤーは大体同じような感覚を持ってらっしゃるのだと再認識できました。あとは、これらの課題をどう解決するか、ですねー。

以下、お話しした内容全文です。
私が話した内容と、私が後から考えたことと、サイテックの方がお話しされたことが混ざってしまっていますが、ご容赦ください。
基本的に中二病っぽい発言が私です。

[2009/06/13 20:07追記]ご指摘のあった不適切な箇所を修正いたしました。ご迷惑おかけしましたことをお詫び申し上げます。
その他、いくつか思い出した内容を追記しました。
[2009/06/16 22:42追記]誤字修正。本田誠一郎って＞＜ お恥ずかしいことこの上ないです・・・

---

■お話ししたお相手
@yatabeさん（CEO）
@fw_tx76129さん（プロジェクトマネージャ、2年目。別の会社で5年勤務。テキサスの大学に留学していた）


■今後の展開
　→マルチプラットフォーム
　→WebはPC上だけではなくて、モバイルとか家電にも広がっていく
　→となったときに、どこかで書いたソースがそのまま使えないというのは問題
　　　※たとえばObjective-Cとか、iPhone以外では使えない資産になってしまう
　→Perl, Ruby, PHP, JavaScript, ActionScript...これ以上いくつ言語を覚えればいいのか（笑）
　→そこでFlash（Air, Flex）などを模索している


■現在の事業内容
　→現在はPHPの案件がメイン
　→自社でPHPのフレームワークを作ったりしている
　→@fw_tx76129さん・・・基礎部分だけ書いて、残りは新人に課題として「こんなの作ってみて」と振っている。
　　　※そしたら毎日「面白くて仕方がないです」とか言いながら仕事しやがって（笑）
　　　※滅茶苦茶うらやましい！


■Androidはどうなる
　→Androidの最大のメリットはOSのライセンス料ではないかと思っている。
　　　※詳しい額は分からないが、現在のSymbianだと1台あたり5000円程度のライセンス料がかかっているのではないか
　→そのうちケータイブラウザやお財布ケータイなどの機能を搭載した機種が出てくるだろう
　→むしろ現在のケータイの、OSの部分だけをSymbianからAndroidに入れ替えただけの機種が出てくるかもしれない


■組み込み2.0
　→ハードウェアの組み込み系は未だにC言語で、オブジェクト指向なんて流行りだしたのはつい1年ぐらい前
　　　※生産性が低い、そういうところで開発者の気持ちが鬱積している
　→そこにAndroidが登場した。
　→今後は生産性の低いハードウェアの制御とかミドルウェアのあたりはすべて任せてしまうようになるかも
　→そうすると今まで溜まっていた開発者の気持ちが爆発して、ものすごい物が生まれるかもしれない
　→組み込み2.0になるかも


■守る文化について（広告代理店の人の話）
　→CGM (Consumer Generated Media) が流行している。例：logotournament.com
　→日本でもC-team (http://blog.livedoor.jp/kensuu/archives/50783668.html) というのがある
　→このC-teamについて、ある広告代理店の人はこのような話をした
　→我々広告代理店は、広告主からデザイナーを「守ってやっているんだ」
　　　※広告主はデザインとか良いバナーとか全く理解しない、単にお金だけ出して「後頼むわ」という
　　　※そのくせ後からデザインに自分の勝手な感覚で思いっきりケチを付ける「金出してるんだから俺の物だ」
　　　※その中間を上手く取り持つのが広告代理店だ
　　　※日本人のデザイナーはこういう競争に耐えられない、弱いデザイナーを救ってあげなくてはならない
　→なるほどちょっと納得。実際間違ってない。欧米型の競争原理が働くと弱い人は没落するしかない。
　　　※そのおかげで鍛えられて強い人が育つのかもしれないけど
　→日本人の「守ってあげる文化」
　　　※鎌倉幕府の御恩と奉公もまさにそれ


■今やりたいと思っていることを信じつづけること
　→iPhone開発で飯を食ってみたいと思っているのですが
　→長いスパン、10年後ぐらいを見て、どうなるかを考えてやってみるといい
　　　※それでも続けたいか？
　　　※当然だが、10年後にiPhoneはなくなっているだろう、それでもか？


■iPhoneアプリは事業になるか
　→結論から言うと会社の事業として100％の力を割いてやっていくことは出来ない、リスクがある
　→App Storeは市場として全く成功していない
　　　※アプリの価値が余りにも安すぎる
　　　※魅力的な開発環境がクリエイターを誘った結果、完全な供給過多に陥っている
　　　※アプリの価値をどうやって引き上げるかを考える
　　　※携帯サイトで上場した企業はあっても、iPhoneアプリで上場した企業はない
　→しかし無視することは出来ない。案件が来たらまずiPhoneでやってみようと考える
　→App Store以外で成功する方法を考えなければならない
　　　※たとえば、アプリを買収する。安く作ってもらってストアに出して、気に入ったアプリを大企業が金で買う
　　　※シリコンバレーで、ベンチャー企業がExitを目指すビジネスモデルに相似している
　　　※B2BでのiPhoneの利用は出来ないか考える
　→重要なのはアプリの構成、デザイン。どのような層にどう視覚的に訴えかけるか。
　→まだiPhoneのビジネスは生まれたての卵で、どう転ぶか何が生まれるか全く分からない
　→会社全体のエネルギーの2割3割を割いて動向を探る
　　　※ただ、このやり方だとあるタイミングが来たときに波に乗った人が全部成功をさらっていきそう（笑）


■B2B、B2C、C2Cの次、D2D（Developer to Developer）
　→開発者が開発者を集めるために、開発者のための物を供給する
　　　※Android
　　　※iPhone
　　　※MacromediaのころのFlash
　　　※各種フレームワークなど
　→勝手にC2C (Creator to Creator), いやD2Dと命名
　→そうすると、集まってきた開発者が勝手に面白い物をどんどん作ってくれる
　→プラットフォームが一気に普及する
　　　※Flashが搭載率99％の化け物プラグインの地位を握ったのもそのおかげ
　　　※HTMLの仕様がろくでもない頃に、インタラクティブなウェブを作ることを可能にしてくれた唯一の存在


■自分とは違う価値観の人を、どうしたら「認めてあげられる」のか、怖くはないのか（正直自分は怖い）
　→@yatabeさん「私も怖いですよ」
　→怖いですけど、そういう利害関係だから
　→たとえば株主と社長の関係がそうで、株主というのは利益にしか興味がない
　　　※うちは君にN億円投資してるんだから、きちんと年間M％ずつ利潤出してよね。売上だけはきちんと上げてね
　→社長としては社員の面倒を見てあげたり、先行投資をしたいけど、株主のために売上をあげなければならない
　→そういう利害関係を肌で感じて学んだ
　　　※どちらが良い悪いではない。利害関係に良い悪いも無い
　　　※株主と社長、どちらがいなくても成立しない


■では、もし「社長」＝「株主」の会社が存在したら、どうなるか？
　→利害関係が発生しなくなる。社長が株主になってしまう
　　　※社長が株主にである＝利益にしか興味がないということ
　→ブレーキをかける存在が無くなってしまう
　→良い利害関係とか悪い利害関係は無いと思っているが、「利害関係が発生しない」のは悪いこと
　→競争して切磋琢磨しないと成長が無くなってしまう
　→成長が無くなったら、その会社は終わる
　→本田宗一郎さんも確か「株式会社は株を公開してもって貰うべきだ」というニュアンスのことをおっしゃっていた
　　　※出典不明（忘れた・・・ちゃんと調べないと）


■とある企業の悲劇
　→90年代後半に現在のMQと同じメッセージングシステムを作って売り出した日本企業がある
　　　※時代背景からいうと、ようやくインターネットがかろうじて流行ってきたぐらい。
　　　※まだGoogleは設立1年目とかそのぐらい。Yahooとgooが検索エンジンの主流だったと思う。
　→他にも現在で言うTracやRedmineのようなチケットドリブンシステムを自社開発
　→アレを作ったのは信じられないぐらいの天才。本当に頭がいい。たぶん世界最先端だったと思う
　→にもかかわらず今は没落、なぜか
　→そのシステムを捨てることが出来なかったから。固執してしまったから。
　　　※2000年代序盤に廃棄されるべきだった、既に競争力が無くなっていた
　→そのシステムを作った人が社内で神格化した。彼らの言うことが絶対になった。
　→同様にそのシステム自体も神格化した。動いてるソースをメンテナンスすることは絶対の禁忌になってしまい、改修が進まなかった
　→ブレーキをかける人がいなくなった。新しいことにチャレンジしなくなった。そして古くなり役に立たなくなった。
　→第2次世界大戦の帝国海軍が大艦巨砲主義から脱却できなかったのを繰り返しているように思える


■Windowsはタッチタイプすら出来ないコンピューター素人の人でも使えるように作られている。少なくともそれを目指している。
　→@akisute「にわかには信じがたい」
　→例：Windows95ぐらいの地点で既にinternationalizationを完備していた。とある言語ファイルを一つ入れると23の言語すべてが使えるようになる
　→Macはクリエイターがクリエイターのために作ったもの。だから当時の爆発的普及には至らなかった
　→ビルゲイツの偉大なところは靴を投げられなかったこと（笑）・・・ではなくて、ド素人の人にコンピューターを使わせたこと
　→最近Macが流行りだしているのは、世の中でクリエイターがクリエイターのために作るものが流行ってきているから
　　　※単に世の中の流れがMacにとって追い風になっているだけに過ぎない


■世の中には流れがあって、単にそのときの流れに乗っている物が成功しているだけ。良い悪いではない。
　→最たる例が任天堂
　　　※余りにもわかりやすいので説明不要だと思う


■文化の翻訳
　→iPhoneアプリもそうだけど、日本が世界に通用するのは何か？というと、「文化」
　　　※世界はみんな日本の文化を知りたがっている。ニーズはものすごく強いらしい。
　→文化を発信するだけではなくて、文化を「翻訳」して伝えること。これが次のWebの目標。
　→たとえばニコニコ動画などは海外でも一定の成果を上げているが、「翻訳」しているのではなくて「そのまま押しつけている」だけ
　　　※弾幕とかコメント職人の技は日本語以外ではとても再現できない
　　　※@akisuteにはFacebook上にイスラエル人の知り合いがいるけど、全員日本語を使っている。翻訳していない、向こうがあわせてくれている
　　　※押しつけるのはただの文化侵略（Civilization 4みたいですね）
　→翻訳というのは、相手の理解できる形に変換すること
　　　※例をあげると、寿司はカリフォルニアロールになった。あれがアメリカ人の理解できる形
　→Facebookが世界では優勢になっているが、世界各地には独自の文化圏内でのSNSがたくさんある。Mixiもそのひとつ。
　→それらのコンテンツを「翻訳」して中継する、SNSのSNSのようなサービスがあるといい
　　　※@akisuteがちょっと考えた例では、Mixiの日本語の書き込みが、アメリカ人に理解しやすいように翻訳されて表示される。
　　　　このとき、Mixiのアバターは実際の顔写真（ダミー）に変換される。向こうの人は実際の顔をさらす文化があるため。
　　　　逆にアメリカ人側の書き込みは日本人が親しみやすいアバターに変換されるなど。
　　　※最終的に書き込み主の人種が全く分からないレベルまで文化的翻訳が行われれば完璧
　→そこで問題になるのが、我々は日本を余りにも知らない。歴史も文化も知らない。
　　　※アメリカに留学していて気づいたのが、アメリカ人は自国の文化を本当によく知っている。
　　　　中学校の歴史の教科書でも信じられないぐらい内容が細かい。300年しか歴史がないから。
　→たとえばNinjaとかもてはやされているが、実は向こうの人の方がよっぽど忍者をよく知っている。
　→アメリカの寿司屋はみんなアメリカ人が店主だったりする。
　→origamiで検索すると、フランス人のもはや折り紙とは思えないレベルの作品が多数ヒットする。
　　　※発見できなかった・・・
　　　※http://en.wikipedia.org/wiki/Origamiなどは、sub articleも含めると日本語版の記事よりよっぽど充実していたりする
　→このように、草の根レベルで既に文化の翻訳が行われて根付いているが、我々が翻訳できて伝えられていない
　→相手国の文化をインターネット経由で知ることができる。実際に現地に飛んで文化を学んでも、インターネット上では異なることがある
　　　※確かに日本もリアルとネットじゃ文化が違う気がする。匿名文化ってのはネットだけかもしれないし
　→宗教問題とか人種問題とかが、ネット上なら解決できる。ネットは同じ興味のある人をクラスタごとに引き寄せる。そこに人種とか宗教は関係ない。
　　　※興味がない、自分の嫌いな人は自分のいるクラスタとは違うクラスタにいて見えない。だからネット世界なら簡単に同居できる。
　　　※この手の問題はリアルでは絶対に解決できないと思う。アメリカでは未だに黒人がどうのとか白人がどうのとかがあった。
　　　※同様に、会津（福島）のお年寄りは、いまでも薩摩（鹿児島）が嫌いだとかがあるらしい
　→今は人気がない歴史学科とか文化学科の人材が、10年後20年後にこのあたりのビジネスモデルが開拓されると、突如として経済界から引っ張りだこになるかも
　→iPhoneアプリの話に戻すと、ラジオ体操アプリとかどうよ（笑）
　　　※Radio Social Performance（爆笑）
　　　※絶対クックパッドより人気出るから！ｗ クックパッドは日本の外に翻訳できないサービス。
　　　※一人でラジオ体操とか続けられないから、みんなで動画撮ってストリーミングすればいいんじゃないｗ

時間を入力するために、カスタムUIPickerViewを作ってみた

時間を入力するためのUIが欲しかったので、こんな感じのカスタムUIPickerViewを作ってみました。ソースコードはこちら。
http://github.com/akisute/YourTurn/blob/8119bf028acf4908edb602d277544bc2cf6a5848/Classes/YTTimePickerView.h
http://github.com/akisute/YourTurn/blob/8119bf028acf4908edb602d277544bc2cf6a5848/Classes/YTTimePickerView.m


使い方はソースを見ていただければきっとご理解いただけると信じておりますので、UIPickerViewを使っていて気づいた点などをいくつか晒してみたいと思います。


■参考にした記事
id:paellaさんのダイアリーを参考にさせていただきました。ありがとうございます。
http://iphone-dev.g.hatena.ne.jp/paella/20090521#20090521fn1

基本的にはこちらの記事にまとめられている内容に従って、

// 2) ビューを返したい場合
- (UIView *)pickerView:(UIPickerView *)pickerView viewForRow:(NSInteger)row forComponent:(NSInteger)component reusingView:(UIView *)view {}

このデリゲートメソッドを使いカスタムViewを利用した実装を行ったのですが、一部私の実装とpaellaさんの記事で異なっている点があるので、ご紹介したいと思います。


■UILabelを直接デリゲートメソッドから返す
元記事では、

UIViewを返すデリゲート、必ずUIViewを返さないとうまく動いてくれません。このサイトやこのサイトで紹介されているようなUILabelを直接渡してあげる方法は、少なくとも私の環境(2.2.1)では何も表示されませんでした。

と、UIViewを返さなくてはダメとご指摘がありますが、どうやらUILabelでも大丈夫みたいです。ビルドターゲット = iPhone OS 2.2.1の環境で確認できました。

UILabelをそのままデリゲートから返却したときに画面に表示されなかった原因は、どうやらUILabelのframe.size.heightが0になってしまっていた（要するにつぶれてしまっていた）のが原因みたいです。そこで、以下のようなコーディングを行いました。

- (UIView *)pickerView:(UIPickerView *)picker viewForRow:(NSInteger)row forComponent:(NSInteger)component reusingView:(UIView *)view
{
    UILabel *label = (UILabel *)view;
    if (!label)
    {
        label = [[[UILabel alloc] init] autorelease];
        label.frame = CGRectMake(label.frame.origin.x, label.frame.origin.y, 20.0, 23.0);
        label.backgroundColor = [UIColor clearColor];
        // 以下初期化コードなど・・・
    }
    
    return label;
}

このように、label.frameの高さを無理矢理指定してやれば、きちんと画面に出せるみたいです。また、この方法を使えば、元記事で

ポイントはビューの座標。どうも各要素での{0,0}の位置はPicker内各Rowのど真ん中にあるらしく、サンプルのように負数を指定してあげないとどこかに寄った状態になってしまうみたいです。

とご指摘があったビューの座標も、特に気にせず普通に指定することが出来るようになりました。


■Pickerを、UIScrollViewのサブクラス（UITableViewなど）にaddSubviewする場合の注意点
この記事の見出しに貼り付けた画像では、作成したカスタムPickerをGroupedスタイルなUITableViewのfooterViewに貼り付けています。

    // Initialize time picker with a previously selected value
    timePicker = [[YTTimePickerView alloc] initWithFrame:CGRectZero];
    NSInteger initialValue = [[NSUserDefaults standardUserDefaults] integerForKey:_USERDEFAULTS_TIMEPICKER_INITIALVALUE];
    timePicker.time = (initialValue == 0) ? 300 : initialValue;
    timePicker.timePickerViewDelegate = self;
    [timePicker selectRowWithCurrentTime];
    self.tableView.tableFooterView = timePicker;

このように、UIScrollViewのサブクラスのサブビューとしてUIPickerViewを貼り付けると、そのままの状態ではうまくPickerのドラムが回転してくれないという症状が発生してしまいます。
これはどうやらUIPickerViewのスクロールとUIScrollViewのスクロールがけんかしてしまっているみたいです。そこで、スクロールする必要のないTableView側の設定をOFFにします。具体的には、Interface Builderを利用する場合、以下の赤枠でくくった箇所を設定すると良いようです。



こうすることで、綺麗にドラムが回転してくれるようになります。

java-ja #15 TDDとかペアプロとか

株式会社ドワンゴの本社にて開催された、java-jaの第15回勉強会に参加してまいりました。（ドワンゴさんありがとうございます！噂通りの社風が垣間見られておもしろかったです）
今回のテーマはTDDとペアプロ。TDDの権威である@t-wadaさん（http://twitter.com/t_wada）の講義＋実際にTDD＆ペアプロを体験する時間が設けられ、非常に充実した時間が過ごせました。

以下、Twitterにアップした感想を転載。

---

とにかく疲れる！そして慣れていないせいもあるがコードが進まない！普段の倍疲労して半分しかコードが進まないなら、明らかに生産性が下がっているように見える。でも違う、逆だ。こんなに生産的にコードが書けるとは思わなかった！

TDDを進めていくうちに、自分が意図しない考えや見落とし、typoなどの指摘が次々に飛び出した。書き上がったテストコードも普段自分が作っているものより綿密だ(もっとも普段はかなり手抜きなのだが)。TDDに反する進め方を指摘してストップすることもできた。

TDD自体はというと、テストケースが増えたり仕様が複雑化してきたりすると、途端に難易度が跳ね上がるな。一箇所直すと複数のテストがあっという間に真っ赤になる！新しくテストを作る判断とかも難しい、なによりテストを実行するのが面倒になったりする。jUnitMaxが素晴らしい理由を体感。

ペアプロの弱点は調べ物だな。明らかに調べ物をするときは個々人がググったほうが早い。だから熟練度が高くないとオーバーヘッドが大きくなってかえって非効率的。@yuruyoroさんには足引っ張って申し訳ない。スキルの差を埋める必要があるのも課題かなー、、、

個人的には一人でやる方が楽かな。人と話すのがへたくそ何だよなあ、、、いつもより疲れるのもそれが原因かも。ウォーターフォールがいけてないとはよく言うが、TDDやペアプロ自体にもたくさん課題があるのだなー、、、でも同じ課題満載なら、新しいやり方を開拓する方がいいよね、多分

---

TDDやペアプロは良いプラクティスですが、慣れないと実践は難しいですし、ウォーターフォールに代わる銀の弾丸でもなさそうです。そのことを実際に体で覚えることができたのが一番の収穫かな！