コードを書き続けたいから会社を作った話
大場寧子氏（以下、大場）：「強いエンジニアという灯（あかり）」という話ですが、強いエンジニアは憧れでもあると思うし、なりたいなと思っています。それに向かって進んでいるんですけど、仕事の選択肢というのはいろいろありますよね。私の場合はずっとコードを書いていくために会社を作りました。
なぜかと言うと、どこかの会社にいてコードを書いているとマネージャーとかをやらされるようになって、コードが書けなくなる。「いつまでコードを書いてるの？ そろそろ卒業して」みたいなことを言われちゃったりしかねないので。自分で会社を作って社長になれば、そんな目に合わないだろうと思って会社を立ち上げました（笑）。
それで他の人にマネージャーをやってもらって、コードを書くということにしたんです。でも結局、マネジメントができないと、うまく会社がまわらないということに気づいて、マネジメントを学ぶことになりました。
すると2、3年ぐらい前に「あれ？ 私、もしかしてあんなに避けていたマネージャーじゃない？」みたいなことを思うようになって。だんだん経営者ぽくなってきて、気づいたら経営が楽しくなっていました。組織を整えることが、オブジェクトの構造を整えるのにテイストが似ていて、同じように楽しくなったんですね。
今は組織を整えたりマネジメントをすることに満足していて、あまりコードが書けていません。趣味で小槌のメンテナンスや、仕事でもレビューとかはしますけど。でも、また書きたいなとは思っています。
仕事で何を実現したいのか？
強いエンジニアを目指す旅の途中で出会う事柄の例はいろいろあるかなと思っていて。例えばエンジニアリングで何を実現したいかに重点を置く場合があると思うんですよ。それから、どんなユーザーエクスペリエンスが最適なのかを気にしたり、チームが生き生きと働けるかどうかが気になるというのもありますよね。
エンジニアを育てたくなるかもしれないし、方向性は少し違いますが育児や介護とか趣味で、仕事量を調節したり、現場を離れたりするという選択をするかもしれないですよね。
例えばエンジニアリングで何を実現したいかが気になると、プロダクトオーナーという方向性では、技術者と兼任することはできますが、それだけではなく、プロダクトのことを考えることが増えていったり、それから自分や社会の課題を解決するために事業を立ち上げたり。
例えば「せっかく技術を覚えたけど、実は保育所の問題をなんとかしたい！」と思ってシステムを組んで、会社を作って人を雇っているうちに、全部コードを書き直されるみたいな、そういったことってよくあるパターンだと思います。
受託開発をしていても「お客様は本当にそれが必要なのか？ もっと何が必要か相談に乗ったほうがいいのではないのか？」みたいなものを感じるようになると、コンサルティングなども必要になると思います。
あとはどんなユーザーエクスペリエンスが最適かが気になると、UXとかデザインを詰めていくと思います。チームのことが気になってくると、コミュニケーションやマネジメント、チーム開発、それから組織の仕組み作りみたいなところ。組織の仕組み作りは、例えば情報共有の基盤、評価制度とか人事系のいろいろなことをやってみたくなると思います。
エンジニアを育てるなら、教育活動や採用に携わったり、本の執筆とか教材作りみたいなことをエンジニアと兼務していくこともあると思います。だんだんそちらの方向にシフトしていくかもしれない、現場を去るかもしれない。
強いエンジニアであり続けるためには、現場でエンジニアリングを続ける必要があると思うのですが、ただ、いろいろな選択肢を選んでいくと、気がつけば強いエンジニアとは違うところを旅しているかもしれません。
当然、ずっとエンジニアでいる選択肢もあると思います。なのでイメージとしては、強いエンジニアという灯があって、その周りでいろいろな活動をしていく感じ。ちょっと離れては、エンジニアのところが強くなってから戻ってきたりとか。灯は心の中にあって、いつでもふらっと戻ったりする、そんなあんばいになるのかな、ということを最近は考えています。ご清聴ありがとうございました。
（会場拍手）
憧れの存在
司会者：はい、どうもありがとうございました。非常に貴重なお話だったのでいろいろ聞いてみたい、質問してみたいという方は今がチャンスです。手を挙げてください！
（会場挙手）
質問者1：エンジニアとして活動してきた中で、大場さんにとっての灯になった、憧れの存在みたいな方はいらっしゃいますか？
大場：そうですね。私はちょっとインフラが弱点と言うか苦手なので、例えばペパボ（GMOペパボ株式会社）の柴田さんはかっこいいなと思います。プログラミングもインフラもオールラウンドで問題解決できるので。もちろんMatzさんもすごいなと思いますし、DHHさんももちろん尊敬しています。松田明さんとか、あとはクリアコードの須藤さんとかも……。
（会場笑）
いろいろです（笑）。
質問者1：ありがとうございます。
失敗の芽の溜め方
司会者：はい。他に「新人なんだけど、これを聞いておきたい」とか、何かありますか？
（会場挙手）
あ、前の方。
質問者2：失敗の芽を溜めてから潰していくことで成長につなげていく。そんなお話だったと思うんですけど、失敗を忘れたりすることはよくあるなと思っていて、そういうのを溜めて置くコツはありますか？ 失敗の芽の内容を駆け出しのエンジニアさんとかにシェアできる教育があれば、有効に活用できると思っているんですが。
大場：そうですね。個人的にはそんなに忘れないのかもしれません。忘れていることに気づいてないだけかもしれませんが。でも、繰り返しやることが忘れないことへの一番の近道だと思います。
そしてレビューなんですけど、けっこうコードレビューがキーかなと思っていて、自分が何かをして「あぁ、これは失敗した」と思いますよね。コードレビューをそれなりの頻度でやっていると、同じような失敗をレビューでも発見きます。そこで、「これをこうしないとこうなりますよ」みたいな話をする。そうすると記憶が定着するし、みなさんにうまく伝えることもできます。コードレビューを定期的に行うことが、記憶の定着にいいのかもしれません。
質問者2：なるほど。ありがとうございます。
どうしてマネージャになったのか
司会者：ありがとうございます。もう一人ぐらいいけます？
（会場挙手）
司会者：じゃあ、後ろの……。
質問者3：お話ありがとうございます。すごくフワッとした質問になりますが、先ほどお話で「コードを書きたくて会社を作ったけど、なぜかマネージャーになってしまった」とありましたが、それを聞いて「なんでコードを書いているだけでマネージャーになってしまうんだろうな？」と思いました。
（会場笑）
大場：なぜだと思いますか？ 私に限らず、周りを見ていても、コードを書いている人がマネージャーになることを求められてそうなっていく場合があるなと思っています。
よすぎる質問で、私も知りたいです（笑）。コードを書いている人がみんなマネージャーになるわけではないので、ざっくり言うとマネージャーの素質があると周りから思われている人がそうなるのかなと思っています。そうするとマネージャーになる機会がどんどん増えていくと認識しています。
あとはコードを書くこととマネジメントもけっこう通ずるところがあると思っています。結局問題解決ですよね。問題解決のレイヤーを変えるだけで、とくに仕組みとして落としていくにつれて、コードに近づいていきます。同じようにコードを書いて、うまくいった経験をマネジメントに応用してみると、意外とうまくいくんです。コードを書いてうまくいったときと同じ喜びが得られるので、つい引き受けてしまいます。やってからの喜びはあるので。
質問者3：ありがとうございます。
成長するエンジニアたち
司会者：じゃあ最後にもう一人。
質問者4：今までの経験の中ですごく成長したなというエンジニア、具体名を出さなくてもいいんですけど、例えばこういう形だったのが1年後にはこういうなったみたいな。具体的に「こういう成長を遂げたエンジニアがいました！」というのがありましたら教えてください。
大場：ありがとうございます。そうですね。「仕事でRubyコードを書いたことがない」人も、半年ぐらい立てばチーム内のエース級になっていたり、極端なケースでははかなり頼れる存在になって大変なプロジェクトを支えてくれたみたいなことはありました。
具体的には、自前で書いていたメール関係の古いコードを全部解析して「SendGrid」に移行するといった作業をやり遂げてくれる人もいました。伸びる人は半年や1年でプログラマーとしては相当成長する場合もあると思います。とはいえ、一般的なスピード感としては、3年ぐらい経験するといい感じになるようなイメージがあります。
質問者4：ありがとうございます。
司会者：ではこれで大場さんの発表を終わりたいと思います。最後に大場さんに大きな拍手をお願いします。ありがとうございました。
（会場拍手）
