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

新卒準備カレンダー 2011春 : ATNDいう、4月から新卒として特にIT業界に就職される学生の方に諸先輩が日替わりで激励のメッセージを送るという素晴らしい企画があり、それに参加させて頂きます。既に多くの方が示唆に富むエントリを書かれており、これまとめてiPhoneとかで読めたらいいのにと思う今日この頃です。 Who Am I ？ お前誰よってことで、簡単な自己紹介を。 2003年に某大手商社系SIerに新卒で入社しました。サーバサイドはJava、クライアントはFlash/Flexなどを駆使したRIAアプリケーションを構築する部署に配属されて、Webプログラマとして社会人生活をスタートしました。その後開発チームリーダー→プロマネというパスを歩み、途中からコンサルタントとしてIT戦略立案／内部統制の支援のお仕事をやってました。毎年色んな仕事をさせてもらい、偶然にも僕のクライアントは全て大企

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

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

SIerでプログラマ(PG)からプロマネ(PM)までやった僕が通ります。 ＰＭになりたくない症候群 - ベテランIT営業が教える「正しいITの使い方、営業の使い方」 - ZDNet Japan 一度でも失点をしたらそこからリカバリーすることが困難な立場に放り込まれるし、放り込まれたら現場の裁量で何とかするしかないというデフェンシブなやり方に起因する構造的なPM疲弊体質。確かにコレは、嫌悪される理由の１つにあると思います。ただ、それだけではないな、と。技能という側面で考えても嫌悪される理由があるのかな、と思いました。 要はPG→SE→PMというキャリアパス、についてですね。 色々な議論がありますが、何が問題かと言えばプログラマとして未来を奪い去ってしまう所が過多あるってことに尽きるように思います。技術は移り変わるわけですから、プログラマでありたいなら保有スキルが陳腐化しないようにしなくてはな

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

Tumblrをぷらっと見ていたら、非常に刺激的な記述があったので思わずReblogした。 http://gothedistance.tumblr.com/post/321109250/yuco-seepassyouagain メシの種になる実践的(practical)な知識と全然それだけでは飯の種になりそうもない抽象的な知識のバランスを考えさせてくれます。 僕は大学卒業する直前まで、全くpracticalなスキルを磨いたことはありませんでした。アルバイトでISPのテクサポをやってたけれど、多少のネットワーク知識とHTMLが書けるぐらいの知識しかなかった。プログラム言語やデータベースに触ったことがなかった。経済とか経営とか全然興味が無かったし、今ではネタだろって言われるんですが、僕は英文学科を卒業しており学歴上は文系なんです。卒論を書く時にはじめて｢論文｣というものに触れて教授に論理的なアプ

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

業務以外でも自分の技術的能力を高めようとすることに対して、そのモチベーションはどっから来るんだろうと不思議に思う人がいっぱいいるというお話。 はてなダイアリー 趣味なんでしょ？ - GoTheDistance そろそろ「好きだからできるんですよね」について一言いっておくか - じゅんいち☆かとうの技術日誌 僕も昔こんなことを言われて、なんでだろって思った。 多くの人は自分の時間を削って頑張っていることに対して不思議に思うようなんですね。どうしてこの人は、がんばっているのだろうと。別に業務上必要ないことなのにって。で、やっぱり｢好き｣だからできるのだろう⇒趣味でやっているんだろう、ということになるらしい。 違うんだよねぇ、それ。物事は好きだから続けられるものじゃないんだよ。簡単に言えば、習慣なんだと思う。溶け込むことができているか、って所だと思う。 僕はクルマが好きで麻雀が好きだけど、それに

なんで管理について書きたいのか 動機です。 単純に「プログラミングだけできればいい」「SIする人は要件定義だけやれ」という声を聞くと切ないからです。 ただし、わたしは個人的に、開発というお仕事においてプログラミング技術が何を差し置いても最重要だと思っていますから、その軸は絶対にぶれない、ということを念押ししてから始めたいと思います。 ひとりにはなりきれない空を見あげる これも昔思ったことなので、取りとめも無く書いておきたいと思います。 技術リテラシーが死んでいる人間が立ち上げた or 回しているプロジェクトは高い確率で砂上の楼閣のように崩れ落ちていく。だからプログラミング技術に代表される技術リテラシーは必要不可欠。だけど、全員が全員その道を突っ走ると今度はビジネスにならない。取ってきたシーズをプロジェクト化できない。僕は後者が出来ない自分でありたくないという思いから、スーツ的な何かを２年ぐ

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

福岡に遊びに行った時に、id:komoko-iさんから頂いた本があった。それが、これ。 非属の才能 (光文社新書) 作者: 山田玲司出版社/メーカー: 光文社発売日: 2007/12/13メディア: 新書購入: 3人 クリック: 155回この商品を含むブログ (148件) を見る 先日読了したので、読後の感想をブログに書こうと思う。 他人と違うことを恐れるな、楽しめ！ この本の主題を一言で言ってしまえば、多分コレに尽きる。 違うことを謳歌したら世界が閉じることはないし、自分らしく生きていけるよって背中を押してくれるような本だった。僕も｢他人と違うことを楽しむ｣ことに強い意味を感じている。言われたことをそのままやるのは、大嫌い。違うことを平気でやるから誰かのアンテナにひっかかりアテンションを得ることが出来る。赤い背景の中に白があるから目立つわけだって、同系色に埋もれていたらそのまま埋もれてし

メディアに乗るとなんでも釣りっぽく思えてしまう汚れた僕ですが、本件については数年前からとっくに曲がり角に来ていると思っています。 受注するだけの製品販売や顧客の言うがままに作るSI（システムインテグレーション）、委託されるだけのアウトソーシング、報告書を作成するだけのコンサルティング─。IT業界に染みついた「受託体質」は、ビジネスモデルの転換期を迎えているユーザー企業のシステム構築・維持にとって、むしろ足かせになっているのかもしれない。 乱反射 - 曲がり角にきた受託体質のIT業界 顧客は共同で事業創造を望んでいる：ITpro こちらの記事で使われている｢受託体質｣の意味は｢要件はお任せしますので、労働力だけ提供しますという役務提供型のサービス｣という文脈のようです。それって単なる御用聞きだから、ビジネスモデルの改善・革新を求めているユーザー企業と足並み揃うわけがないよね、という趣旨だと解

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

yuripopとyamkazuのエントリーを読ませてもらった。 「外注と同じ仕事しかしないなら辞めろ」 - 歩きつづける　ゆり　咲きつづける 製造を行っていないSIerで製造出来る社員に育つには - 山本和樹のはてな日記 2人のエントリを読ませてもらって思い起こされたのが、豆蔵の萩本さんのこちらのコラム。たぶん、今の2人にすごく役に立つコラムだと思う。是非全文を。 人のマネジメントと、技術のマネジメント あまり開発経験がないにもかかわらず、若手エンジニアにプロジェクトマネジメントを任せる企業が増えているようだが、私は反対だ。人はマネジメントできても、技術のマネジメントができないからである。 技術のマネジメントとはどういうことなのか。簡単にいえば、開発で使用するソフトウェア技術、開発手法やツールなどの長所・短所を見抜いてその組み合わせを考え、メンバーの開発工数などを見積もることである。人のマ