2015年8月6日
「全てのプログラミング言語は同じだと、ある時気付いたんです」
本記事は、原著者の許諾のもとに翻訳・掲載しております。
―iDoneThis社プロダクト責任者 Leif Singerへのインタビュー
Leif Singer：日中はスタートアップ企業のプロダクトマネージャ、夜間は研究者
ドイツで育ったLeif氏が選んだキャリアは、ソフトウェアエンジニアリングです。カナダのビクトリア大学にポストを得てからは、いかにして開発者が他の人とコラボレートするかについて研究を始めました。
現在はiDoneThis社でプロダクト責任者の役職に就き、現代的なチームコミュニケーションを形作りつつ、人々がより多くの物事を成し遂げられるよう尽力しています。同社のビジョンや方向性を設定するには、調査を通じて多くのデータを収集しながら、TwitterやBufferなどといった著名な顧客とも対話をする必要があります。
Leifさん、こんにちは。お忙しいところありがとうございます。まずは自己紹介をお願いできますか？
機会を作っていただきありがとうございます。私は iDoneThis社 でプロダクトマネージャをしています。仕事の内容は、製品について決定を下すことです。何を作りたいかを把握した後、ワークフローの構想やモックアップの作成、ワイヤフレームの作成をして、開発者が最も効率的な方法で製品の構築ができるよう手助けをします。重要な一面として、プロジェクトをタイトにするため、要件の変更などが起きないよう気を付けることが挙げられます。そうすることで、常に最小のものを構築しようとしながら、ゴールに向かっていくのです。全ての機能は、生み出されるだけではなく維持される必要があります。
その上で、私は次に作りたいものについて、また構想を戦略的に巡らすというわけです。
なるほど。では、どうやってみんなの足並みをそろえているのですか？
それについては2つの部分があります。1つは何を作るかを把握することです。そのために、ユーザリサーチやユーザとの対話、調査、アンケート、分析結果の確認などを行います。
チームとして同期するためには、もちろん私たちの製品である iDoneThis を使います。離れて作業するチームには最適のツールですよ。それから、より同時進行的なテキストベースのコミュニケーションに関しては、 Slack も使います。私たちは概ね、チームメンバーの間で定期的に1対1のやり取りを行っているんです。
例えば私は毎週、CTOや開発者の1人と1対1のやり取りを行っています。そこで実際にどんなツールを使うかは決まっていません。今は speak.io を試しています。これも最近のアプリケーションで、私たちが知る限り、現在これを使っている他のスタートアップは数社のみのようです。
iDoneThis社でのプロダクト責任者という現職において、何に最もやりがいを感じますか？
私の主なタスクは、開発者がベストな仕事をできるようにすることです。それが実現し、全ての物事がスムーズに運ぶ時、最高にやりがいを感じますね。それから、事前に障害物を取り除くことができた時などは、本当に報われる気がします。
テクノロジーが本当にピタッと来るような「アハ体験」をしたことはありますか？
私は元々、作家志望でした。確か、最初のインターネット接続は1996年だったと思いますが、当時の私は出来の悪い青春時代の詩やその類いのものを出版したいと考えていたので、HTMLを覚えることにしたんです。まだHTMLが許されていた当時のチャットルームに入り浸り、少しずつ実験をしました。それからというもの、1つが次につながりながら、最終的に自分のWebサイトが持てるまでになりました。
実を言うと、1999年に別のスタートアップを共同設立していたんです。それ以来、コンピュータサイエンスを学び始め、基本的にはPHPでほとんどの作業をこなしました。その後、再びJavaにも手を染めました。ただ、iDoneThis社に参加した時はビクビクものでしたよ。ここで使われている言語はPythonとDjangoですが、そのどちらも使ったことがなかったからです。それでも、他の言語やフレームワークで重要な概念を知っていたせいか、コツをつかむのに時間はかかりませんでした。
「全てのプログラミング言語は同じだと、ある時気付いたんです」
今ではPythonとDjangoで仕事をしています。それが現状、私が立つ地点です。
大学でのキャリアを捨て、iDoneThis社に参加した実際の理由は何でしょうか？
ここドイツで博士号を取得後、すぐにカナダで博士研究員になりました。博士研究員になった理由は、いつの日か教授になりたいと思っていたからです。ただ、私には妻と2人の子供がいますが、24時間分ものフライトの距離で、家族や友人のサポートの輪から隔てられるような生活は望んでいませんでした。
もし博士研究員を続けて学術方面に進んでいれば、教授のポストを得るため、請われた地域に飛んでいくような生活を余儀なくされたでしょう。
教授のポスト数はたかがしれているため、空いたところに行くしかないのです。だから離れた場所でも、当時は絶好の機会だと思っていましたよ。
では、iDoneThisで仕事を始めた理由は何でしょうか？
おかしな話ですが、カナダで研究員に就いたきっかけはTwitterだったんです。ツイートを見て担当教授に連絡しました。iDoneThisについてもそれは同じです。技術系の仕事にとって、Twitterは正に最高のソーシャルネットワークですよ。
私は1日を管理したいタイプなので、iDoneThisは以前から使っていました。つまりツールについては知識もあったので、彼らの求人情報を見つけた時にはeメールを送っていました。そして数ヵ月語、晴れて働き始めたというわけです。
ソフトウェア開発者がTwitter上でコラボレーションする方法についても研究されていましたよね？
ええ、確かにしていました。 開発者がどのようにTwitterを使うか についての研究です。Twitterでの職探しというのも、研究を通じて発見したテーマでした。それ以外には、主にプロのネットワーク向けにクライアントを見つけたり、局所的なつながりを見つけたりすることについても研究しましたね。
開発者によるTwitterの使い方に地域差はあると思いますか？
そうですね。ある人によると、新しい街に引っ越した時に、Twitter上で同じ街の人を見つけて、その人たちとオフ会を開いて会ったようです。
一方、これが郊外や小規模の街の場合、TwitterはWeb開発の世界とつながるためのツールという感が強いと思います。地元ではそういった動きが活発ではないわけですからね。
14歳の自分に伝えたいアドバイスはありますか？
心配しなくていい。何とかなるさ。
iDoneThis社での製品管理における挑戦についてお聞かせ願えますか？
私たちはとても小さなチームです。5人のうち開発者が半分。次に何を作るかは慎重に決めなければなりません。少ない時間の投資で、ユーザや顧客に最大限のポジティブインパクトを与えるのが理想です。
その点が今の私たちにとって、特に私にとって一番の挑戦ですね。
ただ、大局は時間と共に変わるので、そういう時こそ、定量的な調査やアンケート、顧客へのインタビューや分析データなども活用していきたいと思います。
一方にはデータがあり、他方にはiDoneThis社のビジョンを改善していく継続的な努力があります。この2つを組み合わせ、次に作るべきものの指標とするのです。
技術やツールで掘り下げて使ってみたいと思うものはありますか？
もっと時間があれば、プロダクトマネジメントをサポートするツールを詳しく見たいと思いますね。使いたいツールについてはリストを作っています。現状、 Hackpad やスプレッドシートなどといった、より軽量なツールを試している最中ですね。
ソフトウェアエンジニアリングの領域において最先端であり続けるための助言はありますか？
エンジニアリングについて、私たちはDjangoとPythonを使っていますが、それ自体は急には変わらないでしょう。大切なのは、使って慣れること、腕を磨き、技術ではなくどう使うかを考えることだと思います。
私たちは、TDDの練習方法やエディタを最大限に生かす方法などを紹介する destroyallsoftware スクリーンキャストを購読しています。
「私たちにとっては、現時点で行っている方法を熟知することの方が技術よりも重要です」
iDoneThis社では、バグのトラッキングはどのようにされていますか？
バグのトラッキングについては、 GitHub を利用しています。私たちが使っているのは異なる問題のクラスです。GitHubでは明らかにバグであり、明確に定義され解決が可能なバグだけをトラックします。
開発者は、問題を読んで、2時間ほど手が空いていればそれを解決できるでしょう。ただ、その他の全ての場合はAsanaに入れます。なぜなら、詳しく調べたり仕様を書いたりする必要があるような、より大きなプロジェクトのようなものになる可能性が高いからです。
また私たちは随時、誰も使わない機能やほとんどの人が見向きもしないような機能は削除します。使われることのない技術的な欠陥の削除は、製品の洗練というよりも課題という意味において問題の一種です。そしてこれはAsanaに入ります。
新しい機能を実装するテストはどのようにされていますか？ そのためのワークフローはありますか？
自分たちが書いたものは自分たちでテストを記述するようにしています。時には、ただ機能だけを先に書くよりも賢明なこともあるようです。未テストのコードをプッシュすることについては、私たちはかなり用心深いと思います。
質の高いテストの実践を心がけていますが、一方で合理的であることへのバランスを取るようにもしています。各自、テストは自分で書くのが原則ですが、ペアでのプログラミングの場合などは例外です。
総合的に見て、iDoneThis社はどの方向に進もうとしているのでしょうか？
いい質問ですね。ユーザはiDoneThisを使って自分の行動を管理するだけでなく、コミュニケーションも数多く行っています。
例えば、iDoneThisは日々のスタンドアップミーティングの代わりとしてうってつけです。顔を合わせての話し合いの時間を減らし、実際の作業時間を増やすことが可能となります。
iDoneThisがスタンドアップミーティングの優れた代替えとなるよう、ミーティングで特徴的なものをもっとサポートするために倍の労力を注いでいこうと思っています。今ではgoals、dones（目標と達成）というのが使えるようになりました。自然な開発では、例えばブロッカーのようなものを加えたりもするでしょう。なぜなら、そのことも立ちミーティングでの話題に上るだろうからです。
スタンドアップミーティングに特定した改善とは別に、長期的には非同期のよりよいコミュニケーションプラットフォームにしていきたいと思っています。それでも、チームとはつながっている必要はありますけどね。
