CodeIQ MAGAZINECodeIQ MAGAZINE

エンジニアの三大美徳「怠惰」「短気」「傲慢」 ─「怠惰」を極めて働くこととは?

2017.05.19 Category:勉強会・イベント Tag: ,

  • 198
  • このエントリーをはてなブックマークに追加

プログラマの三大美徳である「怠惰」。怠惰な働き方とはどういうことか。またどうすればより怠惰な働き方でできるのか。
まつもとゆきひろ氏をはじめ、リクルートマーケティングパートナーズ(RMP)、Quipperのエンジニアがそのコツを披露した。
by 馬場美由紀 (CodeIQ中の人)

エンジニアの美徳「怠惰」とは?

リクルートマーケティングパートナーズ(RMP)とQuipperが共同で主催するMeetupイベント「Food&Drink meetup include matz」。第5回目となる今回は、プログラマの三大美徳である「怠惰」をテーマに行われた。

イベントは大きく2部で構成。第一部はRMPの技術フェローであり、Ruby開発者であるまつもとゆきひろ氏が基調講演、そして第二部はRMPとQuipperのエンジニアによるLT「怠惰を支える技術」が行われた。

最初に登壇したのは、RMP技術フェローであり、楽天技術研究所フェロー、Rubyアソシエーション理事長などを務めるまつもとゆきひろ氏。

日本で一番有名なプログラマと言われているが、最近はプログラミングをしているよりも講演をしている方が多く、昨年度は47講演を行った。1年間52週しかないので、週に1回は講演しているような感じだという。

基調講演のタイトルは「怠惰のスゝメ」。今回のテーマ「怠惰」というとラリー・ウォールが頭に浮かぶ。ラリーはまつもと氏が尊敬しているプログラマ。

彼はPerlという言語を作った人として有名だが、彼が作ったプロダクトはPerlだけではない。「rn」というネットニュースリーダーの作者でもある。

このrnは非常に賢いソフトで、rnというコマンドを起動し、あとはスペースバーを押していると未読のファイルを読んでいけるというプログラムだ。

またそのほかにも、バリエーションの異なるUNIX向けプログラムがより簡単に作成できる「Metaconfig」というパッケージ、さらには、テキスト差分適用プログラム「patch」を作成した。

プロダクトだけではない。ラリーは本を書いても、講演をしても面白い話をするのだ。そんなラリーはプログラマの三大美徳として「怠惰」「短気」「傲慢」を挙げる。

一見、美徳に聞こえないかもしれないが、これらの3大美徳の意味はこういうことだ。


怠惰:全体の労力を減らすために手間を惜しまない気質。この気質のも主は、役立つプログラムを書いてみんなの苦労を減らしたり、同じ質問に何度も答えなくても言いように文書を書いたりする。

短気:コンピュータが怠惰なときに感じる怒り。この怒りの持ち主は、今ある問題に対応するプログラムにとどまらず、今後起こりうる問題を想定したプログラムを書く。少なくともそうしようとする。よって、プログラマの第二の美徳である。

傲慢:神罰が下るほどの過剰な自尊心。または人様に対して恥ずかしくないプログラムを書き、また保守しようとする気質。よって、プログラマの第三の美徳である。


これら3大美徳の反対の言葉は、「勤勉」「寛容」「謙遜」ということになるが、こちらの方が美徳に見える。

「ここで今回のテーマ「怠惰」の反対語とも言える「勤勉」について考えてみたい。勤勉な人は尊敬できるし、尊敬を集めるが、勤勉にも悪い側面がある」とまつもと氏。

「勤勉」の悪い側面

勤勉な人は一生懸命働く。だが一生懸命働く人の美徳とは、苦労していたり、苦痛に耐えている、我慢しているという側面がある。

「世間では『若者は泥のように働け』とか『若いうちの苦労は買ってでもしろ』という言葉が蔓延している。これらの言葉には、あなたの価値は『我慢』しているところにあるということが隠れている。

つまり『我慢』の価値である。日本人の多くが働くことは苦痛であり、その苦痛に耐え忍んだり、我慢することの対価として、お金をもらっているというイメージがある。無意識のうちに、我慢をすることや苦痛に耐え忍ぶことが素晴らしいことである価値構造になっているのである」

「労働の価値は我慢ではない。報酬は苦痛の対価ではなく、価値の対価。つまりその人のアクティビティで発生した価値によって分け前として報酬をもらうということ。

もちろん、ビジネス上の価値を提供するのは簡単ではないため、その過程ではストレスを感じたり、辛いと思うこともあるだろう。それは副作用であって目的ではない。

我慢することに価値がある、苦痛を耐え忍ぶことで結果を出していると思い込んでいる。これは単に暗黙の内のルールに縛られているだけだ。この構造に気付くと、ルールから外れた生き方ができる。

本当にそんなことができるのか。ゲームを考えてほしい。ゲームではできないと思われていたことをできるようにするのは裏ワザと言われ、それを見つけると称賛される。

私たちの生きている社会では、ビジネスはビジネス価値を創造してお金に換え、それを分配して給料になるというのが本当のルールだ。

だが、先のような我慢することや苦痛に耐え忍ぶことで報酬をもらっているというのは、あくまでもローカルルールでしかない」

ローカルルールであるのなら、それを破っても怒られることはない。本当のルールに従うことで楽ができるようになるというわけだ。

「これまでのような厳しい条件が課されたローカルルールの中でプレイをするのではなく、本当のルールで戦うことができるので労力が少なくてすむし、勝ちやすくなる。

ただ、本来の目的である成果を挙げることに集中するのだ。生産性が高ければ、何も文句は言われない。

さらに仕事が早く進むので早く帰れ、家族との時間に使うこともできる。このように生産性は人生におけるほとんどの問題を解決する」

ただ、注意しなければならないのは、現在の社会は生産性を低くすることにインセンティブが働くようになっている側面もあるということだという。

つまり長く働いたり、残業代をもらおうとすると生産性が低くないといけないからだ。そこで大事になるのは「我慢しない」「空気を読まない」ことだと、まつもと氏は語る。

そのためにも心の中に明確な基準を持つこと。それは「無駄に働きたくない」「絶対に働きたくない」=「怠惰」であること。

もっと怠惰になろう。そのためにももっと生産性を高めよう。これがまつもと氏からの「怠惰のススメ」だ。

人間でなくてもできる仕事はできる限り自動化しよう

続いて、リクルートマーケティングパートナーズ(RMP)×Quipper社員によるLTが始まった。

最初に登壇したのは、佐々木悠人氏。佐々木氏はゼクシィキッチンのサーバーサイドを担当しているエンジニアである。

LTのタイトルは「全力で楽をして人間らしく生きる」。

「人間らしく生きるというのはどういうことか、まずは人間とは何かについて調べるために、マーク・トウェイン(「トム・ソーヤーの冒険の著者」)の「人間とは何か」という著書を読んだ」という佐々木氏。


「揺りかごから墓場まで、人間って奴の行動ってのは、終始一貫、絶対この唯一最大の動機──すなわち、まず自分自身の安心感、心の慰めを求めるという以外には、絶対にありえんのだな」

「まず君の理想をより高く、さらにより高くするように務めることだな。そしてそのいき着くところは、みずからを満足させると同時に、隣人たちや、ひろく社会にも禅をなすといった行為、そうした行為の中に君自身まず最大の喜びを見出すという境地を志すことさ」


つまり、人間とはこういうもの。心の平穏を求めて周りも幸せをしていくものが人間である。全力で楽をするにはどうするか。楽をすることは生産性を上げること。人間らしくするために楽をするである。

佐々木氏がいちエンジニアとして、人間らしさを手に入れようと取り組んできたことは以下である。

事例1:勤怠記録がだるかった

背景はリモートワークを開始するときと終了するときはSlackで報告する。一方、勤怠を記録するのは、パソコンからしかアクセスできないツールにログインすることが必要だった。

そのため、都度記録するのが面倒くさくて、まとめて入力しており、そのたびに過去のSlackの発言を遡っていた。

そこで「勤怠みてれぅ」というサービスを作った。Slackの発言を拾って、始業と終業を入力してくれるサービスである。

Slackで広報してみたところ、他のエンジニアから「神」というリラクションをもらった。チームメンバーも楽になり、時間が生まれた。

事例2:Excelを書くのがダルイ

これまで人事評価用のシートはExcelで作成されており、そこに記入しての提出する必要があった。

その手間を省くため、md2wcmといWCMシート生成器という、テキストボックスにマークダウンで入力すると、Excelが生成されて落ちてくるというサービスをApache POIライブラリを使い作成した。これも「神」というリアクションをもらえた。

事例3:息子や愛犬との時間を大切にしたい

そこで生まれた時間で、週に3日間、リモートワークをしているという。リモートワークを上手く進めるため、スクラムを採用している。ちゃんとスクラムをするには、スプリント(全力疾走)しないといけない。

佐々木氏のチームでは1週に2日間は対面で議論をしたり概要設計をしたりする時間にあて、それ以外の3日間はコードを書いたり設計をしたりという体制になっている。本当にスクラムをうまく回しているチームだとリモートワークもうまくいくと思われる。

このように、人間がやらなくていいことはなるべく自動化すること。そして、人間がやるべき仕事を全力でする。これはエンジニアが本来得意なことである。

ワークスタイル変革で仕事も子育ても全力

続いて登壇したのは、リクルートマーケティングパートナーズの市川純氏。市川さんは2014年2月に入社。現在はスタディサプリ進路、ゼクシィキッチン、kidslyを担当している。

LTのタイトルは「子持ちエンジニアのワークスタイル変革」。子どもの成長とエンジニアとしての成長を両立するためにやっていることについて話した。

市川氏の家族構成は、妻と子ども二人。長女は6歳、長男5歳だ。子どもが生まれる以前は、妻が怒らない限り残業し放題だった。最初の子どもが生まれた頃は、ベンチャーを共同で起業していたので、残業ばかりしていた。

週末は妻が怒らない限り、勉強に時間を使えた。平日も残業がなければ、市川氏も妻が怒らない限りは勉強会に参加していた。しかし子どもが生まれてからは、気にせず残業していると怒られる。

もちろん、子育ては家族でやるべきもの。自分の子どもなのだから、子育ては当然のこと。とはいえ自分の時間は作りたい。当然妻も同じように思っている。そこでお互い自分の時間を作れるよう、ワークスタイルを変革させたという。

まずは遅くまで残業しなくなった。リリース前などの例外はあるが、基本的には遅くまで残らないようにし、日中の仕事は一気に進めるよう心がけるようになった。

目標としては遅くとも20時頃には会社を出る。すると21時前に家に着くので、短い時間だが子どもと過ごす時間も取れる。22時になると子どもを寝かしつける。子どもが寝た後は自分の時間として使う。

週末の過ごし方も変わった。週末はほぼ子どもと過ごす時間として費やす。朝早くから行動して、昼過ぎまで遊んで昼寝時間を狙って自分の時間を作るようにしている。

また自分に使える時間が短くなったことで、学ぶ技術を厳選するようになった。これまでは新しいことがでてきたら、手当たり次第に調べたりしていたが、今は本当にやりたい、必要なモノだけ触るようになった。

コミュニティ活動や勉強会は聞く側ではなく、発表する側や開催する側に回るようになったという(JAWS-UGなど)。

登壇する側になることで、アウトプットのためのインプットも増えるし、他の登壇者と交流することで、新たなインプットも増えた。

このようなプライベートでの調整も大事だが、会社での働きやすさも大事になる。RMPでは子育てエンジニアを支援する次のような仕組みが用意されている。

  • リモートワークの推進
  • フレックス勤務
  • 研修・海外派遣 自己起案制度(業務扱いでカンファレンス参加可能)※一部部署のみ
  • 育児休暇の必須取得(男性・女性ともに)
  • STEP休暇(3年ごとに最大28日間の任意休暇と30万円が支給される制度)

今回のテーマは怠惰。子育てに関しては怠惰にはなれない。ただ、自分の時間を作るためには全力で子育てや家事をこなす。妻とのスケジュールも調整する。

全力でこなした後にできた時間をエンジニアの成長や興味に使う。最後に、「今子育てで大変な思いをしている人や、今後子育てを経験するかもしれない人の参考になればうれしい」と語った。

WebTranslateIt(WTI)を活用し怠惰なi18n運用を実現

4番目に登壇したのは、Quipperのyuya_takeyama氏。

yuya_takeyama氏は、Quipperに入社して約1年半。Webデベロッパーとしてサーバーサイド(Rails)、クライアントサイド(Backbone/Marionette/React/Redux)の双方の開発に携わっている。ちなみにi18nとはinternationalizationで国際化のことだ。

LTのタイトルは「グローバルプロダクトにおける怠惰なi18n 運用」。WebTranslateIt(WTI)という翻訳支援サービスを使って、Railsアプリその他の翻訳の効率化をどのように行っているかについて話した。

Railsにおけるi18nの翻訳ファイルを怠惰に運用する方法が以下のやり方だ。

Railsであれば、config/locales/en.ymlが更新されたときなどにJenkinsで英語がWTIにアップロードされる。するとWTIのWebUI上で他の言語も編集できるようになる。

Quipperでは、プロダクトマネージャーやビジネスデベロップメントの人などが翻訳を行う。翻訳後はJenkinsで定期的に、英語以外の言語(日本語、インドネシア語、スペイン語等)のファイルを生成してPull Requiestを作り、確認して問題なければマージする。

改善したいと思っているところもある。

文脈が分からないという問題

:cancelという単語だけみても、これが「ダイアログを閉じる」または「決済の解約」なのかわからない。

ソリューション案:ラベルを使う。WTIではラベルという形式で、翻訳対象の文言ごとにメタデータを付与できるので、そこにPull RequestのURLを指定することに。Pull Requestを見れば文脈が分かるようにした。

非開発者は英語がいじれないという問題

英語はWTI上でいじれない状態になっている。

ソリューション案1:ベース言語を用意する。元々英語だったところを、ベースの言語を用意してそれをpullしてWTIで翻訳するという形にすると、英語も他の言語の一つとなる。

ソリューション案2:それは非開発者にもGitHubでYMALをいじってもらうようにすることだ。

Quipper的にはエンジニアでなくてもPull Requestを送る人もいるので、できるかなと考えていたそうである。

開発者も常にWTIで訳さないといけない問題

ちょっとした文言を直すときに英語のYAMLを少しいじれば終わるが、他の言語も一緒に直さないといけないときは、WTI上でやらないといけないのは面倒である。そこで以下のソリューション案を挙げた。

ソリューション案:同期を双方向にする。pushとpullを双方向にする。単純にやるとバッティング問題が起こる。安全にやるためには、Pull Requestのマージのタイミングで新規キーの追加のみを行う、といった工夫がいくつか必要となる。

このように、今後もいかに怠惰にi18nの翻訳(YAML)を怠惰に運用するかについて検討を進めているとのこと。

13段クエリをTD Workflow(Digdag)で怠惰に走らせる

4番目に登壇したのは、beniyama/山邉哲生氏。もともと組み込み系の研究者で、一度大学に出戻った後、Webアプリケーションエンジニアとして様々なシステムの開発に従事。

今はRMPのデータ基盤グループでデータエンジニアとしてスタディサプリのデータ分析基盤の開発・運用を担当している。また一方で学習データを活用して教育をテクノロジーで進化させる試みも行なっている。

LTのタイトルは「13段クエリを怠惰に走らせる」。スタディサプリのデータ基盤グループで取り組んでいるテクノロジーの一つにアダプティブラーニング(適応学習)というものがある。

それは学習者の個性や理解度に応じて、その場で最適と思われる教材・コンテンツを選択・提供する学習の仕組みである。学習者にとっては、まなびにつまずいたとき、次に何をすれば良いかを提示してくれる学習ナビゲーターとも言える。

例えば単元1を習得し、次の単元2では足止めにあったとする。その時、単純に単元1に戻るのではなく、実は強い依存関係を持っている単元Xに戻るようにするなど、ビッグデータが指し示す知識獲得のパスを考慮することが効率的なまなびにつながると、山邉氏は考えている。

そこで、スタディサプリでは知識の地図を作成し、各単元を構成する講義の関係性を見ている。さらに、この知識の地図とスタディサプリのドリルの解答ログを照らし合わせて、実際にいくつかの高校でお勧め講義のレコメンドを提供するという実証実験を行っている。

スタディサプリの学習ログはTreasure Dataに蓄積されており、以下のようなプロセスを経てレコメンド講義のリストが作成される。

  1. スタディサプリのドリル解答ログを整形
  2. ドリルの設問間の依存関係を抽出
  3. 任意の解答に対してレコメンドを提示するためのテーブルを抽出
  4. つまずきを検知するための前処理済みの解答ログを作成
  5. レコメンド講義のリストを作成
  6. 到達度テストと呼ばれる一斉模試から抽出されたレコメンド講義のリストを作成
  7. 初学者向けのプリセット講義リストを作成
  8. 5~7を全結合
  9. 学習者それぞれについて指定された分量のレコメンド講義を抽出・リスト化

クエリは13段にも及び非常に長く、直列だと2時間はかかる(しかもまだ後工程がある)。また人の手で実行すると前段が終わらないうちにクエリを実行してしまったり、ステップを飛ばしてしまったりする。

そこで、ワークフローエンジンの一つである Digdag (Treasure Data では Treasure Workflow として提供されている) を導入し、一連の処理を自動化することにした。

DigdagとはTreasure Data社発のOSSで、YAMLベースでワークフローを記述することができる。基本的に上から下へ流れ、ブロック内で並列実行箇所を指定することもできる。

また多様なオペレータが利用可能であり、TD Workflow(Digdag)を導入することで、13回クエリを叩かなくても目が覚めるとレコメンドリスト一式ができ上がっている状態が実現できた。

TD Workflow (Digdag) ではTDに登録されているクエリをクエリ名で直接呼び出すこともできるので、既存のクエリを単純に連鎖実行するのは非常に簡単だった。

ただし、別種のワークフローエンジンである Luigiのように複雑な依存関係を記述することはできないので、その辺は人間が気を遣う必要がある。このようにワークフローエンジンを活用することで、多段クエリの実行を自動化し、怠惰を実現した。

またもう一つ、アダプティブラーニングもある意味で怠惰を実現する試みであり、まなびのガイドを自動化することで多忙な教育現場に少しでもゆとりが生まれることを期待しているという。

だが、教育の現場にいる先生方は、授業に生活指導に放課後の活動に非常に疲弊しきっており、多種多様な生徒を個別に対応していくには限界がある。

究極の適応学習の形はAIチューターであり、基礎的な知識獲得は AI (アプリ)との対話で個々に進んでいく。

そうして生まれる時間を活用して、先生は本当にヘルプが必要な生徒を重点的にサポートしたり、メンタルや健康面のケア、あるいは21世紀型の教育などに注意を払うことができるようになる。

張り詰めた教育現場に少しでも怠惰という名のゆとりを生み出すべく、研究開発に励んでいるとのことだ。

エンジニアやディレクターが無駄な仕事をしないための環境整備

最後に登壇したのは、naokianinoya氏。naokianinoya氏は新卒でミクシィに入社。インフラの部署で数千台規模のサーバ群を管理していたことから、いかに怠惰に効率よく運用するかを身につけたという。

LTのタイトルは「ごみあるところに金はある」。

全社で使うプッシュ通知の基盤、デプロイを簡単な記述で実行するツール、walterでシンプルなビルドパイプラインツールを作ったりした。

RMPでは「スタディサプリENGLISH」という英語学習のインフラを開発していた。

「スタディサプリENGLISH」とは、話す力、聞く力、最短距離で楽しく身につけられるサービス。現在は開発支援グループに所属している。開発支援グループは、エンジニアがいかに怠惰に仕事をできるかを考えて支援をしていく横断組織だ。

具体的にはSite Reliability エンジニアリング(サイトの安定性を高める仕事)や、Develope Prodctivity Engineering(生産性を高めるエンジニアリング)、セキュリティ対応、エンジニア採用・人事・組織活性、社内ITなど、その業務は多岐にわたる。

支援対象は内製開発組織内の複数のプロジェクト群で、それらのサービス開発を加速させるための開発ならなんでもやるというのがミッション。

なぜ、開発支援をするのか。それはエンジニアにディープ・ワークをしてもらうためである。ディープ・ワークとはムダな仕事はしないで、本質的な仕事をする。そして質を高めて短い時間で成果を出すことだ。

エンジニアの本質的な仕事とはユーザーに価値を届けること。その一点のみに集中できる環境を作るために、不要で無駄な時間を削るのがこのグループの目的だ。

具体的に、どんなことを行ってきたかが紹介された。

ハイパワーコンパイルマシン導入でビルド時間の短縮

AWSでJenkinsマシンを動かしていたが、どんどんテストケースが増えて、それらが全部終わるのが10分かかっていた。ハイパーマシンの導入で、Scalaプロジェクトのコンパイル+テスト+dockerImageのビルド時間を3分の1に。時間を金の力(約20万円)で短縮できた。

OpenSTFの導入(検証端末のテストファーム構築)

QAのチームに対しては、スマホアプリのテスト自動化基盤の導入。これまではお金でテスターさんを集めて労働集約的にテストを実施。大量のテスト項目を手作業で行っていた。しかし人間の目の方が、精度が甘くなったりする。

そこで機械的にこなせるモノは自動化を行った。テスターは人間でないと発見が難しいバグを探すことに集中することに。OpenSTFの導入により、リモートワーク時も検証端末利用が容易になった。

Appiumによる実機e2eテストの検証・導入

OpenSTF/Saucelabsをテストファームとして自動化基盤を構築。Appiumによる実機e2eテスト実行の仕組みを整えた。

デザイン崩れなどは人間が見た方がよいので、機種別とOS別にストーリーに従ってスクリーンショットを並べていくようなことをやっている。

細かいボタンの崩れなどは人間の目だと見落としもあるので、画像を比べて差分を赤く表示するような、差分を出すツールを入れてインテグレーションをしたりしている。

ディレクターのシャローワーク削減

ディレクターは無駄な仕事が多い。例えばデータ集計業務は人力スクレイピングになっている。

売り上げ集計システム、データ出力APIやデータダンプ機能がなかったりするので、他社管理課の売り上げ集計画面を1ページずつめくってエクセルに転写するようなことを行っていた。

それをScrapy(クローラ向けのフレームワーク。数行書けばそこそこ動くクローラがつくれる)を導入して自動化。人では実現不可能だった頻度での売り上げ計測ができるようになった。このようなシャローワークを地道に自動化していくことで、サービスの価値向上に充てる時間を増やすことができる。

会議室予約アプリを作成

全社で使っている会議室予約画面をスクレイピングして、会議室予約アプリを会議室前に設置。会議室が埋まっているときは他の会議室をサジェストするようなアプリを作成した。

とにかく自分たちが変えられる範囲で変えていくことが、怠惰になる大事なポイントだ。このほかにもコツコツと自動化している。

ルーチンワークの悪いところは、無価値なのに仕事した気になりがちなこと。そして就業時間に見合うところまで膨張する傾向がある。ルーチンワークで埋め尽くされることで、未来のことも見えなくなる。ゆとりこそ価値を生む。

ごみ(ルーチンワークやシャローワーク)あるところに金はある。ぜひ、参考にそれらを削減し、怠惰を実現しよう。

LT終了後、まつもと氏はこう語っている。

「生産性を高めること。それが怠惰である。怠惰は怠慢とは違う。ぜひ、無駄な仕事をしていないか、自分の仕事環境を見直すきっかけとしてほしい」

イベント最後にはリクルートマーケティングパートナーズの専門役員、竹迫良範氏が登壇し、今後は同社でHR(Human Resource)× Technologyを導入し、怠惰な働き方を支援するツールやシステムを正式なルールと変えるバックアップを行っていることなどを語った。

同イベントでは寿司職人を招き、握りたてのお寿司を振る舞ったりと、カジュアルにエンジニア同士が語れる場も用意。登壇者たちとの交流も積極的に行われた。

  • 198
  • このエントリーをはてなブックマークに追加

■関連記事

伊藤直也・増井雄一郎・まつもとゆきひろ・白石俊平が語る「必要とされるエンジニアになるには?」... どこでも必要とされるエンジニアになるには? パネルディスカッションのテーマは「技術のキャッチアップ、マネジメント、エンジニアの方向性etc.…『どこでも必要とされるエンジニア』になるには?」。 今回はITエンジニアに人気のRebuild流に、それぞれが気になるニュースや記事をもとに、意見を交わす...
エンジニアとしていかに幸せに生き抜くか?まつもとゆきひろ氏が説く「エンジニア・サバイバル」... 人が幸せになるための条件とは何だろう 人はどうなれば幸せなのか。例えば年収1千万円を超えると人は幸せなのかといえば、そうとはいえない。人が幸せになるにはいくつか条件が必要になるが、一人ひとり求めるものも違えばバックグラウンドも違う。 そこで今日はいくつかの話題を提供し、結論へと導いていきたいと、...
まつもとゆきひろ氏がSpeeeで語った、勉強会・英語・プログラミングの話... まつもとゆきひろ氏とコードを競うコードゴルフ大会 今回訪問したSpeeeの社内勉強会が開催されたのは、同社のカフェスペース「SpeeeLounge」。とても素敵なカフェだ。 そこでは、エンジニアたちが真剣にコードを書いていた。 今回の勉強会で行われたのは、与えられたお題に対して、誰がも...

今週のPickUPレポート

新着記事

週間ランキング

CodeIQとは

CodeIQ(コードアイキュー)とは、自分の実力を知りたいITエンジニア向けの、実務スキル評価サービスです。

CodeIQご利用にあたって
関連サイト
codeiq

リクルートグループサイトへ