良いエンジニアの育て方 - ひがやすを技術ブログ
人を育てるというのは、とても難しい。 なぜなら、育てる方も未完成な人間だから。 ちょっと経験値のある未完成な人が、経験値の少ない未完成な人と、ともに冒険をし、ともにレベルをあげていくことが、人を育てるってことだと思う。 人を育てようと思うと、どうしても上から目線になってしまう。上から目線だと気持ちも相手に伝わりにくい。気持ちが伝わらないと相手もうまく成長してくれない。 だから、人を育てる機会があったら、ともに冒険をする仲間を持ったと考えよう。きっとその方がうまくいく。 それでは、自分の話をしよう。自分というよりは自分たちの話かな。 2010年、自分は、昼間、ブラ三をやりながら、新規ビジネスの企画を考えたり、プロトタイプを作っていたりしていた。ブラ三をやっていたのは、当然ソーシャルアプリというものを学ぶためだ。ブラ三の能力はかなり向上したけど、仕事ではたいした結果が出せなかった。特に企画考え
第3回 どのようにスキルを伸ばせばいいか？ | gihyo.jp
3人のペルソナからスキルの伸ばし方を考える これまで、スキルの定義、年数に応じたスキルレベル、職種や所属会社による違いを説明してきました。そうすると次に興味が湧いてくるのが、スキルの伸ばし方ではないでしょうか。 マーケティングの世界では「ペルソナ」と呼びますが、データを基に架空のユーザを想定して、商品やサービスを設計する方法があります。じつは執筆でもこのようなことを行います。 今回は、以下の3人のペルソナを定義して、スキルアップのポイントを紹介します。 Aさん（若手で情報システム部に所属） Bさん（中堅で運用部門に所属） Cさん（データベースの派遣エンジニア） 若手で情報システム部に所属するAさんへのアドバイス Aさんは、情報システム部に所属する20代前半のエンジニアです。データベースの経験は2年程度です。以下のような悩みを持っています。 社内調整ばかりで、本当に役に立っているのか実感が持
日本のエンジニアの採用面接は不思議だと思う - 水まんじゅう2
あまり技術力もない、口も下手で、日々のシステム開発を大きな不具合がないように先回りをしながら大きな苦難の無いように仕事をしているプログラマーよりのエンジニアによる感想です。 何回か転職をしてきて、エンジニアの採用面接は非常に不思議だと思うようになってきました。 その思いを完成させてくれたのはJunichiItoさんによる このたびソニックガーデンの7人目のメンバーになりました でした。 自分が不思議と思ったことを5つほど挙げたいと思います。 システム開発の判らない人が評価をするのですか？ 最初に不思議に思ったのは面接を人事の方がすることが多いことでした。 システム開発をしたことがない、することのない人が面接官をして、 エンジニアが自分がどれだけ優れているのかを面接でお話をする。 エンジニア同士ですら、昨今の技術は多岐にわたっており、自分の専門としていない分野に関しては評価ができないような状
「ソフトウェア開発という仕事」と題して講義をしました
社内で新卒向けに講義をしました。社内固有の情報を削除した上で、下記に講義資料を公開します。 ソフトウェア開発における開発者の仕事を理解してもらうために話をしました。 講義対象者の半数以上が開発志望ではなかったので、開発者でない人が、今後、IT業界の中でどう開発者と向き合っていくかを主眼にして話しました。IT業界にいながら、開発者のことを理解できない人たち、あるいは何をしているのか分からない、と偏見を持つ人がいるからです。彼らにそうなって欲しくないからです。共感できるかは別です。考え方や価値観が違うなら違うでもいいと思います。はじめから理解を拒否していたら、いつまでもコミュニケーションが生まれません。 ついでに、半数以上が女性だったので、裏の意図として、プログラマがモテるようになって欲しいと思って話しました。プログラマがモテる世界にしたいと思っているからです。若い女性の前で話す機会を得られた
マネージャになりたくないプログラマのキャリアパス
金曜日、KLab元CTOの仙石さんからありがたい話をいただきました。 話は、開発者の採用、教育、評価あるいは開発者の心構えなど多岐に渡りました。いくつも興味深い話がありましたが、個人的に一番聞いて良かったと思える話を紹介します。表題の件です。 若いプログラマの中には年をとってもマネージャになりたくないと言う人がいます。他人事ではなく自分もそのひとりでした。若い時にマネージャ志望のキャリアパスに語ることは、プログラマとしての自分の誇りを傷つける気がしていました。マネージャを偉いと見なす風潮が、技術に対する裏切りのような気分がしていました。技術者をマネージャより低いと位置づけるのが許せませんでした。 たぶんピュアだったのでしょう。そんな経験があるので、今でもピュアな若者は好きです。本物のプログラマになるには、技術だけに一心に向き合うピュアな期間が必要だと信じています。そして、技術に真摯に向き合
技術者の倫理
ミラクル・リナックスに入社して1ヶ月経った。3月からまた新しい人（NetBSDハッカー！！）が入ったので、昨日は歓迎会だった。つまりは飲み会なのだけれども、ミラクルの人たちと話していてひとつ驚いたことがある。彼らは、会社の飲み会で技術の話をするのだ。往年の親指シフトから、最新の（？）GNU Hurdまでが話題に上がった。 技術者には個性というものがある。強みである。もちろん、弱みともなりうる。前職の三菱電機では、マネジメント上の最大の焦点とされたものに、技術者の個性の無効化がる。無効化という言葉が過激すぎるなら、均質化と言い換えてもよい。逆に、ちょっと過激な言葉を使うならば、前職のマネジャーたちは、技術者を交換可能な標準化された部品とみなした。 天才的技術者がいたとする。すべての製品を彼の天才に頼っていたとする。ある朝、彼が交通事故に遭うようなことがあれば、直ちに事業は破綻する（スーパーコ
差別化で未来を生き抜く エンジニアの7つの秘訣
書籍や論文をあたることもなく、インターネットでほぼ無償に近い形で無尽蔵に情報を手に入れることが出来る現在、エンジニアが価値のある存在として「自分を差別化」することがこれまで以上に難しくなってきているのではないでしょうか？ オープンソースソフトウェア開発などを通じてキャリアを重ねている私が「これまでの10年」、如何に差別化を計ってきたのか、秘策を大暴露します。皆様の「これからの10年」のキャリア構築の参考になればと思います。Read less
日記（3分の1ルール）
どうもこんばんわ。SE/PG広報を担当しているvalvallowです。 昨日の日記がまさかのホッテントリ入りで少々ビビりました。 vallog: 日記（転職しました） どうしてこうなった・・・。ビビりなので今朝出社して上司に報告しときました。上司「いいぞもっとやれ」。ということもあり、せっかくなのでこの流れに乗って続きを書いてみます。ただ相変わらず派手な内容はありません。 今日は以下のことについて書いてみます。 「3分の1ルール」 ラーメン代稼ぎ 「Lisper採用枠」始めました 「3分の1ルール」 「3分の1ルール」というものがあります。これは何のルールかというと「儲かったらみんなで山分け」という会社のスタンスにおける利益分配ルールです。 割り振りは 会社 社長(追記：というか株主だね) 社員 となります。こうやって見ると「社長ズルくね？」と思うかもしれません。これは会社がヤバくなったら
日記（転職しました）
ということで実は先日、熊本本社の独立系ソフトウェアベンダに転職しました。2月から社員として働いています。職種はSE/PGです。お客さん先に行ったりプログラム書いたりしております。 はてな界隈では華麗な転職話がにぎわいますが、私の話にはあまり派手な内容はありません。ですが下記を見るとわかるように面白い会社です。 社員も多くないので適当に仕事すると会社に大打撃を与えてしまいそうです。だからというわけではありませんが真剣に頑張ります。何よりここで働くのが楽しいのでうまくやってけそうです。 詳しいことはまた後日書いてみます。 熊本の小さなISVです。ベンチャーと言った方がいいのかな。で、今後5年間の目標が 収入の自動化 週休5日 のようです。もちろん汚いことをせずに真っ当に、です。上司が「働いたら負け」と言ってる。 現時点でも残業なく定時には皆帰る。創業以来、徹夜や赤字が一度もないとのこと。デスマ
コード書けるインフラエンジニアの深刻な不足問題
インフラエンジニアを厳密に定義しないであえて使うことをお許しください。 だいたいは、ゼロスタートの山崎さんの記事を見てほしい。 巷で聞かれる、「インフラエンジニアの深刻な不足問題」は、実は「コード書けるインフラエンジニアの深刻な不足問題」であり、それは「コード書けるインフラエンジニアへの深刻な給与不足問題」なのではないかと思うのです。 インフラエンジニアに15年前にはいった人(私は大学卒業が15年前なので感覚で語れるのはこのころから)は特にインフラエンジニアなどとは呼称されていなかったはずです。オープン系サーバ屋、オープン系ネットワーク屋、汎用機のプログラマ、IPのネットワーク、ATM、sonet、INSのエンジニアなどのように分類されていたように記憶しています。もちろん複数の分野を持つ人、持たざるをえなかった人が時代を推進していたことは事実です。しかし、そのように区分されて業界にはいって
ソフトウェアエンジニアを採用する時に見るべき６つのポイント - umitanuki's blog
何を期待されてるのかさっぱりわかりませんが、到着３週間で早速採用インタビューとかに使われてたりしています。英語がわからんっつーの。しかもMathのPhDの喋る内容なんて日本語で聞いてもわからないっていうのに。こちらから質問しておきながら半分以上は聞き流したりして何とかやってます。パーソナルなことは聞かないようにと言われていますが、人種も年齢も性別もごちゃまぜなのでほんとに気にならないというか気にしている場合ではない。「ジュニア」「シニア」ぐらいの分け方はありますがそれ以上でもそれ以下でもないし新卒中途とか年齢とか性別とか見てたころは一体何だったのだろうという。 そんなわけで今日は採用に関する６つのポイント。実は半分は人の受け売りです。 Passion これはよく言われると思いますが、その職場や職種に熱意とか興味とかがない人はやっぱり駄目でしょうね。逆に他のものが足りなくても熱意があれば（特
ウェブ業界で起業したいならMarcoを目指そう | quipped
Marco Armentという人をご存知だろうか？ Instapaperという「ブックマークして後で読む」アプリの作者として知られており、アメリカで大人気のブログサービスTumblrの共同創業者でもある。彼は2010年にTumblrを離れ、今はInstapaper一本にしぼって仕事をしている。主な収入源は$4.99のiOS用Instapaperアプリで1、アプリのダウンロード数が常時ランクインしていることを考えると、十分生活できるだけの額だろう。 今日のお話は至極単純なもので、ウェブ業界で起業したい人たちは、Mark ZuckerbergでもSteve JobsでもなくてMarco Armentをお手本にするべきだという話だ。ここですでに納得なら、残りを読む必要はない。 ぼくがMarcoをお手本とするべきだというには、3つの理由がある。 Marcoがウェブプロダクト制作に関して平均的に能力
esminc/jobs - GitHub
(このジョブポストは永和システムマネジメントの中途採用に関連した書きかけ項目です。内容は予告なく編集されることがあります。このリポジトリのmasterのHEADが常に最新版です) We're hiring! 株式会社永和システムマネジメント サービスプロバイディング事業部アジャイルグループでは、 アジャイル開発とオブジェクト指向スクリプト言語Rubyを使って「お客さまに価値を提供し続けるシステム」を構築し、 お客様と一緒に育てていくという強みを活かした受託開発を生業としています。 今回、私たちの強みをさらに伸ばしていくためにRubyプログラマを中途採用します。 (github:jobsにポストしていますが、文面からお分かりのように、日本語でのコミュニケーションに支障のない方を募集します) いま現在あなたが何者であるかよりも、次のような者でありたいと強く願う方の応募をお待ちしております(職務
人月商売が悪だと思っている、イノセントなあなたへ - GoTheDistance
色んな意味で示唆的なエントリ。山本さん、どうしちゃったんですか。飲みにでも行きますか。 人月は悪どころか、ものすごい善かもしれない - 山本大＠クロノスの日記 140文字ぐらいでまとめちゃうと、人月ではなくソフトウエアの持つ価値だけでお金を取ろうとすると、例えばスマホアプリの場合は非常に単価が安いのでペイする算段が立たないこともある。それを鑑みると、エンジニアの稼働ベースで請求できる人月ってなんだかんだでイイとこあるよ、って話です。 人月について語られる記事はエンジニアよりの観点で議論されることが多いんですが、そうなると「人月はエンジニアにとって善か悪か」という方向に話が飛んでしまい、ゼネコンは死ねば良いし多重請負は終わってるし日本のIT競争力はなんだかんだっていう感じで一定の結論が出しにくい。なので、もっとビジネスよりの観点で整理してみたい。 人月のメリットは成果物ではなく作業内容に対し
タダ飯よりも素敵なものは - steps to phantasien
GitHub co-founder の Tom Preston-Werner (以下もじょ先生) が お仕事のコードも大半はオープンソースにしたほうがいい という話を書いている。 (@higepon の tweet で知った。) 同じような主張は、ビジネスとしてのオープンソースが隆盛を極めた 2000 年前後にもみられた。 時は流れ、今はソフトウェアそのものよりはアプリケーションやサービスをウェブ越しに売る時代。 ハイテク企業の前線もコード自身からデータやユーザの時間といったコード以外の部分に少しづつ軸足を移しつつある。 そうした企業は十年前とは異なる文脈でコードをオープンソースにしはじめた… というだいたいの背景を踏まえつつ読むと、もじょ先生の話は感慨深い。 もじょ先生はスタートアップの founder/CTO らしい立場でオープンソースの利点を説いている。 私はスタートアップ勤務でもな
「プログラマを一生の仕事にできるビジネスモデルで目指す未来のビジョン」の衝撃。これからやるべき事 - アナザーディメンション
僕は一応SEとして仕事をしているんだが、東京で2年間仕事をしていた期間とても苦しい働き方をして体調を崩し、休職とかもしておかげさまで今は元気になったが、以来将来この仕事をどのように続けて行けばいいかということを常々考えている。 その中で思っているのが、会社で与えられた仕事やそこで生まれた人脈に頼るだけじゃどうしても会社に依存するようになるから危険なので、〜会社の僕じゃなくて個人として活動する幅を広げる必要があるんじゃないかってことだ。なので、今まで全く興味を持っていなかった勉強会とかセミナーに顔を出すようになったんだが、先日非常に感銘を受けたというかある意味衝撃的なプレゼン資料を目にした。 ＜講演者：倉貫義人氏のサイト＞ ・プログラマを一生の仕事にできるビジネスモデルで目指す未来のビジョン ＜レポート記事＞ ・プログラマを一生の仕事にできるビジネスモデルで目指す未来のビジョン（SIビジネス
DevOpsというオシゴト | quipped
DevOpsというオシゴトをご存知だろうか？ DevOpsというのはDevelopmentとOperationsのかばん語で、この数年話題になっているフレーズである。伝統的に、ソフトウェアの世界は、大きくわけてDevelopmentとOperationsの2つに分かれていた。Developmentに属するのは、いわゆるプログラマーやソフトウェアエンジニアと呼ばれる人たちで、ガンガンコードを書いてアプリケーションを作る人たちのことだ。Operationsは、プログラマーたちが書いたソフトウェアを管理したり、開発環境を整えたり、サーバーを監視したりするのが主な役割で、インフラエンジニアやシステム管理者と呼ばれる人たちがこちらに属する。 今までDevelopmentとOperationsは、きっぱりと分離されていた。それもそのはず、必要とされるスキルも経験も大きく違う。例えばウェブの世界でいえば
IT部門と経営の溝を埋めるために必要なたった1つのこと - GoTheDistance
もう何周目になるのでしょうか。｢情報システム部門が経営に貢献できていない｣というこの手の話は。 システム部門再生 - 経企部門が吐露する「システム部門への不満」：ITpro なんか色々ダメだしされていますが、重要なポイントは１つだけです。システム部門がビジネスに貢献するためには、自社の事業に対する理解が必要なだけではなく、その遂行手段である業務プロセスの理解が必要だ、という圧倒的な事実があることだけ。WhatとHowはクルマの両輪だと。で、この手の問題はシステム部門の問題ではなく経営の問題だという水掛け論が水びだしになるまで色んな人にされてFUDが残るのも味わい深いポイントであります。 自分達で管理できないものを改善できるわけが無い システム部門が業務プロセスの改善に貢献できない理由。突き詰めれば１つだけです。自分達で管理できずに、安易に外部に投げているからです。管理できないシステムをたく
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ulog.cc
クソゲーを作る組織とそうでない組織 2012 05-12
