Mobile Factory Tech Blog

技術好きな方へ！モバイルファクトリーのエンジニアたちが楽しい技術話をお届けします！

目的と技術に向き合う。その心は、楽しさのため｜モバファクエンジニア座談会

モバイルファクトリーのエンジニアは、NFTマーケットプレイスの「ユニマ」や位置ゲームの「駅メモ！」など様々な事業の開発をしています。そんなエンジニアたちが、普段、どのようなことを考えているのか。3人のエンジニアに聞いてみました。

@kfly8 : 今日は、モバファクのエンジニアが普段どんなことをしているのか、考えているのか、大切にしているのか、みたいなことを聞いていきたいです。よろしくお願いします！
まずは、みんなが普段どんなことをしているのか、自己紹介兼ねて教えてください。

@tsukumaru : エンジニアとして入社し、いまはマネージャーをしています。チームビルディングやピープルマネジメントに興味があるので、今回はその辺りを中心に話せればと。

@odanado : ブロックチェーンチームでソフトウェアエンジニアをしているodanです。チームではテックリードのポジションでブロックチェーン技術のキャッチアップや機能開発の設計などしています。ブロックチェーンの他にWeb 技術やプログラミングが好きです。

@maeken : 開発とスクラムマスターをしていて、普段はビールを飲んでいます。

@kfly8 : マネージャー、テックリード、スクラムマスターだね。
遅れたけれど、自分も簡単に自己紹介を。エンジニア組織開発責任者をしていて、堅く言えば、人材開発、組織開発、採用、技術広報など開発パフォーマンスにかかること何でもできればと思って動いています。
今日は３人のイイ話を楽しみにしています！

@maeken : まかせてください。

この記事に出てくる人たち

  • @tsukumaru
    2016年新卒でモバファクに入社。駅奪取、ブロックチェーンチームのエンジニアを経て、現在はマネージャーとして、チームビルディングやピープルマネジメントなどに注力している。
    去年生まれたこどもと過ごす時間が一番の癒し。
  • @odanado
    2018年新卒でモバファクに入社。入社当初に立ち上がったブロックチェーンチームにソフトウェアエンジニアとして在籍。現在はブロックチェーンチームのテックリード。
  • @maeken
    沖縄県出身。琉球大学大学院理工学研究科情報工学専攻修了後、モバイルファクトリーにエンジニアとして2019年に入社。アワメモ！の新規開発・運用を経験し、現在はステーションNFTチームの開発・スクラムマスターを行う。ビールを飲むのが得意。
  • @kfly8
    ゲーム開発やプロダクトマネージャーを経て、現在はエンジニア組織開発責任者。エンジニアの育成、採用、組織課題などに取り組む。また、技術コミュティ好きをこじらせて、Japan Perl Associationの理事もやらせてもらっている。

チームによって性質は異なるのだから、課題に応じて、開発の進め方を変える

@kfly8 : まずは、普段の働き方、開発環境だったりを教えてほしい。

@tsukumaru : フルリモートで、コアタイムありのフレックスで働いていますね。東京だけじゃなくいろんな所で働いている。

@kfly8 : 支給されているPCはどうだろう？

@tsukumaru : 会社支給のMac Book Pro。スペックは不足している印象はない。M1 Macなども使い始めているので、新しいものも反映されていて良いなと。

@kfly8 : odanはどう？

@odanado : あー、それで言うと足りていなくて（笑）
tsukumaruさんのチームだと、AWS上に開発環境があって、大丈夫ですけど、自分のチームはローカルでバックエンドも、フロントエンドも開発している。
メモリ16GのMacBookProを使っているんですが、メモリが足りない。
これは会社にどうこうでなく、Appleシリコンで32GB積んだやつをAppleに出してもらえればと（笑）

@kfly8 : 2台PCがあればいい？

@odanado : あー、開発用とSlack用？（笑）

一同 : （笑）

@odanado : リモートワーク前提だと、デスクトップマシンを支給するのはもしかしたらあるかもしれない？

@kfly8 : １周回っている感じだね。以前はデスクトップPCを使っていて、会議室へ持ち込みしやすくするためだったり諸々の理由で、ノートになった。フルリモート環境だと、デスクトップに回帰する選択肢もあるのかもね。
各々の在宅環境もそれぞれだよね。

tech.mobilefactory.jp

@kfly8 : 開発の進め方についても聞かせてほしい。
これもチームごとに個性があるけれど、スクラムマスターのmaekenから聞こうかな。

@maeken : 前提として、開発の進め方は、チームに任されている。「会社として開発の進め方は決まっているんですか？」と聞かれることがあるけれど、そうではなくて、自分のチームと他のチームでも異なる。

@maeken : それで、うちのチームはイテレーションが1週間のスクラム。週に各種セレモニーがあって、それを繰り返している。作ったものをレビューしてもらって、開発の方向性を決めていくのを大切にしている。スプリントレビューといった定例もあれば、もう少しまとまった単位でレビューを行う場も用意していたりする。ただ、ミーティングの量はスクラムのセレモニー以外は減らすようにしている。これには失敗談があって、なるべく全員で、共有する場を設けていたけれど、それだと、ベロシティが伸び悩んでいた。振り返りをして、まとまった作業時間がエンジニアは必要だと思った。細切れの時間だと集中ができない。ミーティングをガッとまとめて、作業時間もまとめてとるようにしてみて、スゴイ改善した。やるならミーティングを固めるようにする。
普段の開発の進め方も随時、ふりかえり、改善していっています。

@odanado : 会議を1日に集中させる、というのはうちのチームも取り組んでいるプラクティスですね。実際、メンバーからも好評の声が。

@maeken : odanさんのチームとスプリントの長さも違いますよね。

@odanado : あー、ですね。1週間だったスプリントを、2週間のスプリントに変更した。それはミーティングを減らしたり、まとめたりする意図もあった。スプリントのセレモニーを、毎週にすると実質開発する日が4日となるので。

@kfly8 : odanのチームは、1週間だと収まり切らない大きいチケットがありがちだったよね。小分けにするプランもあったけれど、価値の切り口が難しかった。結局、2週間で計画を立てる形にして、うまくいっていそう。

@maeken : チームによって性質が異なるから、それによって開発の進め方が変わる良い例ですね。

@tsukumaru : 開発チームとしてミーティングをまとめるのは良さそうではありつつ、違う切り口で、ひとつ。今の自分のマネジメントの役割だと、1on1をすることがあるけれど、それを1日にまとめると、喋りつかれちゃう（笑） 自分の場合は、意識的にずらしたりしている。

@kfly8 : マネジメントあるあるだ（笑）

ワークログを書くのは楽しい

@kfly8 : フルリモートになって工夫していることはある？コミュニケーションなど、新たに出てきた課題などあれば。例えば、新しい人が入ってきた時に工夫していることとか、コミュニケーションするために何かしていることとか。

@maeken : コミュニケーションは、意外とそこまで変わってないですね。
ミーティングは先程の通り時間をまとめたり、合間で雑談をしたり、あとは、Slackでのチャットコミュニケーションと、オフラインの時とあまり変わっていない。

@maeken : チケットの整理など、物理ホワイトボードが使えなかったのが一番大きい変化。みんなで図を書いて議論したり、付箋ぺたぺたしてふりかえりするのとかしづらい。最近はホワイトボードのWebサービスを使っていて、すごい良かった。ふりかえりや、チケット同士の依存関係、あとは朝会の連絡事項なども掲示板的な感じで使っている。逆にオフラインになったとしても使うと思う。どこでも見れるし、無限にでかいホワイトボードで記録が残る。

@kfly8 : コミュニケーションに変わりないのは興味深いね。意外。

@odanado : maekenさんのチームは、リモート前とメンバーが変わっていない、というのは大きいかも？リモート前の関係値がある状態で、リモートをやっているので、そんなに困らなかったのかなぁと思った。チームとして成熟している印象。

@maeken : たしかに。2年間くらい同じメンバーで、チームや関係値ができている状態なので。以前、気軽に雑談できる場所を用意してみようと、コミュニケーションツールを導入してみたが、結局だれも利用しなかった。様子を見ていると、コミュニケーションも悪い感じじゃなさそうだから、それはそれでいいのかなぁと。

@kfly8 : チームメンバーが変わって、課題やトライしたことがあれば。だれか教えて。

@maeken : tsukumaruさんのチームだと、毎日定期的に雑談する予定を設定していますよね？どんな感じ？

@tsukumaru : それは、2,3名で話すくらい。これがもっと機能していればリモートワークの工夫として良いかもしれないけど、まだ工夫が必要そう。
自分のチームでやっていたのは、オンボーディング用のドキュメント整備を行った。長年のドキュメントが溜まってきて、どこから読んだら良いのか、どこまで読んだら良いのか困っていた。それを、新卒は"まずここだけ読めば良い"という案内をわかりやすくした。これは好評ですね。

@kfly8 : イイネ。ドキュメントが多いというけれど、ドキュメントを書く人が多い？

@tsukumaru : みんな書いてますねー。
仕様だけでなく、ワークログとか。

@kfly8 : ポジショントークになってしまうけれど、ドキュメントをよく書くのは、モバファクの特徴的な良い文化と思っている。

@maeken : たしかに。入社してからドキュメントがあるなと思った、先輩も書いているし、自分でも書こうと思った記憶ある。

@odanado : ワークログという概念は、入社して初めて知ったが、良いなと思った。個人開発でも書くようになったし、Zennがスクラップ機能を出して、そこにワークログ書いている。どうして書くか言語化が難しいけど、メモを残すのは楽しい。

可視化するのは、組織開発においても、当然サービス開発、エンジニアリングでも大事

@kfly8 : 最近、直面した課題があれば、教えてほしい。

@maeken : ステーションNFTに関連するサービスを最近作っていて、そこのスクラムマスターとして開発している。最初の数週間が思うように開発が伸びなかった。そこで、数週間分スプリントを回した内容踏まえ、大きなまとまりのふりかえりを行った。何か開発のボトルネックはないか？って見直した。その時に、さっき話した、ミーティングが多くて、開発に集中しずらい課題が出てきた。

@maeken : もう一つが、要件決めを何からやれば良いかわからない課題が出てきた。スプリントでやることを決めるためには、何をやるのか決まっていなくちゃいけなくて、さらにその前に、要件を決めていく必要がある。で、当時、開発途中で別の要件が発覚したり、変わったり、逆に削除になったりで、そういったことが原因で開発のスピードが伸びないことがわかった。
　それをどうにかするために、いくつか先のスプリントまで、いつ何をしないといけないのか、依存関係はどうなっているのか可視化した。スクラムでいうとバックログの透明性をあげよう、とした。可視化したことで、自ずと「このタイミングでこれをするから、その前にこれの要件を決めておこう」といった会話がしやすくなった。それはすごい効果があった。
　問題をチームで見えるようにすることで、動きやすくなる。それは、開発のパフォーマンスであったり、開発の着地の見込みであったり、同じかなって思ってる。

@kfly8 : 普通にいい話。今度、詳しくブログに書いてほしい。

@tsukumaru : 可視化、に関連して、最近やっている、DX Criteriaの話がある。
自分のチームは、かなり大所帯。エンジニアはたくさんおり、それ相応にやることも多いし、要件を考えるディレクターの余裕もない状況。
それを改善するために何かできるかと、がっとふりかえってみて、チームの課題点を洗い出し、改善できるところを可視化しようとして、DX Criteriaを使ってみた。やってみた感じ、直感的に「ここまずいだろうなぁ」と感じていたところが、ちゃんと実際に赤く問題があると可視化された。これから改善の行動を取る必要があるけれど、一旦可視化って所はできたなと。

@kfly8 : イイネ。
こんなことを言うと、良くないかもしれないけれど、すでに直感的にまずい所はあって、可視化せずとも出来るところから進めたいと感じる人もいると思うんだ。なぜわざわざ遠回りしたのか？

@tsukumaru : 直感的に感じている課題だけが、課題なのかわからなかった。全体像を把握したかった。全体像を把握した上で「いくつか課題があるけれど、今はこの課題に取り組んでいる」と、全体像を共有しながら、改善していきたいと思った。局所解にならないようにしたいと思った。

@kfly8 : イイネ。もう少し聞かせてもらいたいのだけれど、大所帯のチームだし、チームの人を動かすのに苦労はしなかった？

@tsukumaru : 計測をするのは、チームに相談して、反発はなかった。むしろ「そういうの良いと思うんでやってみましょう！」といった反応。
多分、問題になるのはこの先。こういう課題があるのでやっていきましょう、と言ったときにみんなが取り組んでくれるか。そこをどう進めていくか、は問題。

@kfly8 : 今後に期待だね。応援したい。
テックリードとして別の切り口で、odanから最近課題になっていることあれば。

@odanado : 最近チーム内でWeb APIのパフォーマンス分析で、どうやってボトルネックを探すか、が課題になった。こういうパフォーマンスの文脈だと場合は「推測するな、計測せよ」と良く言われるけれど、これもさっきの可視化の話に繋がりますね。可視化するのは、組織開発においても大事だと思うし、当然サービス開発、エンジニアリングでも大事。

@odanado : 元々ある程度計測しやすい状態にはあった。というのも、ISUCONのおかげ。ISUCONでの学びを活かして、プロダクトに事前にAPI呼び出しをトレースできるようなものをバックエンドやフロントエンドに仕込んでいた。そのおかげで、ボトルネックの可視化という面で役に立って、何時何分にAPIのリクエストが始まり、何時何分に終わったか、というのが全部データで取れていて、さらにその中で何時何分にクエリが始まっているかだとか、何時何分から外部APIを呼び出しているかなどある程度計測できる状態にあって、すごい助かったというのはあった。
けれど、全てを計測できるわけではなくて、足りないオブザーバビリティの改善をした。オブザーバビリティの向上はこれからもやっていこうと感じています。

@kfly8 : odanもイイネ。

可視化は目的ではない

@kfly8 : 3人とも可視化をして、チームを動かす、システムをよくしていく話だったね。
敢えて聞くけれど、可視化に落とし穴もあると思うんだ。例えば、人によって解釈が違う、数字が1人歩きしてしまったり、数値の低さに注目が集まり本質的な話しから逸れたり。
可視化するときに気をつけていることはある？

@maeken : 落とし穴は、計りすぎること。計ることや数値自体が目的になってしまうのは良くないなと。例えば、ベロシティの話であれば、1人1人のベロシティは計っていない、チームのベロシティだけ計っている。個人個人のベロシティを計ることで、その人を評価しているようにみえるし、比較になってしまう、それによって、低い人のショックに繋がる。
ベロシティを計っているのは予測をするため。今これくらいのペースでアウトプットを出しているから、未来のここではこれくらいのことが出来ていそうと予想が立てられる。手段と目的が逆転しないように、計測する際は、目的を添えて伝えるようにしている。

一同 : 大事大事。

@odanado : うーん、なんだろう。
自分は対象がシステムだから、そういう懸念はあまり起きないなーと。

@maeken : APIのパフォーマンスで、数値のやばさの基準はどうやって作った？

@odanado : 相対的に見るなら、同じアプリケーションのAPIの平均、分散や呼び出される回数などをみて、API間のグラデーションを見る。
そもそも、パフォーマンスが絶対的に悪いかどうかは、フィーリングかなぁと。実際にユーザーになって、マウスを動かしたり、スマホでボタンタップをしてみたりして、まぁ雑ですけど、もっさり感を感じるか、とか、フィーリングに今は頼っていますね。

@maeken : 実際にさわってみて、そのフィーリング。

@odanado : ですねー。ここは今後、プロダクトマネージャーと話さないといけないところで、例えば、このAPIは何ms未満にすることが、このプロダクトの価値提供なんだと、決めていきたい。プロダクトによって、例えば「100ms」を早いと取るか遅いと取るかは異なる。50ms or dieとか、場面場面というか、どんなサービスやっているかに寄ってきますね。

@maeken : 変わってくるからこそ、例えば「100ms」を遅いと決めつけたり、それも落とし穴なのかなと思った。

@odanado : ですね。maekenさんが言っていた、目的の話に繋がる思っていて、プロダクトのゴールや体験してもらいたいことがあって、そのためにどこまでが許容ラインなのか決める話なので。

@kfly8 : 可視化するだけでなく、目的志向でありたいと。

楽しく仕事をする。そのために斧を研ぐ

@kfly8 : 可視化にフォーカスされているけれど、他に開発で大切にしている価値観があれば聞きたい。

@maeken : 全てひっくるめて、開発、というか、仕事は楽しくできた方が良いと思っていて、命大事に、楽しく開発するために、頑張る。仕組みづくりやチーム作りを頑張る。余計なことをやらない。結局、楽をしたいじゃないですか。ラクするというのは、サボるという意味じゃなく。大切なことに集中したいので、そのために頑張る。

@tsukumaru : 自分も楽しく、というのはある。そのために、斧を研ぐ時間は大事にしたいと思っている。木こりのジレンマの話。第一領域に集中するだけでなく、もちろん大事なんですけど、それだけでなく、第二領域、チームの改善や振り返りなど、そこもやっていかないとチームが良くなっていかない。チームがよくなっていかないと、個人も楽しくなっていかないと思うので、その時間は大事にしたい。第二領域をやれるようチームを動かすのも自分のマネジメントの仕事の一部かなと思っている。

理想を知らないと妥協してることに気づかない

@kfly8 : odanは全然違う視点で話してくれるはず。

@odanado : そう思っていました（笑）
ソフトウェアエンジニアのマインドとして、理想を追い求める。これは個人的に大事にしている思想で。理想は誰にも見つかっていないとしても、絶対に理想はあると思っていて。設計や実装をするのは、そこに向かうための道だと思っている。業務というのは、それを見つける作業だと信じているところがある。

@odanado : 基本的に100％妥協しないように仕事をしていることが多い。例えば、外部ライブラリを使う場面で、とりあえず目的は達成できているから、ライブラリの挙動がわからないけどokとするのではなく、ドキュメントを読み理解をした上で、ライブラリがどうやって動作するのか、それを解釈した上でコードを書いたりとか、そういう部分は強く持っている。

@odanado : ただ、もちろん、ビジネス的な要求だったりで、システム的な妥協をすることもある。けれど、理想を知らないと妥協してることに気づかない。それは成長とか、プロダクトの品質向上には繋がらない。ので、常に理想を持ち、それを追求できれば追求できるくらいの気持ちでいる。

@kfly8 : ふわっとした質問になるけれど、システムの理想ってなんだろうね？もちろんこれも目的次第だけど。システムはどんな特徴を満たしてると良いのか、特に気にしているところがあれば聞きたい。さっき出てきた話なら、オブザーバビリティとか。

@odanado : あー難しいですねー。
理想を、フレームワークに閉じ込める、というのは１つあるかも。仕組み化することによって、常に万全の状態にする、というか。チームのフレームワーク、規約に沿って開発すれば、ベストプラクティスに乗った状態で開発できるようになっていると良いなと思う。例えば、この関数で、Web APIを呼び出せば、バックエンドにログが残り観測性が担保できるとか。

@kfly8 : フレームワークに乗れば、ベストプラクティスに乗れる、というのは発想としては、Easy？中身がわかった上でライブラリを使えた方が良いという話と、若干相反する？

@odanado : Easyというより、開発者体験。１回目は中身を見て理解して、２回目以降はEasyの恩恵を預かれて、開発者体験が良くなるくらいのイメージでしたね。

自分が望んでいる環境があるなら、そう変えればいい

@kfly8 : 話が変わるけれど、どうしてモバファクに入社したのか教えてくれるかな？

@maeken : 就活をしている時、自分がやりたいことがある程度できるところが良いなと。そのために雰囲気を見ていた。会社の人数で100名を超えてくると分からない人が増えてきたり、風通しが…といった話を聞いたことがある。ので、100人くらいの規模で探していた。そんな中、話を聞いて、面白そうだと思ったのがモバファク。

@odanado : もともと駅メモ！のライトユーザーで、もっさり感を感じていた。競技プログラミングもやっていたので、パフォーマンス改善、最適化に興味があった。自分が触ったことがあるゲームで、なおかつ、パフォーマンス改善でおもしろそうなことができそうだなと思った。
ただ入社直後にブロックチェーンチームが立ち上がり、手を挙げ現状こうなっている。入社してから全く駅メモ！に関わっていないですね（笑）

@tsukumaru : 社長のメッセージと位置ゲームに惹かれましたね。
社長のメッセージに「家族を守る力がほしい」と書いてあった。そんなこと言っている会社って他にいなかった。他だと「会社を成長させる」「社会に還元」っていうのが多かったけれど、家族に注目している社長はいなかった。珍しいと思った。自分自身も家族を大事にしつつ働きたいと思っていたので良さそうだなぁと。
あと位置ゲームに関しては、もともと自分がゲームを作りたいわけではなかった、サービスが作りたかった。位置ゲームは、人のおでかけするっていう実際の行動に影響を与えられるゲームだと思った。これも珍しいなぁ、良いなぁ、と思った。

@kfly8 : 入社してみて、思っていたことと違ったことはあった？良い意味でも悪い意味でも。
悪いギャップがないのも不自然だし、それは改善すれば良いこと。

@tsukumaru : 悪い方のギャップはなかった。いい意味で予想通り。
面接で、みんな強そう、いい人そうという印象。実際入ってみるとみんな強くて、いい人たち。予想通りだし、予想以上にそういう会社なんだなとおもった。
唯一驚いたのは新卒同期が3人しかいなかったこと（笑）

@kfly8 : 例年はもう少しいるからね。

@maeken : 良かったギャップは、思ったよりやらせてもらえること。入社して、新卒で配属されるのが、いきなり新規開発になると思ってなかった。配属言われた日に驚いたことを覚えています。
悪いギャップは、現場と経営層で思ったより距離があった。100人規模の会社なので、社長であったり直接話す機会は多いと思っていた。

@odanado : まず良いギャップについて。
就職活動の時、モバファクか従業員10名くらいのベンチャーで悩んでいた。研究室の先生や周りの友人に相談していて、「同期は一生の繋がりだからいいよ」と言われていて、「ホンマか？」と思っていたが、今でもプライベートでゲームするくらいの仲。そういう所が良いギャップ。
悪いギャップは、シニアエンジニアがもっと欲しい。当初、シニアエンジニアがチームにいたが、半年で退職してしまった。チームメンバーの歳が割と近くて、びっくりした。

@kfly8 : 確かに。若い人が多いね。
２つの悪いギャップに関して動いていることはある？
現場と経営層のギャップに関してはどうだろう？

@maeken : 月次の全社締め会で、社長に質問をして回答してもらうコーナーが始まったけれど、社員の経営と距離が遠い、という社員の声を拾って始まった。きっかけとしては良い取り組み。直接話せる場があるかないかで全然違う。結果踏まえ変えていくところはあると思うけれど、どんどん取り組んでみるの良いと思う。
新型コロナのこの状況的に直接会って飲むのは難しいけれど、逆にリモートだから、オンラインでパッと集まってパッと聞ける、なども良いなと思った。

@kfly8 : シニアエンジニアが、もっと欲しい件に関しては、どう？

@odanado : とりあえず自分がシニアエンジニアになった（笑）

@kfly8 : かっこいい

@odanado : 去年からフロントエンドランチ会を定期的に開催している。フロントエンド技術のキャッチアップしながら、雑談する場。教育というか、会社全体のレベル感を引き上げるための取り組みを行なっていますね。
きっかけは、他社でもフロントエンドランチ会をやっているのを聞いていた。そういう会があることや、そこに参加する社員がいる会社がとても魅力的に感じた。まずは自分がいる会社にそういう文化を作るのが良いかなと思った。他社の真似をしながら、モバファクでもやってみようと思った。
自分が望んでいる環境があるなら、そう変えればいい。

一同 : エライ！

@odanado : 今年の新卒もフロントエンドランチ会に参加してもらえているので、脈々と続けられるかなと。

三者三様のキャリア

@kfly8 : 最後に、今後どうしたいのか、今後のキャリアについて聞かせてもらいたい。モバファクにどんなエンジニアがいるのか伝えるためにぜひ。

@maeken : 今のスクラムマスターはエンジニアリングマネージャーの一つの要素だと思っていて、そこに興味がある。今、イメージしやすくて、成功体験や楽しさを感じられているから。
自分だけじゃなく、チーム全員で楽しくできるようにしたい。

@tsukumaru : エンジニアリングマネージャーの話が出たけれど、元々自分もEMに憧れてはいて、最近管理職になったことでそういった動きがしやすくなった。ただそこで終わりではなく、経験、知識が足りないので、まずはEMとして成果を出していきたいし、自分が成果を出すことで、maekenとか他のメンバーにEMっていいね！と思ってもらいたいし、その結果会社に良い影響を与えられると良いなと思う。
EMを広めつつ、最終的には、会社の事業の変化を楽しめるような、変化に強い会社をつくることに貢献できたら嬉しいですね。

@odanado : キャリアプランは、最強になることで。

@kfly8 : それどこかで聞いたな（笑）

@odanado : （笑）
理由はより良い妥協をするには、理想を知っている必要があって、仕事の上でより良い妥協を繰り返して、選択していくことで、任意のテクノロジートピックについての理想を知っている状態。つまり最強になりたい。

@maeken : 全知全能に。

@odanado : 全知全能に。

@kfly8 : はい！それでは今回はこの辺で。ありがとうございました！

モバイルファクトリーでは、エンジニア組織をより強くするために、採用を行っています。 興味を持っていただいた方は、カジュアル面談も実施していますのでぜひお気軽にご連絡ください。

カジュアル面談のお申し込み

あわせて、こちらの採用サイトもご覧ください。

recruit.mobilefactory.jp