【自社プロジェクト編】シナップエンジニアのお仕事紹介
こんにちは、エンジニアの池田です。
今回は[前回][第二回]までとは違って、自社企画のプロジェクトをご紹介したいと思います。完全に自社のことということでテンションもこれまでとちょっと違いますが、どうぞ楽しんでください。
前回までの内容を忘れてしまった方は以下のリンクからどうぞ。
<シナップエンジニアのおしごと紹介シリーズ>
第1回：「【星海社サイト編】シナップエンジニアのお仕事紹介」
第2回：「【モリサワ TypeSquare編】シナップエンジニアのお仕事紹介」
第3回：「【自社プロジェクト編】シナップエンジニアのお仕事紹介」
サマープロジェクトとクリスマスプロジェクト
シナップでは、自社プロジェクトとして年に二回、夏とクリスマスに企画物のページを公開していました。以下のページにまとまっているので見てみてください。
これは、必要・不要を度外視して新しいことに挑戦したり、クライアントへアピールする機会を作れるほか、クリスマスプロジェクトはチャリティーという側面もあり、わたしなどはいい文化だと感じていました。ところが、この活動は2014年にはどちらも行わないことが決まり、結局わたしが参加できたのは、最後のクリスマスプロジェクトのみとなりました（編注：池田は2013年夏入社）。
「お祭り」がなくなってしまい純粋に寂しいということもあり、また「失敗してもいい環境」というのは組織にとって絶対に必要なものだと思っているため、軽い危機感を覚えてもいました。
新しい自社プロジェクト
そんな中、今年2015年になり、サマー・クリスマスプロジェクトに代わって別タイプの自社企画がスタートします。
一つはiOSアプリの開発を行っている、コードネーム「C3PO」（編注：若い方はご存じないかもしれませんが、『スター・ウォーズ』という大人気映画シリーズの登場人物です。ひょうきんな優男ロボット）、もう一つは電子書籍に関するサービスを作っている「R2D2」（編注：C3POの相棒のようなロボット）です。
従来の二つは夏冬の季節のみの企画でしたが、今回の二つは恒常的に活動しています。それぞれ紹介していきましょう。
C3PO - iOSチーム
C3POは、先日OSS化が発表されたことでも話題を集めたプログラミング言語Swiftを使って、iOSアプリを開発しているチームです。
シナップではこれまでウェブのコンサルティングと制作を主軸にしてきており、iPhoneを始めとしたスマートフォンのネイティブアプリの開発ノウハウでは出遅れていました。そこでC3POチームでは、まず一つ公開できるアプリを作ることで、開発開始からリリースまでの流れを一通り体験すること、絵空事に留まらない実装レベルの話ができるようになることを目標にプロジェクトを進めています。
チーム構成はデザイナー一人と開発者二人。二週に一度ミーティングを設け、KPTのフレームワークに沿った振り返りと、続く二週間の計画立てを行っています。
KPTではその名の通り、この二週間でやってみて効果があり継続すべきこと（keep）、起こった・顕在化した問題（problem）、続く二週間で行う問題解決法や挑戦したいこと（try）を洗い出して定期的に振り返ることで、継続的にチームを改善していくというフレームワークです。受託案件の始まりから終わりまでが済んだ後で振り返りを行うのとは違うメリットがあります。
まず、振り返りの間隔を短く取ることで、リストアップされるK、P、T、それぞれの要素を少なめに抑えることができます。一年も掛かるようなプロジェクトだと、終わってから洗い出すと膨大な量になってしまい、当然すべてを覚えておくことはできません。二週間で挙がる程度であれば、続く二週間、頭の中に留めておくのは難しくないでしょう。
素早く振り返ることには、問題があった時に早い段階で全員がそのことを認識できたり、頻繁なノウハウ共有によってチーム全体としての能力が上がったりする効果もあります。
また、非常に大事なこととして、「同じプロジェクトは二つとない」ことがあります。どのプロジェクトも、どんなに似ていてもそれぞれに異なるため、プロジェクトが終わった後に出てきたKPTでは、そのまま次のプロジェクトに活かせる物がそれほど多くないのです。チームメンバーも変わってしまうことが多く、メンバー固有の「これならうまくいく」という連携や「あの時のあれ」といった高速なコミュニケーションもなかなか取れません。
定期的なKPTはリズムもよく、また全員が慣れてくることでミーティング時のファシリテーションも楽になってきています（編注：池田は別にファシリテーションをしているわけではない）。
この二週間おきのミーティングの他に、毎日のミーティングも行っています。朝、前日やったことと今日やることを確認し合い、心配事や問題があればチームメンバーに共有します。そのまま対策の相談に入ることもあります。ほかの案件にも携わっている人がほとんどのため、前日、当日とC3POの作業はしない人も出てきますが、それでも毎日継続してミーティングは行うようにしています（編注：ときおり忘れてしまうこともあるようですが）。
こうした体制で、数週間に一度、全社員に現在の動くものを見せたり、社内リリースしてフィードバックを集めたりしてアプリ開発を進めています。この記事が公開される頃には実際にお目にかけられる物があるかも知れません（編注：もうちょっとお待ちください......）。
R2D2 - BiB/iチーム
R2D2チームでは、BiB/iというEPUBリーダーを使った自社サービスを開発しています。
BiB/iはデザイナーの松島が個人で開発しているOSSで、ウェブブラウザーで動作するEPUB（電子書籍用のファイルフォーマットの一つ）リーダーです。EPUBファイルをブログなどのウェブページに埋め込んで、ページの一部として本を見せられることが大きな特長です（編注：要はYouTubeはSlideShareみたいな......）。単独のEPUBリーダーとして、ブラウザー内でBiB/iを開いてファイルを放り込み、読むこともできます。
メンバーはデザイナー二人と開発者一人です。デザイナーとは言っても一人は松島で、BiB/iのウェブデザインと開発（HTML、CSS、JavaScript）の両方を行っています。二週間おきのミーティングと毎日の朝会を繰り返して開発を進めているのはC3POチームと同様です（編注：相棒なので）。
また、『Running Lean』というスタートアップ向けの本に載っている手法を使って、顧客インタビューも始めています。
『Running Lean』では、顧客（見込みとなる人達）に対して行うインタビューを、課題インタビューとソリューションインタビューの二つに分けています。
課題インタビューは、自分たちが課題だと考えているものが、そもそも、本当に顧客にとっても課題となっているのだろうか、なっていないとしたら本当の課題はどこにあるのか、ということを明らかにするためのインタビューです（編注：念のために言っておくと、単に「課題はなんですか」と尋ねるだけではありませんよ）。
そうして明らかになった課題に対して、自分たちが提供しようとしているソリューションが本当にソリューションたり得ているのか、実際に顧客がお金を払ってくれるだろうか、ということを明らかにするのがソリューションインタビューです。
当然、課題インタビューを繰り返して課題をはっきりさせ、そのあとでソリューションは何がいいのかという仮説を立ててソリューションインタビューで改善したり、場合によっては捨ててしまって別の仮説を試すことになります。
ですが、R2D2チームでは課題インタビューと、既に作ってあるサービスを見せながらのソリューションインタビューを、同時に行っています。失敗だと自分たちでも感じています。
最近、シナップでは全員で『リーンスタートアップ』（編注：『Running Lean』の理論的背景となっている本）を読み、また今、輪読の形で『Running Lean』を読んでいますが（編注：先日輪読が終わりました）、R2D2の開発を始めた時にはチームはそれらについて知りませんでした。まずはプロトタイプとなる物を作ってリリースし、それへの反応をもとに方向を探っていこう、というスタンスでいたのです。
こうして後からリーンのことを知ったため、またその時には既にある程度動く物が出来てしまっていたために、課題インタビューとソリューションインタビューを分けずに実施するという少々いびつなことになっています。しかし、（二冊の本から学んで）これがいびつだということは自覚できているので、「課題インタビューの段階で、こちらの課題認識がおかしいようであれば、サービスを見せてインタビューすることにはこだわらないようにしよう」など現状に合わせた方法をチームで話し合いながら進めています。また、こうした「失敗」を、会社の大きなプロジェクト、クライアントのいるプロジェクトではなくて、自社のみの小さなチームでの失敗に留められていることは幸運だし、まさにそのための自社プロジェクトでもあるため、有効に働いているのだとも感じています。
こちらも、この記事が読まれる頃にはサービスインしているはずです。
（編注：『パン』ベータ版としてリリースしました！ ぜひご覧ください：
https://pan.press/）
以上二つが新しい自社プロジェクトです。
ミーティングやインタビューなど、いわゆる「開発」以外のことに時間を使いすぎていると感じるでしょうか？ そうかもしれません。ただ、シナップでは、そうした部分が非常に大切で、かつ実は開発も加速させる物だと考えて、半分試験的にこれらを導入しています。もし、「やはりコミュニケーションの時間を取り過ぎて全体としてもスピードが落ちている」という結果になれば、それはそれで、そういう学びがあるのでいいことです。そうして確信を持って開発の方の比重を増やすことができるわけです。ここでも、「試験」を行う場があるということで、重要なプロジェクトだと思います。
なお、この二つのプロジェクトは、三か月単位で継続が判断されます。幸い（かどうかは分かりませんが）、三月から始まった両プロジェクトは六月以降も継続することになりましたが、九月にどうなっているかは分かりません（編注：どちらも継続が決まりました！）。プロジェクトはそのままでメンバーが一部入れ替わる、メンバーが増えたり減ったりするという可能性もありますし、メンバー総入れ替えでテーマも変えて、全く新しいプロジェクトを始める、という可能性も充分あります（編注：他の人にも参加のチャンスがある、というわけですね）。
何しろ始まったばかりの試みで、結果を見みながら色々と改善していくことになります（ここでも「繰り返し」が活きてきます）。自社プロジェクトで色々と試した結果がだんだんと会社のプロジェクト全体にも浸透していくことでしょう。
昨年感じていた危機感は払拭されそうです。
オフィスシェア
シナップは原宿の住宅街にオフィスを構える会社ですが、このオフィスは、シナップ以外の会社さんにも使用してもらっています。JavaScript、ウェブフロントエンド開発で名高いPixelGridさんです。
オフィスが同じということで、顔を合わせる機会が多いのはもちろんですが、仕事上でも同じプロジェクトを共同で行ったり、パーティやプロジェクト打ち上げでご一緒するなどいい関係を保てています。
また、そうした直接的な交流ではなくても、エンジニアにとっては、隣の席から聞こえてくる（JavaScriptに関する）雑談だけだけでも刺激になります。
以前は、PixelGridさん以外にも、Georepublic JAPANさんともオフィスシェアをしていました。Georepublicさんは数か月前にオフィスを離れてしまいましたが、これからもまた素敵な会社さんと同じ場所で仕事ができる日が来るかも知れません。シナップとしては、お互いいい関係を築ける会社さんとはぜひお願いしたいので、シナップのことを見付けてくれる所があればそういう日が来ることでしょう。
まとめ
シナップでは、始まったばかりの試みに参加して自分も積極的に楽しみたい、仕事のみの関係でない人たちの中で仕事をして程よい刺激を受けたい、というエンジニアを募集しています。以下の採用情報ページからぜひご応募ください（編注：ご応募ください）。
また、応募の前に様子を見てみたい、という場合にはランチをご一緒したり、会社見学をするなどもできると思うのでお気軽にご相談ください（編注：ご相談ください）。
