ワカモノは悩んでいるらしい 自分は今年で旧エヴァのミサトさんと同い年という感じで若くないせいか、たまに自分より年下の知り合いに会うと、仕事の悩み相談みたいな展開になることが多い。 会社もバックグラウンドも年齢もそれぞれ違う彼らの悩みは多種多様であるように聞こえていたのだが、最近ある共通点に気づいた。「このままじゃいけない」と無意識に思い込んでいる点である。 今以上にスキルをつけなければいけない、成長しなければいけない、ユニークな仕事をしなければならない、など人によって異なるのだが、なぜか「～なければいけない」の思いを持っていた。 そしてもう一つ共通しているのが、その「～なければいけない」の目的が見えないという点である。何となく焦っているのは分かるのだが、その焦って行動した結果によって自分が何を得たいのか。これまで色んな悩み人と会ったが、共通してそれが見えてこなかった。それとなく中長期的な計

「コードレビューをキメると品質も上がるし自分のレベルも上がるので最高」みたいな論が巷を賑わせていて、以前はそういうイケてる制度を指をくわえてみるのみだったのだけれど、最近職場と、それと個人的に関わったプロジェクトでコードレビュー制を無理矢理交渉して導入してみた結果、世間のイケてる書籍やエントリから得られる情報とはまた少し違う知見が得られたので書いてみる。 割と泥臭かったり、あまり希望に溢れてたりはしない感じのエントリなのでそういうのは期待しないほうがいいです。 準備 些末なコードレビューを極力避けるために、コードの規約やスタイルについてはlintとフォーマッターを用意した。 他は無策。 結論 結論から言うと、理想的な運用は出来なかったものの、コードレビューについて世間で言われるような成果（作業を共有する意識、レベルの向上）は得られた。良かった。 ぶっちゃけ僕なんかが浅はかな考えで導入しても

2015.06.03 スキル 社会人になったばかりの若いエンジニアの中には、一度この道に足を踏み入れたからには、自らの技術一本で身を立てていけたらという、強い思いを胸に秘めている人も少なくないのではないか。 そう考えて今回、Rubyの父として知られるまつもとゆきひろ氏に、あえて「これからの時代に技術だけで生き残るには？」という偏ったテーマで取材を依頼した。返ってきたメールの冒頭にあったのが、次の一文である。 「技術だけで生きるというのは幻想である」 まずはその真意を聞くところから、取材は始まった。 まつもとゆきひろさん(@yukihiro_matz) 1965年生まれ。筑波大学第三学群情報学類卒業。プログラミング言語Rubyの生みの親。株式会社ネットワーク応用通信研究所フェロー、一般財団法人Rubyアソシエーション理事長、Speeeをはじめとした複数社の技術顧問、Herokuチーフアーキテ

2001年、17人のメンバーによって アジャイル宣言 が発表されました。私はその立案者そして著者の1人であることに誇りを感じます。この出来事は、何かをする上でより良い方法を導き出すことへの期待、そしてソフトウェアを開発することで世界をより良くするといった、私自身の活力の源となり、極めて重要なターニング・ポイントとなりました。 あれから14年が経ち、私たちは行き先を見失っています。”アジャイル”という言葉はスローガン化してしまいました。本来の意味をなさなくなっただけならまだいいですが、最悪に考えれば排外的な存在になってしまったとすら言えます。2～3のソフトウェア開発のプラクティスを、不十分に生半可に試みるといった”軟弱なアジャイル”を行う人が数多く存在します。本来の目的を忘れて努力を重ねるといった、口先だけのアジャイルの 狂信者 がたくさんいるのです。 更にひどいのは、アジャイル開発手法その

「ここ、こんな感じにできませんかね？」と言われたエンジニアが、「うーん、それはちょっと厳しいですね。できないです」と返すみたいなやりとりは結構見かけます。 この「できますか？」⇒「できない」というやりとりなんですが、「できない」という言葉にはいくつか裏が考えられます。言葉足らずだっただけでちょっとした調整をすればできるよね、というケースもあるので、「できない」という言葉の裏側をまとめておこうと思います。 先に補足しておくと、「エンジニアの人の言葉が足りなすぎるでしょ」という意見ももちろんあると思います。こういうコミュニケーションは、お互いの信頼度によっても変わってくるので難しいところです。お互いが相手に伝わるように意識すべきだと思うんですが、 エンジニアから「できない」と言われた時にどういう意味で言ってるのか想像しやすくなればいいなという思いで書いておきます。 ちなみに、「（できるけどやり

Githubでの開発 - Issue, Commit, Pull Request, Mention, Code Reviewに関する基本的なルール ゴール 「 チーム で 長期にわたって 生産性を上げる 」 前提 みんながサービス・プロダクトについて自主的に考える組織 エンジニア全員がそれぞれオーナーシップを持ってよりプロダクトを良くすることを考える いわゆるPM職の不在 = コードは書かずに、マネージだけする人がいない これは組織による。(e.g. 外注やディレクター職の存在) けれど、Wantedlyは、多少変化しつつも、より良いサービスを生み出すために、役割の程度の差はあれ全員がプロダクトについて考え責任を持ったほうが良いと考えている。 理想型 図:「青と黄色」のチーム構成が従来の縦割り+統括チーム、「緑(金)色」のところが目指すべきマイクロサービスチーム マイクロサービスチームは、

騒動についてはじめに、今回の騒動について語る。ついにスラドに取り上げられたので、以下のスラドを見れば大まかには分かるだろうが、多くの人が事実を誤解していると思うので、釈明したい。 「年功序列などで働きづらい」として転職した元日立社員、転職後「日立のほうが良かった」と後悔して話題に | スラド 現職VA Linuxに入社後すぐ、もう一年前のことになるが、素晴らしい功績をスラドに取り上げられて(第9回日本OSS貢献者賞・奨励賞の受賞者、発表される | スラド)、いよいよ開発者としてキャリアを始めようかという時にこの惨事なので自分の社会不適合性が嫌になる。私は過去にも散々、掲示板やSNSなどでやらかしてきた。しかし私は根っからの異常者ではない。私という人間に興味があって会う人は口々に「ふつうだ」という。ネット社会の私が、完全な異常者なのだ。ちなみにリアルの私は、自己評価になるが、極めて素敵な好青

自分は普段ソーシャルゲームの開発に関わっていますが、群雄割拠のグリモバ全盛期にその開発を効率化するために社内ではいろいろな取り組みがなされました。そのひとつにアプリ別ではなく機能別のチームを作るということがありました。結果としてそれは失敗だったと言えるのでそのことについて書いていきます。 背景 当時のソーシャルゲームの主流はカードゲームで、クエスト・レイドをこなしつつガチャで引いたカードを合成して強化していくスタイルが一般的でした。そしてその多くがシステムはほとんど同じで見た目だけを変えた「柄替え」アプリでした。 その中で行われたのが二つの共通化です。 コードの共通化 今までのアプリでは元のアプリのソースからフォークするなどして別のプロジェクトとして独立させそれに対して各チームが開発を行うと言う感じでしたが、今回の共通化ではゲームのコアとなるロジック部分をサブモジュールとして分離し、各アプ

なんか最近、(比較的)アウトプットしてないな、とふと気づいたんだけど、よく考えたらプロジェクトの進捗のフェーズによってアウトプットの分量が偏るのはいつものことだなー、とも思った。 それらのフェーズを前期、中期、後期、運営期で考えみる。 初期段階 おそらくライブラリの選定段階から始まる。この時期のアウトプットは、いわゆる「やってみた系」の記事が増える。ウェブに出る記事だと、これが大多数をしめる。汎用性が高く、技術的に挑戦的なものが多い。(立場的な話をするとQiitaはそういう記事がたくさん共有されると助かる) 選定が終わった段階で、アーキテクト的な役割の人は、たぶんこうあるべきだ、みたいな思想を形成する。それをクラス図やコード規約や役割に応じたドメイン特化基底クラスとして表現したりする。DDD的なアレならこれをユビキタス言語の構築としてプロジェクトを通してやるべきなんだろう。 使う予定のフレ

就職活動の一環として、東京のとあるゲーム会社にゲームプログラマーとしてインターンシップをしてきました。一ヶ月間、会社の一員として仕事をし、もし付いていけるようだったら内定を出すという条件です。 前日 上京してきて一日目、その日は台風でした。 就職活動でよく東京に訪れていたのですが、私が来る日はよく天気が荒れたり、大雪が降ったりと、まさに雨男というべき存在。25キロのスーツケースを持って、上京2日前に契約したマンスリーマンションに辿り着きました。なぜギリギリになって契約することになったのかはあえてここでは語りません。マンション付近には歩いて30秒のコンビニエンスストア、また5分ほど歩くとスーパーマーケット、100円ショップ、薬局、駅も徒歩10分圏内のところにあり、立地条件として最高でした。そして部屋にも家具が一式ついており、風呂・トイレが別で、一ヶ月間暮らすだけとはいえ、贅沢すぎるほどです。

2. よしだたけひこ • フリーランスエンジニア歴10年ほど • 去年までJavaエンジニアとして10年以上活動 • レベルは下の上〜中の下 • 今年からフロントエンドエンドエンジニア

中堅SIerを経て2009年にドワンゴに中途入社。複数のシステムの開発に携わった後、エンジニアの生産性を高めることをミッションとする部署の立ちあげに参加する。趣味はプログラミングとネトゲ。 ドワンゴ清水俊博氏にドワンゴのエンジニア文化について聞いた。2012年4月の第1回「ニコニコ超会議」の後、ドワンゴのエンジニアが大量退職するという危機的な時期があった。エンジニア文化を立て直す社内組織に参加した経緯を聞く。 ──転職のきっかけはコミュニティ活動とのことですが、当時参加していたコミュニティjava-jaの雰囲気をお聞かせください。 java-jaでは、スキルがある人たち、技術力がある人たちに囲まれていました。ヨシオリ（java-jaを立ち上げた庄司嘉織氏、清水氏の元同僚）も当時はSI業界にいて、互いに話をして共感しあい、友人になりました。 java-jaは、ヨシオリが「勉強会」という呼び名

「アジャイル」という言葉が一人歩きしてしまっていて、たまに話をしていても通じないときがあります。 それくらいアジャイルという言葉が広く知られるようになったんだと思う一方で、かえって話が通じなくて、もどかしく感じることもあります。だからといって、そこで「正しいアジャイルとは」みたいな議論をしたい訳でもないのです。 広まれば広まるほど、そういった言葉の認識の齟齬が出るのは仕方ないですね。その正しい定義みたいなところを追求するのもナンセンスなので、そんなつもりはないですが、ただ自分がどう考えているかについては書いておいても良いかな、と考えました。ここは私のブログですしね。 そこで、この記事では、私の考えるアジャイル開発の本質について、そしてウォーターフォールとの違いについて書きました。 アジャイル開発では機能を全部つくらない これまで私の中で、アジャイルと言えば当たり前の前提がありました。それは

Photo by Financial Times 今回のpaiza開発日誌は片山がお送りします。 仕事柄色々なITエンジニアの方と話す機会があるのですが、全般的にエンジニアは技術面についての探求は強いけれど、自分のキャリアについての探求はわりとのんびりしている方が多いのだなと思う事が良く有ります。また、そのあたりで働き方の面で少し損しているかも、と感じる事があります。 エンジニアは、どうしたら自分のスキルを生かして自分のやりたい開発を続けることができるのか、夢を叶えられるのか、そのためにはどのようにキャリアに向き合ったらいいのかについてまとめてみました。 ■キャリアは自分で考える時代 少し損をしているなと思った例で言うと、、、 とりあえず開発できればいい⇒常駐や保守メインの仕事 30代半ばで初めての転職、かつSI、組み込み⇒Webなどの業界チェンジ それぞれ結構レベルの高い方です。１のタイ

まつもとゆきひろさんが弊社の技術顧問に就任する事となりました。せっかくなので、「ベンチャーの重要性」「世界での勝ち方」「SIerのヤバさ」「モルモン教とエンジニアリング」など、まつもとさんに色々聞きたかった事をぶつけてみました！ VASILY Officeにて 質問 我々は、小さい会社ながらも技術によって世の中にインパクトを与えようと頑張っています。 他にもそういった会社が増えていますが、思う所など教えてください。 まつもと その逆は大企業とかだけど、関わっている人が多くなればなるほど、辛くなりますよね。 僕はビジネスマンじゃないので、エンジニアが幸せかどうかしか分からないけど、自分で決められないエンジニアは不幸なんですよね。 この技術の方が絶対いいのに、「上司が説得できないから従来のやり方で頑張りましょう」みたいな空気で腐りながらやるのは、エンジニアにとっては不幸なんですよね。 小さ

フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発

Photo by Joi 今回のpaiza開発日誌は片山がお送りします。 今後も技術（開発）を中心にエンジニアとしてのキャリアを歩んでいきたいなと考えている方向けに最近騒がれているフルスタックエンジニアとは何か、という事と、何故今後フルスタックエンジニアしか生き残っていけないのか？という事について書いてみました。 ■最近よく見かける【フルスタックエンジニア】とは何か？ まずStackって何だろう？、というところで海外の記事などを読むと"LAMP stack"という言葉が良く出てきます。LAMPの場合、OSはLinux、WebサーバはApache、データベースはMySQL、プログラミング言語はPHP(もしくはPerl、Python)という形で組み合わせたものの事を言います。つまりOS、Webサーバ、DB、プログラミング言語の組み合わせ≒積み重ね、なのでStackという事のようです。こういった

今回のpaiza開発日誌は片山がお送りします。 現在日本で転職をしようとすると、書類選考後面接、というのが一般的な選考プロセスで、エンジニアの採用でも同様のプロセスがとられている企業が殆どです。 しかしコードを書けるエンジニアを採用したいのであれば、まずコードが書けるかどうかを見極めて、そのあと面接したり履歴書を見たりする方が理にかなっていると思わないでしょうか。技術に自信がない人は違うかもしれませんが、エンジニア側としても喋りや書類などによるアピールよりも、技術力でアピールできた方が良いでしょう。 徐々に状況は変わってきていますが、考えてみると当たり前と思えるエンジニア採用時の技術力チェック・プログラミング面接という事がなぜいままであまり行われてこなかったのでしょうか。今回はその辺りについて考察してみます。 Twitter、Googleの採用選考は技術面中心 毎度シリコンバレーが比較対象