三十路から眺める人生地図 - みんからきりまで
とうとうこの時が来てしまった。 僕はあと数日で30代になる。 こんな日が現実に訪れるなんておそろしい。 いろいろと思うことがあるので、20代を振り返りながら近況や今後のことなどを雑多に書いていきたいと思う。 20代の振り返り 二十歳になった日からもう10年が経ったなんて信じられない。今でも憶えているけど二十歳になった時に僕は死にたいと思っていた。 とにかく昔から時間が過ぎていくことが嫌だった。 思えば10代の頃はほぼフルでニート状態の生活を送っており、20歳はちょうど専門学校に通いはじめた歳だ。 周囲の誰もがすぐに挫折するだろうと思っていた専門学校を無事に卒業し、プログラマとして就職した時はもう人生ゴールしたというかこのまま成仏してしまうのではないかという気持ちだった。 kirimin.hatenablog.com その後、1年で最初の会社を辞め、もう正社員になりたくないという後ろ向きな理
自分を見積もるスキル
ITが苦手な経営者と、プログラミング初心者の味方、下駄です。 これまで、サラリーマンエンジニアに対して企業内で教育をしていた時に優秀な人材とそうでない人材の違いで、「見積もり」ができるかできないかという問題がありました。 1. システムの予定見積もりが出来る 2. 設計見積もりができる 3. ビジネスとしての見積もり金額が出せる 会社にいるエンジニアがやるべき見積もりはこの３つぐらいかと思いますが、サラリーマンであるので、給与は昇給査定にまかせている人もおおいかもしれません。 そんなあなたのもらっている給料は、自分を見積もった金額よりも多いか少ないか？という質問をすると、「多い、少ない」という返答は返ってくるけど、明確な内容は返ってこないことがほとんどです。 自分の価値を一番知っているのは自分であるという事は、誰でもそうだと思いますが、今回はそんな自分の見積もりについて考えてみましょう。
101回死んだエンジニア：エンジニアライフ
Staticおじさんを掘り返す今までコラムを書いてきて、「コイツは越えられない」と思ったコラムが一つある。実はオブジェクト指向ってしっくりこないんです！ある意味、エンジニアライフの流れを変えた伝説のコ...
進捗ヤバいプロジェクトに直面した経験がある人なら（多分）楽しめるカードゲーム「Not My Fault!」 - 科学と非科学の迷宮
エンジニアがプロジェクトがオンスケであると嘘をつき続けるゲームは盛り上がった pic.twitter.com/aWkKIPtAAS— Yoshifumi Yamaguchi (@ymotongpoo) 2017年7月30日 @ryushi さんの主催で仲間内で集まってボードゲーム・カードゲームで盛り上がったのですが、その中で @tokoroten が持ってきた「Not My Fault!」というカードゲームが非常に衝撃的でした。 まず、背景設定がすごい。 残り30日で絶対に完成させなければいけないプロジェクトに、プレイヤー達はプロジェクトメンバーとして参加しています。 進捗は絶対に遅れてはいけません。 もし、プロジェクトの進捗が報告されていたよりも進んでいないとしたら？ それはもちろん、進捗を過大報告したヤツの責任です。 監査を入れて、そいつを追い詰めよう！ というのがゲームの設定です。
「ひとりで何でもできるエンジニア」は勝手に育つ:Geekなぺーじ
「スタートアップベンチャーはスーパーエンジニアを求めるけどエンジニア界隈と起業家界隈で想像しているスーパーエンジニアの定義が違う件」という記事が話題です。 その中で、「「ひとりで何でもできるエンジニア」は存在しないと思った方が良い」」として、以下のように書かれています。 「ひとりで何でもできるエンジニア」は存在しないと思った方が良い」 起業家の方が知らない側面として 現在バリバリ活躍しているエンジニアのほとんどが得意領域を持っていて それ以外の分野については出来る人であっても「平均点以上」ぐらいの活躍しか出来ないということです。 そして優秀なエンジニアの方はそのことをよくわかっています。 たまに化け物みたいな化け物がいて物理からインフラからアプリケーションからUI/UX ネイティブアプリ開発からwebマーケティングに資産管理まで全部出来ちゃう人もいますが その人を望む事は「年収1000万の
リクルートテクノロジーズ、「2016年おすすめプログラミング言語」ランキングを発表、初めて習得する人にはどの言語？
リクルートテクノロジーズは、事前調査で「過去に習得または勉強したことがあるプログラミング言語が3言語以上である」と回答した20代～40代のITエンジニア 507名を対象に、プログラミング言語に関するアンケートを実施。一定以上の学習を積んだITエンジニアが「初めて習得」「これから最も重要」と考えるプログラミング言語が明らかになった。 【補足：リクルートテクノロジーズからの「お詫びとお知らせ」（2016/6/20）】 リクルートテクノロジーズは、このアンケート結果を伝えるプレスリリースを「お詫びとお知らせ」（PDF）に変更し、プレスリリースを閲覧した方に多大なご迷惑をお掛けしたとしてお詫びを述べるともに、本件に関する問い合わせ・質問を下記窓口で受け付けている。 株式会社リクルートテクノロジーズ PR 事務局 アウル株式会社内 TEL：03-5545-3888 FAX：03-5545-3887
過去の賢人に学ぶ、インフラ運用チームのマネジメント失敗事例 - Qiita
gumiアドベントカレンダー9日目です。 今回はちょっと技術的なことを離れて、チームマネジメントまわりのことを書いてみようと思います。 1.チーム背景 私の所属しているチームは、主にAWS環境の運用を行っています。 チームメンバーは、ほぼ私が1人で対応していた時期から、数人規模のチームを推移してきました。 「愚者は経験に学び、賢者は歴史に学ぶ」とはよく言ったもので、残念ながら私は完全に前者になってしまいました。 改めて自分の失敗を振り返ると、良書と呼ばれる本には、失敗内容に関連した内容が記載されています。 特に、【Team Geek】の内容は、以前読んだ筈なのに全く実践できていなかったなあと。。。 【参考】『Team Geek』を読んだメモ 今回は、私のチームマネジメント失敗事例やそこから学んだことを徒然なるままに書いてみようと思います。 2.失敗したこと 2-1.メンバーの増加タイミング
理想的なエンジニアでありたい - kurainの壺
前回のエントリにかなり反響があって、友人達が数ブクマして終わりという想定もしていたので、少々驚いている。 エクスキューズを全く入れなかったのもあって、いろんな感想を持たれた。 フワッとした文章で論点もはっきりしてないので、 941 さんのブコメはもっともだと思う。 ただ、一番言いたかったことは、 "プライベートを犠牲にしなきゃ、理想的なエンジニアになれない" って発想が嫌だってことだ。 結構ブコメで"好きだからやっているんだ"っていうコメントが多くて、そんなのは僕も知っている。 僕もコーディング大好きで、なんの制約もなければ体力の続く限りやることもあるだろう。 自分の時間の内であれば、コードを書くのも勉強するのも犠牲なんて思わない。 でも、それでいいの? 持続可能なの?って話なんだ。 独身のひとは、好きなようにすればよいかと思う。その人だけの人生だし。 でも、テレビゲームしたり、漫画読んで
仕様書がない開発が増えた理由 | ScrapEngineer
最近の開発で仕様書等のドキュメント類を書くことが少なくなりました。 私は主に業務系のWebサービスを作成してましたが、最近はオープン系のサービスも受け持つことも多いのですが、仕様書やテストのエビデンスがオープン系のお客様の場合は求められることが少ない・・・ というかほぼない。 何故、お客様は仕様書を求めないのか？ 予算を削りたい お客様にとって仕様書なんて見てもわからないもの貰ってもしょうがない。 貰ってもしょうがないものなら作ってもらわないで、削ってしまおうって考えがあります。 テストのエビデンスも同様です。 これは仕様書の作成やエビデンスの作成に工数が掛かるため、工数の削減を計って予算を削りたいという考えがあります。 例えば、おおまかに計算しますが以下のようなシステムがあります。 開発工数：1人月 検証工数：0.5人月 設計工数：0.5人月 ドキュメント作成工数：0.5人月 管理工数：
[ThinkIT] オープンソース時代の企業システム選択ポータル
2024/3/21 「GNOME 45.5」リリース 2024/3/21 JavaScript/TypeScript対応Webフレームワーク「Astro 4.5」リリース 2024/3/21 ELYZA、700億パラメータの大規模言語モデル(LLM)「ELYZA-japanese-Llama-2-70b」の開発を発表 2024/3/19 Linuxディストリビューション「4MLinux 45.0」リリース 2024/3/17 セキュリティを重視した「Proton mail」のデスクトップアプリケーション発表 2024/3/17 PHP向けWebアプリケーションフレームワーク「Laravel 11」リリース 2024/3/17 「Samba 4.18.11」リリース 2024/3/16 Visional、脆弱性管理クラウド「yamory」のAWS Marketplaceにおける提供開始 20
技術を伝えても、技術者の価値はなくならないという話 - プログラマでありたい
増田で、この記事が話題になっていました。 正社員に仕事を教えたくない 私は今年で契約が切れるパート。同じ部署に昨年、数歳年下の新入社員が配属された。 彼女は私が少ない仕事から数年かけて学び、また効率的に処理できるように試行錯誤して会得したノウハウを、たくさんの仕事の中でどんどん吸収している。これまで私しか使えなかったソフトも、ほぼ同じくらい使えるようになった。 この記事書いた人の仕事の内容はよく解らないので元ネタに対するコメントは差し控えます。一方で、これを見ていたIT系エンジニアのクラスタっぽい人々が、技術職にとっては技術を伝えると自分の価値が無くなるよなぁ的な発言をしているのを幾つか見たののが興味深かったです。なので、ITエンジニアにとっての技術と、それを伝えるということを考えてみました。前提として、ITエンジニアの技術についてです。製造業の技術流出は別の問題だと思うので、対象にしてい
エンジニアは獲るより育てよう、と改めて言いたい。そして経験不問で絶賛採用中 : Nothing is impossible
吉岡さんが「技術系ベンチャーの技術者募集で経験不問とかいうのは、社長がバカなのか、技術者をバカにしているのか。」という発言をしていましたが(公開範囲が全体なので引用)、まったく真逆の考えです。 これまでも事ある毎に主張していたんですが、エンジニアは獲る(採る)ものではなく育てるものだと思います。 みんなこぞって「優秀なことがハッキリわかるエンジニア」を獲ろうとするから、エンジニアが足りない足りないっていうことが起こるし、エンジニアへのハードルが上がるんです。 いま優秀で経験の多いエンジニアだって、最初は未経験だったんです。 それが成長して経験を積んで、今に至るわけです。 ベンチャーか大企業か問わず、素材として良い人材を採用して教育するというのが、会社にもその人にも社会にも良いと思うわけです。 「即戦力のみ採用」より「経験不問」のほうが、バカどころかむしろ志が高いと思いますね。。
業務系エンジニアはどうしていくべきか？ - 急がば回れ、選ぶなら近道
まず超個人的な見解です。あとWeb系の人は関係ないので、そういう人は読んでも無駄です。ここでいう業務系エンジニアというのは、主にSI屋で特定企業向けのシステムを構築しているエンジニアの人たちをさします。 まず、非常に難しい時代になったと思います。 端的に、ちゃんとしたSIをやることが難しくなりました。まず、技術的には面倒なことが増えた、というかできるオプションが制御できないくらいに増えているので、うまく制限をしないとコードや仕組みが劣化する一方になりました。エンジニアリングに自由を！というのは聞こえはいいのですが、チームプレーをするのに、いちいち約束事決めないと回らないようになっているような気がします。それも毎回。始めるたびに。 別段、いきなりチームメンバーの能力があがったり、さがったりするわけではないのですが、なぜか外すと酷いことになる振れ幅が増大したような気がします。ルール決めをいちい
転職したいITエンジニアが知るべき97のこと
元プログラマ、現Web系企業の人事担当者による、エンジニア転職指南。「応募書類の書き方」や「自己PRの仕方」について、エンジニアの視点を持ちながらアドバイス。エンジニアの幸せな転職のために、菌類が奮闘する。 人を泣かせる花粉より、人を笑わせる胞子でありたい。こんにちは、きのこる先生です。ヤツ（花粉）らの破壊力はすさまじいものがありますね。皆さま、いかがお過ごしでしょうか。 さて、本連載もついに最終回です。今回のテーマは「転職したいITエンジニアが知るべき97のこと」。タイトルの元ネタはもちろん、私の愛する“きのこ本”こと、『プログラマが知るべき97のこと』。 前半は過去の連載を振り返った「まとめ編」。転職についてのあれこれをおさらいしてみてください。後半では転職について特に重要なこと――「ソーシャル転職」「面接」「新人エンジニアの心構え」について解説します。 ラブレターは読まれてなんぼ――
第2回 「締め切りは絶対に守るもの」と考えると世界が変わる | gihyo.jp
「締め切りを守ること」の大切さ 今までたくさんの日米のエンジニアと仕事をしてきた。その中には私よりも明らかに「賢いエンジニア」もいたし、ものすごい生産性でプログラムを作ってくれる「馬力（ばりき）のあるエンジニア」もいた。しかし、そんな中でも、私がものを作るうえで最も大切だと考えている「あること」をキチンとこなせる人は100人に1人もいなかった。その「あること」とは、「常に締め切りを守れるように仕事をすること」である。 チームで仕事をする場合、どうしてもお互いが担当するタスク（＝作業）の間に依存関係が生じる。そんなときに、どれか一つのタスクの完了の遅れが、ほかのタスクの完了に波及し、それがタスク間の競合を引き起こして全体のスケジュールがさらに遅れる、という事態はソフトウェア開発の現場ではよく見られる。そんな状況をできるだけ回避するには、プロジェクトに関わる人全員が、自分に割り当てられたタス
夜遅くまで残業する技術者たちへ--身の安全を図るための10の自己防衛術 - builder by ZDNet Japan
あなたも「コンピュータの専門家」という言葉から連想されるステレオタイプなイメージをご存知のことだろう。極めて聡明であるものの、内向的で少し軟弱（他に言いようがない）というものだ。もちろん全員がそうであるというわけではない--しかし、IT分野に従事する人の多くは、護身術の訓練を受けたことがないということも事実だろう。われわれは、自らの身を守ることよりも、ネットワークを守ることに注力している。このため、自らの仕事に熱中するあまり、身の周りで起こっていることに気が付かないということもあり得るのだ。 われわれの仕事の性格上、サーバにパッチを当てるために、あるいは翌日の始業時間までに電子メールを復旧させるために、他の人々が帰宅した後も夜遅くまで仕事をしているということが多いはずだ。その結果、睡眠不足と極度の疲労に襲われ、周囲の状況に注意を払っていない状態で、午前2時に暗い駐車場を歩くこともあるかもし
開発者必見、起きつづけるための5つのテクニック | エンタープライズ | マイコミジャーナル
迫り来る納期に対して連徹を敢行しなければならないというのは、Webデベロッパであれば1度や2度ならず経験のあることだろう。徹夜が必要ないように進捗管理できればそれにこしたことはないわけだが、現実は無情だ。起き続けて作業しなければならないことなんていうのは、この分野ではまま起こってしまう。 そんな状況は世界中どこでもそう変わらない。どうしても夜行生物のように夜に行動しがちになる。最大の敵は睡魔なわけだが、どうやってこいつと戦っていけばいいのだろうか。SitePointにおいてJames Edwards氏がTop 5 Tips for Staying Awakeのもと起き続けるための5つのテクニックを紹介している。要約すると次のとおり。 コーヒーをたくさん飲む - 数時間効果があり精神と身体の双方ともに影響がある。インスタントコーヒーでもいいがちゃんとフィルタで淹れた方がお薦め コーヒーをたく
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
エンジニアのキャリアを考える際に刺さった記事三選
プログラミング言語は「黙って写経」──カーネルハッカー・小崎資広（4） | サイボウズ式
サーバ運用の現場でひたすら監視し続けるエンジニアの手の内のすべて
