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

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

PublicKeyの新野さんが刺激的なエントリを書かれているので、便乗してこれからのSIerの未来像を考察してみます。 顧客にとってITコストの削減はSIerにとって売上げの減少になります。顧客がクラウドのサービスをそのまま利用することは、開発やカスタマイズをすることに存在意義があるSIerそのものを脅かします。 クラウドの存在は、SIerにとって逆風のように見えます。そしてSIerの存在もクラウドの普及にとって逆風なのかもしれません。 日本のSIerはクラウド普及の逆風なのか？ － Publickey クラウドとSIerの価値が相反している為、お互いにとって｢目の上のたんこぶ｣ではないかという意見ですが、現状その通りだと思っています。開発せずにスムースにサービスを利用できることがクラウドの強みでもありますが、システム運用をクラウドによって完結させることができる故にシステム基盤の構築･運用

久しぶりにスーツとギークのお話。一説にはスーツ女子とめがねっ娘ギークの萌え論争だと言われています、ええ。 ｢要件決めて話をつけるのは誰でも出来る仕事であって、それをプログラムに落としこむのが大変｣ということがわかっていない、というトピックをあるブログのエントリで見つけました。もっと言ってしまえば、｢何かトラブルが起きた時にお前らは何の役にも立たない。技術者がいなかったらスーツは何が出来るんだ｣という話に発展する。お気持ちわかります。 ここで言わんとしていることは、｢技術がわからないスーツはいつも｢このボタンを押すと注文明細が出る｣レベルの要件しかもってこない。そんなもん誰でも出来る。そこからプログラムに落とし込む所が大変。｣だという話だと思います。確かに｢このボタンを押すと(いくつかのルールを元にDBを更新して)帳票(フォーマットやレイアウトは？)が出力されてグラフ(レイアウト・縦軸と横軸

田中克己の針路IT - ソフト会社に明日はない？：ITpro ＿＿＿_ ／::::::::::　 u＼ ／:::::::::⌒ 三. ⌒＼ 　　　　 　ウソだろ！？ 今期、いきなり利益半減？ ／:::::::::: （ ○）三（○）＼　　 　 　　　　　会社どーすんだろ・・・orz |::::::::::::::::⌒（__人__）⌒ 　|　＿＿＿＿＿＿＿_ ＼::::::::::　　 ｀ ⌒´ 　 ,／　.| |　　　　　　　　　　| ノ::::::::::u 　　　　　　 　＼　| |　　　　　　　　　　| ／:::::::::::::::::　 　　　　u 　　 　　 | |　　　　　　　　　　| |::::::::::::: ｌ 　u　 　 　 　 　　　　　| |　　　　　　　　　　| ヽ:::::::::::: -一ー_~､⌒)^),-､　　　| |_＿＿＿＿＿＿__| ヽ::

全くもって、その通りだなぁと思った。 初期段階ですべての意志決定をしても、問題はコードを書き始めてから表れるのです。そして終わりに近い時点で判断する方が、より正しい判断ができるはずです。ですから、できるだけ意志決定は先延ばしにして、正しい意志決定をしようとするのがアジャイルのやり方です。 「有能な人がコードを書くべき」「意志決定はできるだけ先延ばし」「契約を変えるのは難しい」アジャイルの専門家の答え － Publickey ｢ウオーターフォールとは｣のラベル貼りの議論になるとめんどくさいから、とりあえず｢初期段階ですべての意志決定をしようとするシステム開発の進め方｣という定義で話を進めたいと思います。 滝 ｢要件定義｣→｢設計｣→｢実装｣→｢テスト｣という一連の流れがあって、ウオーターフォールなるものは前工程が100になるまでひたすらそこでPDCAを回します。100になると言う意味は、ソフ

atsuizoさんのこのエントリを読んだ。 そろそろ内製回帰について一言いっておくか。 - なからなLife 同時期に内製派として出会い、立場は変われど目指す方向が同じの友人のエントリを読んで、歯がゆい気持ちになった。 上記エントリの骨子は｢プラスを広げる内製のメリットを引き出すためにも、「言われたからやる」じゃなくて「提案して、実行する」ことに価値がある、それをモチベーションにする組織作りをしなくてはならない｣ということにあり、その点については完全に同意です。 でも、現場じゃ忙殺されているうちにわかんなくなるんだ。何のために今この仕事をしているのか、が。それを伝えるのは、経営の仕事なんだ。 僕は中小企業に属しているから経営と実際の業務と情報システムの３つの軸を自分の中に立ててバランスを取ることができていますが、ほとんどは｢経営｣｢現場｣｢情シス｣に役割が別れているため、その調整コストたる

2009年、SIerの現状を俯瞰する − ＠IT自分戦略研究所 今週の金曜日です。テーマは得意の｢内製化｣です。生々しい経験を可能な限り詰め込んでみました。 ああ、僕も出世したな・・・！こんなところに記事を書けるようになるなんて・・・！ この前セブンアンドアイさんが内製したECサイトで個人情報ダダ漏れというニュースがあり、僕のこの記事を出すタイミングでやってくれるなーと思いつつ内製派の私としては(´･ω･`)ｼｮﾎﾞｰﾝなわけでございますが、これは内製・外注以前の問題なのではと思います。組織的な問題でしょう。外注しても同様の問題を発見し解決できる組織的なサポートが無いなら、おなじことなので。内製の場合は適切に的確な技術やツールを選ばないと痛い目見ますよ、という暗示になってくれてありがたいぐらいに考えています。 しかし、社内に閉じたシステムなら自分達が痛い思いするだけで済みますが、外部公開し

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

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

あきみちさんが良いことをおっしゃっていたので、僕も相乗りする。 個人的な感覚だと、「勉強」という単語は、お金などの対価を受け取って何かをしているときには迂回すべき単語であるような気がしています。相手は「専門家としての知識や意見」に対して対価を払っているのであって、「その人の勉強」に対してお金を払っているわけではないからです。 Geekなぺーじ:「勉強になりました」は禁句 全面的に同意です。 ホント難しいのは「勉強」という言葉の受け取り方なんですね。あきみちさんもおっしゃっておられますが、言っている本人は相手の意見が正しいと思うから「勉強になりました」という言葉を使うのですが、この言葉を使ってしまうとどうしても上下感が醸成されてしまうので、「あんたはうちが困っているから意見や知見を提供する側なのに、なんでこっちがお金を払って勉強させなければいけないのよ」と受け取られてしまうという話です。 し

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

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

いろんな見解があったほうが面白そうなんで、参戦してみる。 タケルンバ卿のBotの作成からあきみちさんのエントリに飛び火し、そこへまなめさんがTB打ってみたら呼ばれて飛び出たダンコーガイ状態になっているようです。 何とかbotができました -タケルンバ卿日記 Geekなぺーじ : 初心者はプログラミングをどうやって学ぶと良いのだろうか？ 304 Not Modified: プログラミング初心者はギークから学べるのか 404 Blog Not Found:いきなりCの方がよっぽど難しい 僕は弾さんと同じ意見 プロになるためには、確かに原理も知らなければならない。JavaやPHPしか知らない「プログラマー」には、私だって「スイーツ(笑)」と頭につけたくなる。しかし、それは原理から学ばなければならないということを全く意味しない。むしろ原理は、動作感覚を会得してからの方が学びやすいのだ。 いきなりC

スーツ界のカリスマ id:gothedistance とトゥギャザーしてきた スーツな会社に勤めていてギークになりたいのに葛藤しているid:int128と昨日トゥギャザーしてきました。スーツな会社やめたらいいのにというのはあまりにも雑なので、スーツな会社でどう立ち位置を築けばいいのかを頑張って書いてみることにします。 スーツな会社には理系の人間はいないわけではありませんし、必要とされていないわけでもありません。id:int128も相当なギークです。彼らのような人間がごろごろ入社しているのは事実だし、ウチの会社にもギークな人はいっぱいいます。id:int128の会社も僕の会社も大きな会社ですから、スペックには結構うるさかったりします。大きな会社がその規模を保つためには、当然のことながら多くの売り上げを叩き出さなくてはなりません。多くの売り上げの意味する所は多くの人間を使うということです。１人

ネタ元はこのあたり。 SIer と Rails とエンタープライズと エンタープライズにおけるRailsの価値とは 弊社の某エロい人がRoRに萌えており「おお、なんて生産性が高いんだ。もうWebアプリなんて全部これでいいじゃないか。」とか本気で思ってそうなので萎える。言語の違いは時にはビジネスモデルの違いにつながることが理解できないようだ。言語ってのは文化なの！これからはRubyを全面的に取り入れ開発標準もRubyだぁぁぁぁとか言い出したらどうしよう。グーで殴るしかないかｗ 本来、コード量の少なさや、CoCを前提とした設定の少なさが価値を発揮するのは、メンテナンスの場面です。読み込まないといけないコード量の少なさと、少ないコードの変更で修正ができることが、その理由です。そのためには、大前提として、Ruby（on Rails）らしい、プログラムを作っておくことが必須なので、マネージャはその辺