原油高と同じくらい深刻な「ホワイトカラーの仕事破壊」 - アンカテ
日本人は海外からやってくる危機には敏感に反応する。原油高とか円高とか新型インフルエンザとかはよく報道されるし、政府の対策が不適切だったら批判も高まる。 私は「成長戦略」として語られている問題も本来は、そういう種類の問題だと思う。 しかし「成長戦略」という言葉はヌルい。ヌルすぎる。なんか、やってもやらなくてもどうでもいいけど、やるとちょっとボーナスが増えるみたいから、気がむいたらちょっとやってみるか、みたいな感じ。 本当は、これは原油高に匹敵するような日本にとって大きな問題だと思う。原油は間接的にあらゆる製品の材料になっているから、原油の高騰はどんな産業にとっても大問題だ。 それと同じように、今、ホワイトカラーの労働力の単価が急激に落ちている。日本は直接間接にホワイトカラーの労働の成果を海外に売って食ってる国だから、これは、逆に言えば、あらゆる資源が高騰しているということだ。 「成長戦略」と
問い：Java 8のStream APIは業務でどんな時に使うの？ 答え：あなたがfor文使いたい時 - ブログなんだよもん
※ サンプルがJDK7までとJDK8までで意味が変わっていてわかりにくいという指摘があったので、少し直しました。 ※ boxedを使う書き方だと無駄なAutoboxingが走るとの指摘を頂きましたのでmapToObjを利用するように変えました。 Java8の目玉機能の一つにStream APIがあります。 目玉機能だけあって、先日のJava Day Tokyo 2014を含めて色んな所で発表やブログの記事が公開されているので、どんなものかを知ってる人は多いと思います。 Stream APIといえば「".parallel()"と書くだけで並列化してスピードアップ出来る！」という魅惑的なキーワードで紹介されることが多いので、並列化のための仕様だと勘違いされそうですが、そうではありません。 ※ もちろんそういった記事の中をちゃんと読めばそう単純な話じゃないことも分かります。 むしろ、並列化に関し
クリエイティブ業界で働くべき理由、キャリア論
キャリアハックのインタビュー記事「エンジニアがクリエイティブ業界で働くべき最大の理由｜バスキュール 古川亨のキャリア論」が公開された。こういうところにも、ソフトウェア・エンジニアのポジションがあることを知ってもらえるといいなぁ、という思いでグダグダ話した内容を、記者の白石氏がきれいにまとめてくれた。 タイトルにある働くべき理由や、キャリア論が明示的ではないと指摘された。記事に興味を持った人に対して、続きはブログで、という位置づけで、この文章を書くことにした。 「一般的な問題解決方法と、技術的知識/技能を、自分自身の環境に合った組み合わせで習得/実践することで、エンジニアが提供できる価値が大きくなる領域が存在する。クリエティブ業界はそのひとつだ。」という立ち位置で、インタビューに答え、この文章を書いている。 主語は、私（のようなエンジニア） 人口百人以下の村役場に勤める二十三歳の出納係と、丸
自分の人生のライフスタイル（構造的なアセット）を自覚的に形作ることのすすめ - 物語三昧～できればより深く物語を楽しむために
2008-01-21 最後通告は３７歳 http://d.hatena.ne.jp/Chikirin/20080121 2009-05-05 まだいける、と思ってた？ http://d.hatena.ne.jp/Chikirin/20090505 残りの人生が、目に見えて、変えられなくなる境が37歳という話。 ふと思い出したのですが、ちょうど数年前の37歳前後に、僕は、大きな決断を下しています。老後を楽しく過ごすセカンドラウンドライフのために時間を使うのを優先すること、です。もう一つあるのですが、それは個人的すぎるので、ここでは横に置いています。 逆に言うと、かなり早くも会社人生の出世をあきらめてしまったんですね。 会社ぐらいしか逃げ道がないパンピー社畜会社員のペトロニウスにしては、なかなかの決断です。 当時なぜ自然にあきらめてしまったのかはとても不思議です。なぜならば、僕は社内の出世街道
プロセスをマネジメントしたければプロセスを削れ: DESIGN IT! w/LOVE
不確実な時代をクネクネ蛇行しながら道を切りひらく非線形型ブログ。人間の思考の形の変遷を探求することをライフワークに。 プロセスマネジメントにありがちな間違いのひとつに、ミスを減らそうとして、そのチェックをするプロセスを増やしてしまうということがある。 もちろん、すべての場合にそれが間違いというわけではない。 そのチェックが機械によって自動的に行われるのであれば大丈夫だし、そもそものプロセスが単純なものであれば、ひとつ工程が増えても大きな問題にはならない。 ミスを減らそうとして、そのチェックをするプロセスを増やしてしまうことが問題になるのは、そのミスが実はすでに多すぎて複雑な工程からなるプロセスそのものが負担となり、業務の遂行を圧迫しているケースだ。 すでに多すぎて複雑すぎるところに新たにチェック工程など追加すれば、業務の圧迫度合いはより大きくなり、また違うところでミスが起きやすくなるのは目
前向きなヒューマンエラー対策をしよう。 - Sacrificed & Exploited
SIerが仕切っている開発現場でありがちなのが、何かミスを犯すと、そのミスを防止するようにすごく手間がかかるチェックが追加されて、開発効率とモチベーションが下がるというダメなパターン。 たとえば、「今年度は申請書(EXCELシート)書いて上司の判子もらわないと svn commit すらできない職場で仕事することになりました。 - SiroKuro Page」とか。 これはプロセスマネジメントでもなんでもない、管理ごっこだ。管理したつもりになって自己満足しているに過ぎない！！ プロセスをマネジメントしたければプロセスを削れ: DESIGN IT! w/LOVE では、次のように述べられている。 プロセスマネジメントにありがちな間違いのひとつに、ミスを減らそうとして、そのチェックをするプロセスを増やしてしまうということがある。 もちろん、すべての場合にそれが間違いというわけではない。 そのチ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
