ペラナビ連載
- ペラナビリリースに当たっての想い - ペラログ
-
ペラナビ連載3回目 「ペラナビ」開発現場のチャレンジ - ペラログ
リリースから2週間を迎える新サービス、「ペラナビ」をテーマとしたブログも今回で連載3回目となりました。
前回のブログでは、「ペラナビ」がどのような紆余曲折を経てサービスとして定義づけられたのか、といった企画の現場のお話をご紹介いたしました。
この現場でキーパーソンとなったのが佐藤さんです。今回の「ペラナビ」は、企画側のマネージャーと開発側のマネージャーを兼任していた彼の手によって、企画側に開発側が寄り添う形でサービスが開発されていきました。
さて、今回のテーマは、ペラナビの開発秘話です。開発に携わった3人のエンジニアとデザイナーの皆さんにお集まりいただきました。
向かって左から、開発マネージャーの佐藤さん、デザイナーの小川さんと萩本さんです。
編集部
お集まりいただきありがとうございます。
早速、それぞれ「ペラナビ」の開発のどの部分をご担当されたのか、詳しくお話いただいてもよろしでしょうか。
佐藤
僕は企画側のセミナーサポーターチームの方の部長でもあるので、企画検討から要件定義までして、そこから先は開発エンジニアとしてペラナビのバックエンドを構築するのと、それから基盤となるサーバー作ったり、とインフラの方もやっています。
リリース対応やヘルプ作ったりも。…要するにデザイン以外ひとしきりやってますね（笑）
編集部
プロジェクトマネジメントからコーディング、サーバーサイドからインフラまで。
つまり「作る」という観点においては、進行も然り、フロントエンドに関わること以外の部分は全部やっていることになるんですね。
小川さんはいかがでしょうか。
小川
僕は今回デザイナーとして関わったのですか、基本的にデザイン部分は萩本さんに任せていたので実際に手を動かした部分は管理画面、表には見えない裏の部分をやりました。あとは、萩本さんのデザインのレビューなどです。
編集部
では、萩本さんは表の部分のデザインをなさったということになりますね。
萩本
小川さんのおっしゃった通り、僕はデザイナーとして主にユーザーさんが使う表の部分、管理画面以外の部分をデザインしました。
UIから実装まで、一連を担当してます。
ここで少し先週の内容を少し、振り返ったお話を挟んでみます。
佐藤さんの、ペラナビへの関与は、
開発のマネージャーとして、セミナーサポーターチームの相談に乗っているうちに、セミナーサポーターチームのマネージャーになることが決まり、
実現したいサービスの内容をヒアリングしてシステム要件に落とした時、これは自社で開発したほうが良い。という結論になり、設計して実際に開発へ着手して行かれたというもの。
技術側がビジネス側に寄って行って課題を解決するという形でリリースまでの運びを取り、キーワードとしては「リアルボトムアップな事例」という言葉が出ました。
さて、今回の「ペラナビ」の開発プロジェクトはもともと昨年12月にリリースを予定してでした。それが、年を跨いで3月にリリースを迎えました。そこにはどんなドラマがあるのでしょうか。
編集部
実装・サーバーサイドとして、今回の案件に関しての特殊な試みや工夫についてお聞きしてもよろしいでしょうか。
佐藤
技術要素で言うと、今回は使用したフレームワークを普段のものと変えました。「ペライチ」はPHP・Cakeで出来ているのですか、今回使用したのはRuby On Rails (以下、Rails)です。
僕自身は個人的によく利用するフレームワークですが、現場で使うのは今回が初めてでした。
エンジニアとしては、現場で新しい技術に取り組めたので良かったなという思いです。
あとは、やはりフロントエンド以外は頭からつま先まで全てに関与していますので、
自分の強みである「浅く広く」を発揮ができた案件だったと思います。
編集部
バックエンド含めてフルスクラッチで1つの案件をやる中で、新しい技術を採用するということは挑戦的なことだと思うのですが、既存のやり方でない、コーディングルールや実装方法を採用する中で困ったことや、逆によかったことなどありますか？
佐藤
Railsは現場で使うのは初めてのことだったのですが、個人では昔から使っていたフレームワークだったので技術的なハードルは感じませんでした。
それに、社内のメンバーにはRailsの使用に慣れているエンジニアも多かったので「こういう時、設計ってどうしたらいいんだっけ？」といった相談もできました。
そういう訳で、別段困ったことはありませんでした。
編集部
流石ですね。新しいプロジェクトで新しい技術の導入をするにも、周りと建設的に相談しながら、進められている環境は素晴らしいと感じました。
続いて、デザインに関してですが、
お話していただいた通り、小川さんと萩本さんとではデザインの向いている視点が違いますよね。
ご担当はそれぞれ、小川さんのサポーターさんがお使いになる管理画面、萩本さんはユーザーさんが目にする部分のデザインです。
ここでの新しい試みや工夫に関して、小川さんへお聞きします。
管理画面は今までのUI設計と少し違いますよね。そうした理由はどこにあるんでしょうか。
小川
管理画面って基本的に表面よりも優先度低くなるんですね。つまりは、あまり見られない部分です。
使い手としても、「サポーターさん」という僕らに近い人が使うので、ある程度細かいことは許容できるはず、と考えて、それよりもスピードを優先して速くお届けすることを意識しました。
編集部
スピードを優先させるというのがペライチらしいですよね。MVP*（Minimum Valuable Product) 戦略のような考え方です。
(*)実用に必要な最低限の機能のみを実装し、スピード優先でリリースさせる考え方
小川
まさにそうですね。ベータ版でサポーターさんに操作してもらって、そこで何かあったら直せばいい。
必要最小限をまずは作って、フィードバックをいただいたら加味して修正しよう、という想定で作りました。
管理画面に関してはデザインにかかった期間は1ヶ月半くらいです。
編集部
サポーターさんが社内のメンバーに近いからこそ事前にベータ版を触っていただく、というのができることですよね。
フィードバックとしてはどのようなものがありましたか？
小川
ボタンのサイズに関してのご意見や、最初に例文が書いてあったら使いやすいんじゃないか、などのお声をいただきました。
編集部
細部よりも早く届けることを意識したとおっしゃっていましたが、他に早いスピードを実現させた要員としてはどんなことがあったのですか？
小川
管理画面に関してはペライチで使われているCSSをまるっと持ってきたので、今回に関してはゼロからコードを書いていないんです。
編集部
過去の知見が溜まっているがゆえに実現できたスピードですね。
続いて、萩本さんへエンドユーザー向けのUIに関して同じ質問をいたします。
萩本
僕にとっては、「ペラナビ」のUI設計はペラマネに次いで、大規模なUI設計になりました。
エンドユーザーが使うこととなるBtoCの設計に関しては今回が初めてでした。
基本的に、ペライチのサービスのデザインをする場合は、ペライチの中のUIを参考にして、真似に近い感じで、トンマナを合わせる感じで作っていたのですが
今回に関しては、派生サービスであるいうことも踏まえて他社サイトのリサーチをしたり、ターゲットを考えて、どういうUIがわかりやすいかな、と自分で考えながら作っていきました。
例えば、若い方ばかりではないターゲットの年齢層を考えて、トレンドを抑えつつもちょっと昔のシンプルなタイプのデザインを取り込んでみたりしました。
編集部
あえて「昔の」デザインを取り入れてみたとおっしゃいましたが、画面で言えば具体的にどの部分になりますか？「このあたりが特に、」という部分があれば、教えていただきたいです。
萩本
基本的にペラナビをお使いになる方って、ペライチのユーザーさん、その中でも特にWebに関して何かお悩みを持っている方だと思うので
意識したのは、ヘッダー部分をちょっと昔のサイトっぽく感じにやってみたり、とか。シンプルにツーカラーにしてみたり。
ボタンやバナーの文字に関しても、ホバーしたら色が変わるように、とか。
「セミナーを探す」を押せば検索フォームが出て…というように、
直感的に用途がわかりやすくなるように、いわゆる「よくあるパターン」をなるべく意識して作ってみました。
萩本
僕がこのデザインにかけることができた期間は2ヶ月だったのですが、
本当はもっと時間をかけたかったな、というのが本音です。
ただ、せっかくの派生サービスですし、ここで普段のペライチと違った印象も見せられたら、新しいユーザーさんにも興味を持ってお使いいただけるのではないかと思いました。
佐藤
萩本さんは、すごくこだわってデザインしていましたよね。
彼は満足していないような口ぶりですか、かなりこだわって作っていた印象でしたし、フッターひとつ取っても3回も4回も修正していました。
毎回新しく上がって来たものを見たら、彼が、何をどんな風に考え直して修正を重ねてきたのかが手に取るようにわかりました。
編集部
まだ、世の中にないものをゼロから自分たちの手で作るという精神が、ITスタートアップ企業らしいですよね。
最後に、今回の「ペラナビ」を通した「チャレンジ」をテーマに皆さんに自由にお話いただいて、今回のグループインタビューを締めくくらせていただければと思います。
萩本さんからお聞きします。いかがですか？
萩本
チャレンジ、ですか。
今思えば、デザイン面は反省は腑に落ちない部分はたくさんありましたが、仕事の進め方として、チームとして一体感持った仕事をしなければならない、というのが課題として残りました。
今回の仕事にはセミナーサポーターチームやマーケチームの方の意見をきちんと取り込めていなかったので。
デザイナーの視点だけにこだわって作ってしまった部分があると、仕上がりが自己満足に始終してしまうことになります。
関わる人、使う人、のステークホルダーをきちんと意識してデザインへ反映させられるような仕事のやり方を心がけたいと感じました。次回からチャレンジしていきたいポイントです。
佐藤
それに彼が自分自身で気付けたので、僕は満点だと思います。
他のプロジェクトの兼ね合いでリリースが伸びた分、時間ができたのでしっかり作り込むことができたはずです。デザイナーとしていい機会となったのではないでしょうか。
小川
僕も、萩本さんは今回でデザイナーとしてかなりレベルが上っていると感じました。
編集部
満足できるまでの時間をかけて取り組める、いい環境ですよね。
「チャレンジ」について小川さんはいかがですか？
小川
僕の場合は技術面の話になります。
Railsというフレームワークをペライチでは初めて使ったという話は佐藤さんの方から最初の方にあったと思います。
当初は、Railsを使うのは僕も初めてだったのでどれくらい時間がかかるか読めませんでした。
なので、UIとHTMLだけをこちらで用意して、実装は佐藤さんにお願いする予定だったんです。余裕があればやります。とは言っていました。ただ、デザインを仕上げてみると、実装も含めて自分もやってみたいな、という思いが出てきました。
やってみるとCakePHPと近しいところや、勘で触れる部分があり、結構いじれました。
自分にとっての新しい技術の触れることは楽しいですね。
編集部
佐藤さんも小川さんも、現場をマネジメントする立場でありながら技術者として新しい技術へ能動的に触れてみたり、現場で実践したりする姿勢を持ち続けていらっしゃるのが素敵ですし、
新しいものに挑戦できる環境であるということが素晴らしいですよね。最後に、佐藤さんはいかがでしょうか。
佐藤
今回のプロジェクトには今までのキャリアが全部詰まっています。
最初はインフラエンジニアをやって、次にサーバーサイドをやって、マネージャーへ、という今までのキャリアの要素が全て詰まっていました。
一方で、一貫してプロジェクトを1人で回すという中で、
課題は3点残りました。
1.要件定義の段階で、デザイナーさんにデザインを始めてもらえるようにすれば、もっと効率が良かったことを、他の並行して行なっていたプロジェクトから気付いたこと
2.コーディングに関して1人でつくってしまっていた分、サーバーサイドのコードのレビューが甘かったこと
これは、時間があるときにリファクタをするつもりです。
3.クオリティコントロールの加減について
ですね。
クオリティコントロールの件に関しては、会社のスタイルやカルチャーにも通じる組織的な課題にもなってきます。
今回に関しては、開発に余裕があった分、萩本さんが時間をかけてこだわりを持って仕上げていったデザインが、サポーターさんからも社内からも好評で、結果的に良かったのですが、
今後タイトなプロジェクトとなった時、メンバーの持ち味やを殺すことなく、開発としてどの段階で「一旦打ち出します」という線引きをするかというのは今後考えて行かなくてはならない問題です。
全体的に、また次に生かせればな、と前向きに考えています。
■終わりに
今回も、最後までお読みいただきありがとうございました。
この取材の後、萩本さんは筆者にこっそりと、「インタビュー記事の個人の名前のとこ、色分けしてみたらいいんじゃない？」と話しかけてくださいました。
よいものを追求する目が自分にも向けられ、気が引き締まる思いがしました。いつか、反映させるかもしれません。
マネージャー職にありながらも現場で次々と新しい技術の登用や、現場での初挑戦を行う佐藤さんと小川さんの姿勢も素敵ですよね。
プロダクトをリリースする際、追求すべきは、機能を必要最低限満たした早さか、こだわりを隅々まで反映させた品質か、という議論は尽きませんが
ペライチの開発チームが、挑戦的で、常に高みを目指す技術集団であることに変わりはありません。
次は、どんなサービスがこのチームから誕生するのでしょうか。
今後も、「開発秘話」シリーズをお楽しみに。
ペラナビはこちら