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

1年以上付き合ってきて最近落ち着いてきたので、この辺でまとめておこうと思う。僕は現在Follow 1700/ Following 2100ぐらいです。 Twitterの本質 タケルンバのTwitterとは掛け算サービスである - (旧姓)タケルンバ卿日記とまなめ王子のこのPOSTで、だいだい網羅できていると思う。 Twitterではタイムラインを構築するのは自分だから、自分のタイムラインには責任を持たなくてはならない。ムカツク発言をした人に文句を言うのではなく、その人をフォローしてしまった自分を責めればいい。気楽だねぇ。 Twitter / maname: Twitterではタイムラインを構築するのは自分だから、自分 ... Followに偶然は無い。そして、Followして発言(POST)をしなければ、何も始まらない。 これほどわかりやすいものはないなぁと思う。 自分が求めているものをタ

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

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

人脈というのは｢人｣の｢脈｣と書きます。つまり、これが意味する所は自分を中心して｢人｣が｢脈をなしてつながる｣ことで初めて人脈と呼ぶに相応しいものになります。 人脈を築くために一番大切なこと。それは、相手に何かを与えられる自分であるかどうかです。それ以外は全部二の次です。 ２年ぐらい前になりますが、僕は前職のある営業部隊の担当役員の下で仕事をさせてもらったことがあり、その時に僕の年齢じゃまず会うことが無いであろうエグゼクティブな方々とお会いする機会に恵まれました。もちろん名刺も交換しましたし、ある程度メールのやり取りもしました。打ち合わせも重ねましたし懇親会とかもやらせてもらい、色々と勉強させてもらいました。 でも、仕事が終わればお付き合いはそれで終わってしまいました。 その時僕が感じたのは、人脈を築くってのは相手に与えられるものを持たなくちゃいけないんだ、ということです。相手に対して自分

キヨシローが他界してしまった。 癌というのはリンパまで逝ってしまうと両足棺桶に突っ込んでしまったようなもので、けっこうな確率で死に至る。覚悟はしていたけど、やっぱり寂しい。 圧倒的な歌唱力と、日本語をロックのリズムに乗せられる絶大なセンスと、どこかに母性に近しい優しさを内包している歌声が、すごく好きだった。彼のビブラートは絶品だ。最高のボーカリストの一人だと思う。 色々名曲はあると思うけど、僕が特に好きなのがデイドリーム・ビリーバーのカバー。というか、完全に別物になっている。この動画の4分10秒ぐらいからはじまる。原曲とは意味合いが違っているけど、自分の物語に変えて歌っているのが超絶カッコよくて目にも心にも染みる。 この歌は、明らかにキヨシローからの最愛の女性に対するメッセージだ。多分、生みの母と育ての母に贈られた曲だと思う。故人に向けられている。 この歌には、僕が｢デイドリーム｣を信じて

転職して３日しか経過していないんですが、小さい会社が大きい会社よりも圧倒的に有利だなって思った点が｢ダメなもんはダメ｣と割り切って方向転換できること及びそのスピードにあるように感じます。大きな会社は色んなものを背負いすぎてしまい、舵を切りたくてもまず舵を切ることが出来ないことが実に多いです。 大企業は多方面にビジネスを展開しています。時代の変化に共に採算が取れる事業とそうでない事業が明らかになっていきます。それは悪いことじゃないし、盛者必衰と申しますか、環境が変わればその事業が持っている価値のレベル・大きさも変化します。問題は、ここからです。ダメな事業から撤退する決断の次に待っている決断は、その事業に携わってきた人員の雇用をどうするか、です。ここがすごい難しいんだと思う。 ダメだからと言ってバッサリ切れば、明日は我が身だというコンセンサスが生まれ組織内で奪い合いが発生し、活力など無くなる。

転職先の社長に、そのようなことを諭された先週末。レンガで頭を打たれるような衝撃が走りました。 タイトルで言わんとしてることは何かと申しますと、｢オマエの価値を決めるのは自分でもなく、言い渡された値段でもなく、お客様が気持ちよくお金を払ってくださるかどうかだぞ。｣ということです。こう書くと当たり前ですが、やっていることが報われるかどうか見えない中で手を動かしている時に、どうしても損得勘定が出てきてしまいます。でも、損得勘定が考えたら成功なんか出来ないぞ、と社長は申されるのです。 前向きな技術者は、必ずと言って良いほど自分の作ったものに対するひそかな自負があります。当然のことです。たとえそれが｢DBから適当にブチ抜いて画面に吐き出す簡単なお仕事｣の集合だとしても、立派な成果物です。 でも、その自負があることとその成果物に価値があることは、全く別のことです。評価軸が違います。そして困ったことに、

アツいエントリなんで思わずTBうってみる。 この業界の問題、それはプログラムが、新人〜3年目の作業と位置づけられていることだ。 プログラマーの誇りを見せ付けろ - 山本大＠クロノスの日記 正確に言うと上級プログラマも初級プログラマも同じ値段で評価されるってことが弊害である、ってことだと思います。予めXXX万円で作ってねという予算が決まっていて、その予算をオーバーしないことだけが成果の基準にあることが問題だと考えます。このルールにおいては、極論ですがコード品質が高くても低くても大差が無くねっていう力学が働きます。 基本的にニッポンの受託開発のプロジェクトの場合は、大きく２つのプレイヤーがいます。 案件を立ち上げてお客さんへのコミット権限がある人・会社 立ち上げた案件をシステム化してデリバリする人・会社 ですが、今の流れでは工程が分断されちゃっているので、案件を立ち上げる人とシステム化してデリ

ホッテントリメーカーからタイトルを頂戴した。id:phaさんありがと。 社会人なら押さえておきたいフレームワーク思考 : LINE Corporation ディレクターブログが非常に人気で今年のアルファブロガー(というかエントリ大賞に見える)大賞にもノミネートされている。こういう記事はニーズがありそうなので、僕なりにフレームワーク思考についていくつかサンプルを用意し、僕が使うチャートのサンプルを紹介しておきます。 というか1000以上のﾌﾞｸﾏとか・・・嫉妬！激しく嫉妬！！ハンカチ噛んじゃう！！！！ そもそも議論しちゃいけないこと 個人の価値観に依拠し、お互いの主張を出し合っても全体として合意が得られそうにないこと。例えば｢浮気の定義｣とか。こんなのは議論したって全体最適なんて導けるわけが無いので、ビジネスの場では全く持ってムダです。居酒屋でやりましょう。 仕事で議論することの意味 あなた

また、お金の話についても、そもそも簿記（booking）・会計（accounting）・財務（financial）の区別がついてない人が多いです。 株式会社スターロジックの羽生章洋が書いてるブログ:起業・経営の必要条件 「やべー正直わかんねぇ、オレってだせぇ」と思った紳士淑女のために、ざっくりまとめてみました。突っ込みはゆるふわでお願いします＞＜ 簿記とは 企業が日々行う取引から、貸借対照表や損益計算書を作成するための元ネタ(総勘定元帳)を作ることです。単式簿記・複式簿記とかもあくまで方法論です。ただ、企業組織の場合は家計簿とは違い、発生したお金の結果だけではなくその原因について因果関係を踏まえて帳簿をつけていかないと、プラスとマイナスが正しく管理できない。つまり、5万でEeePCを買ったという行為だけを管理するのが単式簿記で、5万円のEeePC入手＆現金5万円の支出を紐付けて管理するのが

昨日誕生日が来て、無事2X歳になることが出来ました。今までをずっと振り返ると、ここまで生きてこれたのもなかなか奇跡的です。 ここ数年、本当に色んなことがあったけど、その中で僕が学んだことをいくつか書いておきたい。忘れないために。 みんなにいい顔は出来ない。 ヒトは立場によって思考を左右されてしまいます。従業員の立場と経営者の立場。お客様の立場と業者の立場。旦那様の立場と奥様の立場。嫁の立場と姑の立場。僕の立場とあなたの立場。自分で物事を考えているつもりでも、立場上合理的なことを考えてしまう。 右に向いても左に向いても何かにぶつかってしまうような時でも、僕が立ち位置を決めなくちゃ全員が前に進めなかった。誰かに顔を向ければ誰かには背中を向けてしまうけど、みんなにいい顔は出来ない。どっちつかずが一番良くないし、それは卑怯なことだ。 分岐点から逃げるな。 人生ってのは困ったものです。生きているだけ

本当はこういうのをエンジニアの未来サミットでお話できればよかったんだろうと思って、電車の中でふと思ったことをガンガン書く。 IT業界に携わってシステム開発を行っている方々で最も多い層は、受託開発という形でシステムを作ったりメンテナンスをされている方々のはずです。江島さんのニッポンIT業界絶望論というエントリが出てから「受託開発なんてうんこ」みたいな空気がすごく醸成された感があると思うのですが、無自覚にふわふわとイノベーションにかぶれるのもいい加減にして欲しいと思います。 確かに受託開発には負の側面があります。誰でも始めることが出来る参入障壁の比較的ゆるい世界ですが、どこでも出来るような仕事しかやっていないような会社はすぐに行き詰ります。そういうお話は結構耳にします。受託開発という形態をとって実際には技術者を派遣しているだけの創造性のかけらもないような会社もたくさんあると思われます。こういう

久しぶりのガチンコSIネタ。 「人生のファイナルアンサーが見出せません。」「何なの？スイーツなの？」 SI子会社でのキャリアのメインストリームから外れた俺。 私が感じた範囲で、きっとこういうことでSIerの中にいて閉塞感を感じているのかなぁと思う点を書いていきます。 技術的興味関心にマッチするかどうかは運 私は５年間SIerで働いていますが、自分の興味関心のある技術を仕事(＝プロジェクト)で触れることが出来る機会は基本的に相当少ないと感じます。これが閉塞感を生んでいる一因だと思います。 仕事でJavaやりたいと言ってもJavaが出来る案件に自分がめぐり合えるかどうかは、ちょっと語弊がありますけど基本は運です。SIerは複数のプロジェクトを当然抱えており、あなたが無事プロジェクトが終わった時に次にアサインされるプロジェクトが.NETの案件しかなかった、というのはよくある話。また、会社の方針で

はてなで書き始めて2年が経ちました。ここ半年の間にホットエントリに入ることが多くなり、色んな方に見て頂けるようになりました。ブログそのものは4年前から始めているので、3年半の下積みの結果はてな村でちょっぴりアテンションを獲得できるようになりました。そこまで来てはじめてわかることもあったので、今日はその話をしたいなと思います。 はてなというのは「idありき｣のサービスになっています。ダイアリー、ブックマーク、スター、ハイク・・・。どれもがidを認識させるような設計になっています。はてなのidを書いただけでTBが打たれ、同じはてなユーザーならばエントリを引用しただけでTBが打たれます。これは恐らくはてな独自のサービスでしょう。このid制と過剰なトラックバックが、はてなという世界を狭くしています。 はてなダイアリーを開設する時にid:jkondoがどう考えたのかはわかりませんが、コミュニティ性善

GoTheDistanceではほとんど結婚・恋愛ネタは書かないんだけど、まぁたまには。失敗事例を共有することはいいことなので。 離婚して1年して思うこと この人と僕とは理由は違うけど、まぁ同じく離婚経験者として一言申し上げておく。 スキンシップがなくなると、必然的に会話も減り、相手の考えていることがわからなくなった。そうして3年くらいかけて、ゆっくりとゆっくりと他人に戻っていった。 離婚して1年して思うこと すごくわかる。特に家庭内や異性におけるコミュニケーションは言葉よりもスキンシップの方が大切です。スキンシップの減少⇒会話の減少⇒共有できる時間の減少⇒相互理解の減少⇒別れというコースをこの人も辿っただろうし、僕も辿った。肌と肌が触れ合うことではじめて伝わってくる情というものがあって、それは決して言葉では埋められないもの。スキンシップがめんどくさくなったら、もう惚れていないんだよ。僕はセ

最近よく思います。 システム開発の上流工程においてはコードは出てこない。言葉や図解で埋めつくされて、最終的には日本語でしかない。設計書とか仕様書とか。で、この大抵上流工程ではこれらのドキュメントに対するレビューなるものがあるのですが、これが実に無益なものだと感じることが多い。こんな所でPDCAまわして何が面白いんだろうとよく思う。 ここでチェックする多くのことは、言葉の解釈に関することがほとんどです。 この言葉はプロジェクトで使われていない 書き方が統一されていない 誤字脱字が多いので直せ。 この文章ではこのように解釈される恐れがある ここではこのような話になっていたがどうなのか こんなんばっか。どこもそうだと思う。解釈の違いは、要件の違い。なんちゃって。 で、結局こういうことを繰り返していくうちに段々とドキュメントがグダグダになっていく。そして繰り返していっても前提が変わってしまえば全部

先日のエントリーがアツいことになっており、初のホッテントリ入りに若干興奮している今日この頃です。同じような問題意識を持っておられる方が多くいらっしゃることがわかり、改めて書いてよかったなぁと思っています。 話の流れは相当グダグダなのですがあのエントリーで表現したかったことは、「アメリカにSIerが存在しないのである」⇒「アメリカは素晴らしいのである」というのが骨子ではなく、いわゆるディフェンシブなシステム開発を強いられているSIerというのは、いわば奇形児のような存在ではないかということです。 改めて、ディフェンシブとは 言わずと知れた名エントリから。 ディフェンシブな開発とは、開発途上のリスクを計画上の時点でなるべく潰し、開発側に発生する利益分を減らさないような開発の進め方をすることを言っている。加えて、この場合、開発側はリスク分はなるべく多めに見積もり金額にいれようとしがちだ。 なぜそ