ネクストイノベーション開発ブログ

ネット診察「スマ診」を手がけるネクストイノベーション株式会社の開発ブログです。

ネット診察サービス「スマ診」を提供するネクストイノベーション株式会社の開発者ブログです。

デザイナーにもいい感じの開発ブログが書けるだろう!と一方的に勘違いされてるみたいなんだが

どうも、こんにちは。
ネクスイノベーション株式会社のデザイナー織田です。
この度、この開発者ブログの記事を書かせていただくことになりました。
よろしくお願いします。

f:id:nextinnovation-tec:20190313154959j:plain

はじめに


さて、この「開発者ブログ」という言葉。
なんと神聖で、そしてインテリジェンス漂う響きでしょうか。
果たして私のような人間に、そんな高尚なブログ記事が書けるんでしょうか?

否、書けません。

書けるはずもありません。

まったく弊社のメンバーは、何を考えているのでしょう。
しかし、これも業務。やらねばならない。
そしてやるからには自分にできる最大限のパフォーマンスを発揮しなければならない。

というわけで、私が今までネクスイノベーションで携わってきた中でも、最も自分のデザイン感に影響を与えた取り組みのお話をしようかなと思います。

これまでの業務と感想


ベンチャーはスピード勝負

まず、第一に学んだのは、何よりもスピードが大事だということ。
もちろん一定のクォリティも大切です。
しかし、それ以上に、加速する会社の成長速度についていけるように、自分の作業効率を上げることが重要だなと実感しました。
コツとしては以下の2つに注意しました。

  1. 知らないこと・分からないことは、どんなにバカと思われようとも、その瞬間にすぐに聞いてしまう
  2. 初校時の指示にはなくても、再校時に上乗せされるであろう指示をあらかじめ予測してすでに反映させてしまう

1. 知らないこと・分からないことは、どんなにバカと思われようとも、その瞬間にすぐに聞いてしまう

これに関しては、正直何の抵抗もないタイプなので、どんどん質問しました。
おそらく弊社のメンバーに、私は何度「この人なんでこんなことも知らないの?」と心配されたことでしょう。
しかし逆にこうも思われたと思います。

「この人、本当に何でも聞いてくるな」と。

そう思われていたら、もう私の中では勝ちです。
私にそう思わされた、そういうことですね。
私の掌の上で、転がされたというわけです。もう、くるっくるですよ。

冗談はさておき、まぁ昔ことわざでも「聞くは一時の恥、聞かぬは一生の恥」と言うように、ギリギリまで分からないことを先延ばしにしておくと、どこかで速度がガクンと落ちます。
そしてそれが後になればなるほど、次から次にやってくる業務と重なって、気づいたら首が回らない!という現象に陥ります。

2. 初校時の指示にはなくても、再校時に上乗せされるであろう指示をあらかじめ予測してすでに反映させてしまう

これは業務をこなせばこなすだけ出来るようになっていきました。
おそらく、人間としての防衛本能が働いたのでしょう。
それと、私はガーッと作業をやれるだけやってしまったら、あとはゆっくりしたいタイプの人間だからですね。

どこかで必ずぶつかると思っていたクォリティの壁


しかし、スピード感が備わってきた頃、振り返ると愕然としました。
自分のデザインしてきたものがあまりにも無秩序なのです。

「本当にこのままでもいいのか?」
「私のデザインだけで進めていくのは危険じゃないのか?」
「読めればいい、分かればいいだけ考えてきたけど、それだけじゃダメじゃないのか?」

そんな不安がドッと津波のように押し寄せてきました。

時を同じくして、サービスが急成長

そんな不安を他所に、ネクスイノベーションのサービスである「スマルナ」が急成長を続けます。
その成長ぶりを見ていると、やはり思うわけですよ。

「やばい!このままのクォリティでスマルナが成長を続けたら、私のせいでスマルナまで低品質のサービスだと思われてしまう!」

そんな時でした。
相談の結果、とある方に「スマルナ」のロゴを新しく作っていただこう!と決まったのです。

デザイナー大崎淳治さんとの出逢い


グラフィックデザイナー&アートディレクター

f:id:nextinnovation-tec:20190313155137j:plain

大崎 淳治

デザインはコミュニケーション

デザイナー歴1年ぐらいの私には、大きなお仕事をいくつも手がけられたデザイナーさんとお会いできる機会などまったくなかったので、ビクビク緊張しながら初めてお話ししたのを覚えています。
大崎さんは、私たちに「デザインはコミュニケーションだ」と教えてくださいました。
(詳細を話すと割愛できそうなところが見つからないので、詳細は省きます。大崎さんごめんなさい!)

新しいロゴのデザインを依頼しようと思っていた私たちに、大崎さんは

「本当に必要なのは、ロゴを変えることですか?」

と分かりやすく諭してくださいました。
そして私たちは、大崎さんと「スマルナ」をもっと良くするために、ブランドコンセプトから考えようと取り組みを始めることに決めたのです。

ブランドコンセプト


ブランドコンセプトなんて考えたこともなかったので、大崎さんを含めての話し合いは勿論、社内での打ち合わせも何度も何度も重ねました。
正直ここ数ヶ月、頭の中から「スマルナ」が離れることがない日々が続きました。
ご飯を食べてる時も、寝ようと布団に入った時も、頭の中は「スマルナ」。
待ちに待ったキングダムハーツ3をプレイしている時も、号泣しながら頭の片隅には「スマルナ」。
まるで恋でもしているかのように、「スマルナ」と向き合い続けました。
辛かったか?と聞かれたら、そこまでというのが正直な感想です。

だってそもそもこんな機会、与えてもらえたことがハッピー

デザインは楽しくあるべき!
と私は考えています。

それは新しいものを作る時。
大きなものに取り組む時。
一度しか出来ないことに関わる時。

そういうチャンスに立ち会えるなんて、なかなかないことです。
ましてやスピード勝負のベンチャー企業で、こんなに時間をかけてじっくり取り組めるなんて、駆け出しのデザイナー歴1年のペーペーができます?
やっていいもんじゃないでしょう。
でもやらせてもらえたんですね。

私しか社内デザイナーがいないから!

まとめ


別にベンチャーというものを持ち上げたいわけでも、会社を持ち上げたいわけでもないです。 でも、間違いなくネクスイノベーションじゃないとできないことに、今取り組めていることを実感しています。
そしてまだまだ私も成長できる!と日々確信を得ることができることの大切さというのも、デザインを続けられる原動力であり、デザインの魅力だと思います。
(勿論会社の魅力もあるよ!)

しかしやはりデザイナーが一人しかいないことはとっても寂しいので、誰かがネクスイノベーションのドアを叩いてくれることを、待っています。
かなり切実に。

f:id:nextinnovation-tec:20190313154954j:plain

ということで、ネクスイノベーションでは一緒に働いてくれる仲間を募集しています! www.wantedly.com

Sink or Swim 〜元営業が本気でエンジニアを目指すようになっていた〜

f:id:misaki396:20181214110232j:plain こんにちは^^ネクスイノベーション株式会社エンジニアの徳藤美咲です。 現在私は、システムの運用・保守を担当させていただいております。 私がネクスイノベーションにジョインさせていただいてから、早くも半年が経ちました。

今回は、私の自己紹介も踏まえながら、ネクスイノベーションにジョインして感じたことを綴っていきたいと思います。

わたしは

もともと、大学時代は文学部(専攻は哲学w)で 大学時代も、アルバイトでは接客業や訪問販売などを経験し 社会人スタートの時も、営業のお仕事をさせていただいておりました。 今24才の私が、エンジニアの世界にいるなんて当時は夢にも思ってませんでした。
私が、エンジニアの世界に足を踏み入れたのには、とある出来事があったのです。 それは、前職で、営業のお仕事をさせていただいていた時に起こりました(笑) エンジニアの方に、案件を紹介するというお仕事をさせていただいてたのですが その時に、紹介したエンジニアの方が急遽プロジェクトに参加できなくなるトラブルが起きてしまいました。

これは、まずい。早く代わりの人を探さなければいけない。 たまたま、未経験でも参画できる貴重な案件だったので 絶対に逃したくない思いもあり、なんとか枠を確保しようと
「代わりの人を見つけられなかった場合、未経験でも良ければ、私が代わりをやってもいいでしょうか?」
と気づいたらそんなことを言ってしまいました。(もっと冷静な答えはあったはずです。。)
その時のプロジェクトリーダーの方たちも、驚いていましたが
「最悪の場合、君がプロジェクトに参画してください。一年半の長丁場のプロジェクトですが、大丈夫ですか?」
と答えてくれ、私も
「はい」
と答えていました。。。。。
細かくは割愛しますが、結局代わりは見つからず 約束通り、私は未経験エンジニアとしてデビューすることができました。(主な担当はデータベース運用やSQLチューニングなど) 初めは、パソコンすらもそんなに好きだったわけでも無いし、 エンジニアになりたいと思ってもなかったし、 果たして、やっていけるんだろうかという思いしかなかったです。 だけど、自分で代わりをやりますと言ってしまって、一年半という約束をして 途中で辞めてしまったら、営業として、嘘をついたことになってしまう。。。それだけはいやだ!という思いで 一年半はどんなことがあってもやるしかないという決意で日々を過ごしていました。
すると、どうでしょうか。 新しいことを知れる喜びと、覚えたことを使える楽しさで毎日が過ぎて行きました。

エンジニアって意外と楽しい

そう思い出した頃にIT業界全体のことやエンジニアの世界を知るようになり、 せっかくやるなら、Webエンジニアになりたいと思い 一年半のプロジェクトが終わったら転職しようと決め、 ネクスイノベーションにジョインさせて頂きました。 もともと文系だったし、プログラミングを始めてから思いましたが、 将来、プログラミングで必要な論理的思考は今のうちに身につけておきたかったことだと感じています。 今思うと、自分はエンジニアの世界に入ってなかったらどんな悩みにぶつかっていたんだろうと 考えただけでも恐ろしいです(笑) 振り返ると、本当にラッキーなことが起こってくれたと思っています。

きっと初めは誰だってできない

ネクスイノベーションは、トライ&エラーを繰り返しながら前進していける環境です。 (トライのレベルにはもちろん個人差はあります。)
それこそ、私は、99回バットを振って空振りしても間違いに気づけなかったりしてるのかもしれないけど 不屈の精神が道を開くんだ。一歩ずつ行くんだとまずは自分に言い聞かせながら(笑) コードを書いたり、運用のお仕事をさせていただいております。 ネクスイノベーションには、 間違いに気づくまで、自分で解決できるようにさせてもらえる周りの人たちがいます。 どんなことを聞いても「おー!その方法があったのか!」と 頭の中を交換してみたいぐらい尊敬できるエンジニアの方達がたくさんいて、毎日刺激をもらっています。 (基本リモートワークで毎日会うことはないので、毎日は大袈裟でしたね(笑))
できない自分に落ち込んでいると一瞬にして消えてしまいそうで、 どうやったらできるんだろうって手を動かすかのどっちかで。 まさにネクスイノベーションは Sink or Swim の状態で。(あくまで私個人の感想です。)
この環境が自分にとっては嬉しくて、出てくる悩みすらも自分が望んで出して乗り越えたかったものだと感じています。 本当に、毎日色んな人に助けてもらってばかりだなぁと思います。みなさま、本当にありがとうございます。

以上、ネクスイノベーションにジョインして半年経った今の自分を綴ってみました。

最後までお読み頂きありがとうございました!

ネクスイノベーションでは一緒に働いてくれる仲間を募集しています!

エンジニアが受託会社からスタートアップの会社にきたら異世界だった

はじめまして

ネクスイノベーション株式会社でスマホアプリを担当している松下です。
ここではスマホを通して医者に診察してもらうことができる、オンライン診療サービス「スマ診」と「スマルナ」を開発しています。

f:id:nextinnovation-tec:20181207094136j:plain

私は以前まで、受託会社でスマホアプリを開発していましたが、今年からネクスイノベーションのプロジェクトに参画することになりました。
ネクスイノベーションは一昨年にできたばかりのスタートアップであり、同じエンジニアリングでも受託会社からのマインドを一新する必要がありました。 実際にプロジェクトをやってみて感じたことを話したいと思います。

サービス全体を俯瞰して見る

受託開発になるとソースコードに対して、ある程度品質を担保する必要があります。 理由は他にもありますが、一つ例を挙げると、開発する会社と運用する会社が異なるケースが存在するからです。

家に例えると、ハウスメーカーである建設会社とリフォームなどを行う地域の工務店みたいなものです。家を建てるのは建設会社ですが、リフォームを行うのは工務店です。 リフォームを行なっている際に、欠陥住宅であるということがバレると建築会社の信頼に関わるので、顧客は二度とその会社には依頼しないでしょう。
つまり、ソースコードが汚いと可読性が悪くなり運用がしにくくなり、仕事をもらえなくなるリスクがあります。

f:id:nextinnovation-tec:20181207094322j:plain

極端な話、スタートアップで自社の新規サービスを構築する場合はそんなことどうだっていいのです。
ソースコードが汚くても、サービスが正常に使えるのであれば、ユーザーにとっては関係のない話だということです。 ソースコード内の変数をわかりやすい名前にするのってエンジニアの自己満であり、サービス全体を俯瞰としてみると小さな問題です。

もちろんマインドの話をしているのであって、汚いソースコードを書いてもいいって話をしているわけではないです。
例えば、何気なく行なっている言語を採用する際に関しても「AndroidアプリではJavaよりもKotlinが流行っているし、完結にソースコードを書くことができるから採用しよう」 ではなく、「Kotlinを使うことでソースコードを完結に書くことができ、全体的な開発コストが下がり、ユーザーにサービスを安く提供できる」というところまで考えることが重要だと感じさせられました。

アウトプットの大切さ

アウトプットができる人が評価されるのは受託会社であってもスタートアップの会社であっても同じだと思います。 ただ、そのアウトプットの方法、敷居の高さ、定義が異なるのではないかと実感しています。

個人的には、受託会社はエンジニアリングとしての技術力をどれだけ蓄積しているかで会社全体の価値が決まると思っています。 技術力が高いものをアウトプットすれば同僚の技術力がアップするし、エンジニアの仕事の幅が広がれば、会社として受託できる仕事の幅も増えるという好循環を発生させることができます。 つまり、技術力向上のためにアウトプットした人は会社からも評価されますし、周りからも信頼を置かれます。

f:id:nextinnovation-tec:20181207094328j:plain

しかしながら、技術力をアウトプットする場合は普段の業務からは指標化しにくい部分があります。なので、一般的にブログ、勉強会など様々な方法が採られますが、どれも"イベント"感があります。 ブログを書くにしても記事を書かないといけないし、社内勉強会にしてもプレゼン資料が必要になります。
まぁそれは仕方がない部分ではありますが、"イベント"は毎日あるわけではありません。 自ら手を挙げて、日時を決めて、周りに告知する、という段取りが必要になるので少しハードルが上がってしまいます。

ですが、ネクスイノベーションに関しては技術力の向上というよりも、事業がよりよいものにすることを目的としています。
事業をよりよくするためのアイデアを発言する場所って、会議でも飲み会でもいいわけです。普段の何気ない会話から解決するかもしれません。 完璧な意見を出す必要はなく、ふと思ったことを発言してみると、問題解決の糸口になったりするケースが多いです。 そういった意味では意見も立派なアウトプットであると思っています。

受託会社していた時の癖が抜けずに、効率化のみを考えた意見を出してしまうと、チーム内の人から「それってユーザーにとって不親切だよね」と言われた時には「やってしもた!!」って思うときもあります(笑)

まとめ

私がプログラムを始めたのは2年前のことで、受託会社に入社したころは右も左もわからないような状況でした。 その頃は、エンジニアの世界でやっていけるのかという不安もありましたが、それよりもプログラムの楽しさに心を奪われていました。好奇心に勝る勉強法はないですね(笑)
出来る事が増えていくほど任される業務が日に日に多くなっていき、技術力を向上させることが優秀なエンジニアだと思い込んでいました。

でもそれは違っていました。
正確には、間違ってはないけどその先があったと言ったほうがいいかもしれません。

技術力に固執してしまうと俯瞰してサービス全体を見れなくなってしまうということがあります。
ですが、技術力がないとユーザーに対して価値を提供できないということも事実です。

私はまだまだ未熟な部分が多いですが、スキルとマインドがあってこそ優秀なエンジニアになれると思います。

それら両方を経験してきたからこそ、自分にしかできない価値を生み出せるエンジニアになれるよう精進していきたいと思います。

実際にネクスイノベーションでどういった働き方をするのか、どういった業務をしているのかという情報はこちらをご確認ください!!
ネクスイノベーションではあなたのような好奇心に溢れるエンジニアを募集しています!!

www.wantedly.com

エンジニア未経験の大学生がベンチャーで1年間働いて学んだこと

はじめまして!

ネクスイノベーション株式会社でインターンさせていただいている古賀です。

つい最近、ネクスイノベーションのエンジニアチームに参加してちょうど1年ほどたったということに気づきました。未経験エンジニアから駆け出しエンジニアくらいには称号が上がったのでないしょうか。

始めたころは当然右も左わからないような感じでしたが、今ではWebフロントエンドをほぼほぼ1人で実装しているというのは感慨深いです。成長を自分でも実感しています。

今回はそんな1年を振り返って、ネクスイノベーションインターンしてみてどうだったのか振り返ってみようと思います。

f:id:Sh0n0:20181128082322j:plain

インターンを始める前

大学では経営学部に通っており、文系です。授業でプログラミングを学ぶことはありませんが、当時は「ゼロイチ」という部分に強い思いがあり、自分の力で何かを生み出せるようになることを目指して勉強し始めました。

まずは HTML/CSS から始め、Ruby on Rails に入っていきました。RubyRails を勉強する過程でサラッとやったというレベルでした。 勉強し始めて一番苦労したことは、言われたままに書いて「動いた!」以上の何かをなかなか得られなかったことです。初心者向けの内容をしているのだから仕方ないのですが、勉強に段々と作業的な気持ちが混じっているように感じていました。

また、なんとか基本の学習を終えたとしても「オリジナルサービス開発」で立ち止まってしまっていました。

なぜ私がこの課題で止まってしまうのかというと、サービスの中身や、運営、集客、収益構造まで意識し企画が進まず、手を動かすまでに至らなかったり、サービスの中身が中途半端なままで作成し始めると開発にも気持ちが乗らないというのがいつものパターンで完成に至らないからです。

これらから環境を変えたいと思い、エンジニアとしてインターンをしようと考えました。インターン先を探すにあたり、経験値をガッポリ獲得するために以下の条件を基本として探し始めました。

  • 長期での採用をしている(得られた経験を基にさらなるチャレンジをするために)
  • 社内の過半数インターンという体制ではない(日本人が少ないとこに留学に行く人の心境とたぶん同じ)
  • 自社サービスを運営している(自分たちが作ってますって言えるのいいよね)

このような欲張った条件のもと、色々探し、紆余曲折を経てネクスイノベーションで働かせていただくことになりました。

1年間インターンしてみてどうだったの?

ここまででインターンを始めるまでのあれこれについてお話をしました。ここからは、実際に1年間インターンしてみてどうだったのかについて話をします。

目的を意識するようになった

「こういう機能ほしい」「〜ができるようにして」などざっくりした感じで開発の要求を受けることがほとんどでした。ここから自分なりに要件を考えるのですが、その際、意識するようになったことがあります。

それは、それを行うことによって何を達成したいのかという目的をきちんと確認することです。

インターン当初はタスクが小さかったので、いわれるがまま作業を進めていても問題がなかったのですが、タスクが大きくなるにつれ要件を考えるために目的をしっかり把握しておくことが必要に感じていきました。

目的部分がわかっているからこそ、より詰めなければならない仕様が作業開始前に把握できたりするなど、エンジニア目線だからこその発見があります。

世の中のベンチャーなどで働くエンジニアの方にとってはこれ普通のことなのでしょうが、インターンで気づけて良かったことの1つです。

UI・UXの重要性を理解した

インターン当初はHTML/CSSJavaScriptを使用して、UI・UXの改善を主に行っていました。 ですがその頃は、UI・UXというよりデザインは大事というざっくりとした認識しか保っておらず、さらに当時はデザイナーもいなかったため主観的な改善がほとんどで、効果としては不確かなものがほとんどであったように思います。

そのような状況もあってか、その後プロダクト改善のためにCTO主導のもとデザインスプリントが導入されました。 デザインスプリントについてざっくり説明すると、この手法はデザイナーの思考プロセスを元にしており、検証すべきビジネスの問題をデザインの観点から考え、答えを導くための生産サイクルといった感じです。

デザインスプリントを通して、UI・UXの改善はただ見た目を整えて終わりではないと気づきました。改善する必要のあるところには、ユーザーの離脱率が高いなど何かしら問題を抱えてています。そしてこの問題をUI・UXという視点で解決するのですが、そこには検証という段階が不可欠であることも新しく学びました。

UI・UXに関しては、検証されたものが事例となって出版されていたりするので、そういったものを読んで基本部分を学んでおくのも大事だと思っているので今後取り組んでいきたいです。

デザインスプリントの導入では以下の書籍を参考に取り組みました。

デザインスプリント ―プロダクトを成功に導く短期集中実践ガイド

デザインスプリント ―プロダクトを成功に導く短期集中実践ガイド

技術力が向上した

インターン前は、自分でロジックを組み立てる力がとても低かったと思います。基本の文法を身に着けても、それらを使って大きなプログラムを組み立てるイメージが湧いていませんでした。

インターンを始めてこの部分の改善に大きな役割を果たしたのはソースコードでした。

スマ診のリリースまでの開発はCTOと業者の方で進められており、私はその途中で参加したため、ソースコードを読む必要がありました。書籍やブログに書かれたコードを除くとで他人の書いたコードをしっかり読むのはこれが初めてだったのですが、これがとても勉強になったのを覚えています。

ここで、わからない事は調べながらではありましたが、自分の力で処理の流れを追える、理解できるということに1つの達成感を感じられました。

また私と業者の方はプルリクエストを出してレビューしていただくといった形以外ではコミュニケーションを取る機会がなかったため、業者の方が書いたコードから、なぜそのように書いていのるかなどの意図を考えてなるべく把握しようと努めていました。

そうこうしてるうちに、それまで意識していなかった設計や責務などの部分の重要性を理解し始めました。これがあったからこそ現在の開発で設計についても考えられるようになったいるのだと思います。

スマ診のリリースまでのお話はCTOがこちらでしています。

nextinnovation-tec.hatenablog.com

自分で考える力が伸びた

インターンで求めるものは、わからないことを質問できる環境というのが多いと思います。実際インターンをして、すぐに質問できるという環境は非常に助かっています。

しかしながら、インターン当初はCTOを除けば、先輩という立ち位置の人はいませんでした。またCTOも忙しい身なので、謎のエラーにハマったり、どのように解決すればよいのかわからない問題というのを自分の力で解決していく必要がありました。

もちろん、全てを自分の力だけで解決できるわけではありません。自分なりに調べ、考えてみて、それでも何かしらの解決策が出なかったり、いくつか解決策はあるがどれがベストなのか判断できないときなどは、かき集めた情報やそれらをもとに考えた自分の考えを引っさげて質問に行きます。わからないままにするのは良くないです。

このような環境に新人をおくことに対して賛否両論あると思いますが、エンジニアにとって自分で試行錯誤する時間は成長の機会でもあると思うので、色々試行錯誤してから質問するという環境になっていたのは自分には良かったと思っています。

今では、経験豊富なメンバーも増え、質問や相談がよりしやすい環境になっています。

ですが、現在ではWebフロントエンドをほぼ1人で開発するようになり、自分でより良い答えを出すしかないような場面もあります。このような状況下でも割と普通にやれてるのは、当初から自分なりに問題を解決するための試行錯誤をしてきたからだと思っています。

まとめ

今回はインターンとしての1年間を振り返ってみました。

この1年で技術力の向上はもちろんのこと、それ以外の部分でも得られたものは多く、インターンにチャレンジしたことは本当に良かったなと思います。

今後はより事業にコミットできるエンジニアを目指して邁進していきたいです。

ここまで長々と私の振り返りにお付き合いいただきありがとうございました。次回以降は、現在進行中のプロジェクトでフロントエンドをメインに担当しているので、フロントエンドに関するお話をしていこうと思ってます。

ネクスイノベーションではエンジニア募集中です!!!

www.wantedly.com

初めてのモバイルアプリ開発に挑戦してから現在に至るまでと、これから

ネクスイノベーション株式会社(以下弊社)に所属している藤井(@syo_sa1982)です。 担当は主にAndroidアプリの開発とビールとかカレーについて薀蓄を垂れ流すことです。

今回の記事では元々Webエンジニアだった私が入社してから、未知の領域であるモバイルアプリ開発アサインされてから現在に至るまでの話とこれからの話をいくつかの時期に分けてご紹介させていただきます。

また、モバイルアプリ開発を行うことになった経緯などは前回までの記事に詳しく書かれているかと思うので、そちらをご覧ください。

執筆者とアプリ開発チームについて

アプリ開発チームは現在私を含めて2名体制で開発しており、相方のメンバーはモバイルアプリ開発の経験が長いのですが、一方の私は…

  • 前職まではPHPer
  • Webフロントエンドも少しやってた
  • アプリ開発についてはAndroid4.x時代に軽く勉強してたり、趣味でUnityやCocos2d-xを触った程度
  • 前職でモバイルアプリ開発に関わっていたが、CI/CDの整備がメイン

…と、このようにモバイルアプリの開発については、ほぼゼロの状態でスタートしていました。 ですが、相方のメンバーとチームを組んで知識を吸収しつつ開発に臨んでいたので、ここまでやってこれたのかなと思っています。

これまでのAndroidアプリ開発を振り返って

さて、ここからが本題です。 このようにWeb開発メインだった私が現在までAndroidアプリを経験してきてどうだったか、これから今後どの様に開発していくのかを下記の時系列で紹介していきます。

  1. 技術選定
  2. 開発初期〜画面量産期
  3. REST API実装
  4. 大規模仕様変更

尚、現在までの話については以前、モバイルメソッド大阪という勉強会にて登壇した時の資料もありますので、興味がある方は併せて御覧ください。 classmethod.connpass.com speakerdeck.com

技術選定

モバイルアプリ開発を始めるにあたって、弊社ではまず最初にクロスプラットフォーム技術で開発するかどうかの検討が行われており、主に3つの選択肢が挙げられていました。

  • ReactNative
  • Xamarin
  • ネイティブでAndroid/iOS別々に開発

これらの選択肢の採用可否をモバイルアプリ開発の経験が長い相方のメンバーと共に調査を行った結果、クロスプラットフォームとはいえどもAndroid/iOSの知識は必要など様々な理由でAndroid/iOS別々に開発することに決まりました。

開発初期〜画面量産期

開発当初、まず相方のメンバーがアーキテクチャ/ライブラリの選定を行いました。 当時採用されたアーキテクチャはMVPにDataBindingの仕組みを取り入れたものです。

github.com

developer.android.com

役割分担としては相方のメンバーは実装難易度の高い機能の開発・調査を担当し、 私自身は採用されたアーキテクチャをなぞるようにひたすら画面を量産し続けていました。

その中でも特に以下のようなところで苦労していました。

  • Layoutの実装
  • Rx・DataBindingの理解
  • Model層の実装の手間

github.com

Layoutの実装については、特にConstraintLayoutについて慣れるまでが大変だったなと記憶しています。 Rx・DataBindingについても今まで触れたことがなかったので、慣れが必要でした。 ただ、いずれも慣れてからは使い所を見誤らなければ、使いやすいなと感じています。

Model層の実装については後にも書くのですが、画面の表示に使うためのModelとAPIで使用していたレスポンスModelを使い回していた事もあり、ビルドが失敗しない単位でプルリクエストを出すまでに必要なクラスの数が多かった様に思います。

逆に良かった点としては、開発言語にKotlinを採用して私自身も初めてKotlinを書いたのですが、今まで触ってきた言語と比べて、非常に書きやすく良い言語だったなと思います。

REST API実装

一通り画面を作り終えた頃にサーバーサイドと通信するためにREST APIの実装を始めたのですが、今にして思えばこの頃が私にとって一番つらい時期だったと思っています。 というのも、この時期になって以下のように様々な実装上の問題が浮き彫りになってきたからです。

  • ModelイコールAPIレスポンスと想定していたがために、APIレスポンス変更に対応できずにエラーを吐き出してデータを取得できない
  • MockAPIをアプリ内に作っていたためにAPIの結合に伴う修正を行うとMockAPIも修正しないとビルドが通らない
  • 問題解決のためにリクエスト/レスポンスを扱う実装が必要になるが、設計をミスると修正範囲が膨大になりかねないリスクがある

このような問題に立ち向かうためにチームで協議して無理な共通化をやめてMockAPIの修正範囲を抑えるなどの実装ルールを策定してAPIレスポンスを扱うクラスを実装していきました。

そこから先はリリースへ向けてひたすらAPIとの結合を進めていくだけでした。 ここまでは上述した登壇資料にも書いているとおりです。

大規模な方針転換

リリースへ向けて開発を進めていたある日、ビジネス上の都合によりサービスの仕様が大幅に変わるという決定が下されました。 そのため、開発中のアプリケーションはほぼ全て作り直す事になりました。 代わりにリリース時期にも調整が入ったため、チーム内ではアーキテクチャを変更する決断を行いました。

この頃になると私自身Androidアプリ開発について様々な情報をキャッチアップしており、AAC(AndroidArchitectureComponent)とMVVMアーキテクチャに興味を持っていました。 そのため、チームの二人で設計方針について議論を重ねながらペアプロしました。

developer.android.com

特に前回のアーキテクチャで問題になっていたModelとAPIの密結合に対処するために、データ層・ドメイン層・プレゼンテーション層を用意し、最終的にCleanArchitectureとMVVMを合わせたアーキテクチャが完成しました。 このアーキテクチャについての詳しい説明は相方のメンバーが後の記事で説明してくれると思うので、ここでは割愛させていただきます。

github.com qiita.com

最後に

入社するまではモバイルアプリ開発について未知の領域ですが、半年近く経験してきてある程度私自身一人で実装できるところまで上達してきたかなと自負しています。 今回はAndroidアプリ開発における歴史的な話に終始しましたが、今後は技術的に掘り下げた話題や勿論iOSアプリについても投稿していこうかと思うので楽しみにしていただければ幸いです。

ネクスイノベーションではモバイルアプリやマイクロサービスに興味があるエンジニア募集中です! www.wantedly.com

入社して間もない新人がWebアプリケーションの再構築プロジェクトをリードするためにまずやったこと

はじめまして。

今年の6月にネクスイノベーション株式会社(以下弊社)に入社したWebエンジニアの大山と申します。

私が弊社に入社してすぐ、弊社が運用しているサービス「スマ診」のアプリケーションを再構築して大幅リニューアルするプロジェクトが始動し、私も参加することになりました。 現在このプロジェクトにはWebアプリに2名、iOS, Androidアプリに2名と計4名のエンジニアがアサインされています。私は現在Webサーバサイドの開発をメインに担当していますが、プロジェクト初期からWebフロントエンドやインフラの設計のみならず、サービス全体の設計にも積極的に関わってきました。

そこで今回は「入社してすぐ、システムをイチから作り直すプロジェクトに参加することになったWebエンジニア」が、まずはじめに何をやったのかについて簡単にお話させていただきます。
ちなみに、アプリケーションを「再構築」することになった経緯について説明するのは今回のテーマに合わないため割愛しますが、弊社CTOのこちらの投稿に目を通していただければ、ある程度お察しできるのではないかと思います。気になる方は是非お読みください。

nextinnovation-tec.hatenablog.com

アプリケーションを再構築するにあたってはじめにやったこと・やらなかったこと

「アプリケーション再構築プロジェクト」に参加することになった私は入社して間もない新人です。つまりサービスの仕様や運用プロセスについての理解度が他のメンバーと比較して全くない状態です。とはいえ、既存の仕様を把握しているデザイナーの方が新しいUIのワイヤーフレームを作成していたので、フロントエンドの開発にはすぐにでも着手することは可能でした。
しかし、Webサーバサイドの仕様については全く固まっておらず、詳細な仕様を取り決めるためにすぐ動ける人間が私しかいないという状態でした。なので私は早急に現在稼働中のサービスの「いま」を知るために動くことを選択しました。
このプロセスを進めるにあたってはじめに個人的にやったこと、やらなかったことがあったので紹介します。

やったこと

やったことは以下の2つです。それぞれの詳細はこの後に説明します。

  1. 社内にいる全メンバーとコミュニケーションを取る
  2. サービスの運用に関するフィードバックをもらう

1. 社内にいる全メンバーとコミュニケーションを取る

まずはじめにやったことは、社内の全メンバーとコミュニケーションを取るよう努めることです。 この段階で積極的にコミュニケーションを取る際に優先すべきことは、「自分のことを知ってもらう」よりも「相手のことを知る」でした。どのような人がこの会社とサービスに携わっているのか、どのような領域を担当しているのかなどを早めに把握しておく必要がありました。なぜなら、ある特定の問題を解決するために誰を巻き込むべきなのかが判断できるからです。
これにより、何かわからないことがあったとき、そもそも誰に聞けば正しい答えが返ってくるのかもわからないという状態に陥ることは阻止できるようになりました。

2. サービスの運用に関するフィードバックをもらう

次に現在稼働中のサービスの運用を担当しているメンバーに、運用に関するフィードバックをもらいました。サービスを利用しているユーザからのフィードバックも含みます。 特に、マイナスのフィードバックを中心にもらうようにしました。「この仕様のせいで運用が大変だ」「はじめは必要だと思って追加してもらった機能、今は全く使っていない」「複数のユーザから同じ箇所についての問い合わせがきている」…などなど。
アプリケーションを再構築するとはいえ、現在稼働しているサービス仕様の大半は継承します。その中には、そのまま継承したら結局使いにくいアプリケーションのままになってしまう仕様が混入しています。ですがそれを開発チームだけでは判別できなかったりします。
予め運用メンバーからフィードバックをもらっておいたことにより、「この機能は実装しなくていい!」「この部分の仕様は思いっきり変更してしまおう!」なんてことをサクッと決断できるようになりました。

やらなかったこと

次に意図的にやらなかったことが1つだけあります。エンジニアなのにまじ?と思われるかもしれませんが、「稼働中のアプリケーションのソースコードにしっかり目を通す」ことです。
もちろんソースコードを開発PCに入れ、軽く目を通したり、実行してみたりしようとはしました。ですが、アプリケーションの再構築のための参考としてちゃんと確認したのはデータベーステーブルの構造だけでした。(Railsが分かる人にしかわからない表現ですが db/schema.rb だけしっかりチェックしました。)
それほどデータベーステーブルの構造というものはアプリケーションの仕様に直結しているものです。その他のロジックがどう実装されているのかについて理解することは、この段階においては全く必要ありませんでした。

Webアプリケーションを再構築する際の技術的な選択

入社してすぐ「アプリケーション再構築プロジェクト」に参加することになった私はどうにか現在稼働中のサービスの「いま」を知り「これから」をイメージできるようになりました。
その結果、再構築するWebアプリケーションに対して以下のような技術的選択を行いました。

Webサーバサイド

既存のアプリケーションはモノリシックな構造で構築されています。しかし、今回のような破壊的な仕様変更がいつ訪れてもおかしくないです。引き続きモノリシックで構築すれば、またどこかで破綻する可能性が十分にあります。
そういったコストを避けながら爆速で成長し続けるために、今回からモノリシックではなくマイクロサービスという形でサービスを構築することにしました。
フレームワークは引き続きRuby on Railsを採用。マイクロサービスということもあり、Hanamiも検討していましたが、知見が無いため今回は採用を断念しました。 現在はRails5.2のAPIモードで構築された5つのマイクロサービスを立ち上げ、順次開発を進めています。

Webフロントエンド

今回からiOSAndroid向けネイティブアプリの本格的なリリースが決定しており、サーバサイドではネイティブアプリ用のJSON APIを実装する必要があります。このJSON APIをそのままWebアプリケーションのフロントエンドでも使用すれば実装コストを削減できるうえ、よりよいUI/UXをWebアプリケーションからでも提供できるため、React.jsベースのSPA(シングルページアプリケーション)を採用しました。
SSR(サーバサイドレンダリング)対応などにも考慮した結果、Next.jsを使用して開発中です。
Next.jsの導入奮闘記は別のエンジニアが担当してくれる予定です。(無茶振り)

nextjs.org

インフラ

AWSを利用します。現在稼働しているアプリケーションはEC2インスタンス上で稼働していますが、次に新しく構築されるWebアプリケーションの各サービスはすべてDockerコンテナ化され、ECS+Fargateで稼働させる計画です。
ECS+FargateやDevOpsについては知見が集まり次第、別途記事を作成して投稿できればいいなーと思っております。
aws.amazon.com

まとめ

入社してすぐ「アプリケーション再構築プロジェクト」に参加することになったWebエンジニアの私がまずはじめにやったことは、ディレクターっぽいことを自発的にやる、でした。
今回のテーマ的に、あたかも私だけがディレクションを行っていたかのような内容になってしまいましたが、実際には開発チーム含め社内メンバー全員がこのようなプロセスに積極的に取り組んでいます。
それぞれが担当する領域に縛られず、メンバー全員が積極的にコミュニケーションを取っており、一丸となってよりよいサービスを私達全員で発信していくのだという強い志を持って活動しております。 今回はこのことをエンジニア的な味付けをしつつ伝えようと頑張ってみましたが、なんかオチが雑になってしまいましたね。
次はもっと技術的な内容を投稿する予定です!お楽しみに!

ネクスイノベーションではエンジニア募集中です!!!

www.wantedly.com

設立当初に負債覚悟でプロダクトを作った話

こんにちは。ネクスイノベーションCTOの宮田です。 今回はネクスイノベーションの最初のプロダクトである「スマ診」の開発思い出ばなしをしたいと思います。

f:id:hardison:20181031184013j:plain

え、4ヶ月ですか!??

スマ診のサービスを構想しているときは、ネクスイノベーションにはエンジニアは僕一人でした。 スタートアップあるあるですが、投資家さんにいつまでにサービスを作ってローンチします!と事業計画をお約束をして資金を調達しますので、開発前に納期が決まっていました。その納期から逆算すると、仕様が固まった段階で、え、開発期間があと4ヶ月しかない!!(結局、規制対応で2ヶ月伸びたんで、実際は6ヶ月)という状況でした。

1人じゃ無理だ、と、外部の開発会社さんにお手伝いいただきながら出来上がったサービスです。

スマ診は、当時の要件を簡単にいうとテキストチャットでドクターと診察してもらい、お薬代や診察代を決済してもらうサービスです。目立つ機能はドクターとのリアルタイムチャット、決済機能、そして医療をあつかうので医療記録を保存する電子カルテや、セキュリティにも気を配る必要がありました。

何でつくる?

スマ診のサービスを期限までに作り上げるということは経営にかかわる大きな課題です。少しでも早くサービスを届けたい! しかし、言語や構成を決めるという段階で、悩むこととなりました。エンジニアとしては人気のある言語や構成でやりたいな〜、でもそれで良いんだろうか…

できるだけエンジニア母数が多くて、枯れたものを駆使して作る

新進気鋭のスタートアップらしくはないと思われるかもしれませんが、僕たちは技術を提供する会社ではなくて医療サービスを提供する会社です。エンジニアとしての面白い技術を取り入れたいと思う一方で、「医療サービスとしてのプロダクトを完成させる」ということに全力を投資しないといけません。そんな中、エンジニア母数が少ない技術で作ってしまったら、僕が病気になったらサービスが死んでしまうかもしれない、、、これは恐怖でした。

設立直後のスタートアップに転職しようと思う人は、ほとんどいません。だって、お金もねぇ、人もいねぇ、要件毎日ぐーるぐる、、です。おら、こんな村嫌だ〜となっても当然のことだと思います。お金のないスタートアップでもエンジニア採用できる可能性がある構成をとっていく必要があると考えていました。「どこかで困っている人の辛みを解決する」サービスを作る上では、少ないリソース(IT的目線でいうと人、時間、金)でも回すことができるプロダクトを目指すことにしました。決して奇をてらわず、泥臭くやっていく。

枯れた構成の採択

当初はWebサービスだけですが、サーバーサイドをRailsにして、フロントはjQueryで動かして、チャット部分はFirebase使っちゃえ、、というエンジニア母数が多い構成を選びました。Railsの採用理由は未だ人件費が低い若い世代が多かったからです。また仮想DOMの時代には入っていましたが、jQueryはデザイナーさんでも触れる人が結構いるという利点もありました。Firebaseは実装が楽だったからです。

f:id:hardison:20181031184301j:plain

紆余曲折を経て作り上げたプロダクト

スタートアップですもの要件すぐ変わります。。

どこもそうですが、作っている途中での要件変更は日常茶飯事でした。社外の環境の変化などで容易に要件はドカンと変わります。こんなことを言ってしまうと、要件がすぐ変わるような会社は嫌だなと思わせてしまうかもしれません。僕自身もネクスイノベーション以前は要件変更による手戻りで散々嫌な思いもしてきました。 でも常に変更を走らせないとビジネスは死にます。プログラミングでスクラップ&ビルドを回すように、ビジネスも試しては変えの連続です。自分の作り上げる価値を最大限に昇華させてユーザーに届けるためには、常に変更を受け入れて適応するという体制がとても大事です。ただ、期限もあります。変更の受け入れで、どんどん当初の設計どおりにはいかなくなり、無理やりな実装が増えることにもなりました。

で、作ったらどうなった?

サービスが出来たときには、すでに多くの問題を抱えていました。

  • 規制要件を安易に考えたために拡張性を殺してしまった
  • 動的描画処理でエゲツナク負荷かかる
  • 使ってないのに放置されているもの(テーブルとか)が乱立していて、整理整頓できていない (特にフロントのUIデザインを変えまくったおかげでフロントまわりがゴミのように)
  • jQueryのもっさり感

まぁ分かっていたことですし、リソースが整ってから直していけばいいだけのことです。技術負債を恐れては何も作れませんし、変更を予想しきることなんて出来ませんから構成にそこまで気に病む必要はありません(でかい変更なんてあるもんです)。 負債抱えて、内心はうわぁぁぁ〜やっべ〜な〜とは思ってますが、それでもいいから利用者のために、プロダクトを磨きあげていく気持ちと実行力が大事だと思っています。

f:id:hardison:20181031184939j:plain

今現在はサービス再構築中

第一弾のプロダクトが完成して、ユーザー需要を確認できたことで、1億円の資金調達をすることができました!!!!資金調達のおかげで、スマホアプリエンジニア2名、サーバーサイドエンジニア2名、サービスデスクエンジニア1名の採用ができ、現在ではチームを作ることができました。

そして今は、スマホアプリの構築に向けて(ついでに負債回収!!!)、スマ診サービスを再構築しています!! WebフロントはReact、サーバーサイドはRailsAPI、iOSはSwift4、AndroidはKotlin。 詳しい構成は後のブログに託しますが、ナウでヤングでトレンディーな構成でやってます!

「結局ナウでヤングな構成を取り入れたんだ〜?」というツッコミが聞こえてきそうですが、先行プロダクトの成果がでて新たに資金を調達できた結果、取り入れることが出来たんだと思っています。ただ結果論ですが、振り返ると最初からヤングな構成でも良かったと今では思ってます(オイッ!!)、だってモチベーションが上がらん(ゥオイッッ!!)。。 今ではエンジニアが自由にやりたい構成をとることを良しとして開発をしています。ビジネスの方向性が決まったので次元を超えた要件変更がなくなり、余裕と自由を手に入れることができたというのが大きいですが、なにより自分で決めた方が楽しい!(冒頭の話はなんやったんや!!)

まとめ

設立当初は資金に懸念がある状況で、ただ作ればいいというだけでもなく、どうやって開発を進めていくかを常に悩んでいましたが、今振り返ってみればプロダクトへの想いさえあれば、気にせず好きなようにやってもよかったと思います。常に考えることは必要ですが、設立当初はガンガン環境が変化するので、考えていたとおりになんてなりません。だったら、ちゃんとマネジメントしながら、常に考えていれば、好きにやってモチベーションを高い状態で維持し続けることの方が価値があります。

5年たったらどう考えているかは分かりませんが、今はそんなことを思っているよ。という思い出話でした。

あぺんでぃっくす

ネクスイノベーションではエンジニア募集中です!!!

www.wantedly.com