【MICINのひと】創業期から在籍する静かにアツいエンジニア、その①

組織の変遷や社会の流れのなかでも変わらないMICINのカルチャーや、医療分野でエンジニアとして働くことの魅力について語ってもらいました。 自分が加わった頃のMICINは、スタートアップの創業期特有の「狭い部屋にすごい人たちが集まって何かをやろうとしている」といった感じでした。最初は当時出来たばかりだった「curon(クロン)」のインフラ周りの整備をしていて、社員でいうと5人目くらい。 学生時代から「小さい会社で未来を変えるプロダクトをつくる」みたいなことに憧れがあったので、実はあまり深くは考えずに「面白そう」と思って入社しました。 それに、新卒で入った会社ではソーシャルゲームを作っていたので、医療×ITの世界がどんなものなのかもきちんと理解しきれていなくて。 ゲームの場合は、面白いものを作り多くの人に使ってもらえればヒットする世界。もちろん「面白いものを作る」ってかなり難しいことなのですが、目的や方法自体はすごくシンプルでした。 一方で医療は、社会構造や既存の業務フロー、様々なステークホルダーの方々の存在など、すごく複雑な構造のなかでプロダクトを作り、不具合なく使ってもらう必要があります。 こういった難しさは、作るプロダクトの難しさにも当然反映されるし、つまりは実際に我々が書くコードも複雑化するということ。 言い換えれば、これらをエンジニアとしてやりがいに感じた自分は、MICINに合っているのかもしれませんね。 キラキラなイメージを良い意味で裏切るMICINの人たち 創業当初は、それぞれが自分にできることをなんとかやっている感じで、エンジニアの僕が電話をとったりしていました（笑）。 今は組織として成長してきて、制度も整備されたし、プロダクトの開発もだいぶスピーディーに取り組めている実感があります。 でも一方で、昔からのメンバーもたくさん残っているし、MICINらしいカルチャーの本質はそんなに変わっていないと思います。 いい意味で「おっ」と思ったのは、薬局向けのサービスの開発が立ち上がったとき。 急にSlackで部屋ができて、「こんなサービス作ろう」という話があって、どんどん人が集まってきて、「（たぶん本当は承認のプロセスとかもあると思うんですけど、そういうのも一旦どっかいっちゃって）とりあえず有志でつくってみました！」みたいな。 自主的に集まって、みんなが楽しんでやっていたものが、新たなプロダクトとして正式にリリースするところまで育っていったんです。 僕自身がスタートアップで働くことに楽しさを見出していているのは、MICINのこういうところ。MVPをいただいた時のスピーチでも、そんな話をさせてもらった気がします。 「社会が変わっていく時にスピーディーに開発して提供していくのってすごくワクワクするし、そういう文化がこの会社にはある。そこに携われたのが大きな喜びだった」っていうのと、「苦労ある中でもチームで一丸となって進んでいけることが嬉しかったし楽しかった」みたいに。 MICINって、いろんな業界から有能な人が集まっている組織だと外からは見られていると思うし、実際そうなんですけど、「キラキラなイメージを良い意味で裏切る真面目さ」があるというか。 みんな割と泥臭くてスピードも早い、というスタートアップ的な性格と、医療機関やユーザーの方々への誠実さが同居している感じがあります。 一緒に働いていてすごく気持ちいいですし、「この人嫌だな」みたいな人はいないんですよね。 （つづきは、その②をご覧ください）

【MICINのひと】創業期から在籍する静かにアツいエンジニア、その②

（その①をご覧ください） 目的の見える開発でユーザー目線のプロダクトを作っていきたい 改めて技術面の話をすると、医療分野はセキュリティの要件が厳しかったり、安定性を求められたりと、一般のwebサービスでは考えなくてもいいことを考えて作っていく必要があります。 さらに、MICINのプロダクトは横断的に活用できるようにしていきたいので、プロダクト間の連携をどう設計していくのかも大事だし、チャレンジングな部分です。 例えば、「curon」と「curonお薬サポート」の2つは相互に連携しながら使ってもらえるようになっているのですが、そうなると相互に通信して、データ連携をしながらスケールしていかなきゃいけない。 でも、この流れは今後おそらく活発になっていくはずです。 理想は、MICINがカバーできる領域が増え、医療に関わる人たちや患者さんが一気通貫で使えるように各プロダクトがゆるやかにつながって、相互的な体験を作り出していくこと。 ちょっと抽象的ですが、そういった拡張性を見据えて開発しつつ、実際に動かしてみると課題にぶつかることもたくさんあります。 だから、まずは小さく作って、ダメだったらすぐに変えていくことを積み重ねるのが今は大事なんじゃないかな。 そういう意味でも、MICINのエンジニアはプロダクトとインフラの距離が近く、インフラ業務でも「何のためにこれをやっているのか」がクリアな状態で取り組めるところも面白さだと思います。 自分のタスクだけに集中しすぎると全体の流れや目的が見えなくなりやすいし、重大な見落としが障害につながってしまうこともありますよね。 他の人がどういうタスクを持っていて、どういうコードを書いているのか、どういう機能が開発されていてどういう仕様なのか、などの繋がりを意識しながら広い視点でプロダクトを作ることは自分も普段から意識しています。 自分たちが作っているプロダクトの先にユーザーの方々がいて、いろんな選択肢がある中で使ってくれているから、不具合を出してしまったり、質の悪いものを使わせてしまったりはできるだけしたくない。だから、細かいコードレビューの精度も含めて、エンジニアとしてできることはちゃんと貢献したいと思って。 今後さらに仲間を増やしていくなかでは、「タスクにアサインされたので開発します」ではなくて「こういうプロダクトを作ると喜ばれるんじゃないか、ここがこうだったら分かりやすいんじゃないか」とか、ユーザーの方々の目線に立ってプロダクトを考えていける人とやっていきたいですね。