Figmaでアイデア発散会をやったら盛り上がった件

こんにちは、デザイナーのとりみずです。

最近Misocaでは全社的にデザインツールにFigmaを導入しました。

Misocaではリモートの社員も多く、モバイルアプリを開発しているチームは

  • 東京…デザイナー
  • 名古屋…サーバサイドエンジニア
  • 京都…デザイナー
  • 鳥取…Androidエンジニア
  • 福岡…iOSエンジニア

という日本各地の集まりになっています。

このメンバーで、とある価値仮説に対して「俺の考える最強のアイデアぶつけあい大会」をすることになりました。 そこでFigmaを活用したところ、リモートでのアイデア発散会にとても向いていたので、その様子を紹介したいと思います。

当日までの準備

課題とターゲットをすり合わせを行い、当日のアイデア発散会までの準備に下記を宿題としました。

  • アイデア発散会の日までに各自手書きでアイデアイメージをA1の紙に書く
  • 匿名性を考慮してアイデアに考えた人の名前はつけずにおく
  • FigmaのPageに貼っておく

※この時、どういう形式で書けばいいで迷ってアイデアだしが止まってしまわないよう、サンプルを私の方で用意しました。

f:id:torimizuno:20190222180139p:plain

そして当日…

オンラインミーティングサービスのZoomでFigmaの画面を共有し、俺の考える最強のアイデアぶつけあい会のはじまりです。

このようにZoomでFigmaを画面共有しながら、ひとつひとつのアイデアを順に見ていきます。 最初は匿名性でのジャッジを想定していたのですが、説明がないとわからないアイデアもありましたので、全員が順に自分の書いたアイデアを説明する流れで共有をしていきました。

f:id:torimizuno:20190225141710p:plain

その後、各アイデアのここがよかった!を可視化するため、自分がよいと思った部分や疑問点に、Figmaのコメント機能でコメントをしていきます。 誰かがコメントすると、派生してどんどん意見が生まれていたり、ポジティブなやりとりが発生していているのを見るのも楽しかったです。

Figmaはリアルタイムで同じ画面で誰がどこを見ているかもわかるので、コミュニケーションもより取りやすいと感じました。

f:id:torimizuno:20190225141737p:plain

よかった部分の可視化の後は、似ているアイデアをグルーピングし、特長を書き出します。 この日はあくまでアイデアをぶつけ合う発散会目的でしたので、ここまで終えたところで、最後に全員で次回のアクション決めをしました。

まとめ:figmaでのアイデア発散会は、盛り上がる🎊

ミーティング後、チームのチャンネルでメンバーの感想があがっていたのですが、とてもポジティブな反応があって嬉しかったです。 もちろんアウトプットが重要ですが、会自体が盛り上がり、全員が発言しやすい環境づくりも大切だと改めて感じました。

f:id:torimizuno:20190225110810p:plain

📢採用

Misocaでは、チーム開発を一緒に楽しんでくれるデザイナー、エンジニアを募集しています!

(東京の弥生本社オフィスの拠点紹介ページもできました)

recruit.misoca.jp

Webpackerを導入してから外すまでをふりかえる

こんにちは、@mugi_unoです。

MisocaでjQuery製のフロントエンドコードを書き換え続けていた結果、技術書典6に参加することになりました。現在必死で書いております。

farewell_webpacker

さて、先日とあるブランチがmasterにマージされ、リリースされました。

f:id:mugi1:20190213111057p:plain

farewell : ごきげんよう!、さらば!
farewellの意味・使い方・読み方 | Weblio英和辞書

farewell_webpacker です。

長い間フロントエンドのビルドにはRailsのGemであるWebpackerを使ってきましたが、現在は完全に依存を外しており、純粋なwebpackビルドを行う形に書き換えました。

正直なところ、フロントエンド界隈からは否定的な意見を聞くことも多いWebpackerですが、実際にある程度の期間プロダクションで利用してみて、良いところも辛いところも両方感じることができたので、今回はそのあたりをご紹介したいと思います。

Webpacker導入に至った経緯

Webpackerを導入した際にもこのブログに記事を書いています。

tech.misoca.jp

当時は次のような課題を抱えていました。

  • browserify-railsによるビルドが致命的に遅い
  • ほぼnpmによるパッケージ管理が行われていない
  • アセットパイプラインを使うものと使わないものが混在

とはいえ、それとは別にコードベースにも

  • jQueryべったり
  • Vueが0.12
  • テストコードが存在しない

といった問題を抱えていて、フロントエンドが絡む機能開発に支障が出ていました。 そのため「まずは手っ取り早く基盤周りをいい感じにしたい」という考えから、導入コストの低かったWebpackerを採用することにしました。

🤝 Webpackerのよかったところ

初期導入の敷居が低い

Railsとフロントエンドのビルド周りを組み合わせるのはそれなりに手間です。また、Misocaの場合はフロントエンド専任のエンジニアがいるわけではなく、基本的には誰でもバックエンド・フロントエンドを通してコードを書きます。逆に言うと、フロントエンドのみに全労力を注ぐことが難しいため、シンプルで理解しやすいものが望ましいと考えました。

フロントエンドに限った話ではありませんが、環境構築を行う際には「その後にちゃんとメンテナンスしていけるか?」も重要な観点です。流行っている・使いたい、といった理由だけで導入すると後で痛い目を見る可能性もあります。(流行っている技術を使わないほうがいいということではありません。私も誰も使ってないようなイケてるフレームワークとかガンガン突っ込みたい人です。)

Webpackerが理解しやすいかと言われると正直思うところはあるのですが、少なくともGem側で道を示してくれており「レールに乗って導入しています」というのは情報共有の面では大きいメリットがあります。

また、Webpackerが提供するインストールタスクを利用することで各種設定もすぐに完了するため、「とにかくwebpackを利用したビルド環境をサクっと整えて他の作業に注力したい」という場合には大いに役立ちます。

レールに乗っている限りはコードに集中できる

Webpackerの提供するレールに乗っている限りはフロントエンド側はコードを書くことだけに集中できます。 マイグレーションが発生した場合も、基本的にはCHANGELOGの内容などを参考にしていけばさほど難しくありません。 フロントエンドが好きだったり得意なメンバー以外からすると、フロントエンドのビルド・環境設定周りは苦痛が伴うこともあるため、そこをGem側でケアしてくれるのはとても助かります。

Railsアクセス時の自動ビルドがうれしい

Webpackerはビルド時にコードのハッシュ値を保存しており、アクセス時にコードに差分が発生していると自動的にビルドをしてくれます。 (デフォルトでは開発時のみのオプションです)

「あれ、なんか動かない〜」→「フロントエンド側ビルド忘れてました」 というケースは結構発生するので、それを回避できるのは地味に便利で快適です。

🤔 Webpackerのつらかったところ

レールから外れたカスタマイズがしづらい

レールに乗っている間は快適ですが、そこから外れようとすると厳しい面が出てきます。 たとえば、webpackではwebpack.config.jsというファイルに LoaderやPluginを利用して設定を追加していくのが一般的な方法かと思いますが、 Webpackerの場合は、独自でラップされたクラスを経由してカスタマイズする必要があります。 たとえば、次のようなイメージです。

const { environment } = require('@rails/webpacker')

environment.loaders.append('json', {
  test: /\.json$/,
  use: 'json-loader'
})

environment.loaders.prepend('json', jsonLoader)

module.exports = environment

webpack.config.jsのお作法を覚えなくても良いというメリットはありますが、 そのぶん独自のカスタマイズ方法を把握することになるため、 すでにwebpackに関してある程度の知見がある場合にはコストに感じるかもしれませんし、 最初からwebpack.config.jsの書き方覚えたほうが手っ取り早いのでは?と思ってしまう部分はあります。

また、Webpackerが提供していない範囲でwebpackのカスタマイズが必要になってくると、結局はwebpack.config.js相当のものを引き剥がして書き変える必要が出てきます。

実際には次のようなコードを通してしました。

const webpack = require('webpack');
const merge = require('webpack-merge');

module.exports = function(environment) {
  const defaultConfig = environment.toWebpackConfig();
  const webpackConfig = merge(defaultConfig, {
    /* webpackの設定を独自でカスタマイズ */
  });

  return Object.assign(environment, {
    webpackConfig,
    toWebpackConfig() {
      return this.webpackConfig;
    }
  });
};

このあたりのカスタマイズにはWebpackerが内部で保持しているコードを把握しておく必要があり、 「レールに乗っていればOK!」という状態からはかけ離れてしまいます。

依存関係が見えづらい

Webpackerを使うことで、たとえばbabelを利用したECMAScriptの変換やCSSのビルドといったことは簡単に実現できます。

しかし、そのために必要な依存は@rails/webpackerの内部で閉じられているため、実際のところ何を利用しているのかが若干見えづらいことがあります。

そのため、例えばwebpackプラグインを追加しようと思った際に「すでにWebpacker内部で依存に追加されていないか?」「Webpacker内部での依存バージョンは何か?」といった情報を把握する必要が出てくるため、確認すべきものが多くてつらい、といったことが多々あります。

内部のモジュールのバージョンに引っ張られる

Babelを例に挙げると、@rails/webpacker#v3.5.5 であれば、内部で利用しているBabelは6.x系ですが、本エントリ投稿時点ではBabelはv7.3.3が最新バージョンです。 6.x→7.xの時点で必要となるパッケージ構造などに大きな変更があり、関連して、Babelを利用する他パッケージではBabel6.xとBabel7.xによって設定や挙動に変化があるものが少なくありません。

たとえば、テストフレームワークのJestはBabel6.xのサポートを打ち切っています。 https://jestjs.io/docs/en/getting-started#babel-6

こういった影響を受けて「Webpacker側のパッケージが更新されるまでは、独自で入れたいパッケージが更新できない・あるいは追加できない」といったケースが発生することがありました。(強引にやっていくこともできそうでしたが、メンテナンスコストが増大しそうだったので避けました。)

🎓Webpackerを卒業することにした

さまざまなメリット・デメリットを考えた結果、Webpackerを卒業して純粋なwebpackビルドに置き換えることにしました。

Webpackerの他に追加しているパッケージが増えてきた

テスト環境の整備などを経て、導入初期と比較するとWebpacker以外で独自で導入しているフレームワークが増えてきました。先に挙げた依存関係やバージョンの問題から、「使いたいが使えない・使いづらい」というシチュエーションが発生してきました。

開発環境のDocker化が進んだ

Webpackerの自動ビルドがとても便利で、Rails以外にwebpackプロセスを独自で立ち上げなくて良いのは大きなメリットだったのですが、最近ではDockerによる開発環境の整備が進んでおり、docker-composeを利用することでwebpackプロセスなどは特に意識せずともコマンド一発で起動することが可能になってきました。

マイグレーションコストが高くなってきてしまった

独自でのパッケージの追加や、力技でのカスタマイズを加えていったため、マイグレーションが発生した場合に、CHANGELOGなどを見るだけでは安心できない状態になっていました。 また、Webpacker外のパッケージを更新する際もWebpackerとの影響を考慮する必要があり、気を払わなければいけない対象が多く、それであれば独自でwebpackを構成してしまって自分たちで依存モジュールを完全に掌握できている方が安心だな、という考えに至りました。

結局Webpackerを採用したのはどうだった?

個人的な感想は「採用してよかった」と思っています。

今現在で言えばマッチしない状況があるのは事実ですが、導入初期のころから振り返ってみると、確実に僕たちを助けてくれた存在だったと思います。

初期の設定をWebpackerに任せたことにより、すぐにVue.jsの更新・CoffeeScriptからの脱却・テスト環境の整備といった、プロダクト的にもっと重要な他の改善作業に注力することができましたし、その間はwebpackのことを考えなくて良かったのはとても助かりました。

また、つらかった部分を幾つか挙げましたが、これらはほぼすべてこちら側でカスタマイズしたことに起因して発生しているものであり、本来Webpackerが推奨しているものとはズレており、Webpacker自体の問題とは言えません。先に述べた恩恵のことを考えると、入れ替えるコストを考えても遥かにメリットのほうが多かったと思います。

つまり、プロダクト側の状況が変化したことでWebpackerを使うフェーズからは卒業したんだな、と思っています。Webpackerに限った話ではありませんが、フレームワークにはプロダクトとの相性や、マッチする時期、旬みたいなものがあるので、定期的に見直して最新化していくのは重要ですよね。

というわけでWebpacker、今までありがとう!

📢採用

Misocaでは旬を追いかけるエンジニアを募集しています!

www.wantedly.com

続・Android版Misocaのマルチモジュール対応

みなさんこんにちは、こまたつです。
突然ですが去年のこの記事を覚えていますか?

マルチモジュール化の波にのるべくモジュール分割にとりくんだのですが、しばらくころがしてみてこの分割方法ではイマイチということがわかってきました。
人生には失敗がつきもの、良くない点を整理して次へ進もうと思います。

まず今どうなっているか

冒頭にリンクをはった記事に詳細がありますが、だいたい次のような分割になっていました。

f:id:komatatsu:20190215150308p:plain
旧モジュール分割プラン

文書ごとにモジュールが分かれています。

なにがよくなかったか

まずはこの画面をみてくれ

f:id:komatatsu:20190215150358p:plain
取引先別文書一覧

こいつをどう思う?

すごく...モジュールをまたいでいるんですね。
そもそも各文書は似通ったデータ構造をしているのでクラスも抽象化されています。
これでは文書をさわると分割した別のモジュールにも影響が出てしまい、モジュール分割の恩恵をあまり受けられません。 *1

手間だけが増えてしまいビルドも早くならないし、モジュールをまたぐ画面があるので結合度が高くかえって複雑になってしまいました。

じゃあどうするの?

f:id:komatatsu:20190215150541p:plain
モジュール分割プラン2

これがモジュール分割プラン2です。
Misocaアプリはまだ機能も少ないので、ログインなどの今後追加される機能でも絶対必要な物さえ分離できていればちょうど良さそうというのがわかりました。
秘密の新機能が気になりますよね、私も気になります。

モジュール結合では分割時に追加したものを消したり移したりすれば特に躓くところはありませんでした。
AndroidStudioの表示がおかしいな?と思ったらAndroidStudioを再起動したりcleanしたりしてみましょう。

初挑戦で不安も多かったですが実際に試してみることで、資料を読むだけじゃわからない勘所がつかめました。
時間は失ってしまいましたが、この経験は今後のアプリ開発に活かされることでしょう。

採用情報

Misocaでは一緒にチャレンジしてくれるモバイルエンジニアを募集しています。
失敗を重ねて成功を掴みましょう。

*1:これを考えた当時は見積書だけInstantAppsにできるとよさそうみたいな構想があった

Misoca のお仕事 First impression

1月から Misoca で働いている @suer です。
入社から1ヶ月間働いてみた感想を紹介したいと思います。

今までの経験と比べて驚いたことはたくさんありますが、中でもスピード感の違いはいまだに戸惑うことがあります。
そこで今回は「スピード感」をキーワードに考察してみようと思います。

写真は名古屋勤務の合間に御朱印集めで立ち寄った護国神社です。 f:id:suer:20190112113026j:plain:w500

朝会・週次振り返り

Misoca では毎朝の朝会と週次の振り返りが行われます。
Trello にアジェンダが書かれていて、また、共有事項がある人は予めカードを登録しているのでサクサク進みます。
もう慣れましたが、最初は「あれ?もう終わった?」という感じで戸惑うほどの速さでした。

また、これらのミーティングで驚いたのは、「アクションに落とす力」です。
カードから問題や課題が見つかると、すぐにアクション列に移動され、
「誰かやります?」
「じゃあ私が」
という声がすぐにかかりすぐに処理されていきます。

f:id:suer:20190203202249p:plain:w500

この動きによって課題が着実に解決されていきます。 このリズムが Misoca のスピード感を出している要因の一つなのでは?と考えています。

  • 課題は解決しなきゃいけない
  • やれることは人任せにせずに自分たちでやる

ということは当たり前のようですが、ここまで徹底して実施されているのは経験上あまりなく、Misoca の文化だなぁと感じました。

リモートワーク

Misocaでは、場所にとらわれない働き方を推進しており、リモートで働く開発者がたくさんいます。

仕事中は普段みんな Zoom で同じ部屋につないでおり、お互い顔が見える状態で働いています。 *1

f:id:suer:20190205130542p:plain:w500

顔が見えないとなにか相談したいときなど、声をかけていいものか…と余計なことを考えてしまいがちですが、お互い顔が見えていると妙な安心感があり、声をかけやすくなっている気がします。

今までの経験では、なにか相談したいときや一緒に作業したいときなどは、会議室をとって…メンバーの予定を合わせて…という感じで実施が後回しになってしまいがちでしたが、ほとんどの内容はその場で個別のビデオ会議の部屋を作ってすぐに実施・解決されていきました。

このスピード感は、むしろリモートワークの方が有利だよなぁと思うことが多々あり、いい体験でした。

Pull Request を滞留させない

週次のミーティングでやることの中に、作成されてから長い期間がかかっている Pull Request を確認する時間が設定されています。
これはとてもいい方法だなと思いました。

放置されている Pull Request があるというのは良くない状況なので、それを週次でチェックし、どうするのかをみんなで考えます。
これにより、問題があるのであればその場で対処を決め、レビューのための説明が必要なのであれば説明するなど対処することができます。 結果として、その場にとどまっていた Pull Request を、マージできるように前へ進める事ができるようになるのだと思います。

ただ、みんなレビューが早かったり、「レビューして欲しい」と声をかけることで自発的にレビューしてもらったりしていたので、 この1ヶ月働いた中で滞留している Pull Request を見ることはありませんでした。
なのでこれはあくまでも想像です。

まとめ

ここで紹介できたことは Misoca のスピード感を生み出す要因の一部であり、今後もキャッチアップしていこうと思います。

この記事で見てきたことは、ものごとを着実に前に進める力を生み出しており、それがこれまで経験したことがなかった「スピード感」という体験となったような気がします。

このスピード感についていくのは入ったばかりの身としてはなかなか大変です。
しかし、他のメンバーが助けてくれていますし、またチャレンジしがいがあります。
なんとかついていけるよう頑張っていこうと思います。

Misoca では、ものごとを着実に前に進めていきたいエンジニアを募集しています!

www.wantedly.com

*1:VR 出社している人もいて物理的な顔が見えない人もいますが、ここでは「あー、一緒に働いてるなー」くらいの意味です

🌈俺たちのCustomEmoji

こんにちは、@mugi_unoです

最近4Kモニタを買いました。あまりにも快適で「なるほど、これが人権か・・!!」と思いながら作業をしています。

SlackのCustomEmoji

ご存知の方も多いかと思いますが、SlackではCustomEmojiという機能があり、独自に絵文字を追加することができます。

get.slack.help

ここにはチームの文化や雰囲気が色濃く反映されることもあり、眺めているだけでも結構楽しかったりします。

というわけで

俺たちのCustom Emoji

今回のエントリでは、MisocaにあるCustomEmojiを紹介してみたいと思います。

なお、トータルで356個あったので、比較的利用頻度が高いものに絞って紹介したいと思います

f:id:mugi1:20190128122448p:plain:w300

同意・肯定系

f:id:mugi1:20190125164658p:plain:w40 わかるとき

f:id:mugi1:20190125164746p:plain:w40 わからないとき

f:id:mugi1:20190125164808p:plain:w40 わかるわ、ってとき

f:id:mugi1:20190125174047p:plain:w40 それな〜〜

f:id:mugi1:20190125174151p:plain:w40 おなじ気持ちですよ!

f:id:mugi1:20190128115717p:plain:w40 いいこと言ってるな〜、ってとき

f:id:mugi1:20190128120042p:plain:w40 何かを見て「良さそうだな」ってとき

他にも、わかる・わからないのパターンがありましたが、諸事情によりここには載せられません。「わかり哲也」 で検索してみてください。それです。

よくあるリアクション系

f:id:mugi1:20190125171900p:plain:w40 Looks Good To Meなとき

f:id:mugi1:20190125171937p:plain:w40 完全にLooks Good To Meなとき

f:id:mugi1:20190125175000p:plain:w40 なにかが完了した時

f:id:mugi1:20190128115904p:plain:w40 なるほど

f:id:mugi1:20190128115948p:plain:w40 OK牧場

f:id:mugi1:20190128122003p:plain:w40 アレなとき

反応がほしいけど、テキストで返してもらう程でもない、というシチュエーションはわりと多いです。 その時にサッと意思だけ伝えられるのでとても便利です。

賞賛・感謝系

f:id:mugi1:20190125173729p:plain:w40 ありがとう!

f:id:mugi1:20190125165955p:plain:w40 わーい!

f:id:mugi1:20190125165741p:plain:w40 えらい!

f:id:mugi1:20190125165738p:plain:w40 すごい!

f:id:mugi1:20190125175208p:plain:w40 めっちゃいい

f:id:mugi1:20190125170206p:plain:w40 いい動き!

f:id:mugi1:20190125165812p:plain:w40 神だわ・・・

f:id:mugi1:20190128115805p:plain:w40 むしろ仏だわ・・

f:id:mugi1:20190125174817g:plain:w40 イエーイ!!
Created by modifying "cultofthepartyparrot.com" / © 2016 John Hobbs (Licensed under CC BY-SA 4.0)

普通に 「🎉」が使われることも多いですが、その時の気持ちをサッと告げられるようにバリエーションが豊かですね。特に、過去のエントリでもご紹介した「褒めるチャンネル*1」で良く使われています。

ちなみに

f:id:mugi1:20190125170424p:plain:w40

というのもあり、ナイスムーブと組み合わせると

f:id:mugi1:20190125170424p:plain:w40f:id:mugi1:20190125170206p:plain:w40

になります。しょうがナイス。

挨拶系

f:id:mugi1:20190128120554p:plain:w40 「あがります」って言うと返ってくる。熊本弁らしい。

f:id:mugi1:20190128120702p:plain:w40 体調がアレなときに

できたとき

f:id:mugi1:20190128122204p:plain:w40 できた!!

f:id:mugi1:20190128122212p:plain:w40 できとる!

f:id:mugi1:20190128122220p:plain:w40 できとるやん!!

コンボで使われることが多いです

Misocaならではっぽいもの

f:id:mugi1:20190128120815p:plain:w40 税です

f:id:mugi1:20190128120856p:plain:w40 プロジェクト外から失礼します

f:id:mugi1:20190128121020p:plain:w40 自由に使える会議室、通称「ドブ川」

f:id:mugi1:20190125165501p:plain:w40 草が生えたとき

なおこのEmojiは、FindyさんがRubyKaigiで配布していたステッカーを元に作成させて頂いています。

PDCA

f:id:mugi1:20190128120418g:plain:w40 PDCAサイクルが回っているとき。すごい回ってる

ゴリラ

調べてたら大量に出てきました。わたしにもよくわかりません。

f:id:mugi1:20190125164913p:plain:w40 ノーマル

f:id:mugi1:20190125170659p:plain:w40 考えるゴリラ

f:id:mugi1:20190125164941g:plain:w40 無限

f:id:mugi1:20190125164949g:plain:w40 振動

f:id:mugi1:20190125165013g:plain:w40 回転

f:id:mugi1:20190125164930g:plain:w40 フィーバー

Created by modifying "Twitter Emoji (Twemoji)" / © 2018 Twitter, Inc and other contributors (Licensed under CC BY 4.0)

かんそう

些細な一言でも積極的にEmojiにしていますね。

テキストベースでコミュニケーションでは、簡単でも反応があることが大事なので、その時にCustomEmojiを駆使することで、細かいニュアンスも手早くサッと伝えることができて、とても便利です。

また、全体的に肯定・承認といったポジティブなものが非常に多く、逆にネガティブなものはほとんど無いな〜と思いました。

それに似た話として、Misocaでは

🙇‍♂️ (:bow:)

を使っているのはあまり見ません。

見た目のイメージ的には依頼や謝罪を連想させますが、頭を下げてお願いするような必要はなく、失敗したとしてもお互い様で、謝るよりもチームとして次にどうするかを皆で考えていこうな!という意思の現れかもしれません。

ただもちろん謝っちゃいけないという意味ではないので、悪いと思ったらゴメンねとは言いますが、

f:id:mugi1:20190125172753p:plain:w40

が返ってくるのも安心感があって良いです。以下は実際に私がやらかしたときの例です。

f:id:mugi1:20190125175651p:plain:w400


みなさんもカスタム絵文字を使って楽しいSlackライフを送ってはいかがでしょうか。 それでは最後に、私のオススメのCustomEmojiを紹介したいと思います。

f:id:mugi1:20190128121533p:plain

:komon_no_power:

顧問自ら登録しているあたりがとても良いですね。

参考 : 文字の絵文字のつくりかた

絵文字ジェネレーターさんを活用させて頂いております。

emoji-gen.ninja

📢採用

MisocaではEmojiラブなエンジニアを募集しています!

www.wantedly.com

🎍開発メンバーの新年の抱負

あけましておめでとうございます。Misoca開発者の@kokuyouです。

新年早々ほたるちゃんの声を聞けたので、今年もいい年になりそうです。

さて、年が明けてもう1月が過ぎそうではありますが、今回の記事ではMisoca開発メンバー有志から新年の抱負を掲げていきたいと思います。

黒曜

最近はSRE周りに興味を持っているので、

  • ユーザに安定したサービスを提供する
  • 開発者が快適に、回帰テストを保証された状態で開発できる

ということに力を入れていきます。 あと、環境を全体的にDocker移行していきたいです。

またRails Developer Meetup 2019に登壇させていただくことになったので、自身で納得行く発表にできるようちゃんと準備を進めたいと思います。

id:mizukmb

  • Rustの勉強
    • プログラミングRustを読む
    • なんかかく
  • 走る
    • ハーフマラソンは達成したい
    • できればフルマラソンも
  • 貯金する
  • 日商簿記3級合格

thara

おみくじで大吉出て「短気を起こすな」と書いてあったので、 今年の目標は「短気を戒め、身を慎む」に決まりました。

細かいところだと↓みたいな感じ

  • 個人として
    • 日報を書く(継続)
    • 1日30分以上の軽度な運動をする
    • ブログを月に1回以上書く
  • 父として
    • 暗くなる前に保育園に迎えにいく
    • 子どもを注意するときに、大きな声を出さない
  • プログラマとして
    • Ruby gemを1つ以上公開する
    • Rust crateを2つ以上公開する

id:eitoball

今年は大きな目標は立てずに細く長く過ごしていこうと思っています。以下は、必ず成し遂げたいと思っています。

  • 4月にハーフマラソンの大会に出るので完走する。
  • 11月にフルマラソンの大会に出るので完走する。
  • 50km走ってみる。
  • Elixir・Phoenix・Elm を使った何かを書く。

よろしくお願いします。

id:sunflat

  • 開発環境をDockerに移行する
  • e-Taxで確定申告する
  • ドラクエ10のクエストを全部クリアする(職人クエストは除く)

kanizmb

去年20倍界王拳でものすごく頑張ったので、今年はこんな感じでゆるりとやっていきたいと思っています。

  • 物理で人に会う
  • 怪我しない
  • 事故らない

id:mallowlabs

知識をつけるために、いろいろインプットしていく年にしたいと思います。

  • Ruby / Rails の知識をつける > Ruby Kaigi / RailsDM に参加する
  • AWS の知識をつける > Lambda (特に SAM ) を使っていろいろ作ってみる
  • 業務知識をつける > 簿記3級の勉強する

mugi_uno

富山からjsを書きまくっていた2018年でした。今年も引き続きがんばりますよ〜

  • MisocaフロントエンドのjQueryを倒す
  • 富山県以外の場所で登壇する
  • 個人で作っているNuxt.js製WEBサービスのユーザを確保する。現在1名(自分)

id:hidakatsuya

引き続きPDF周りをやっていく年になると思います。

  • Thinreports 1.0 をリリースする
    • Thinreports Editor を書き直したりもしたい
  • 前々から温めていたモバイルアプリをリリースする
  • 数学(~中学レベル)を勉強し直す
  • 4Kディスプレイを買う

こまたつ

今年は健康になりたいのでそのための様々な施策をやっていきます
AndroidアプリのMAUは10倍にします

id:RKTM

  • Kotlin頑張りたい。
    • ktorで何か作ってデプロイしたい。
    • coroutines完全に理解する。
  • パフォーマンス改善(物理)したい
    • フルマラソン完走する
    • クライミング頑張る

id:lulu-ulul

  • Ruby は引き続き頑張る
  • 自分用の趣味アプリケーションのフロントを Vue.js に置き換えていきたい
    • 大半がレガシーフロントエンド(一部 Riot.js)のままなので。
  • 開発環境(物理) 改善していきたい
  • SNS疲れ抜けてきた気がするのでそろそろ何かアカウント作る
    • どうせなら何か新しいサービス試したいなー
  • 半額セールだから半年寝かせても損しないじゃん!と思って半年以上前に買ったままの RubyMine をそろそろ試す

yueno12

  • RxSwiftを使いこなしたい
  • MVC以外のアーキテクチャを試してみたい
  • 1年健康で過ごしたい(できればちょっと痩せたい)

id:ryotaway

コツコツ積み重ねてやっていきます。

  • Rustのcrateを1つ作って公開する
  • Hypervisor.Frameworkを使った仮想マシンを作って公開する
  • 痩せる

📢宣伝

Misocaでは新年から心機一転、抱負を掲げて開発していきたいメンバーを募集しています。

www.wantedly.com

2018年の大晦日にあたって

2018年の大晦日にあたって

こんにちは、マツモトサトシ (a.k.a @Dominion525) です。 昨年と比べると体脂肪率を25%→14%に削ったので、もろもろ快適度が増しました。

さて、今日は大みそかなので、2018年を振り返ったり振り返らなかったりします。

Misoca の名は晦日(三十日≒月末)に由来しており、なかでも年に一度のおおつごもりは気持ち的に大事な日ですしね! 井原西鶴も「大三十日(おおみそか)定めなき世のさだめ哉」と詠んでいますよ!(類題発句集)。

背景となる前提

先般、下記のようなMisoca社の体制変更があったことをご存知の方も多いかと思います。

リリースの中では言及されていないのですが、ぼくも状況がすこし変わっていて、親会社である弥生の技術フェローとして主に活動を行うことになりました。 Facebookでは下記のような記事をポストしましたので、一部の方はご存知かもしれません。

Misoca も組織をきちんとしてしっかりとしたパフォーマンスを出していくべき時期を迎えているわけで、創業者ドリブンで動く時期を脱し自律的に運営されるための体制変更ということになります。

ので、前向きに解釈していただければ!という気持ちです。

雑にいうと部活のOBの先輩みたいなイメージなので、口出しすぎて現行メンバにうざがられないように気をつけていきたいな、という感じです。

このブログの最初のエントリ とかすごい懐かしいなあ…。

ことしのまとめ

他に今年あったこととしては Android版アプリ のリリースは大きかったように思います。取り扱うべきプロダクトが増えますし、モバイル戦略をより一層深く考えないといけなくなるので、よい端緒になったかと思います。@k0matatsu、おつかれさまでした!


技術書典でMisoca名義の合同誌が頒布できたのもすごく良かったと思います。技術書典での活動がきっかけで商業出版につながったメンバもいます。今後もアウトプット


メンバも多様な属性の人がジョインしてくれたので、チームとして活動の幅がより広がりました。

いままでについて

というわけで2018年のみではなく2011年からいろいろ振り返ってみようかなあとおもったのですが、比較的近い時代の認識に引っ張られてしまいますね。 開き直って現状思っていることを書きます。

読み返すと、なんか主語が曖昧になってて良くないなあって感じはありますね 😔 「自分」と「Misocaチーム」が混在してます。

ふつうのことをふつうにする

主観的な認識としては表題の通りで「ふつうのことをふつうにする」というだけだったなあという気持ちです。

Misocaはビジネス向けのWebアプリケーションなので、テクノロジセントリックではなく、如何に利用者の方に価値があるか、というのが重要な観点になるので、必ずしも技術的にエッジなことをしているわけではありません。

なので、開発者が自身の倫理観に基づいて「かくあるべし」と考える「ふつう」を実践していけば、全体としては十分に強くなれるのではないかと思います。

「強みはなんですか」みたいな話でほかの人に説明するときにすごく困るんですけどね。

ともあれ、変な小細工やチート的なことに心を奪われず、正直に振る舞い、ある意味愚直に進んでいくのが一番強いのかなあという感想です。

きちんとバリューを出しているならば、細部については各人が正しいと信じることをやればいいわけですし、他の人もそれを望ましいと考えたなら取り入れてスタンダードにすればいいので、だいたいの場合に有用かなあと思います。

採用について

採用についてては「自分よりも優れているひとを採る」というポリシー*1なので、人が増えるたびに自分の相対順位が下がっていきます。

精神的にはわりと辛いところはあるんですが、方針自体は正しいものと信じているので、向上心を以てランキングに抗いつつ、自分の順位が下がるように頑張りました。

現状のメンバはとても強い人たちかつ、主体的に目標に向かうことができる人が揃っているので、より一層戦力を向上させたくさんのバリューを紡いでいただければうれしいなあという気持ちです。

採用については今後も継続して力を入れていくはずなので、エントリ末のリンクからぜひお気軽にお問い合わせください!

諸々の問題点と現時点の取り組み

いくつかあるんですが、明確に対応が動いているものとしては次のようなものがあります。

これ以外のことも含めて、多様な観点と力強い実行力によって着実に解決していけるものと期待しています。

おわりに

そんな感じでぼく的には状況が変わったところもあるのですが、Misocaとしては今後もより一層のバリューを出していくはずなので今後ともよろしくお願いいたします。

2018年おつかれさまでした。

2019年も、その先の未来も、ずっと佳い年でありますように。

📢 宣伝

2019年のMisocaをより強いチームにしてくれる開発者と、諸々のロールを求めています!

www.wantedly.com

ちなみに「世界のスループットを上げる」というのは、わりと頑張って考えた、個人的には気に入っているフレーズだったりします。

*1:正確には「自分よりも優れている(点のある)ひと」なので、ミスリードではあるんですが