さよならSeasar、最後の!? Seasar Conference開催

2015年9月26日、法政大学市ヶ谷キャンパスにて開催されたSeasar Conference 2015。フレームワーク名を冠するイベントながら、そのフレームワークの開発終了宣言が出てくるなどセンセーショナルな話題も多かった今回のカンファレンス。本記事では、その様子をいくつかの講演をピックアップしてレポートします。

オープニングトーク(DJ HIGAYASUWO)

Seasar2のオリジナル開発者でもあるDJ HIGAYASUWO a.k.a 比嘉康雄さんの発表から始まります。

画像

なぜSeasar2をやめたのか

冒頭から、Seasar2の人気絶頂期の開発中止とそれに伴うメンテナンスフェーズへの移行の理由を語ります。なぜ、認知が広がっていよいよこれからという段階であのように新規の開発が中止されたのでしょうか。

「技術は、最初のころは学ぶことが多くあるものの、ある程度経験値がたまると学ぶことが少なくなっていく」という傾向があります。既存のフィールドに居続けるとその人のスキルは伸びなくなってしまう、居心地の良さやその中で自分が優れているという感覚を得ることはできる一方で、そこで成長が止まってしまう問題があります。

比嘉さんは当時、エンタープライズJavaの世界ではやり切った感がありこれ以上これを続けても伸びないと思うようになっていました。もちろん、少しずつJavaのアップデートなど技術的変化の対応はありますが、それ以上の成長は見込めないと言います。

「明日は今日よりも成長したい⁠⁠、その思いを強く持っていた比嘉さんはこのままSeasar2をやって守りに入ってしまうことを危惧し、新しい開発に切り出しました。Seasar2の路線転換には根本に比嘉さんの危機意識がありました。もちろん、自分の都合だけで開発を中止したわけではありません。ユーザ側に起因する部分もあると続けます。

ユーザも先ほどの問題と似たものを抱えています。フレームワークを使い始めると最初は学びが多くても、長年続けるとフレームワークがわかってきます。トラブルにも対応が早くなるし、ソースもわかるしと良くも悪くも慣れが生じます。 比嘉さんには環境に慣れ、それを極めた、十分やりきったという達成感があったら、エンジニアはそこから離れるべきだという考えがありました。この考え方も開発中止の根本にかかわってくる部分です。広く使われていたので責任を持ってバグフィックスは続けますが、Seasarを極めたら新しいところに行ってほしいと比嘉さんは考えています。

Seasar2からの卒業

ユーザへの思いを告げた後、比嘉さんから驚きのアナウンスがありました。Seasar2のサポート終了の発表です⁠。今まで継続していたメンテナンスも2016年9月16日で完全にやめ、サポートを打ち切る予定とのことです。

他の環境に移ってほしいと思いながらもサポートを打ち切らなかったのは、Seasar2のサポートへの責任に加えて、ファウンダーとして帰ってこれる場所を残しておきたかったという思いもどこかにあったという比嘉さん。今回、ついにSeasarの実質的な終了を思い立ったといいます。

比嘉さんからはSeasar2の新規開発中止の時期から、Seasar2サポートの中心にいた小林さんへの感謝の言葉が述べられ、会場からも小林さんにたくさんの拍手が送られました。

※)
Seasar2のサポート終了については比嘉さんが自身のブログで今後の方針などについて記事を書いています。詳細については当該記事や公式サイトなどをご確認ください。

会場との掛け合い

これまでのいきさつをまとめ、会場に来ていた聴衆からの比嘉さんやSeasarへの質問に答える形で講演は進んでいきました。

まずは、会場にいた庄司嘉織さんから次のような質問が挙がりました。

「比嘉さんはアウトプットが大事だと言っていますが、Seasar2(の開発)が止まってからアウトプットが記事にしてもソースにしてもぐっと減ったように思います。それはなぜなんでしょうか。飽きてしまったのか、あるいは何か戦略的なものがあったのでしょうか⁠⁠。

これに対して比嘉さんはこのように答えました。

「実際にはその後もアウトプットは続けていました。ただ、2011年ごろからなくなってきたと思います。なぜそうなったかというと、2011年5月にジョインした企業の特性上、外に出せるものがあまりなくなってしまったのです。そのため、外部向けの話題というのは2011年5月からはほとんどやっていない。ニコニコ超会議に出たこと、今回、このカンファレンスに出たことが例外です⁠⁠。

Seasar2の開発ストップとともに比嘉さんの業務の関係もアウトプットが減った一因となったようです。

続いて、高井直人さんからは「なぜ今になってSeasar Conferenceを開催したのか?」というストレートな質問が出ました。

「実はSeasar Conferenceの今回の立案者は自分ではない。企画してくれたの橋本(正徳)さんたちです」と、実質のイベント企画者として橋本さんを紹介しました。

「きっかけは飲みの席での話題ですね。そこからこのカンファレンスが始まりました」⁠橋本さん⁠⁠。

開催のきっかけが伝えられたところで、比嘉さんが再び説明を始めました。

「今の話を受けてSeasar Conferenceとは何だったのかを、私自身の視点から解説します。Seasar Conferenceは、最初はSeasarのから騒ぎというイベントでした。OSSのイベントとして、まずはプロジェクトを盛り上げるために始まったのです。そこにコミッタたちがが集まることで、その優秀な人たちを企業が採用する場にもなりました。当時のNifty、Fdelphiなどを目の当たりにしていて、こうなることは予想していました。

当時は、今ほど技術があることに重きが置かれていませんでした。つまり、技術力のある人が会社の中に埋もれていた時代、プログラマへのフォーカスが外れていた時代、実装に落とすことだけが求められており、すごい技術や新しいことが求められていなかったように思います。

そんな中で優秀な人がどんどんコミッタに集まってきました。そこで企業が技術力のある人たちを求めて採用を行い、良い形で転職してという人材の流れが生まれてきました。たとえば、Seasarのコミッタは100人ちょっと、今回のカンファレンスの参加申し込みは550人超。Pythonで有名なビープラウドの社長も来ていますし、他にもいくつかの企業の技術責任者も来ている、そういう人たちに売り込みをかけるいいチャンスの場になっていきました。

一方で、カンファレンスで話を聞くだけでは面白くありません。そういう機会は書籍にもWebにもある。リアルで、人が周囲にたくさん来るというのがカンファレンスの良いところでしょう。自分を売り込みたい人はもちろん、すぐに転職ではないにしても自分が関わっていること、取り組んでいることを外部に話すことはとてもすばらしいです。そして、時代とともに経営者やそれに近いポジションの人たちが優秀な人材を欲することが表面化してきました。

こういうカンファレンスの場で人材を見つけることは良いことだと思っています。Seasar Conferenceにはそういう面があり、続けてきた大きな理由の1つです。今回、数年ぶりに開かれましたので、経営者や人事担当者で⁠この人は⁠という人材を見つけたのであれば、せっかくなので声をかけてみてはどうでしょうか⁠⁠。

ちょうど今紹介されたビープラウド代表佐藤治夫さんから「比嘉さんのように世界で使われるOSSを開発する方に憧れる人は多いと思います。今はDJ方面に進んでいるとのことですが、プロダクトを生み出したいエンジニアへのメッセージはありますか」と、エンジニアに向けたメッセージが求められました。

「2004年以降、Seasar2を世の中に出してから思っていること。多くの人にとっては、良いアイデアを思いついた、これを世の中に使ってもらってどのぐらいいいものか確かめたいというのが開発の動機だと思います。アイデアが動機。Seasar2以降はとくにその傾向が強いと感じていますが、私はそういう考えで動いていません。

重視しているのは⁠世の中の人が何を考えているか⁠です。たとえば設定などでXMLを使うのは前提、常識だったがXMLは面倒という声が世の中に多かくありました。そこからSeasar2では可能な限りXMLを減らす発想が生まれました。

2005年ごろからRuby on Railsが流行り始めました。それは、スクリプト言語のサクサク開発できる感じが受けていたのだと思います。そこの声を感じて、Seasar2.4ではホットデプロイを投入しました。

ほかの人も欲しい、自分も欲しいというものは、世の中の人のニーズと合致し喜ばれるものになり使われていきます。アウトプットするだけではむなしいですし、使ってくれるユーザが少しでも多い環境でやらないとアウトプットも続けられません。人が欲しいというものから機能に落とし込む、それを自分が本当に欲しいか考えて欲しければ作る。それをずっと続けてきました。

素晴らしいアイデアが使われるというわけではありません。使われるものが良いもの。アイデアの時点ではそこに優劣はない。使われるかどうかが問題です⁠⁠。

最後に、ジャーナリストの星暁雄さんから、Seasar2の今後に対する質問が行われました。

「Seasar2は比嘉さんが所属する企業のビジネスに組み込まれ、いわば社業として続けられていたものもあるのではないでしょうか。ビジネスとしてのSeasar2を終わらせることができて、初めて今回発表できたのかなと思います。しかし、ユーザに対しては、Seasar2以降の何らかの道筋を示してあげたほうが親切ではないでしょうか⁠⁠。

これに対して比嘉さんは次のように答えました。

「まず、私の所属企業にとってSeasar2はビジネスではありません。お金にするというよりは、Seasar2を広げていく活動の一環でした。商用サポートというのは手間のわりにお金の儲からない分野、OSSの商用サポートは多くありますが、実際はそれだけでは難しいのが現実です。多くの企業がセミナーなどと合わせてどうにか(ビジネスの形に)していると思います。ビジネス的には大変な分野です。

その上で、移行パスについて考えていることはあります。このフレームワークを組み合わせればなんとかなるというのを提示するのは簡単です。ただ、言ってはいけない気もしています。⁠立場として)権威的なところから発言するべきでないと思っているからです。たとえば、Seasar2の代わりにScalaを使うべきと考えている技術者が多いときに、私がSpringを使おうと言い出したら次はSpringでという流れが生まれてしまいます。私としては、今後の移行については、技術者自身が選択肢を選べるほうが良いと思っています。ですから、そこは各自で考えてもらいたいです⁠⁠。

さらに星さんからは「他にもStrus 1.0を捨てられない現場があるのでは?」という追加の質問がありつつも、比嘉さんはエンジニア自信に選んでもらうことを強く推し、Seasar 2のサポート終了という大きな話題を含めたキーノートを終えました。

継続的インテグレーションの過去・現在・そして未来~ヌーラボの事例と共に考える~

続いて、ヌーラボ中村知成さんによる、ヌーラボの取り組みから考える過去・現在・未来の継続インテグレーションに関する講演を紹介します。

ヌーラボの過去・現在・未来

ヌーラボは、設立当初、最初の環境整備期から自社サーバを持っていましたがメンテナンスが追い付いていない状況でした。⁠ビルドに時間がかかる」⁠DBスキーマの変更で失敗」といったことが起きつつも、テストの失敗をまとめて修正することが多く、リアルタイムでテストが活用できないという問題があったそう。

そんな中、中村さんがチームに参加した2012年にその体制を一旦仕切り直します。まず、テストで失敗したものについては即座に対応、また、良いスペックのサーバでビルド時間を短縮、中村さんがCI番長として、ビルドエラーが起きたら担当者にすぐ通知する、というように社内の開発体制の整備・改善を行いました。その後、2013~2014年にかけて適用範囲を拡大しました。継続的デリバリ、スレーブの自動起動、Ansible, Serverspecによるインフラ部分のCIも進めました。ChatOpsによる経過や結果の共有を手軽にしたのもこの時期でした。

そして現在はPRベースCI、ビルド環境のコード化に取り組んでいます。Backlogは最新のバージョンからPull Request機能が追加され、コードレビューをしやすくなりました。その結果、レビューと合わせてCIでのビルド結果も判断材料に含めるようになります。

GitHub+Travis CIというならこのあたりも簡単に実現できますが、Jenkinsでは難しくなります。そこで、Jenkinsプラグイン自作で対応しているとのこと。ビルド環境のコード化、PRベースCIが導入されてビルドに必応なスレーブ数が増える→最初はmasterブランチをCIしていたがPR対応でブランチごとにslaveを増やす必要がある→スレーブごとに手動設定するわけにはいかないのでコード化という流れで導入されました。

このコード化に使うのはDocker、ジョブごとにDockerコンテナを立ち上げて対応しています。各プロジェクトごとのdockerfileを作成。Jenkins EC2 Pluginを使用し、スレーブ構築時にDockerをインストールしています。他にも方法はありますがJenkinsのスレーブにはDockerが楽と中村さんは思っているとのことです。

ここで、今後の流れについて考察を述べました。

昨今のCI as a serviceの人気
  • Jenkinsの自前運用はコストが高い OSSであるせいかUIなどもわかりづらいところがある
  • 設定の複雑化に伴って生まれた*jenkinsj職人*の排除。ビルド職人からJenkins職人の登場
  • 運用コストの高さ
  • Jenkinsでもある程度は活用可能、JenkinsでもEC2 pluginなどを活用して必要な時に手軽にスレーブ構築もできる
  • それもつらいなら全部外部サービスにする手も
設定の複雑化にはどう対処するか
  • Workflow Plugin
  • DotCI

つまり、画面上から設定するのではなく、.travis.ymlやcircle.ymlのようにコードとして設定を記述します。

CIツールの振り返り

ここで、中村さんは採用してきたCIツールを振り返りました。

まず、cruisecontrolなどによって開かれた概念実証フェーズ。動かすまでが大変でCIの有用性を実感できるところまでは結び付かなかったとのこと。そして、Jenkinsの登場とともに訪れた、一般に普及していくフェーズ。設定もしやすくなり、Javaさえ入っていれば動かせるようになりました。このころからCIのハードルが下がり、CIをあたりまえのように使えるようになりました。

そして効率的に利用するフェーズに突入しTravis CIやcircle ciなどより手軽にスケールしやすいサービスが生まれました。

プロジェクト、Issue管理ツールも最初はbugzillaなど使うのも大変なもの(概念実証フェーズ)から一般に普及していき(Redmineなど⁠⁠、その後効率的に利用するフェーズ(Backlog)が生まれてきた歴史があります。

ヌーラボのCIは今後どうなる?

最後に、ヌーラボのCIは今後どうなるのか――現段階では全移行は高コストと中村さんは考えています。Jenkinsできっちりとフローを組んでいることやJenkinsの自作プラグインによる運用があるからです。

Dockernizeを進めていけば移行時にも無駄にはならないと睨んでいるそうです。また、移行にはお金がかかる、外にお金が出て行くという問題もあります。現在はビルドサーバのそもそものコストが高いのも無視できません。

ただし、一般的にはSaaSも選択肢にはなってきています。適材適所で使い分けることが可能です。ヌーラボでもGitHubで公開しているライブラリはtravisでCIしています。Jenkinsで簡単なテストをして、その後社内でライブラリなどを使ったテストをする二段組みも試したことがあるとのこと。

まずは状況に応じた利用・運用が進められていくのではないでしょうか。このセッションでは、CIの歴史、現在のヌーラボの取り組み、今後の流れの予想がまとまってわかる内容が取り上げられました。

SmartNewsとBacklogの作り方

続いて、再び比嘉さんが登場し、SmartNewsとBacklog、2つの成功したサービスの開発者である浜本階生さん、橋本正徳さんから成功するサービスの作り方を学ぶセッションが行われました。このセッションは、トーク形式で進みました。

画像

まずはSmartNewsの浜本さん、ニュースアプリのSmartNewsは現在1,300万DLに到達しています。正式なリリースは2012年12月、前身のサービスも考えると2010年から開発を続けています。2010年ごろはSeasar依存で当初は恩恵にあずかる形でした。現在ではもう少しモダンな構成に移行しつつあるものの、Seasarも引き続き使っています。

ヌーラボ橋本さんはプロジェクト管理ツールとして人気のBacklogの作り方を解説します。ヌーラボは作図サービスのCacoo、チャットツールのTypeTalkなど企業で、あるいは企業対個人で働くときに使いやすいサービスを提供しています。

はじめ

比嘉:

一番最初はクローラから入って、ニュースアプリに移行したと聞いていますが、なぜニュースアプリに移行したのでしょうか。

浜本:

もともとはクローラーを作るのが趣味でした。最初はAsk you、その後は食べログ、次いではてななどのクローラを作りました。その結果、次第に興味がジェネラルな対象に移っていったのです。それに伴って情報、ニュースへの関心が高まり、⁠新しくて役に立つ情報がWebの広範なクロールで獲得できること」に気付いたのです。

比嘉:

個人的な興味でクロールをはじめたそうですが、その部分の影響は大きいですか。

浜本:

Twitter APIをかなり使っていました。そこからソーシャルグラフを作成し、関係性の強いツイートを選別、その中のURLをまとめればより個人に特化した情報を集められるという発想がありました。

比嘉:

SmartNews開発の裏側の体験談として、⁠プログラマとしては適切な情報を集められる、いらない情報のないニュースがないほうが良いと思っていたが一般受けしなかった」という話を聞きました。実際はどうだったんでしょうか。

浜本:

その問題について、実はSmartNews前に、ユーザテストから「個々人向けにフィルタした情報」にあまり価値がないことはわかっていました。パーソナライズされた情報を重要だと以前は思っていたのですが、その発想のもとで失敗した経験があります。そこから情報のうち「共有できる関心ごと」が重要なことに気付いたのです。パーソナライズ志向からの180度の転換ですね。ノーパーソナライズで既存の技術を応用してSmartNewsが生まれています。

比嘉:

スタートアップ企業が方向転換すること、いわゆるピボットすることはよくあるケースですが、そこで難航するのも事実。なぜそこでうまく転換できたと考えますか?

浜本:

内部的な話になるのですが、当初、情報のパーソナライズ度合いを設定できるシステムを作っていました。そこでパーソナライズ度を一番薄い状態にしても面白い情報が入ってくることに気づいたのです。

今までの考え方とは異なりますが、そこで表示される情報もよくできていたように思います。私はシステムのパラメータチューニングを自分で細かくやるのが好きです。また、機械学習で最適なパラメータを決めることは初期段階では難しい、その時点でのベストな解を導く(チューニングする)必要があります。そこの過程でパーソナライズしない部分の良さを見出したのです。

変化の余地をあらかじめ残しておいたというのは他の多くのスタートアップとは違う点かと思います。パーソナライズでの局所最適のことを考えていましたが、実はそのもっと外に大局解があったのです。ノンパーソナライズの世界の良さに気づけました。

比嘉:

UI変更や機能の選択はどうしました?

浜本:

たとえば、SmartNewsは朝刊・昼刊・夕刊から最新のものを表示し、かつさかのぼって以前の発行をさかのぼれる機能がありました。昼刊を夕方に表示したことで最新の情報を見たいという反応があったからです。そのロジックはエンジニアとしては理解ができましたが、ユーザにはうまく説明できませんでした。さらに一歩踏み込んで、そもそも選択肢がなくていいのではないかという発想に至り、現在のUI、そして機能となっています。

比嘉:

次にBacklogについて伺います。Backlogは必要性に迫られて作ったものだと聞いています。そこの経緯を聞かせてください。

橋本:

Backlogは受託請負の会社だったときにつくったもの。当時、本社は福岡にありました。東京の仕事を受注して福岡に持って帰ってという形で受託開発をしていました。この東京―福岡間のやりとりをどうするかという問題があったわけです。メールでのやりとりは大変でしたし、Issueトラッカーもありましたが、業務用のとっつきにくいものでした。そういった背景から、共同創業者とその問題を共有でき、その問題点の解決のために今のようなBacklogが生まれたのです。

比嘉:

Backlogの転換点はあるとすればどこ?

橋本:

公開のタイミングですかね。Backlogの公開は大きい出来事でした。ソフトウェアというよりも会社としての転換期かもしれません。⁠いかにも業務用」ではないものを世の中に出しました。クラウドへの不信感や提供する会社の規模への不安など、当初はBacklogは炎上気味であったものの続けてきました。そして今のような形になっています。

そういえば、炎上といえばSmartNewsも一時期燃えたことを記憶していますがどうでしたか?

浜本:

圏外でもニュースを読める機能が炎上しましたね。一度は公開停止しようかと思ったのですが、当時ITmediaの藤村さんが火中の栗のような案件にもかかわらずジョインしてくれました。彼が丁寧に媒体社に、より良い体験をユーザに提供することなどを解説し、関係をうまく取り持ってくれて進められました。

そこで助けてもらえたのは、藤村さんがサービスの意義を理解してくれていたからだと思います。藤村さんは良い意味で衝撃を受けてくれていました。スマートフォンの新しいメディアをつくりたいという思いで動いていたそうですが、媒体との折衝で難航していたところに折衝なしにSmartNewsが登場したことで大変驚き、そこで本能的に魅力を感じ、新しいものがあるのではないかと感じジョインしてくれたという経緯があったわけです。

比嘉:

では、Backlogの炎上はどうやって回避しました?

橋本:

放置、です。炎上しましたが結局はサービスは伸びていきました。当時はBacklogに近いことをやろうと思ったらインストールが前提、ASPで使えるものはなかったことなど人気になる理由がちゃんとあったのです。ものが当たるときは賛否両論にきっちり分かれる。炎上はそういう時の非だったと思います。すぐに使える、インターフェースの良さがきちんと受けました。

比嘉:

Baclogはどんな感じでユーザテストしていますか?

橋本:

実はあまりユーザテストはしていません。現場で自分たちが使いながら改善していくスタイルです。社員がUIについてものを言う、意見のあるタイプが多いので、自然と多くの意見が出てきます。一方でUIまわりのデザインは社外の人を採用しています。その人はアナログ寄りで、あまりインターネットに強いという感じではありません。その人に加わってもらうことで、自分たちだけの視点ではないものができるなどのメリットでした。

比嘉:

(インターネットに強い、弱いで言えば)ダウンロード型ではなくASP型にしたことで受けたと感じています。私の会社でもBacklogを使っていますし。開発者が少ない状態でも使うことは多いですね。気軽にWebで使えるという点は非常に大きいと感じています。なぜ、ASP型を採用したのでしょうか?

橋本:

特別な理由はありません。しいて言えば、パッと使えたほうがいいという意識はあったのでそれを開発担当者が採用。とにかくすぐに使えることというのは意識していたことなので、ダウンロードはあり得ないという共通認識で進んでいましたね。

比嘉:

最初から? 作りながら?

橋本:

初期のコンセプトでダウンロード型ではないというのはありました。そうするかどうかでプログラムの作り方も全部変わってきてしまうからです。ダウンロード型だと1社だけで使えればいいということになってしまいがちですが、ASPの場合、より多くの人を意識する必要があります。開発当初にその点は意識していました。

比嘉:

ピボットというのはよくある話ですが、この両者は根底にあるものは変えていませんね。

アメリカのイベントSXSW(サウス・バイ・サウスウェスト)で、無料Wi-Fiが用意されていたものの、あまりにも人が多くてほとんどつながらないことがありました。SmartNewsはそういう電波のない環境、飛行機の中でもサービスを深めたというところから生まれてきたと思います。そこで電波なしから物議を生む発想が生まれました。実際に自分たちが困ったところがサービスを生んでいる特徴があるわけで、それはBacklogも同じです。

スタートアップのだめな例として、方向性を変えてどれもうまくいかないというのがあります。その要因の1つは、コアが魅力的なアイデアじゃなくて押し通すことができないということもあるでしょう。

そういう観点で考えた場合、SmartNewsはたとえばインターネット環境がない場合でも読めるといった機能を削減して出そうという考えはなかったですか?

浜本:

そういう話ももちろん出ました。しかし、当時日本では地下鉄に電波が入りませんでした。そうするとほとんどスマートフォンが(情報取得に)使えなくなります。そんな環境でいくらでもニュースが読めるようになれば、長期的に業界全体のメリットになるという信念があったのです。そして、この信念が受け入れられるという確信もありました。藤村さんのジョインでその状況も良くなりました。

比嘉:

そこからずっと順調ですか?

浜本:

順調にやってきたと思います。昨年、アメリカ進出も果たしました。これも大きな転換点でした。ただ、英語化するなど、アメリカの情報を入力してもらうだけではなく、現地のスタイルを感じてSmartNewsを作る必要を感じたのです。結果、現地に何度も足を運び、拠点も作成し、現地で採用も行いました。アメリカにコミットして進めました。それがよかったと思っています。

比嘉:

Webの情報ではアメリカでもMAUが100万超えと聞いています。アメリカのためにどのようなデザインなど取り入れましたか?

浜本:

英語は日本語に比べて一文字の情報量が少ないです(アルファベットに対する漢字仮名の情報量の差⁠⁠。同じスペースに情報量を詰め込むのは不利になります。そこで、なるべく、大きめの面積でニュースセルを表示して対応しました。

もちろん端末サイズで切り替えますが、アメリカ版では3カラム表示は避けています。メインは2カラムなど細かい変更点が多くあります。このあたりはアメリカでのユーザテストを踏まえて調整しています。テストに関しては、たとえばカフェで個人が英語レッスンをする英会話カフェがあるので、英会話はせず、アプリを使ってと、ユーザテストの場にしたこともあります。

比嘉:

なんとなくユーザテストは海外に行かないとだめというイメージがありましたが、そういう方法があるのはおもしろいですね。

浜本:

アメリカではCraigslist、3行広告が人気です。短い文言で、簡単な依頼をする広告。これを使ってテック業界やネット業界とつながりのないユーザを集めてテストできますね。

比嘉:

Backlog、あるいはヌーラボの海外進出についてはどう考えていますか?

橋本:

ヌーラボはソフトウェアファースト。ある程度狙って英語版は出していましたが、基本的にはユーザがどんどんソフトウェアに対して増えていくという形。ユーザの分布やユーザがいる地域のテック関連の発展具合、あるいは海外の現地スタッフなどを活用してそのあたりを見ながら海外については考えて進めています。

比嘉:

SmartNewsでは現地の人を考えてチューニングをしていました。ヌーラボは?

橋本:

ヌーラボではしていませんね。ただし、スタッフとして海外在住者を採用しています。そうするとそこのスタッフから要望出てくるので、その調整をします。あまり海外向けのチューニングを強めにやっているとは言えませんが、採用の仕組みなどから海外の声が入りやすくなっていると思います。

比嘉:

SmartNewsはスタートアップの典型のような山あり谷ありで今の成功、ヌーラボはのらりくらりという感じで対照的でおもしろいですね。

橋本:

のらりくらりとは会場に現場のスタッフもいる手前、言えません(笑⁠⁠。仕組みをどの程度整えるかという観点はありますが、社員内でのフィードバックも多く、ユーザフィードバックは積極的に取るユーザボイスやユーザミーティングなどで外の声を積極的に取り入れることができるようにやってきています。

比嘉:

最後にSmartNews、Backlogを作った2人から、プロダクト作る人向けのアドバイスやそれぞれの募集する人材について教えてください。

浜本:

個人的な経験として、作ってる側のプロダクトへの目と、ユーザの目は全然関係ありません。思い入れも理解もないユーザの目はまったく違います。あとになって、自分の、作る側の思い込みに愕然とすることがあります。自分としてはどれだけ客観的になろうとしても、自分が思い入れを作るものにはバイアスがかかるからです。まず、そういう開発者バイアスを減らしていかなれければいけないと思っています。それは今も苦しんで試行錯誤しているところですね。その解決法として、ユーザテストというやり方もあります。

また、ほかのプロダクトを触って自分たちが作っているものとの比較もしなければなりません。たとえば、街中を歩いている人たちのスマホ利用を観察することも役に立ちます。ファミレスで、女子高生の雑談からアプリ利用の方法を聞くなんてこともできるわけです。とにかく、自分の感覚じゃないものを取り入れる努力をしていくことが必要です。プロダクトへの冷静な目を持てるといいと思います。

弊社が募集する開発者のタイプはプロダクト志向です。触ることのできるもの、それがサービスと比較したときのプロダクトの意味合いだと思います。我々ならスマートフォンのアプリ、ユーザインターフェースがそれ。サーバーサイドであってもその意思決定がユーザに届く部分がある。その届き方の違いがちょっとだとしても、ユーザが受ける感覚は全然違います。その繊細な意識ができる人は貴重なので、そういう人を歓迎したいです。

橋本:

開発者にとって大事な点が3つあります。

  • おかしいぐらい夢中になっていること
  • 冷静な分析
  • 素早い判断

浜本さんのことは以前から観察していて、おかしいぐらい(一つのことに)熱中しているなという印象を持っていました。SmartNewsのUI変更のときは完全に目がいってしまっていたように記憶しています(笑⁠⁠。2人で飲んでいたら、突然周りにいる見ず知らずの人にアプリについて意見を聞くなど突飛な行動を始めたりもしました。でも、それぐらいの熱中度があるといい。ただ、その熱中度が開発者バイアスのような悪い影響を生むこともあります。そこで冷静に分析すること、その分析からさらに素早い判断を下すことがまわせれば良いわけです。それは実際に作るところの話ですね。さらに売るところの大変さもあります。今回はそこまで話せないので割愛します。

ヌーラボは今は人材募集は行っていないので、募集についてはとくにありません。

以上、SmartNewsとBacklog、2つの日本発のプロダクトを開発したエンジニアの生の声、そして、プロダクトに対する思いを聞くことができるセッションでした。

Javaプログラマー向けGoガイド

次はAbby代表取締役米林正明さんによるJava経験者向けのGo言語解説のセッションを紹介します。ちなみに、米林さんはSeasarはシステム開発の案件などで利用していたそうです。

1年間、Go言語を利用してサーバサイドAPIの開発をしてきた米林さん。Javaの代表的なIDEの1つであるEclipeseはもう数ヵ月使っていないそうです。米林さんが今までJavaを経験していながら、現在よく利用するようになったGoの魅力とはまりどころを解説してくれました。

画像

JavaからGoへ - その文法

まずはGoの言語的説明から。GoはC言語に近くLLではありません。Javaと比較するとJava(およびその周辺のエコシステム)にはある継承、Generics、例外、ライブラリのバージョン指定などいろいろなものが用意されていません。ですが、米林さんはGoに満足しています。その理由は「良いところが満載だから」とのこと。

まず、LLに近い実行方法である「go run」はその1つ。コンパイルと同時に実行できるJavaで言えば「javac」「java」の合わせ技です。Javaプログラマはclasspathを意識するのに対し、Goではgopathが重要です。goは「go get」ですぐにインストールできるなどメリットが多くあります。Javaで言えば、イメージとしては.m2repo以下で書くようなもの。

また、gopath配下で開発するのは当初は違和感があったと言います。Goではpackageの指定にimport文を使います。GoはJavaのようにコンパイル時にライブラリ指定が不要で、ソースコードで依存関係を明確にするためソースコード内で完結する明瞭さがあります。Javaでいうアクセス指定子private publicを大文字小文字であらわすのはプロダクトに投入して以降気づくなどJavaになれているとハマる点もあることを自身の体験談も交えつつ語ります。

interface、型キャスト、例外処理や戻り値、初期化子の違いなどJavaからGoへの移行を考えている人に欠かせない情報を解説していきます。とくに特徴的なのが例外処理です。Goには例外が一切なく、PanicとRecoverなど例外っぽいものもあるにはありますが、言語の作法として常にエラーを返します。議論もあるがソースコードで関数を呼んだら常にエラーを判定させる。例外については最初は違和感があるものの、最終的にはここに落ち着くそうです。

Goの作法

言語仕様から少し離れたGoの特徴について。一般に配布には必要ライブラリを含める必要がありますが、Goは単一の実行可能ファイルができ、かつクロスコンパイルも可能と配布はとにかく容易です。本番と開発の設定変更はJavaのprofile(Maven、Spring bootなど)に対してGoはtagでファイルの指定から切り替えることができます。

次にテストについて。Goを数万行書いた米林さんですがその半分以上はテストだと言います。JavaはJUnitが基本でAssertを実行しますが、対してGoではtestingパッケージを利用しAssertはありません。if文で処理します。ソースファイルとテストは同一パッケージで進め、たとえばcalc.goならcalc_test.goと命名するなどややJavaの経験がある人には違和感があるものになっています。

コード整形でもGoには特徴的な文化があります。IDEまかせのJavaに対して、Goはgofmtやgoimportsによる言の公式なサポートによるコードの統一が可能です。golintによるlintやgo vetによるスペルミスチェックなども有用なツールです。GoではVCSで余計な差分に悩まされるようなことがなくなります。

今まで述べてきた事柄について基本的には違和感を抱きつつも落ち着きつつある米林さんもGoによる依存関係まわりだけは気になっています。JavaではGradleやMavenが担う領域である依存関係の管理ですが、Goの場合は基本的にバージョン指定ができません。これは1個のプロジェクトだと問題にならなくても、複数のプロジェクトでは困ります。プロジェクトごとに異なるバージョンを使いたい時は、go getでライブラリを追加していきGOPATHで単一に管理するGoで困ります。Goではそのような問題に対してVendroingが1.5で試験的に入りました。これでGOPATH配下ではなく、自分の必要なところにあつめてプロジェクトごとにライブラリを入れて解決という使い方ができます。ほかには3rd partyのgodep, gbでもこの問題に対処できます。

最後に

一通りのJavaプログラマー向けのガイドを終えたのち、最新事例も含めて米林さんのGo開発事例を紹介しました。

最後にJavaユーザにGoは向いていること、これからも米林さん自身Goを使用していくこと、はまりどころや問題も思ったほどはなかったことなどJavaユーザにGoの利用を前向きにすすめます。質疑応答ではリフレクションやライブラリの管理への質問、JavaではなくGoを採用した理由、genericsに対する意見などについて聴講者と語りました。Goを採用したのはCTOが当時興味を持っていたことや、話題性も一因だったようです。

現在最も話題の言語の1つであるGo。この講演で利用への興味が増した人も多かったのではないでしょうか。

まとめ

Seasarのサポート終了告知から始まった波乱のSeasar Conference 2015でしたが、Seasarをきっかけに集まったエンジニアのSeasar後のこれからを予感させるカンファレンスでした。

おすすめ記事

記事・ニュース一覧