エンジニア不足はいつまで続くのか（メモ） - yoshidashingo
吉田真吾（@yoshidashingo）です。フリーランスでたくましくやってます。 本日は後ほどこちらにエンジニア代表として参加予定です。 ll.jus.or.jp そこでこんなお題を事前にいただいてます。 Web業界に特有の人材不足の原因とは 人材不足はいつまで続くのか どうすれば解決するのか、あるいは取り組んでること 頭の整理も兼ねて一通り自分の考えを記載しておきたいかなと思います。統計などとの突き合わせはできてませんので、経験則に基づく仮説レベルになってる点はご了承ください。 Web業界に特有の人材不足の原因とは 1. Webに対するニーズに人材供給が追いついてないのではないか説 今回のイベントのお題ではIT業界の中でもとくにWeb業界にフォーカスしています。ITにおけるWeb業界というのは生まれてここ20年くらいの業界です。その前にはそもそもWeb上でのマネタイズがされてなかった（
気が狂った設計 - hitode909の日記
大きめのこととか，自信のないところを触るときは，コード書く前に，こういう作戦考えてみたけどどうですかって聞いてみたり，こういうことやりたいんだけど一緒に考えませんかって，いっしょに話して設計考えたりするとよいと思う． 一緒に考えたすぐあとに気が狂った設計とか言い出したらおかしいので，未然に変な設計のままコード書いてしまうのを防げる． 特に辛い気持ちになるのが、「気が狂った設計」「クソコード」「（こんな実装は）有り得ない」といった言葉だ。 Pull Requestのレビューが辛くて会社をやめたい 単に言葉が強いのはよくないと思う．我が社にはそんな強い言葉でレビュー書く人はいない． 我が社には，普段から強い言葉を発する人もいなくて，みんな物腰柔らかな変な言葉を話している． 言葉使いや文体は，ずっと過ごしてると同僚から移ったりするので，普段からそういう言葉を話していると，全体の雰囲気も悪くなりそ
7年働いた時点での私の仕事の極意 - Kengo's blog
最重要 実行に重きを置く やらないで後悔するよりも、やって反省する。 反省は成長を産み生産的だが、後悔は精神の無駄な消費。 時間は有限で貴重な資源だが、たぶん今の段階では行動する前に得るものや結果を予測するのは難しい。 正しい反省の方法とは何か、考え続けること。 「正しく反省するために、何を記録しておくべきか」実行前に明らかにしておくこと。 反省の結果は組織的な何かに落としこむ。組織構造、戦略、静的解析、自動テスト、教育など。意識しないでも巨人の肩に乗れる状況を作ることが、組織の成長につながる。 Done is Better Than Perfect ただし、思考停止の言い訳にしないこと。詰めの甘さを擁護する言葉ではない。詰めの甘さは立場や考え方が違うひと3人くらいに意見を求めればだいたい炙り出せる。 長期的視野を持ちつつ、それに引っ張られない。進展を作ること、現状を少しずつ変えることを意
ソフトウェアエンジニアがたどる成長過程と失敗の行きつく先 | POSTD
これからご紹介する私の試みはなかなか難しい側面があり、物議をかもすかもしれません。また、お見せするのは初めてなので完璧とは言えないかもしれません。私はソフトウェアエンジニアのスキルとその影響力を評価するシステムを開発しようとしています。少なくとも、プログラマが成長していく理想的な成長過程を大まかに描いてみようと思います。評価スコアは0.0から3.0まであり、それぞれの数字は専門能力を開発していく際の出発点を表しています。 このシステムは主にビジネスの観点から見た、ソフトウェア業界が求めるものに基づく 実務的な スケールです。数学的な才能や高速アルゴリズムを書く能力、Linuxカーネルの内部構造に関するプログラマの理解の深さなどを評価するスケールではありません。もちろんこうした能力は重要ですし、通常、エンジニアのスキルとともに伸びていく能力ですが、私のシステムが焦点を当てたいのはそこではあり
CodeIQについてのお知らせ
2018年4月25日をもちまして、 『CodeIQ』のプログラミング腕試しサービス、年収確約スカウトサービスは、 ITエンジニアのための年収確約スカウトサービス『moffers by CodeIQ』https://moffers.jp/ へ一本化いたしました。 これまで多くのITエンジニアの方に『CodeIQ』をご利用いただきまして、 改めて心より深く御礼申し上げます。 また、エンジニアのためのWebマガジン「CodeIQ MAGAZINE」は、 リクナビNEXTジャーナル( https://next.rikunabi.com/journal/ )に一部の記事の移行を予定しております。 今後は『moffers by CodeIQ』にて、 ITエンジニアの皆様のより良い転職をサポートするために、より一層努めてまいりますので、 引き続きご愛顧のほど何卒よろしくお願い申し上げます。 また、Cod
はてなMackerelチームの開発フロー（スクラム、リモート）について話しました #nanapi_study #hatenatech - 詩と創作・思索のひろば
nanapi勉強会 vol4 - 【nanapi x はてな】はてなとnanapiの開発フロー - nanapi勉強会 | Doorkeeper 【nanapi x はてな】はてなとnanapiの開発フロー in Kyoto - connpass nanapi さんとはてなで開催した勉強会に登壇し、東京・京都で Mackerel チームの開発フローについて話してきました。自慢できるようなカッコイイことをやっているわけではないけれど、今こんな風に頑張っています、ということをお話したつもりです。 Workflow at Hatena Mackerel Team // Speaker Deck チームみんなで勉強する スクラムの導入時もリモートワーク開始時にも、チームメンバーには何冊か本を読んで予習しておいてもらいました。そうすることでチームメンバー全員が同じだけの知識を持って（全員その道に関し
ゲーマーのエンジニアが転職先としてソーシャルゲーム業界を選ばない理由 - mizchi's blog
今回の転職にあたって、各方面から「なんでゲーム業界にいかないの？」と何度も訊かれたので、書いておく。 僕のキャリアはソーシャルゲーム業界から始まって、教育の会社にいって、次はxxxだ。転職先に関しては後日。 僕はそもそもスーパーファミコン時代にスクエニ黄金期の洗礼を受けた古い気質のゲーマーで、ソーシャルゲームを一切楽しめない人間で、ソーシャルゲームに開発として関わった人間でもある。バイアスが掛かっているのは認める。 古巣がどうこうって問題ではなくて、業界全体の問題なので、そこらへんは誤解しないように。 ソーシャルゲーム業界 今のソーシャルゲーム業界の開発現場は、開発の現場が「面白いゲームを作ろう」というモチベーションにはなりにくい。 感覚として、ソーシャルゲームってのは「課金させる場」を作ることであって、面白いゲームを作ることはあまりフォーカスされない。 それを言えばコンシューマだって売り
「失敗を活かす」を実現する仕組みづくり - ワザノバ | wazanova
http://vimeo.com/94950270 1 comment | 2 points | by WazanovaNews ■ comment by Jshiike | 約2時間前 ミスを許さない組織って嫌ですよね。月曜日の朝に会社に行くのがとにかく苦痛だった時期があります。しつけ的な規律をもたらすという一定の効果はあったかもしれませんが、ミスをしないように、しかられないようにするために仕事の進め方が最適化されていって、顧客がどう思うかよりは、上司の顔を伺うところに皆が全力を注ぎはじめます。 そんな会社は反面教師に。また最近は、blameless postmortem（個人批判をしない建設的な障害の振返りミーティング）というのも流行言葉。「そうだそうだ、もっと前向きであるべきだ。」と思いつつ、しかし難しいのは、ユーザに悪影響を与えるものを減らそうとする気持ち。その気持ちを持つことが
2014年夏、カヤックは、Go言語を積極的に推進していきます。 | 面白法人カヤック
カヤックは今後、積極的にGo言語を推進していくことになりました。7月末までのGo言語での実績一覧です。 https://github.com/kayac/alphawing https://github.com/kayac/parallel-benchmark https://github.com/acidlemon/go-dumper https://github.com/fujiwara/zabbix-aggregate-agent https://github.com/fujiwara/go-zabbix-get https://github.com/fujiwara/go-redis-setlock https://github.com/shogo82148/androidbinary https://github.com/mix3/go-irc https://github.co
科学者が書いた質の低いコードが、ベストプラクティスに則ったコードに勝る理由 | POSTD
今ちょうど、 科学者の手によるコードは質が低い という投稿を読み終えたところです。科学者の書いたコードは”ソフトウェア・エンジニア”が関与したコードと比べて質が劣るという内容でした。 私は10年以上同じ職場に勤めていますが、同僚の多くは数学や物理学が専門で、”ソフトウェア・エンジニアリング”の知識はほとんど持っていません。 そこでは、大惨事は必ずと言っていいほど、自分のことをいっぱしのプログラマだと思っている少数派によって引き起こされます。かくいう私も、少なくとも数件、いまだ解決を見ていない大きな不具合の原因を作ったことがあります。他にも大きめのバグをいくつか出しましたが、幸いその時のコードはお蔵入りしたため、私に無駄な給料を払わされた雇い主が被害をうけたくらいで、同僚の生産性を大きく損なうことはありませんでした。 その度（少なくともほとんどの場合）私は反省し、それまでにも増して退屈なくら
運用エンジニアから開発エンジニアになるためにやったこと · As a Futurist...
Web の会社でエンジニアを始めて 4 年、ずっと運用エンジニアをやってました。運用とは端的に言うと、社内外の他人が作ったソフトウェアを期待通りに動作させるためのエンジニアリングだと思ってます。アプリケーションはもちろん開発者が作ったものですし、MySQL や Apache や Linux も全部他人が作り上げたソフトウェアであり、それらの設定を変更したりパッチを当てたり運用ツールを駆使することで、協調動作させることに磨きをかけてきました。 ただ、いつまでたっても他人の作ったものの面倒を見てることには変わりないし、運用ツールを開発したところでそれはあくまで誰かが生み出す価値のサポートにすぎないのが自分的には満足できなくて、ずっとアプリケーション(ビジネスロジック)が作りたいと思ってました。 で、今年の始めからたまたまタイミングよく新規開発の部署に入ることになって、いきなり開発者をやることに
開発を短い時間で集中して毎日やる
今年に入ってから毎日の開発時間を去年の半分にしてみた。 すると、毎日凄く集中できて、空いた時間に頭にスペースが出来てアイデアもわきやすく、効率もよくなったのでこれはいいかも。 タレブとDHHの話がきっかけ 最初のきっかけは、Rails作ったDHHが「開発なんて長時間やっても逆効果だから毎日の仕事時間を減らせ。8時間じゃなくて5時間、4時間だけにしろ。それだけ短かったらSNSなんて見てる暇はない。」とスタートアップスクールで話してたこと。 あと、去年タレブのAntifragileという本を読んで、短い仕事時間を毎日やるのが長期に渡っていいパフォーマンスを出す秘訣だというような事を言ってた。 アップストアでアプリを出すのは、結果が出なければ開発時間をいくらかけても価値が０となる世知辛い世界。でもこれは完全成果主義でなかなか面白い。 毎日の開発時間の成果をいかに上げるかっていうのを考えていると、
テスト自動化研究会 - 4時間で学ぶ、効率的な自動テストスクリプトのメンテナンス
オープンソースのブラウザテストツール「Selenium WebDriver」の使い方と、テストスクリプトを効率よくメンテナンスする方法について、実際にプログラムを書きながら学べるチュートリアル形式教材です。 前半は、Selenium入門ドリルです。基礎から丁寧に解説されているので、Seleniumは初めての方でもテストが書けるようになります。 後半では、テストのメンテナンス効率をあげるための技法「ページオブジェクトデザインパターン」の習得を目指します。こちらも基礎から解説していくので、Seleniumが初めての方でも大丈夫です。 プログラミング言語Javaでテストスクリプトを作成するので、Javaで基本的なプログラムが書ける必要があります。 自習教材として利用する場合 前提知識・事前準備手順ドキュメントの手順に従い、必要な事前準備とインストールを完了させます。作成したEclipseプロジェ
スマホUI考（番外編） UIやUXを劇的に改善する、『ビッグオー駆動型開発』とは | fladdict
いま『ビッグオー駆動型開発』とよばれる開発手法が、業界の一部で注目を集めている。 その理由は非常にシンプルだ。『ビッグオー』は非常に安価で簡単な手法でありながら、従来の開発手法に比べ劇的にUIやUXを改善できるためである。 製品コンセプトのような上流から、ボタンのレイアウトといった下流工程、さらにはグロースハックやプロモといったリリース後のフェイズまで一つの手法でユーザビリティを評価できる。この汎用性がビッグオー駆動開発の大きな特徴であり、導入時の利点となる。 今回はこのビッグオー、の概要と具体的なやり方について論じたい。TwitterのUI拡張予言以来、久しぶりのUI系エントリである。 ビッグオー駆動開発とは何か？ ビッグオー駆動開発は、正式には『OKAN Driven Development（オカン駆動型開発）』とよばれる開発手法である。 これは自分のオカンを指標とすることで、低コスト
若いエンジニアへ
エンジニアなら誰でも突貫工事に喜びを見出した経験がある。深夜2時の夜食を共にした同僚のことは、その職業人生を通じて忘れることはない。しかし、そこにいかなるドラマがあろうとも、突貫工事は例外である。これを常態としてはならない。 メーカーの組込みプログラマとしてエンジニアのキャリアをスタートした私は、「よい製品はよいプロセスから生まれる」ことを頭に叩きこまれた。素晴らしい製品を生み出す工場は静かである。常に誰かが大声で叫んでいるような工場には明らかにプロセス上の問題が認められ、素晴らしい製品を生むことは決してない。 本物のエンジニアは突貫工事を好まない。突貫工事とはプロセス上の誤りであり、つまり誰かが大声で叫ばなければならないということだからである。エンジニアの仕事は計画され、コントロールされたものでなければならない。 長時間労働によって成果を生み出そうとすることも、やはり例外としなければなら
Webサービス開発現場から / 近頃の開発のやり方 ･･･ Github と Pull Request とコードレビュー - naoyaのはてなダイアリー
先日プレスリリースが出たのですが、KAIZEN platform という会社で技術顧問などをやっています。それから、一昨日自分も出たWebアプリケーション開発に関する勉強会 (資料) を開いたじげんという会社でも少し前から同じように顧問のような形で携わっています。 自分が関わっている会社のPRも含めて、すこし、2013年現在のWebサービス開発の現場感、やり方みたいなものを書いてみたいと思う。ただ、自分の利益があるところの話だけではフェアではないので、Webエンジニアならよく知っているであろう Qiita を運営しているインクリメンツの様子も合わせて紹介する。 KAIZEN platform KAIZEN platform が提供しているサービスは planBCD という A/B テストの SaaS で、Webサイトのコンバージョンだとかを画面の構成要素を変えて効果測定したいとか、そういう
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
コミュニケーションツールとしての Git & GitHub
crocos.jp