今の職場で働きだして少し経つが、既にエンジニアとしての自信を割と失っている。 俺は自分のことを少なくとも「そこそこのエンジニア」と思っていた。でも今の職場では、俺は下から数えた方が早い。「技術は有るが人間的にはクソ」と自負していた俺は今「技術者としても人間としてもクソ」となりかねない事態に陥っている。 言い訳の材料はある。周囲のレベルが高いのだ。 自分で言うのもなんだか経歴は豪華な人が集まっている。コアメンバーは最高学府(あえて誤用)卒はザラだし、某世界時価総額トップとか某金融会社とか某大手ゲーム会社に居たとか、某ソシャゲーの幹部とか、あのフリマサービスを作ったとか、別会社の元CTOでしたとかはたまた現役CTOやってますとか集えば、下流エンジニアも皇帝、四天王、１０傑（俺含まない）などの超一流だ。 文系で有名企業どころか正社員歴すらなく、名のしれた商品やサービスに協力会社の人間としても一度

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

今回は、牛尾さんの記事『「Be Lazy」を極めるためには残業をしてはいけない』にインスパイアされて書きました。 私たちのように小さな会社が大きな成果を出すためには、無駄なことはしていられません。時間に対して高いパフォーマンスを出す「時間対効果」の高い働き方を徹底する必要がありますよね。 この記事では、私たちのチームで「時間対効果」を高めるために、前提においている働き方の価値観やマネジメントについて書いてみました。 時間をかけすぎてはいけない 中途入社で入った人がやりがちなのが、頑張りすぎること。いや、頑張ることは良いのだけど、時間をかけて成果を出そうとしてしまう。しかし、それでは「時間対効果」で見ると低いです。 私たちのチームでは「ふりかえり」で、仕事の進め方についてメンターがレビューをしますが、最初の頃に指摘するのが、沢山働いて成果を出そうとすることについて。限られた時間の中で、どれだ

先週の4月2日(土)に浜松市で、合同シンポジウム「サプライチェーン戦略とプロジェクト・マネジメント」を開催した。主催はOR学会・日本経営工学会・スケジューリング学会で、その配下にある「サプライチェーン戦略研究部会」（主査・日本IBM 米澤隆氏）と、わたしが主査を務める「プロジェクト＆プログラム・アナリシス研究部会」が実行主体だ。 講演者には、倉庫管理システムiWMSの開発元として有名な(株)フレームワークスの渡辺重光会長と、ヤマハの曽根卓朗主席技師のお二人をお招きした。お二人の話はどちらも非常に興味深いもので、渡辺氏はロジスティクスとIoTの広範な展望を話され、曽根氏は通信カラオケの製品開発を題材に、生々しい体験をお話しいただいた。最後にパネル・ディスカッションを行い、わたしもパネラーとして参加した次第だ。 幸い大勢の方に来ていただき、立ち見が出そうになったので椅子を補充したほどだった。製

【ウェビナーレポート】クラウドテックワーカーさんもご登壇！ベテランフリーランスの時間の使い方、自己投資について伺うウェビナーを実施しました

プログラミングのやる気を出す方法について。 システム開発作業での「モチベーション維持」は，死活問題だ。 IT業界の問題ゆえに，やるきを失ってしまいかねない。 プログラマのやる気を奪う原因： 仕様変更などで手戻りを繰り返し，せっかくの苦労が無駄になるため。 人の役に立って，ほめられ感謝される，という経験が少ないため。 SEと比べて，プログラマの地位が低いこと。 プログラマがやる気を出す方法： チャレンジ系のプログラミング動画を見る。（１時間でテトリスを作る！など） 自分の書いたコードをWeb上・ブログ上にさらしてフィードバックを得る。 「はてブ」の人気エントリを定期的に見て，世の中のITの流れをつかむ。 「ワクワクする目標」を再確認。 ドーパミンなどの神経物質を増やす。 音楽を聴く・体を動かすなど。 参考： やる気とモチベーションは関係ない - 書架とラフレンツェ http://lafren

プログラマーとして就職するならその会社の体質として技術理解度がどれほどかという点はしっかり見た方がいいです。 営業畑出身の人ばかりが経営陣にいる会社やシステム構築の外注率が高い会社は、総じて技術理解度・技術者に対する理解が低い傾向にある気がします。 工数の感覚が合わない テストの重要性が理解できない 新しい技術への関心の違い 企業の口コミサイトを見たほうが良い 工数の感覚が合わない プログラミングについての理解が浅い人がプロダクトマネージャーだったりすると、ほとんど実現不可能な工数での開発を求めてくる輩がいます。 ５ヶ月位は見積もらないといけない案件だったとしても、３ヶ月でやってくれとか言われてげんなりします。 なんとかその工数について摺り合わせを行って機能削減などで工数の折衷案を取り付けたとしても安心できないです。 開発中の突然の仕様変更、新規機能追加などが舞い込んできます。 別にそれ自

(訳注: 2016/3/2、頂いたフィードバックをもとに記事を修正いたしました。) Ruby on Railsは最近、急激に注目を集めていますが、その原因はほとんど、この言語が斬新なテクノロジーとしてもてはやされたことと、タイミングにあります。技術的な優位性は時間の経過とともに失われますから、タイミングがよかっただけでは、一過性のブームに終わり、このムーブメントの隆盛は長続きしません。従って、「Railsがいかにして、適切な技術としての位置を維持し続けるるだけでなく、影響力とコミュニティを拡大し続けてきたのか」をより多くの人に説明していく必要があります。そして、その維持・拡大を可能にした/していく要因は、物議を醸すことさえあるRailsの基本原則にあると考えています。 この基本原則はここ10年ほどの間に進化を続けてきましたが、最も強固な柱となっているルールはやはり、公開当初から制定されてい

Top 30 Books on Amazon Based on Links in Hacker News Comments 面白いことを調べる人がいるものだ。テック系ニュースサイトとしておなじみ Hacker News におけるコメント欄で紹介される数の多い本を30冊選んでいる。 調べてみたら、だいたい邦訳が出ていた。やはりプログラマのニーズに違いはないということだろうか。邦訳のあるものを紹介数が上のものから並べておく。 アントレプレナーの教科書[新装版] アルゴリズムイントロダクション 第3版 第1巻: 基礎・ソート・データ構造・数学 (世界標準MIT教科書)、アルゴリズムイントロダクション 第3版 第2巻: 高度な設計と解析手法・高度なデータ構造・グラフアルゴリズム (世界標準MIT教科書) 影響力の正体 説得のカラクリを心理学があばく ピープルウエア 第3版 CODE コードから見た

新田です。 最近渋谷区の条例で同性パートナーシップの証明書が発行が話題になったり、各所で 多様性 という言葉が注目を集めてますよね。 「指示待ち人間」はなぜ生まれるのか？ 有能な人たちが「働きたくない」と嫌がる会社の特徴。 また最近Facebookで上記のような記事をよくみかけまして、ダイバーシティ・マネジメントについて自分でも考えていることや、同じような壁にぶつかった経験があるので久しぶりに投稿してみようと思います。 エンジニア社員「これから週3回、昼過ぎに仕事抜けてジムに行きたいんだけど。」　僕「」 タイトルにしてみましたが、今からちょうど一年前ぐらいに実際に社内であった出来事です。弊社で働いているカナダ出身のエンジニアの社員から、或る日突然このような提案を受けました。 会社の業態、職種にもよるとおもうのですが、殆どの場合 「え、ちょっと何言ってるかわからないんですが。。」 となって

2015年11月10日に某社の社内勉強会で、「強いチームの作り方」というテーマで話をしたのでその際の資料を公開しておきます。 内容自体は、WEB+DB PRESS 83号に書いた内容なので興味があればそちらを参照ください。 最近DevOpsの文脈ですぐに「インフラ自動化しないといけない」とか「ツール使って効率化」みたいな話を頻繁に聞きます。 が、端的にいえば、「実際のところ、ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである」というデマルコの一節の通りであり、 DevOpsの本質もツールではなく、CLAMS(Culture、Lean、Automation、Measurement、Sharing)であって、土台となるのはやはり組織やチームの文化になります。 一度自分たちのチームや組織について考えてみるとよいと思います。

こんにちは、ITプロマガジンです。 Web業界の需要が増加する昨今、ITエンジニアの需要は増加し続けています。 ある程度の実績と経験を持つエンジニアのなかには、独立や起業をお考えの方もいらっしゃるでしょう。 そのような方のためにこの記事では、ITエンジニアが起業に向いている3つの理由や目指すべき事業モデル、独立・起業に必要なスキルなどを解説します。独立や起業を検討しているエンジニアの方はぜひ参考にしてください。 「案件はたくさんあるはずなのに、なかなか自分の望む案件が見つからない…」 エンジニア市場は売り手市場であるものの、いまだに正しいマッチングノウハウが確立されておらず、多くの方が案件探しに苦労されています。 ですが、現在の市場感や企業側に刺さる経験・スキルを理解し正しく案件探しをすれば、誰でも自身のバリューを活かし単価を伸ばすことができる、というのも事実です。 ITプロパートナーズで

フリー写真素材ぱくたそ エンジニアの「できない」とははじめに、この記事で伝えたいことは、「ビジネスサイドとエンジニアサイドの目線をしっかり合わせよう」ということです。そのために、ビジネスサイドとエンジニアサイド、両方からどういう歩み寄りが必要かを考えてみます。まず、エンジニアとの会話ででてくる「できない」という言葉。だいたいできます。しかし、できないという言葉には意味があります。というか基本的にトレードオフになっています。じゃあ具体的にどういうトレードオフがあるのか、今思いつく限りあげてみます。・難易度が高い ・時間が足りない ・今実現するには機能不足・他に問題が発生する・その機能、意味ない・めんどくさい 難易度が高い・難易度とは、チームのスキルに対しての開発難易度・解決法1、その要件を満たせる代替案・解決法2、チームのスキルUP難易度が高いというのは、あくまでチームのスキルに対しての開発

ここ３ヶ月ぐらい同じRails案件でリードエンジニアとして仕事をしています。 何気にマネジメント的なことをやるのが初めてだったので色々と戸惑うことがありましたが、だいぶ慣れてきて知見が溜まってきたので、自分のしごとの振り返りも兼ねてまとめておきます。 リードエンジニアのお仕事とは 会社やチームによって全くと言っていいぐらい異なると思いますが、私の場合は以下の様なことをしてきました。 開発スタート時 要件確認 仕様書を読んで全体像やどこから着手するかなどを考える Railsアプリのベース部分の実装 rails new DB周りの設定 初期モデルクラスをDB定義に基づいて作成 factoryも使いそうなものについてのみ作成 rspec、rails_config等諸々の設定 ローカル環境動作用のseedsを整備 使いたいGemを追加 共通で使うCoffeeScriptのライブラリを思いつく限り実

Photo by Indi Samarajiva こんにちは、谷口です。 「ITエンジニアは業務時間外にも勉強をすべきなのか」という問題について、皆さんはどう思われますでしょうか。 少し前には、こちらの記事も話題になりましたね。 業務時間外で勉強をしなければいけない理由：101回死んだエンジニア：エンジニアライフ 今回は、そんなITエンジニアの業務時間外での学習について考察していきたいと思います。 ■企業からの「教育」と自分でする「学習」 業務で必要な知識等について、企業側もある程度は「教育」をすることがあるかと思います。特に新卒の場合、新人研修として業務知識を学ぶ期間が多くの企業で設けられているかと思います。仕事で必要な業務知識に関しては、企業の研修を受けるだけではだめなのでしょうか。 まずは、「教育」と「学習」の概念について考えてみましょう。 「教育」とは、組織の求めるスキルを個人に習

こちらの記事をリスペクトしつつ、2015年度のエンジニアの新人研修をまとめました。一部自社が関わったものもありますが。。 oranie.hatenablog.com なお、最後に追記しています。 株式会社ドワンゴ様 ch.nicovideo.jp 昨年、一昨年に続いて公開されています。KADOKAWA入社の非エンジニア職種も混ざった研修とのことで、研修内容やグループ分けなどを工夫されています。 株式会社ハートビーツ様 heartbeats.jp CTOの方が執筆した書籍を利用した研修とのこと。書籍自体も新人研修の内容をもとにしているとのことで、未経験者が学びやすい順序で必要なトピックを学習できることでしょう。 面白法人カヤック様 tech.kayac.com tech.kayac.com tech.kayac.com こちらも毎年新人研修の内容を公開されていて参考になります。特に先輩社員の

Photo by Armando Sotoca こんにちは。谷口です。 「業務経験は少ないけど、ITエンジニアとして転職がしたい」という方や、「プログラミングを独学で習得したのでITエンジニアになりたい」といったご相談を受けることがあります。 開発業務経験の少ない方、エンジニアを目指す新卒/既卒の方々にとって、作っておくとアピールになるのが、自分で作ったシステムやアプリなどをまとめたポートフォリオです。 ここで言うポートフォリオとは自分の能力を周囲に伝えるための自己作品集のことです。企業にこれまで自作したものを一覧で見てもらうことができれば、自分のスキルをアピールすることができます。 特にSIからWEB、受託から自社サービス開発といった感じで分野を転向しての転職を目指す場合は、ポートフォリオがあると有利です。例えば「業務でのWebサービス開発経験はありませんが、自分でこのようなサービスを作

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

こんにちは、技術部 高井です。 春といえば、フレッシュマンの季節ですね。このブログを読む方の中には、明日からエンジニアとして新社会人になるという方もいらっしゃるのではないでしょうか。クックパッドでも新しい仲間を迎えるための準備をしていたところで、その準備の一環として「新卒ソフトウェアエンジニアのための技術書100冊」というものを作成しました。 この100冊は、職業ソフトウェアエンジニアとしてキャリアを積むにあたって、読むべき技術書に悩んだら、まずはこのリストから選ぶとよいのではないでしょうかという提案です。 リストに多少の趣味や主張がはいっているのは、まあご愛嬌ということでお許しいただければとおもいますが、職業プログラマとして知っておくべき知識を網羅できるように心がけました。古典と呼ばれる名著についてはできるだけ取りいれ、独習が難しい難解なコンピュータサイエンスの教科書は避けています。これ