久々のコラムなので、指慣らしを兼ねて、コラムを更新できていなかったこの3カ月間で身の周りで起こっていたことを書いてみたいと思います。特に、エンジニアの輪を広げるきっかけになったイベントを中心にまとめてみます。

◆ 合同勉強会 その二

　以前、フェンリルさんとの合同勉強会についてコラムに書きましたが、第2回となる合同勉強会をIIJさんと行いました。例によって相互にスピーカーを出し合うLT大会です。さらに今回は趣向を少し変えて、LTの時間からアルコールを入れた非常にノリのよい勉強会となりました。

　（これまでやったことのない形だったので、ちょっとビビってしまい、アルコールは会場である弊社の業務時間終了のタイミングで開放しました）

　この勉強会は、第1回の勉強会の後、弊社開発メンバーが参加した社外イベントの懇親会会場での会話がきっかけです。以前のフェンリルさんとの合同勉強会は楽しかったし、こういった形でも他社の開発者と交流を持てるのだという気持ちから、意気投合したIIJの方と合同勉強会の話をまとめていきました。

　さらに、普段このようなイベントでは必ずといっていいほどスピーカーを担当する私が、今回はなし。完全に一参加者として楽しませてもらいました。先述のとおり途中からアルコールが入っていたこともあり、LTはかなりの盛り上がりを見せました。また、そのような雰囲気のLTの後だからこそ、懇親会ではいつも以上にIIJのエンジニアの方々との交流も深いものになったように思います。

　ひょんなことから始めた合同勉強会が、このようにして進化しながら伝播していくのはとてもうれしいです。ご興味のある方は、イベントなどで私を見かけたら声をかけてください。ぜひ一緒にやりましょう。そして、お互いのエンジニアの輪を広げていきたいです。

　三三 ニュース＆トピックス
　クラウド名刺管理の三三、IIJと合同でエンジニア勉強会を開催

◆ 合同勉強会 その三

　立て続けに合同勉強会です。第3回は、弊社社員の以前からの知人が勤務されているVOYAGE GROUPさんと共同で行いました。この勉強会は、三三合同勉強会初のアウェイです。VOYAGE GROUPさんの誇る社内バー「AJITO」で軽食やアルコールを取りつつのLT大会となりました。

　しかし、この勉強会については多くを語れません。なぜなら、大変楽しみにしていた当日に体調を崩して参加できなかったからです。本当に楽しみにしていたので残念です。悔しくて仕方ないです。ですが、こうして、もはや私が参加もしない（できなかっただけですが）ところで、合同勉強会がどんどん広がっています。

　勉強会に参加できずに失った、エンジニアの輪を広げる機会を挽回するべく、VOYAGE GROUPボルダリング部と三三ボルダリング部による合同でのボルダリングを計画しています。合同ボルダリングについても、いずれ当コラムでお伝えできるかもしれません。

　エンジニアの方で（当然エンジニアでなくてもよいのですが）、ボルダリングをやるという方がいればぜひお声がけください。都内23区内であれば、一緒に登れるかもしれません。

　三三 ニュース＆トピックス
　三三、VOYAGE GROUPと合同でエンジニア勉強会を開催

◆ 高専企業訪問ツアー受け入れ

　以前から私の所属する三三では、高等専門学校（高専）といろいろな形で関わってきています。高専の学生さんは意識や専門スキルも高いため、将来は優秀なエンジニアとして世界で活躍してほしいという親心的な感覚で学生さんとお話をさせていただく機会も多いのです。

　日ごろのそのような活動からのつながりもあって、「高専ベンチャープロジェクト」の主催する「企業訪問ツアー in TOKYO」の訪問企業の一つとして、三三に15名の学生さんが訪れました。ここでは、弊社の誇るホープである高専卒の中森と私がそれぞれ、これから社会に出ていく皆さんにお伝えしたいことを話させてもらいました。

　さすが、意識の高い学生さんたちです。話の後にオフィス内の見学をしてもらったのですが、その合間にも中森や私と名刺交換をしたり、Facebookの連絡先を交換したりと、その後の交流につながっています。高専の学生さんと私は年齢的にはかなり離れていますが、やはりエンジニアマインドに年齢や性別の差はありません。このような会社のイベントを通じても、私のエンジニアの輪は広がっていきます。

　三三 ニュース＆トピックス
　高専ベンチャープロジェクトによる高専生の企業訪問を受け入れました

◆ 専門学校特別講義

　学生さん関連が続きます。東京デザインテクノロジーセンター専門学校（TECH.C.）でIT-Web系コースを専攻している学生の皆さん向けに特別講義を行ってきました。講義の内容は「ITベンチャーで働くということ」です。私からは、学生さんがこれから社会に出るに当たって知っておいてほしいことを中心にお話をさせていただきました。

　突然ですが、私はソフトウェアの開発者という職業が好きです。天職であるとすら思っていますし、大いに誇りも持っています。これから開発者になる方には夢と希望、野望を持って業界に入ってきてほしいです。一口に開発者といっても、自分の専門領域をどこに持つべきか。誰にも負けない専門領域を持ちつつも、フロントエンドからバックエンドまでカバーできるジェネラリストであることも、これからのエンジニアには必須条件になってきます。

　さらには、開発者として価値あるものを提供し続けるには、スキルはもとより、心構えなども非常に重要です。われわれの仕事は単に動くプログラムを書くことではありません。開発するソフトウェアを通じて、価値を創造することが仕事です。自分の職業の意義を知り、価値創造のためのスキルを研鑽し続けるのには、それなりに覚悟がいります。そのためにも、今から高いプロ意識を持ってエンジニアの道を歩んでほしいと思います。

　学生の皆さんには、上記のような内容をお伝えしてきました。

　ここでも、このような特別講義に出る学生の方々は意識が高いなと感じました。講義の後には、講義中には聞けなかった質問を聞きに来られる方や、やはりここでも名刺交換やFacebookの連絡先を交換する方が多く、新たなエンジニアとのつながりを作れました。

　三三 ニュース＆トピックス
　専門学校(TECH.C.)で特別講義を行いました

◆ 3カ月を振り返る

　コラムの更新が滞っていた期間のまとめ記事のようになってしまいました。

　でも、こうしてみると、この3カ月の間にも私のエンジニアの輪はどんどん広がっていることを、あらためて認識します。エンジニアにはエンジニア同士で分かり合えることがたくさんあります。お互いに切磋琢磨もできます。社内や閉じた世界でくすぶるのではなく、どんどんと外に出ていくことをお勧めします。そして、エンジニア同士の輪を広げていきましょう。

　ひょんなことから、あのSleipnirやデザインで有名なフェンリルの人々と知り合うことができました。そして、お互いの技術者同士で何か面白いことをやってみようという話になったのです。

◆ 合同LT大会

　有志による合同勉強会のようなものをやってみようと企画を練ってみました。われわれ三三のメンバーからすれば、フェンリルさんがどうやってSleipnirを開発しているのか、専門のデザイナーさんによるUXの話、さらには東京・大阪・国外などに分散した開発拠点間による連携の話など、聞いてみたいことはたくさんあります。逆に、フェンリルさんからも、自社サービスの運営や、大量データを正確に入力する仕組み、当社の神山ラボの取り組みなどについて聞いてみたいと言っていただきました。

　お互いに聞きたいテーマがたくさんあるし、やるならば少しでも多くのメンバーに話をしてもらいたい。そうなればLT大会が適しているだろうと。幸いにして当社にはかなり大きな銅鑼があります。これはもうLTしかありません。

（この銅鑼は、営業が注文をいただいた時や開発で大きなリリースを終えた時など、社内で盛り上がりたいときに、業務中であろうがなかろうが景気よく鳴らすためにあります）

　このような経緯で開催に至ったフェンリル・三三合同LT大会の様子を紹介します。

　これは神山ラボについて話す当社エンジニア。

　会場は予備の椅子を並べても座りきれないほどの満員御礼状態となりました。

　勉強会の後の懇親会です。こちらは当社のスマッシュルーム（普段は卓球台が鎮座していて、皆で卓球を楽しむ部屋です）を使い、軽食とアルコールで大いに盛り上がりました。

◆ 合同勉強会はお勧め

　例えば当社の場合、開発メンバーは平日の夜や休日の勉強会に各々が参加していますが、勉強会で一緒になることは多くありません。その上、メンバーがLTしている姿を目にしたことは、私はありませんでした。今回の勉強会では多くのメンバーが話したので、普段の業務では見ることのできない皆のLTテクニックやユーモアを垣間見られました。また、新しい勉強会を開拓することも最近はしていなかったので、普段とは随分違う雰囲気で楽しいものでした。

　事前打ち合わせ2回と、あとは当日の会場（当社会議室）の予約、直前に銅鑼を会議室に運ぶという程度で、今回の合同勉強会は割りと気軽に実施できました。また、気さくに話ができるエンジニア仲間は一気に増え、次の週末には私の趣味であるボルダリングに一緒に行くという交流もできました。

　開発をさらに盛り上げていきたい場合には、とてもお勧めです。

　私もエンジニアですから、普段はこういうこともしているんですよということで、今回はMySQLの技術的な話題を書いてみたいと思います。

　初めに、強調しておきます。

MySQLでネストするクエリ（サブクエリ）は絶対に使ってはいけません。

　このことを甘くみると、私のように振り回されてしまいます。世の中のエンジニアの方々には、声を大にしてお伝えしたい。レアケースの話ではなく、MySQLを使う場合の大前提として捉えてもよいほどです。

　ちなみに、なぜこのような動作になるのかはまだ全然分かっていません。追って調べていこうと思っているので、分かり次第コラムの中でも書けるかもしれませんが、何かご存じの方はぜひコメントをください。

◆ 急に遅くなるクエリ

　アプリケーションの開発や運用をしていて、RDBMSへのクエリが急に遅くなった、という問題を経験をしたことがない人はいないのではないでしょうか。私もこれまでに何度も経験をしてきていますが、最近またもやこの問題に遭遇してしまいました。

　ただし、今回がこれまでと違って難航を極めたのは、実行計画そのものは大きくは変わっていないということです。ORACLEやPostgreSQLであれば、時間の経過と共にデータの分散具合が変わったりして統計情報に変化が生じ、同じクエリでも実行計画が影響を受けて速度が遅くなったりすることがあります。この場合にはExplain Analyze（Postgres）やEXPLAIN PLAN FOR（ORACLE）を使って実行計画を確認して、クエリのどの部分の実行に時間がかかっているのかという謎を解き明かしていきます。

　私がORACLEやPostgreSQLに比べて、MySQLに慣れていないということが多分に影響しているのですが、今回も同じような方法で取り掛かろうにもなかなか解決策（回避策？）にたどりつけなかったのです。

◆ MySQLのサブクエリ

　MySQLがサブクエリの実行に弱い（期待に反して実行に時間がかかることがある）というのは、よく知られた話です。これについて若干おさらいをしておきましょう。MySQLがクエリをどのように判定したかを確認するためには、EXPLAINやEXPLAIN EXTENDEDを使って確認します。

>mysql> EXPLAIN EXTENDED
    -> SELECT * FROM (
    ->   SELECT lock_time FROM mysql.slow_log
    -> ) t\G
*************************** 1. row ***************************
           id: 1
  select_type: PRIMARY
        table: <derived2>
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 43665
     filtered: 100.00
        Extra:
*************************** 2. row ***************************
           id: 2
  select_type: DERIVED
        table: slow_log
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 43665
     filtered: 0.00
        Extra:
2 rows in set, 1 warning (1.05 sec)>

　上の例では、MySQLサーバに対して発行されるクエリのうち、実行に指定時間以上必要となったクエリを記録するログテーブルに対して検索を実行しています。このテーブルにログを出力させるためには、以下のように設定します。この例では実行に3秒以上かかったクエリをmysql.slow_logというテーブルに出力するように設定しています。

slow_query_log=1
log_query_time=3
log_output=TABLE

　これは極めてシンプルな例ですが、クエリが複雑になればなるほど、この結果からいろいろなことを読み取ってクエリが遅くなる原因を探っていかなければなりません。

　EXPLAINの結果でselect_typeで表示されるのが、MySQLがそのテーブルの捜査をどのように行うと判断したか（SELECTの種類）ということです。この例では PRIMARY と DERIVED となっていますが、これがDEPENDENT SUBQUERYであると、外側のクエリに依存するので、外側のSELECTの結果行数だけサブクエリを実行することになります。

　オプティマイザによって書き換えられる（最適化された）クエリが、元のクエリの意に反して必要のない結合をしてしまっていたり（SUBQUERYやDERIVEDになるべきサブクエリがDEPENDENT SUBQUERYとして解釈されてしまう）することもあるようです。本来必要のない回数だけテーブルやインデックスを捜査することになるわけすから、こうなってしまうと速度に影響を与えることになり、MySQLがサブクエリに弱いといわれたりします。

　しかし、今回の問題はこれに起因するようなものではありませんでした。

◆ サブクエリにするだけで遅いのはなぜ？

　先の例ではmysql.slow_logテーブルから全件のlock_timeの値を取ってくるという単純なクエリを意味もなくサブクエリにして実行しています。この実行には1.05秒かかったようです。さて、このクエリからまったく無意味な外側のクエリを削除します。

mysql> EXPLAIN EXTENDED
    -> SELECT lock_time FROM mysql.slow_log\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: slow_log
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 1
     filtered: 100.00
        Extra:
1 row in set, 1 warning (0.01 sec)

　あら不思議。0.01秒で完了しました。

　これはどういう仕組みで起こるのでしょう。この例ではEXPLAINの結果を出していますが、これは普通のクエリにするとフェッチにものすごく時間がかかるのが嫌だからです。EXPLAINではないSELECTにしても結果に大きな差はありません。

　私が解決しなければならなかったクエリも、プログラムの作り上無駄だと知りつつ、仕方ないと思っていたサブクリの部分をなくすようにしただけで、実行時間が100分の1程度になりました。

　今回この問題を調べていて、サブクエリをなくすだけで実行時間が短くなるということに気付いたのは、正直なところ偶然でした。高速化したいクエリの一部分をEXPLAINで確認しては早くなりそうなところにあたりをつけて修正する、という作業を繰り返しました。修正しては全体で実行してみて変化があるかどうかを確認して、効果がなければまた元のクエリに戻って別の部分をEXPLAINで確認します。それを行ったり来たりしていたのですが、あるときふと、どうも意味が分からない変化があることに気付きました。

　そこで思いつきでサブクエリだけを削除して、外側に付けていた条件句を内側のクエリに足して実行してみるとなんと激速。サブクエリの構造があまりにも単純だったので、そこを変更すると何かが変わるという発想がありませんでした。

◆ サブクエリは使わない

　実際の開発においては、サブクエリを本当に一回も使わずに作るというのは難しいかもしれません。しかし、サブクエリを実行するというのは、このような影響があるのだと意識した上で判断をしていきたいものです。

　皆さんもお気を付けください。

◆ エンジニアとしての矜持

　受託開発が中心の会社にある技術開発の部署で、いろいろな技術を先行的に調査するような仕事をしていると、難易度の高い技術の要諦をいかに早くつかむかが重要だと思えてきます。これはこれで、きっと正しかったのだろうと思います。しかし、その仕事を続けた結果として、いつしかその技術が何のためにあるのかと考えること忘れてしまっていたような気がします。

　平易な技術について考えることは誰でもできる。だったら他の誰もが考えられないような難易度の高い技術について考えよう。それが自分がここで仕事をしている意義だと。そうやって、技術というものに対する比重がどんどん大きくなっていった気がします。

◆ 価値

　転職して自社のサービスを開発する立場になると、期待されることは一変して、どんな実装をしても、どんな技術を使っていたとしても、ユーザーの価値さえ向上するなら何でもよい環境になりました。極端な話として、どうしようもない実装をしても評価され、イケてる実装をしても評価されないということが起こりうるわけです。そこまでの例はさすがにありませんが、似たようなことは実際にあって、エンジニアとしては簡単に納得できる話ではありませんでした。そりゃそうです。何のために日々膨大な時間とお金を使って学んでいるのかという話です。イケてる実装をするためではないのかと。

　一方で、ユーザー価値の向上こそが唯一にして最大の評価点だというのも、冷静に考えればそのとおりです。我々エンジニアはそのために存在しているわけですから。このこと自体は、受託開発だろうと自社サービスの開発だろうと変わらないはずです。ここがまさに殴られポイントです。頭では分かっているつもりでも、どうしても条件反射というか、これまで培ってきて自分の根底に流れている価値観からそう思えない。なぜだろう、何が間違っているのだろうと考える日々が始まります。

　実際に自分がこれまでに経験した事例をご紹介するのはややはばられるので、あくまでも架空の事例としますが、より具体的な作り話をしてみたいと思います。

◆ 知恵で解決するか、お金で解決するか

　例えば、あるところにデータ量の増加に伴って性能が出せないクエリがあるとします。このクエリは複雑で、DBMS の設定などを含めてチューニングするのには多くの時間が必要だけれども、早くできるのは、エンジニアの勘から分かるという経験はあるでしょう。

　受託開発であれば、プロジェクトには期日や予算などの制約があるので、お客様との調整によってある種の解決を図る場合もあるかと思います。しかし、我々のように自社でサービスを運営していると、プロジェクトの期間や予算というのはあまり強い制約としては働きません。

　このとき、クエリのチューニングにかかる時間がハードウェアの調達時間よりも長いなら、まずは追加のハードウェアで問題を解決することを優先的に考えなければなりません。その方が早くお客様に価値を提供できる（毀損されていた価値を回復できる）からです。

　追加ハードウェアの費用と人件費という観点もありますが、我々ベンチャー企業にとって人というリソースは実際の人件費以上に重要な価値を持っていますから、多少高くてもハードウェアで解決できるなら、その分の作業時間を他にもっと重要な機能を開発する方に向けたいのです。

　このようなケースがあったとしたら、私は（貧乏性だからなのか）どうしても自分の知恵でもって問題を解決したいと思います。それは、ソフトウェアのエンジニアとして自分たちが作ったものに責任を持ちたいという感情もありますし、ハードウェアで解決したとしてもその問題は潜在的にも残り続けるので、それが将来どんな重荷となって自分たちに降り注ぐかも分からないとも思うからです。

　しかし、このケースでいえば、まず真っ先にハードウェアで解決する方法を検討するべきでしょう。もし本当にその問題が将来何らかの大きな課題に発展する可能性があるならば、それは別の問題として捉えて、ハードウェアによってサービス価値を向上させた後に考えるべきなのです。

◆ 新しいテクノロジの導入

　フレームワークのバージョンアップ等でも同様のことが起こりえます。新しいフレームワークには魅力的な新機能が実装されていて、開発がさらに面白くなりそうだと。当然多くの不具合も改修されているわけで、開発としてはバージョンを上げない理由はないわけです。

　ただし、その行為がお客様価値の向上にどれだけつながるのかということも真正面から考えなければなりません。新しいテクノロジやバージョンには学習コストがかかり、見えないリスクがあります。さらに移行するためには多かれ少なかれ作業が必要です。

　それらのコストを払ってでも上げる必要があるのかと。それでも機能面で何も変えられなければ、それはユーザーにとっては本当にどうでもいいことなのです。新しいバージョンで解決される不具合に悩まされているということがなければという前提ですが。

◆ 軸の話

　ここまで書くと、エンジニアとして面白くもなんともない実装でサービスを作っていればいいのかと思われるかもしれません。それが大人の考え方だと。一見すると、ここで挙げた事例からはそう見えます。

　しかし、私がお伝えしたいのは、そういうことではありません。やはり、遅いクエリをよいハードウェアで早く実行できても、それはごまかしでしかありませんし、新しいバージョンには世界中のエンジニア達の知恵と経験が、新機能という形で搭載されているのです。先述のケースで違和感を感じることは誤りではありません。何が言いたいかというと、自分の矜持とか、面白そうだとか、そういうことではなく、きちんと顧客価値という視点から技術をとらえましょうということです。

　エンジニアが求めるものの多くは間違っていないと思います。が、それらは「世の中に提供する価値という軸で説明されなければならない」と思うのです。常にそれを頭の中心に据えておくと、技術の動向のみならず、組織における技術選択の背景も理解することができるようになってきます。

　先の例で言えば、「この問題を最も効果的に解決するには、ハードウェアを購入するべきか、クエリのチューニングを行うべきか」と考えます。そして、ハードウェアを購入することを選択したならば、今度は問題となったクエリを将来の課題にしないためには今何をするべきかを検討します。フレームワークのバージョンアップがあったならば、その新しいバージョンを使ってどうやって顧客価値を向上させようかと考えます。この機能を使えば、今よりもこれだけ早く開発できる（漠然とではなく具体的に）とか、これだけ品質を上げられるかなどを発想するのです。

◆ 技術ってすばらしい

　我々エンジニアは、世界を変える力を持っています。そのことを強く意識して、「自分は今どれだけ世界に貢献しているのだろうか」と考えるようにしてみることをお勧めします。世界に貢献するという意志を持って技術に接すると、それが純粋に面白いかとかイケてるかどうかではなく、その技術が持つ本当の価値が見えてきます。そうすると、その技術を採用するかどうかを進言するようなシーンでも、なぜ採用するべきなのかということを明確に説明できるようになります。その結果、どんどん自分の周りに面白い技術が集まってくるはずです。要するに、面白い技術が面白いのではなく、価値のある技術が面白いのです。

　もしこのコラムを読んでいただいている方の中に、ベンチャーでやってみたいと思っている人がいれば、ぜひ飛び込んでみてください。私のようにハンマーで頭を何度も何度も殴られるかもしれませんが、その苦痛を補って余りある成長があります。そして、世の中に貢献するための技術を身に付けて、1人でも多くの方に真に楽しいエンジニアライフを送っていただきたいと思います。

◆転職は前向きに

　前職に不満があったわけではなく、むしろ大好きな会社でした。何もできない新人から育ててくれて、とても面白い仕事をさせてもらい、アメリカでの経験も積ませてくれた。10年努めてこれから恩返しをしていかなければならないということも重々分かっていました。が、それでもエンジニアとして違う世界を見てみたい、もっと自分を追い込みたい、という思いから転職を決めました。

　転職の意志を告げるときにはかなり心が痛みました。それでも、転職を応援してくれた方々に本当に感謝です。

　やっぱり転職は後ろ向きな動機でするものではないです。どんな世界にも完全にハッピーな会社などあるわけないので。仕事としてやる以上は大変なこともあるし、納得できないこともある。そんなことを理由にしていたら永久に職を転々とすることになるでしょう。転職とは今の環境から脱出するためのものではなく、新天地に挑むためのものです。

　後ろ向きな人はきっと、どこにも採用されません。

◆ハンマーで頭を3回殴られる

　この言葉、すごく気に入っているんです。

　転職した先は三三という変わった名前で、Link Knowledge や Eight という名刺を起点としたサービスを提供しているベンチャー企業です。当時は社員数も随分少なく、事業の将来性がどの程度あるかなど見えない（と当時の私には個人的に思えたんです）小さな会社でした。しかし、名刺だけに全戦力を集中して、日本から世界に出ていくんだと熱く語ってくる人たちに惹かれて入社を決めました。

　本当にハンマーで殴られるわけではないのですが、そのくらいの衝撃をもらったのは事実です。この表現は入社当時に言われた言葉で、「これまでSI企業などで頑張ってきた人がWebサービスの世界に入ってくるなら、価値観やルールの違いを修正するために、少なくてもハンマーで3回は頭を殴られるくらいの衝撃を受けないと適合できないよ」と。まさにそのとおりでした。今までに何度も殴られてます。

　それがいいんです。それを求めて転職したんですから。これまで培ってきたものが適用できないなんて生やさしいものではありません。完全否定です。でもそれを乗り越えたところに違う景色が広がっているんだろうなと。今日もハンマーで殴られます。というか、たぶん自分で殴ってます。自己否定。そして殴られたと思う度に、少しは成長できるんではないだろうかと、明日の自分に期待してほくそ笑みます。

　これは少々大げさかもしれません。「自分はそんなことなかったよー」という方もいるでしょう。私が不器用なだけかもしれないですし。でもやっぱりベンチャーで働くというのは必死です。必死に仕事を楽しむんです。そんな風に仕事を楽しめる人とはやっぱり一緒に働きたいと思いますね。

◆スキルではなく成果を

　この世界にいると、日々新しい技術が生まれてきて、読まなきゃいけない本が常に何冊も積まれて、とにかく技術を習得しなければ自分に価値がないと思いますね。それはそうなんだけれども、でもきっとそうではないです。エンジニアなら、とにかく成果を出す。そのために、技術が必要なら学ぶ。こういう順番で考えるべきです。少しでも早くコードを完成させる。品質を上げる。メンテナンス性の高いコードを書く。これらを実現するために使える技術やテクニックはたくさんあります。ですけど、それらを学んだからといってすぐにできるわけでもないでしょう。だったら学ぶ前にまずはやれと。そして、さらに向上させるために学んでいくわけです。

　よく「どのくらいのスキルが必要ですか？」とか「こういうプロジェクトをやってきていますが大丈夫ですか？」と聞かれます。スキルとか経験とかは当然あったらあっただけいいです。大歓迎。でも、もっと大切なのは、成果を出す気持ちが強いこと。

◆仲間が熱い

　特に三三は。でもきっとベンチャーは大抵そうなんだろうと思います。

　だって、みんな人生賭けてるんですもの。自分の家族や将来を賭けてこの会社でやってやろうと思ってるんです。そりゃ熱くないわけがない。だから手が抜けない。そこがいいじゃないですか。

　ここまで言ってしまうと、かなり大変そうな感じがしますけど、実際そうでもないです。別に死ぬほど長時間働くわけではないですし、それはそれで自己管理します。長い時間働くわけではないですけど、毎日の一挙手一投足に集中します。

◆最終的には技術好き

　最後は、ここに行き着きますね。やはり。技術が好きで好きでたまらない、コードを書くのが大好きだって人とは一緒に働きたい。

　コミュニケーションが得意だったり管理が得意だったりするのもとてもいいです。組織内のコミュニケーションや管理に大きな課題があるならば、そういうことがものすごくうまい人に来て欲しくなることもあるかもしれません。でも、大抵そんなことないです。「技術はあまり得意でないですけど……」という人には開発チームの一員としてコミットしてもらうことは難しいと思ってしまいます。純粋にモノづくりが好きだということをまっすぐにアピールした方がいいです。