ユーザー企業にとってエンジニアを雇用するのはギャンブル - Life is Really Short, Have Your Life!!
Eメール、グループウエア、Officeソフト、レンタルサーバ。用途が限定的なものは便益がすぐにわかるのでどんな企業だって導入できる。でも、業務システムは別。インストールすればいい、契約すればいいというものではない。ハードルがくそみそ高くなる。 経営に資するITを正しく手に入れる手順 自社の事業の全体図(ビジネスモデル)を描き それを支える業務プロセスを描き 何をITに載せる意味があるかを描き ITに落としこむだけの情報を揃えて 実際のITシステムを導入する この5段階のプロセスを踏まねばならない。正しくやろうとしたら、ね。これを提供できる技術がITじゃないってことぐらい、誰でもわかる。何をITに載せる意味があるのかを見出すのが最も大切で、その意味にもベクトルやレベル感がまちまちだ。ある企業は見積のプロセスを強化したいだろうし、ある企業は在庫のリードタイム短縮を目指しているかもしれない。エン
ITエンジニアの業務時間外の学習 - 勘と経験と読経
時間外学習に関するブログ記事をタイムラインで目にして考えたこと。ちなみに業務時間外に学習するかどうかは趣味の問題だと思っている。 業務時間外で勉強をしなければいけない理由：101回死んだエンジニア：エンジニアライフ 業務時間外の勉強が必須なんてことはない IT業界は技術の流れに置いていかれるとしんどい思いをする。業務時間外の勉強は必須だ。しかし、おかしな話ではないだろうか。なんで時間外に仕事のための技術を勉強しなければならないのだろうか。 本来であれば、業務に必要なことは業務時間内で教えるべきだと思う。だが、今時そんな余裕のある会社なんて無い。やって当然という雰囲気はあるが、やるだけの理由を説明できる人は少ない。大半が「仕事に必要だからやるんだよ！」としか言わない。 業務時間外で勉強をしなければいけない理由：101回死んだエンジニア：エンジニアライフ 業務時間外の勉強が必須なんてことはない
顧問エンジニアというロールのあり方 - Life is Really Short, Have Your Life!!
僕も７月の終わりから、「顧問エンジニア」のロールのあり方を模索しています。で、こちら。 iritec.jp これはいわば、「Developer as a Service」というモデル。御社のために出張料理人を派遣しますので、うまいこと使って下さいと。それだけITの裾野が広がり個人でもITシステムを作れる環境が整ってきた、ということでしょう。この流れは鈍化する理由がないので、似たようなサービスが増えていくと思います。 ただ、僕の考える「顧問エンジニア」とはちょっと違います。僕が考える顧問エンジニアは、開発をしないことを前提としています。なーに言ってんだとお思いでしょうが、先日書いた「要件定義+PaaSの活用」で作らない開発を目指し、顧問エンジニアの主な仕事はIT戦略立案から自動生成ツールへの落とし込みです。ノンプログラミングで作れたら、それに越したことはないのです。 aroundthedis
業務時間外で勉強をしなければいけない理由：101回死んだエンジニア：エンジニアライフ
いろいろな仕事を渡り歩き、今はインフラ系エンジニアをやっている。いろんな業種からの視点も交えてコラムを綴らせていただきます。 ▪️業務時間外の勉強を新人にどう説明しているか IT業界は技術の流れに置いていかれるとしんどい思いをする。業務時間外の勉強は必須だ。しかし、おかしな話ではないだろうか。なんで時間外に仕事のための技術を勉強しなければならないのだろうか。 本来であれば、業務に必要なことは業務時間内で教えるべきだと思う。だが、今時そんな余裕のある会社なんて無い。やって当然という雰囲気はあるが、やるだけの理由を説明できる人は少ない。大半が「仕事に必要だからやるんだよ！」としか言わない。 IT系に勤めているからそれが当然だと思うかもしれない。だが、「仕事で必要だから」では理由が弱い。しんどい仕事をした後に、更に勉強というのはなかなかしんどい。相応の理由でも無い限り、モチベーションは保てない。
時間が足りないのではなく、MPが不足して何もできないとき
「忙しすぎて、◯◯ができない」でも、本当に？ Basecampの開発者のブログ、Signal v. Noiseでジェイソン・フリードさんが、時間がないことと、アテンション、つまりは注意力・関心がないこととの違いについて記事にしています。 ここで注意したいのは、attentionを「注意力」「関心」と理解してしまって、注意が足りないから、関心がないからととらえてしまうと誤解に導かれる点です。 Attentionにはそうした意味もありますが、ここで問題になっているのは、時間ならあるのに、それを割り当てるための気持ちのリソースが足りないことを指しています。そういう意味では精神力が足りない、あるいはロールプレイングゲーム的な表現を使うなら、「MPが足りない」といってもいいでしょう。 時間はあるのに、手を付けられない ジェイソンさんが直面したのは、ありふれた、どこにでもある状況です。ある日、彼のため
Eyefi mobi ＋ iPhone ＋ Eyefyクラウドで完璧な写真管理、シェア、バックアップ環境を作り出す
最近Eye-fi mobiやEyefiクラウドを用いて構築した写真管理環境がかなりいいかんじなので、まとめてみたいと思います。 一回の記事で全部のやり方を書くと超大作になってしまうので、セットアップ方法などの詳細は次回以降で書いて、今回は概要やメリットをまとめます。 以降書こうと思っている内容です。シリーズ名はスタンダードに「Eyefi写真管理術」で。 Eyefi mobi + iPhone + Eyefyクラウドで完璧な写真管理、シェア、バックアップ環境を作り出す←イマココ Eyefi mobiとEyefiクラウドでできること EyefiアプリとEyefiクラウドで写真を管理・共有する Eyefi mobi ⇒ iPhone ⇒ Mac な写真の流れを作る iCloudフォトライブラリを使わずにEyefiクラウドを使うことに決めた2つの理由 EyefiクラウドとIFTTTでまとめて写真を
小中規模のIT系企業における技術的選択と雇用戦略に関する雑感 - たごもりすメモ
でっかい主語で入ったが、要するに2月にあちこち会社巡りをしたときに感じたことについてつらつら書こう、というのが目的。 特定の会社について書いてもしょうがないので、あれこれ*1回ったうちから少なくとも2〜3ケースで該当するなあ、と思ったことについて書く。特定の1社のみに該当する事項はこのエントリにはひとつも出てきません。 またエントリの主旨からして超上から目線になりますが、どうかご容赦ください。 これから成長が本格化するのでインフラを支えられる人材がほしい 正直に言ってこれが一番多かったパターン。スタートアップ的にサービスを作ってきたがその一方でデプロイや監視などの運用まわりが後手後手になっており、そのあたりを支えられる人物がほしい。 話としてはわかるのだが、気になったのは、これを聞くとき、詳しい内容を突っ込んでみると、どうも実際にはそう困ってはいない、というケースがほとんどだったように思え
SurfacePro3購入、MacユーザーのためのSurface入門。つーかSurface楽しい！
トップ > Surface Pro > SurfacePro3購入、MacユーザーのためのSurface入門。つーかSurface楽しい！ いしたにまさきの新刊：HONDA、もうひとつのテクノロジー ～インターナビ×ビッグデータ×IoT×震災～ 01 それはメッカコンパスから始まった｜Ｈｏｎｄａ、もうひとつのテクノロジー 02 ～インターナビ×GPS×ラウンドアバウト～ 運転する人をサポートすること｜Ｈｏｎｄａ、もうひとつのテクノロジー 03 ～インターナビ×災害情報×グッドデザイン大賞～ 通行実績情報マップがライフラインになった日 2014.12.11 いろいろと思うところがあって、Surface Pro3を買いました。買ったのは、i7×メモリ8GB×SSD256GBのモデルです。 ▼マイクロソフト Surface Pro 3（Core i7／256GB／Office付き） 単体モデル
残念なソフトウェア開発の現場は、沈みかけの巨大な船に乗った航海に似ている。
残念なソフトウェア開発の現場は、沈みかけの巨大な船に乗った航海に似ている。 船底の穴からの浸水を必死でかき出しながら、どうにか進んで行く。そういう航海だ。 船のどこにどれだけ浸水箇所があるのかは分からない。 ある穴を塞ごうと船底に板を打ち付けたら、 それによって別の場所に新しい穴を空けてしまったりする。 船の構造はあまりに複雑で、膨大な部品の間にどんな依存関係や相互作用があるのか、 誰も完全には把握していない。 それは、はるか昔に組み立てられた太古の船で、 構造把握の手掛かりは、代々伝わる不十分で不正確な古文書だけなのだ。 新任の船員は、出た水に対してとにかく手当たり次第に対処した。 どんな物でも使い、徹夜で穴を塞いで回った。 ひたすら大きな声で号令を出し、 いかに早く穴を塞ぐかが、船員の間で競われた。 何人もの船員が過労と心労で倒れ、 航跡には水葬者が点々と残された。 船員たちが経験を積
Optionalの取り扱いかた - 日々常々
JavaSE8で追加されたjava.util.Optionalにはnullとの戦いに終止符を打ってもらいたいと思っているんですが、思ってるだけだと何も起こらないので、使い方とか思ったこととかを一通り書いておきます。 Optionalのファクトリメソッド Optionalのインスタンスメソッド 値を取得するもの 値を使用するもの Optionalのまま扱うもの まとめ なお、一通りと言いつつOptionalIntとかはスルーしています。機会と書くことがあればそのうち書くかもしれません。 Optionalについては諸事情（遅筆とか理解不足とか分量とか）によりJavaエンジニア養成読本では軽い紹介にとどまっておりましたので、補足としてお読みいただけると幸いです。あと、この辺も参考にどうぞ。 OptionalのJavadoc 一通り触って適当にコメント書いたコード(GitHub/sandbox)
エンタープライズという言葉に意味はあるのか？ - 急がば回れ、選ぶなら近道
「エンタープライズ」という言葉 IT業界では、一応、「エンタープライズ」という言い方があります。残念ながら明確な定義がありません。自分は「一般企業の業務系システムのIT」に対応する言い方だと思っています。大抵はこの意味で通じます。が、これでは漠然としすぎていて定義としては役に立ちません。現実の用例としては、対比的に用いられることが多く、ありがちの用法としては、特にWeb系と対比して、よりしっかりやっているとか、より硬派な仕組みを作っているとか、よりまともな産業に属しているとか、そんなニュアンスで使われます。まぁ、特に品質あたりではよく言われる言葉ですね。「それエンタープライズじゃ通用しない。」マスコミや特に雑誌でよく使われる言葉でもあります。明確な定義があることはほぼありません。 さらに、よく聞く言い方で「エンタープライズでも使われてます」という言い方があります。特にWeb系での利用がメイ
SI屋さんとSIと、直近の課題について。 - 急がば回れ、選ぶなら近道
某セッションでちょっとしゃべったことをつらつらと。SIの現状と近い将来について思うところをまとめておきます。自分自身の立ち位置も確認していくという意味で。 結論的にいうと、SI自体は必要とされていますが、SI屋さんのビジネスモデルは成立しないという状況になるので、旧来の「SI屋さんの方法」ではうまくいきません。なので、別のやり方でSIをどうやっていくか？という議論が必要になりますね、という話です。 まずSI事業は人月稼働で商売をしています。スタート地点はそうではなかったのですが、一旦大きな人数を抱えると、食わせる必要があるため、より大きな仕事を取る羽目になります。要は稼働させる事、それ自体が目的になります。稼働を維持させる事で、収入を確保する事ができ、確保された収入で稼働のための人員を維持できる。そもそもそういう循環をベースに組織の目的が、「結果として」形成されてしまっています。 副作用と
エンジニアの評価基準とキャリアパスのお話 | 外道父の匠
春になって暖かくなると、ついつい意識が高ぶってしまいますね。 今回はあくまで個人的な、エンジニアの評価基準とキャリアパスについての私見を、どちらかというと新人の方向けに垂れ流してみたいと思います。 はじめに 新人の方々は今頃は、研修に追われていたり、それが終わっても配属先で揉みくちゃにされる日々が待っているでしょう。中には既に後ろ向きな思考になっている人もいるかもしれませんが、そういう人には今回どうでもよい話で、前向きな人がそのエネルギーをエンジニアとしての成長に無駄なくつぎ込むために、若いうちにあまり考えないけど、考えておいた方がよい話をします。 ITエンジニアとして始動すると、目の前に与えられた仕事だけでも楽しいのに（その過程で苦しむのは別として）、さらにその先にIT知識が広く深く待ち受けていて、こんなことをやりたいんだ、全部マスターしてやるんだと意気込むかもしれません。そして、目の前
テストコードは「書けるようになる」ものじゃなく「書きたい」と思うもの（ポエム） - give IT a try
「Railsチュートリアルを見ながらテストコードを写経しても、自分でテストコードが書ける気がしない」という新人さんのつぶやきに思わず反応した僕の、斜め上から目線の感想を書きなぐっておきます。 テストコードは「書けるようになる・ならない」の問題じゃなくて、「テストコードって便利！テストコードって大事！！」って思えるかどうかじゃないかな～と思ってる。 僕みたいなおっちゃんが働き始めた頃は「テスト = 手で動かして目で確認してスクリーンショットを撮ってエクセルに貼り付ける」という肉体労働だった。 コードを変更したら、もう一回「手で動かして目で確認してスクリーンショットを撮ってエクセルに貼り付ける」を繰り返さなきゃいけなかった。 ところが、テストコードを書けば「自動化できる！何回でも繰り返せる！すぐ終わる！自動テストすげー！！」ってなって、「こりゃテストコード書けた方が100倍いいわ」っていうモチ
JUAS『ソフトウェアメトリックス調査2014』を読み解く | タイム・コンサルタントの日誌から
「何だこのグラフ。点がバラバラに散らばってるだけじゃないか。」 －－そんな反応が多いだろうと思う。一応斜めに直線を引いているけれど、点はその線上から、ほとんど倍半分のいきおいでずれている。無理やり引いているだけで、法則性があるとはとても言えないな。誰だよこんなグラフ作ったの・・。 だが、このグラフ、わたしはとても面白いと思う。これは、「一般社団法人 日本情報システム・ユーザー協会」、通称『JUAS』が独自に行った調査の結果をグラフにしたものだ（JUAS発行「ソフトウェアメトリックス調査2014」p.66よりスキャンして引用）。グラフの横軸は情報開発プロジェクトの全体工数。単位は人月だ。そして縦軸は、プロジェクトの全体工期（＝期間の長さ）で、単位は月数である。図上に散らばった多数の点一つ一つは、個々のプロジェクトを表す。 なお、よく見ると横軸は一定間隔ではない。10の隣が100、一つおいて5
ドロドロなIT - アンカテ
ちょっと前まで、グーグル対アップルの戦いはオープン対クローズの戦いだった。それが、最近は、Androidのオープン性が怪しくなる一方、アップルは ResearchKit なるものを出したりして、そんなに単純には割り切れなくなってきた。 ネットやモバイルデバイスが我々の生活に浸透するにつれて、両者の戦略はともに複雑化していく。当然のことで、世の中との接点が広がる以上、もし世の中とのつながりを保とうと思うなら、複雑化するしかない。 それに対して、政治は、特に日本の政治は最近なんだか単純化しているような気がする。政治というか政治を巡る言説というか。 多国籍企業が世界政府になるというのは、強権や陰謀的なやり方によってそうなるのでなくて、だんだんと自然に政府が自滅的に権威を失墜していくということなのだと思う。 政治とはドロドロしたものでとよく言われるけど、それは汚職のことではなくて複雑な意思決定のプ
ソフトウェアの技術革新って必要なのかな？
プログラマの間では昔から、この手法は処理が遅いだとか、無駄が多いだとか、再利用を心がけろだったりとか 様々なやり方で、ソフトウェアをチューンナップして処理速度を上げるためのやりとりが際限なく 繰り返されているけど、だいたいどれもハードウェアの技術革新によって記録は塗り替えられてないかな。 そりゃ、ミドルウェアレベルでは全てのパフォーマンスに影響してくるので、ちまちまとした 改良が加えられるべきなんだけど、ソフトウェアレベルではどうなの？ Ｉ／Ｏに引きずられるから、Ｉ／Ｏの処理は最低限に抑えるってのが昔から定説だけど それもSSDの登場で、かなり緩和された感があるし、結局プログラマの努力って ハードウェアの努力には追いつかないし、無駄なのではないかと思ってる。 １０年前を支えたプログラム技術で今も生きているものってある？ オブジェクト指向とかプログラムのわかりやすさを追求したものは別でね。速
泥沼プロジェクト振り返り
はじめに ちょっと前まで結構激しく泥沼化したプロジェクトにいた。 その頃はプロジェクトも僕も相当疲弊していて、何も考える時間がなかった。 ある程度、月日が経って今なら もう少し客観的にあの頃のことが考えられるかなと思い書いてみることにする。 振り返りをし、自分としてもプロジェクトとしてもどうあるべきであったかとか そういう立派なことが考えられればいいのだが。 とかく、Slide Shareとか世の中は成功事例は多く発信される。 けど、失敗事例のほうが共通して当てはまったりする。 前提 ・古典的なウォータフォール ・古典的なStruts1系ベース内製フレームワーク ・Java SE 6 ・QAとかいない ・デザイナーとかいない ・フロントエンドエンジニアとかいない アンチパターン 当時のプロジェクトを振り返って、明らかにこれは駄目だっただろというところ。 ◆プロジェクト全体 ・決定者がいない
コードに対してコメントを書くと実装に関するコメントになる - きしだのHatena
おととい、渋谷JVMというイベントがあって登壇させてもらったんですが、そのあとビール飲んでるときに、ぼくが「コード書く前にコメントだけ書くのいいよね」と言ったあとの返答としてきょんくん(kyon_mm)が言った言葉。 全体としては 「コード先に書いてそのコードに対してテストを書くと実装に対するテストになるし、コードを先に書いてそのコードに対してコメントを書くと実装に対するコメントになる」 という感じ。 ここに至るまでの話もおもしろかったんだけど、ここでは、コメントについて書いてみます。 まず、実装に対するコメントってどういうのかというと、こういうの。 id = findId(name); if(id == -1){ // idが-1だったとき登録 register(name); } いやそれはコード見ればわかるから、ってやつですね。 これは、こうやるとより適切です。 id = findId
パフォーマンスを向上させたいなら、カフェインを減らそう | ライフハッカー・ジャパン
Inc.：今回ご紹介するパフォーマンス向上のコツは、今までで一番シンプルでわかりやすいものです。多くの人には他のどんなアクションを取るより大きな影響を与える可能性があります。さわりだけでも教えてって？ じゃあ言いますね。カフェインを減らしてください。しかし、カフェインを飲んでいる人なら誰でも言うはずです。それは言うは易く行うは難しだと。 ご存じない方のために説明しますが、プレッシャーのもとで感情を抑制して冷静さを保つ能力はその人のパフォーマンスに直接結びついています。TalentSmartが100万人以上を対象に行った調査によれば、トップクラスのパフォーマンスを挙げている人の90%はEQが高い人たちでした。彼らはストレスレベルが高いときでも、自分の感情をコントロールするスキルがあり、冷静でいられるのです。 良い点：実は良くない カフェインを飲み始める理由は、たいていの人の場合、気分が覚醒し
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
