案外成功方法より失敗集のほうがタメになりそう． ところでhost名がtaihaなのは安定性に関係ないです!!

こんにちは。検索・編成部の原島です。 大学の研究者にお会いすると、「クックパッドのデータを研究に使用したいんですが...」と相談されることがあります。料理に関する研究をしているけれど、実際のデータがないため、なかなか研究が進まないという相談です。 料理に関する研究が進まないのは、クックパッドにとっても残念なことです。これらの研究は、クックパッドのサービスを改善するための「芽」でもあります。データがないだけで芽が育たないのは、非常に悲しい話です。 このような現状を打破するため、本日から、クックパッドのデータを研究者に公開します。このエントリでは、我々が準備してきたデータ公開の仕様について QA 形式で解説します。 誰が利用できるの？ 申請していただいた研究者です。ただし、公的機関（e.g. 大学、独立行政法人）の研究者に限ります。申請時には、クックパッドと国立情報学研究所（後述）による審査が

この記事面白かったです！ 「出来る」と「実装する」の間には多くの解決すべき問題が含まれているから気をつけろよっていう警鐘を鳴らしている記事なのに、「出来るからやるって単純バカなんだけど」っていう反応が多いのが印象的でした。その理由の９割は、タイトルに「エンジニアはネ申」って書いたせいだと思うけど。 私からは、社内業務システム内製を通じて感じました、創造主であるところのエンジニアとハッピーに仕事をするためにはこういうことを一緒に考えよう、っていう話をしたいと思います。 実装可能と実現可能は別問題 前述の記事も僕の補足も、主題はこれだけ。だいたいそんな感じ。でも、順を追って説明します。 技術的に実装可能なのか否かは、当然一番最初に考える問題です。そこでNoならこの話は終わります。技術的と簡単にまとめますが、エンジニアによって判断基準は全然違うから悩ましいです。そこは差し引いて、単純に求められた

トップやリーダーがこういう考えで物事を判断するとろくな事にならず経営状態が良くならない。そんな「あるある」ネタが５個たまったので、シェアさせて頂きたく思います。 1. やってみないと分からんと高を括る やったことがないことをやる意味はすごくある。やったことがないことができるから成長できる。けれども、やってみて失敗した時の影響範囲によってはものすごく高い授業料を払うことになります。 運営上の課題を整理して走り続けるのはOKなんですが、やる前にダメだった時の終わり方を必ずシミュレーションする必要があります。ここまでやってダメなら次を考える「撤退ポイント」がないと、いつかは辿り着ける症候群に陥ります。この疾患は感覚で物事を判断するタイプに非常に多く、逆算して物事を考える習慣がありませんのでやってみないと気がすまないという。 「やってみないと分かんない」の対極は「やる前から終わってる」です。ゴール

これは興味深い問題提起。 エクセルでできることができない何百万のシステム・・ 「Excelで出来ることが出来ないシステムとかいうものに、なんで数百万も突っ込む必要があるのか」という話には、キチンと整理して説明できるようにしておきたいもの。 機能面ではExcelには勝てない Excelが提供している豊富な機能群は、世界でも選りすぐりのソフトウエア開発チームが途方も無い期間と金額をかけて作り上げたものです。Excelで出来る機能と同等の機能を提供することは、納期も予算も上限がある業務システム開発プロジェクトにおいて、非常にハードルの高い機能要件でしょう。業者からすると「ウサイン・ボルトに100m走で勝利しろ、期間は2ヶ月で」って言われても的な・・・ でも、「Excelとかいう最強の業務ソフトと同じこと望むなよ、そんなもん無理」で突っぱねてしまうのも違う。Excelには無い価値ってどこにあるかを

Twitterで流れてきたのでつい見てしまいましたが、この方の連載は全体的にやっつけ感が否めないですね。 なぜ“ダメなシステム”は無くならないのか？ - なぜ“ダメなシステム”は無くならないのか？：ITpro この"ダメだしとっつあん"があの手この手で言わんとしてることは｢上流工程と下流工程の分断は悪であり、ダメなシステムはそこから生まれている｣ということですので、この記事を読んだ人は連載読まなくて大丈夫です。僕が書いたこのエントリ読んでください。もっと突っ込んで書いてあります。 ｢SIerでのキャリアパスを考える｣というイベントに登壇しました - GoTheDistance もうそろそろぶっちゃけてもいいでしょ。ダメなシステムができる理由は簡単だってことに。ウオーターフォールが逆流できないせいだ/丸投げするからダメ/リスクをとらないからダメ/技術力のないやつが舵を取るからダメ・・・ってさ

会社組織における業務効率化の限界について - 脱社畜ブログに寄せまして。 書いてある内容は、何度も何度も繰り返しやる必要の無い単純作業を自動化して楽が出来たと思ったら、楽になったんならこっちをやれと言われちゃうので負担自体は変わらないし給料も変わらない。それもアホみたいだから、自分は楽をしているのをバレないように小難しい顔をして仕事をしているフリをするのが個人として最適な戦略になる、と。自分で自分の首を絞める理由がないのだから、業務効率化を図るには正直者が馬鹿を見るようにしてはならないということかと思います。 確かに「仕事を片付ければ片付けるほど、仕事が増えていく」ということはあります。仕事は片付けることが最優先なので出来ない人よりも出来る人が相対的な時間給として見ると損をしやすい。出来ない人には任せられないのだからどうにかして片付けちゃう人に負荷が集中してしまうのは普遍的なこと。その分ア

CAREER HACKさんというWEBサイトに掲載されている、エンジニアのキャリア論レポートが盛り上がっていると聞いてやってきました。 「エンジニアは技術以外の武器を持て」ー nanapi けんすうに訊く！［3］│CAREER HACK エンジニアよ、ゼネラリストなんて目指すな！―VASILY 金山裕樹のキャリア論［2］│CAREER HACK Geekなぺーじ:「汚いコードでいいよ」は夢の環境であると同時に悪魔の囁き Blogger Alliance | 404 Not Found コードの綺麗さの先にあるもの - Fashionable Life で、盛り上がっている論点は｢技術以外のことも出来るように vs ゼネラリストなんて目指すな｣と、｢汚いコードでも稼いだもん勝ちってそりゃあんた｣っていう2点なので、その辺書いてみたいと思います。 ゼネラリストなのかスペシャリストなのか 自分で

エンジニアのキャリアを考えればフリーになったり起業したりするというのは王道パターンの１つであると言えます。いざその道を歩むとなれば仕事を自分で受注しなくてはならない。そこに存在する落とし穴が表題そのものなんですが、もうちょい詳しく書いてみます。 「取ってきて貰った仕事をする」ヒトが「自分で仕事を取ってきて請け負う」を目指すときに起こる一番の勘違いは「能力が高ければ仕事を請けることが出来る」というものだ。 ここでいう能力というのは、エンジニアで言えば｢Javaが書ける｣｢サーバー構築が出来る｣｢MySQLのDBAをやっている｣というような類のモノ。要はスペックと考えるとわかりやすい。単純な話だが、仕事を発注する企業やヒトは技術の専門家じゃないので、ある一定水準以上のスペックは「どんぐりの背比べ」にしかならないことが多い。スペックが高いというのは伝わりますが、伝わったところで「それはすごいです

惰性による判断が横行しているのが、SI業界における最大の敵だ - Fight the Futureにインスパイアされて。 お気持ちはわかるし、言わんとしていることもわかる。より良い解決法を提示しても意思決定者がYESと言わないなら、優秀な人間の能力が発揮できず色んな損失を産む。一例として、情報共有に絶望的に向いていないExcel管理を上げられたが、これが技術の話だったりバージョン管理の話だったりしても、問題の性質は変わらない。でも、前例がクソと言い続けるだけで人生が終わっちゃうのは、あまりにもツマンナイよナ。 先ず、隗より始めよ この手の腐った前例をぶっ飛ばすには、｢この前例踏襲がどれだけ腐っているか｣ではなく｢前例を捨てて、やり方を変えても最終成果物に影響がでないこと｣を先に認識してもらうべきです。メリットの提示はあと、デメリットの消化が先。Excelが腐っている理由ではなくExcelを

インターネットの備忘録（はてなブログ版）にインスパイアされました。交渉や調整で、僕が感じている「やってはいけない」ことを、便乗して書いてみます。 1. 相手の面子を潰してはいけない 自分の主張を通す為には相手の言っていることの弱点を突いて｢あなたが間違っている｣というものだと仮に思っているのであれば、あなたは色んな人の面子を潰しまくることになりますので、利害が絡む交渉ごとは一切お引き受けにならない方がよろしいかと思います。交渉下手な人間は、利害に関する交渉で行き詰まると相手の間違いを非難する方向にいきやすく、それは結果として自ら交渉を難航させる種を散弾銃で乱れ打ちしていることになります。 感情と感情がぶつかったら、もうそれは交渉ではありません。口喧嘩です。 2. 間違い探しに終始してはいけない 交渉や調整ごとは、どっちが正しいか的な軸で考えてはいけません。自分が正しいかどうかは、関係ありま

営業という言葉に良いイメージを持ってる人はかなり少ないんじゃないかと思います。特にエンジニアは営業さんに「泣かされた」経験がおありの方が多いですし。また、電話爆撃営業や詐欺に近いような営業も多い中、益々うさんくささが先行しやすいのかなぁと思ったりします。 ホントはそういうもんじゃないだろって思うので、自分１人で顧客の所に赴き、話をしに行くことも増え、発注側として営業さんの話を聞くことも増えてきました。そんな中で、営業について感じたことを書いてみます。 1. できる人は相手に問いかける、できない人は自分が話し続ける 相手とのコミュニケーションの中で距離感をつかみ、お互いが負担にならないようなコミュニケーションの土台をまずつかむこと。これが恐らく営業のはじめの一歩なんじゃないか、と思っています。 その土台を作るのに、まず自分のことを立て板に水を流したように話す営業がいますが、その時点で僕は「も

KLab×はてな エンジニア応援ブログコンテストに絡めて、エンジニアの仕事からの話であればなんでもよいらしいので、書いてみます。応募も少ないようなので、ある意味大チャンスなので。 僕は今、小さな会社でたったひとりのエンジニアとして働いています。ある意味CTOみたいなもんです。スーツ(社長)の無茶ぶり(問われるのは最終的な結果だけ)に応え会社として必要なシステムを作ったり、受託でコーポレートサイトや業務システムを組む日々を過ごしています。 相談相手が皆無のため、｢自分のやっていることが技術的に正しいか、効率的か、何か落ち度はないか｣という不安を抱えながら｢10を求められて仮に2しか出来なくても、2から3にして次につなげる｣という努力を微力ながらやっております。僕の出来ることが会社の出来ることにほぼイコールになってしまいますので、僕が歩みを止めるわけにはいきません。２しか出来なくても、２が出来

最近仕事で出版業界のシステム関連でお仕事をする機会を頂き、特に出版流通について勉強する必要があったため、下記書籍を購入しました。 どすこい 出版流通 作者: 田中達治出版社/メーカー: ポット出版発売日: 2008/07/18メディア: 単行本（ソフトカバー）購入: 9人 クリック: 158回この商品を含むブログ (36件) を見る 読むまで知らなかったのですが、著者の田中達治さんは、僕の大学の同じ学部・学科の大先輩であり、筑摩書房でシステム内製に取り組んでいらっしゃったご経歴をお持ちでいらっしゃいました。いろんな意味で大先輩でした。既に他界してしまわれたのが本当に残念で、もしご存命だったらお話をお伺いしたいかったと思いつつ、強いシンパシーを感じながら読み進めていきました。 本の内容はほとんど出版業界の専門的なエッセイですが、システム屋として感ずるものがあった記述を備忘録的に書いておきます

はよプログラマとかエンジニアとかから脱却せんかい。 - 山本大＠クロノスの日記への私信。 山本さんの苛立ちを一言で言えば、｢お客様のお困りごとやお悩みごとに対してあまりにも無関心すぎること｣にあるんじゃないのかな。羽生さんのこちらのエントリを参照下さい。 一言で言えば、説明不足ということになるのでしょう。きちんとしたソフトウェアを作りさえすればよいという空気が間違いなく存在しています。(中略)自分たちが作っているソフトウェアがお客様に対してどういう価値があるのかということを説明できずにいると感じるのです。理解してくれ、と相手の努力に丸投げしてしまってるように感じます。 ではどうしてそうなるのかというと、端的に言えばお客様のお困りごとやお悩みごとに対してあまりにも無関心なのではないかと感じるのです。エンジニアとしての技術的な興味や自分自身の仕事と生活のバランスなど、つまりは内向きの関心しか持

人間だもの、そんな時もありますよね。 僕は転職してから自分で自分のミッションを探さなくてはならないため、昔よりも｢なんでこんなことやってんだろ｣って思うことが増えました。そんな時に、感じたことをまとめておきます。 手馴れたものに安住していないか 僕が最初に感じたのがこれです。 転職して新しい職場に来れば、当然自分の持っている武器を活用して行こうと思うわけです。僕の場合は業務システムの構築に関する能力でしたが、いきなり社長に言われたのがFLASHを作ってくれ、でした。｢ええええ、なんだそりゃあ｣って喉元まで出かけましたが、｢それが必要なんだから、できるところまでやれ｣の一言でﾊﾟｼｰﾝ。そういうのが一番苦手なのにな・・・って思いました。 その話は立ち消えになったのもあり結局大した成果は出せませんでしたが、手馴れたものばっかりやっても仕方ないしココに来なければこんなことやる機会も無かったし、ま

今年ももう終わりですねぇ・・・。 スーツ・ギーク論争に参加してた頃に僕と知り合った多くの人は、僕が技術系に戻ると知った時に驚かれた方が多かった。あんだけスーツでいたいって書いていたからそりゃそうだなって、過去エントリ読み返して改めて思った。 この２年ばかりどんな心境の変化があったのか、思い出しながら書いてみたいと思う。新卒はツライよ！みたいな感じで。 僕は大きなSIerに入ったにもかかわらず、幸運にもバリバリコードを書く部署に配属された。相当レアだったと思う。そこで仕事をしているうちに、僕の立場はプログラマという作業員でしかなかったことにひずみを感じるようになった。技術が無ければできないしそこは間違いなく意味があるんだけど、僕は仕事をもらっているから力関係で言えば、間違いなく下なワケで。そういう状況だと、グダグダなプログラム開発を強いられることが多くなって辟易とし始めたってのもあったかなぁ

孤高というやせ我慢をしながら、会社の経営に直接関わっております。 私のミッションの１つには、会社を回す仕組みを高度化させ本業に貢献する業務システムを作ることがあります。 サラリーマン時代、結構な人が自分の会社の売上があがる仕組みを理解していないことに驚きました。お金が降ってわいてくるわけが無いのに、自分の給与の源泉にさしたる関心が無いものかと不思議に思ったものです。自分が存在する組織の成り立ち・競争原理も理解していないにも関わらず、会社の不平不満を言うだけとはトンデモナイ。 前職は｢人月｣という単位で売上を立てておりましたが、入社して人月単価なるものがあると知った時、自分の売価と自分が手にする給料のあいだには何があるのだろうか、と疑問に思ったものです。自分の給与の数字は売上から｢何か｣を天引きされている数字です。それを知る為には、ご自分の会社の大きな仕事の流れを理解しなければなりません。そ

｢技術者が技術要素だけで名を上げる(市場に打って出る)ことなんてできるわけないんだから、技術と顧客の間をつなぐ経営者が最も必要である｣という話も定期的に話題に上がるのですが、毎年思うことは少しずつ変わっていくので、僕も私見を述べたい。 僕が2007年頃にスーツ・ギーク論争に興味を持ってスーツ側でエントリを書いて参戦したきっかけは、このソースコード、一体どういった付加価値を生んでいるんだろうというのが実感できなかったことです。仕事だからの一言で飲み込めずエントリに吐き出してしまった。スーツの考えや世界を変えないとどうしようもねぇなっていう直感が先に来た。今ではこれは確信に変わっています。なので、エンジニアの未来を考える際に顧客の利益と我々の利益をどう折り合いつけるのかが先で、個別の技術論は正直どーでもいいというcodemaniaxさんのご指摘、僕は正しいと思います。侍が明治の世に生きてゆけな

梅田望夫氏の大企業で働くことについてのエントリの尻馬に乗ろうと思い続け、気がつけば尻馬が100マイルぐらい遠くなってしまったのですが、やっぱりこのネタについて書きたいことがあるので、エントリを書きます。すっげー長いエントリになってしまったので、気長に読んでください。連休の夜長にでも。 他の大企業はどうだかわからないけれど、少なくともウチの会社に限って言えば、以下のような事が言えます。 本部長レベル以上はやっぱりデキる人が多い 何にも考えなくても給料がもらえる仕組みがある 人がいっぱいいる、それだけでも意味がある 基本的に隣の部署が何をやってるかわからない 決定が棚上げされる うっとおしい社内業務が多い こんなところかなぁ。 ウチの会社は社員数4桁の会社です。そんな会社にあって本部長クラスになれる人は、どこか一味違います。先を見据えて物を考えていたり、政治力がすごかったり、オレ様全開だけど明

いきなりポイントから入ります。大企業で働くことと中小企業で働くことの違いは、大企業はルールで動き中小は経営者の恣意で動くということです。ココがすごい重要です。 僕は６年近く大企業にいました。その時に考えたことは大企業で働くということ - GoTheDistanceで書きましたが、大企業の根本的な原理原則はルールで仕事が動くということです。異なる立場・異なるレイヤーの人たちを束ねて１つのサイクルを作るには、ルールを作ってその中でサイクルを回すより他ありません。それの累積によって企業文化なるものが形成されます。 大企業にいてよかったことは｢普通に仕事をさせてもらえる｣ことでした。もちろん仕事を選ぶことは基本的に出来ないんですが、明確に自分の役割が与えられ、そのロールに従いすべきことをして、あるべき成果を出してその仕事を終える。あっちいったりこっちいったりということはない。いきなり全く次元の違う

先日識者の方に色々教わったのでメモっておきます。知ってそうで知らない、元々よくわからない、そういう方に向けてまとめてみました。 僕がSIにいた頃は大抵｢基本契約｣と｢個別覚書｣ってのがありました。納期とかお金とかそういうのは個別覚書に書かれたりしていました。 開発の契約体系 ｢仕様策定〜開発まで｣と｢保守運用｣で別契約にすることが多い。 ｢仕様策定フェーズ｣で1つの契約にして、別に新しく契約を締結しなおせるほうが望ましい。リスクが低減できる。 仕様策定までは準委任、開発は請負、保守運用は準委任という契約が多い。 ちなみに準委任は｢事務作業の代行｣という意味合い。委任は｢法的効力がある作業｣の代行。サムライビジネスは後者が多い。 別に運用が事務作業とイコールじゃないけど、成果を問わないタイプの契約の場合は役務提供という位置づけになる。 かといって契約で｢僕らのコンサル案を僕らが実施し成果が出

Redhat 一筋のため Debian に苦手意識があったりするんだけど、その理由が apt-get や dpkg のコマンドをよく知らないからな気がしてきた。 そのために対応表を作ってちゃんと使いこなせるようにしたい！ 説明 Redhat系 Debian系 キャッシュの更新 - apt-get update パッケージの更新 yum update apt-get upgrade パッケージの検索 yum search apt-cache search パッケージに含まれるファイルの検索 yum provides apt-file search 指定したパッケージのインストール yum install apt-get install 指定したパッケージの削除 yum remove apt-get remove 指定したパッケージの情報を表示 yum info apt-cache show

yum と rpm しか使ったことが無いので、apt-get の対応表を作ってみた。これからもどんどん加筆修正予定。 Redhat系 Debian系 Fedora22+ キャッシュの更新 apt-get update モジュールの更新 yum update apt-get upgrade パッケージの検索 yum search <検索文字列> apt-cache search <検索文字列> パッケージに含まれるファイルの検索 yum provides <検索文字列> apt-file search <検索文字列> インストール yum install <パッケージ名> apt-get install <パッケージ名> dnf install <パッケージ名> 再インストール yum reinstall <パッケージ名> 削除 yum remove <パッケージ名> 又は rpm -e <

2. 自己紹介 • 鹿島恵実（かしまめぐみ） • 千葉市出身 28歳 • ブログサービス「JUGEM」の デザイナーとしてペパボに入社 • チームのリーダーをしたりスクラム マスターをしたりたまにデザイナー • 好きなパイルドライバーは スタイナー・スクリュー・ドライバー

ござ先輩による、エンジニアは技術だけ身につけたらもったいなくない？っていう問題提起の資料です。Read less