エンジニアtype - エンジニアのシゴト人生を考えるWebマガジン

「良い開発に必要なのはエンゲージ」、「mixiは世界で勝負できた」~公開インタビュー【みんなで作る中島聡連載】レポ

公開

 
中島聡の「端境期を生きる技術屋たちへ」

UIEvolution Founder
中島 聡

Windows95/98、Internet Explorer 3.0/4.0のチーフアーキテクトを務めた世界的エンジニア。NTTに就職した後、マイクロソフトの日本法人(現・日本マイクロソフト)に移り、1989年、米マイクロソフト本社へ。2000年に同社を退社後、UIEを設立。経営者兼開発者として『CloudReaders』や『neu.Notes』といったiOSアプリを開発している。シアトル在住。個人ブログはコチラ

こんにちは、中島です。今回の連載は、先日7月18日に実施した公開インタビュー「みんなで作る中島聡連載」の中から、気になったトピックを拾い上げて紹介していこうと思います。

当日来場してくれた方や、USTREAM中継を視聴してくださった皆さんからいただいた質問は、今後のエンジニアに必要なスキルの話であったり、広い意味での開発環境の話であったり、具体的な言語や技術の話などなど。質問に返答していきながら、わたし自身も大いに刺激をもらいました。

詳細を知りたい方、漏らさず聞きたいという方は、当日のUSTREAMアーカイブがありますので見てください。

※デバイスやブラウザによって、表示されない/観れない場合があります。その際はこちらにジャンプしてください。

Part-1 編集部からの質問「これから求められる開発スタイル」

Q. さまざまなビジネスが端境期を迎え、ソーシャルな機能を有効に導入しようという傾向や、新しいエコシステムそのものを構築するような傾向が目立ってきていると思いますが、中島さんが考える「今求められるユーザーオリエンテッドな開発スタイル」とは?

この連載やブログで前から紹介してきた教育アプリ『neu.Tutor』(詳しくは中島氏のblogにて)の話をしますね。わたしはこのところ、このアプリの開発に夢中になっていたわけですが、理想としてきたのは「ユーザーのポケットの中に先生がいて、いつでも勉強をすることができる」環境を創り出すこと。

それをどう具現化するか考えた末、「ユーザーが自分でコンテンツを作れるようにしよう」という一つの結論めいたものに到達しました。出来合いの教育プログラムをWebやアプリ経由で提供するだけでは、既存の教育プログラムと変わらない。けれど、ユーザーの全員とまではいかなくても、100人に1人、200人に1人の割合で「自分にとって有効なコンテンツ」を自作してくれたなら、今の質問にあったように「ユーザーオリエンテッド」な仕組みにしていくことができる。

自身が最近手掛けてきた「教育アプリ」の開発談から、ユーザーオリエンテッドな開発スタイルを語る中島氏

自身が最近手掛けてきた「教育アプリ」の開発談から、ユーザーオリエンテッドな開発スタイルを語る中島氏

だから、作り始めたころは「そんなに大変じゃないな」なんて思っていたのですが、そうはいかなかった(笑)。

開発の後半で、一緒に開発をしてくれているアクティブラーニング社の羽根拓也さんをはじめ、何人かの教育関係者にテストをしてもらったのですが、「中島さん、それならユーザーが作ってくれたコンテンツを皆でシェアできるといいですよね」と言われて、単体のアプリだけで完結する閉じたプログラムでは済まなくなっていったんです。

わたし自身も彼らの助言はもっともだと納得しましたから、どうすればユーザーが楽にコンテンツをシェアして、ダウンロードして利用できるようになるか、あれこれ考えました。そうすると、やっぱりFacebookに行き着くんですよね。

で、Facebookの公式アプリに近いものにして、シングルサインオンでFacebook画面上からすんなり遷移し、グラフィックAPIを利用できるようにしよう、としたんですが、そのままではダウンロードできないことに気付きました。サインオンした後、結局もう1回ログインをしてもらわないと、ダウンロードできないからです。

ちょっとカッコ悪いけれど、まぁしょうがないと思って羽根さんたちに見てもらったところ、今度は「中島さん、バグがありますよ。2回ログイン画面が出てくる」と言われまして(笑)。こりゃあダメだ、と観念して、作り直すことにしたんです。

このように、開発者が「この程度なら許される」と考えていても、プログラミングに詳しくない人の目に「バグ」だと映ったのなら、それはバグなんですよ。ユーザーオリエンテッドとは全然言えない。

ですから前にも連載で書いた通り、開発者は羽根さんのように客観視してくれる存在を持つべきだし、そういう存在からもらった意見を受け入れながら、どこまで完成度を上げていけるか。これが大事なんだと改めて思いましたね。

短い期間でソフトウエアのクオリティを高める、中島流の開発法

Q. お話を伺っていると、大事になってくるのはアジャイルなんだと思いますが、中島流のアジャイル開発の秘訣はあるのでしょうか? また、それは例えば(中島氏が過去に在籍した)NTTやマイクロソフトのような「大きな組織」でもできますか?

わたしは「アジャイル」って言葉があまり好きじゃないんですが、やっぱりいったん形にして初めて見えてくる問題点というのはあるわけで、iPhoneアプリなどを作るのなら、「まずはバージョン1ということで出しちゃおう。改善はその後で」というやり方もアリだと思います。

じゃあ、同じような開発手法を大きな組織でもできるのか。えーと、僕がいたころのNTTでは無理ですね(笑)。

今は知りませんが、わたしのいたころには外部にコーダーがいて、彼らに「コード1行○円」という単価でプログラミングを請け負ってもらっていました。つまり、長いコードを書くほど儲かる人が参加していたんです。そういう体制だと、アジャイル開発は難しい。

マイクロソフト在籍時に常用していた「独自の開発法」を明かす

マイクロソフト在籍時に常用していた「独自の開発法」を明かす

一方、マイクロソフト時代にわたしが見つけた開発の進め方は独特でしたよ。この会社で高く評価されるのは、「1週間で作る」と言ったものを、確実に1週間で仕上げる人です。正しく見積もりをできる人が出世する。

でも、ソフトウエア開発では、プログラミングしてみなければ分からないことの方が多いじゃないですか。じゃあどうしようかと考えた結果、導き出したのが、依頼が来てから見積もりを出すまでの1日2日で、先にプロトタイプを作り上げちゃう、というやり方です。

「そんなの無理だ」と思う方も多いかもしれませんが、できるんですよ、実はその気になれば。というか、マイクロソフトでの日々で、わたしはそういうスピードを手に入れたともいえます。

エンジニアというのは、毎日均等に開発をするわけじゃなく、〆切りが迫ってきたところでワァーっとモチベーションを上げて作り上げちゃう人が多いですよね。じゃあ、「見積もりについて考えさせて」と言って確保した1日2日の間に、プロトタイプをある程度集中して作ってしまえば、正確な期限を答えられるぞと思ったんです。

もうプロトタイプができているんだから、本当はあと3日で完成すると分かっていても「1週間ですね」と答えれば、余裕もできるし。

まあ、そんなこんなで、わたしはマイクロソフトで認められるエンジニアになれた。このペース配分だと、例えば、最初に考えたコードが間違っていたことも早い段階で分かるようになるし、時間的余裕があるから、躊躇せずに捨ててしまえる。

もしも「1週間」と見積もりをしてから5日目に失敗に気付いても、なかなか捨てる勇気が持てなかったりしますよね。結果的に良いソフトウエアを作れないというリスクも、このやり方で回避できたんです。

良いものづくりは、ほとんどの場合「エンゲージの有無」で決まる

Q. では、中島さんがFounderを務めるUIEvolutionの開発体制はどうなんでしょう? BtoB案件が多いということですから、そうそうアジャイルな開発はできないと思いますが。

さきほどお話した『neu.Tutor』開発のようにはいきませんが、ほかの大手ゼネコン的なIT企業との違いは明らかですよ。

これはアメリカでの実話なんですが、ある大手IT企業とともに参画したプロジェクトで、UIのチェックボックスを1つ追加してほしいという話が出ました。

UIEvolutionとしては「はい分かりました」とその場で追加しちゃったんですが、一緒に参画していた大手企業は丸2日もかかった。

このスピードの違いは、企業の規模にもよるけれど、やはり開発を実行する上での仕組みとか組織のあり方の違いで生まれてくるものです。

もっと言えば、プロダクトマネジャーとエンジニアがどんな関係でつながっているか、で左右されると思いますね。

Q. UIEvolutionではその関係性が優れているということでしょうか? どんなプロダクトマネジャー、どんなエンジニアが、スピーディーでユーザーオリエンテッドな開発を実現するのでしょうか?

答えは「エンゲージの有無」でしょう。やるべきことに納得をして、しっかりモチベーションを上げているエンジニア、つまりエンゲージしているエンジニアとそうじゃないエンジニアの差というのが大きい。そして、優秀なプロダクトマネジャーとは、エンジニア全員を常にエンゲージできる人ということです。

アメリカではプロダクトマネジャーを「ベビーシッター」と呼ぶのも、そのせいかもしれませんね。多少問題のある仕事でも、プロダクトマネジャーが上手にエンジニアのやる気を引き出せれば、そのプロジェクトは一気にスピードもクオリティもアップするんです。

じゃあ、エンジニアはどういう人が良いのかといえば、抽象論かもしれませんが「仕事や人生に誇りとか面白味とかをちゃんと見つけられる人」ということになる。そういうエンジニアが良いプロダクトマネジャーと出会えたら、開発環境は飛躍的に良くなります。

UIEvolutionは日米ともエンゲージしたエンジニアが集まっているところに強みがあります。日本法人のWebサイトの『UIEvolutionで働く魅力』というページを見てもらえば、UIEvolutionのエンジニアがどういう働き方をしているのか、イメージが伝わるのではないかと思います。ちょうど採用募集をしていますので、エンジニアとして成長したい方は、ぜひエントリーしてみてください。

もっとも、敷居は決して低くはありませんが(笑)。

(公開インタビュー参加者からの質問に続く)