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

日本実業出版社の今野様より献本御礼。 「IT専門調停委員」が教える モメないプロジェクト管理77の鉄則 作者: 細川義洋出版社/メーカー: 日本実業出版社発売日: 2014/07/10メディア: 単行本（ソフトカバー）この商品を含むブログを見る なぜ、システム開発は必ずモメるのか? 49のトラブルから学ぶプロジェクト管理術に続く、細川氏の第２作。前作ではITシステム開発の難しさを題材に網羅的にユーザーやベンダーがプロジェクト運営で失敗してしまうポイントを挙げられておりました。いわば、入門編という位置づけですね。本作では実際にプロジェクト運営でモメてしまう所も判例を通じて論じており、いわば「実践編」という立ち位置になっています。モメてしまうポイントを先回りして、フェーズ毎にヘルスチェックをして頂いております。 本書は女性弁護士キャラは出てきません。悪しからず。 システム開発は複雑系の極み 本

著者の倉貫さんより献本御礼。 「納品」をなくせばうまくいく ソフトウェア業界の“常識"を変えるビジネスモデル 作者: 倉貫義人出版社/メーカー: 日本実業出版社発売日: 2014/06/12メディア: 単行本（ソフトカバー）この商品を含むブログ (1件) を見る 納品のない受託開発とは 簡単に言うと「一括請負契約をしないで、お客さんの欲しいシステムを受託開発すること」になります。何故一括請負契約をしないのかということが理解できないと、このモデルで契約する意味を感じられないでしょう。本書の主題の１つに「完成(納品)を前提とした一括請負契約がシステム開発をダメにしている」という問題意識がありますので、そこを重点的に補足したいと思います。 一括請負契約の問題点 作ることが目的になる 一括請負契約では完成責任を果たすことが求められます。その為に要件定義を行い完成となる条件を決めます。そして要件を満

先日、あるWebサイトのリニューアルの企画資料作成作業の最中で、作業に煮詰まってからのグッドアイデア降臨。紙に整理しようというタイミングで会社の代表電話が鳴ってしまい悲しい思いをしました。その内容が腐れた電話セールスだったので余計悲しかったです。 個人電話なら折り返すという技が使えますが、代表電話はスルーして折り返すことが出来ない。どんな内容かはわからないけど、出なくてはならない。憎いあンちくしょうであります。 それは僕の個人的な恨みなのですが、改めて会社の代表電話って役立たずなケースが多くてどうなんだろうって思うことが多くなりました。ちょっと吐き出してみます。 代表電話の内容はノイズばかり ２年近く代表電話を取ってきて、代表電話にかかってくる内容はノイズがとても多いです。代表電話にフィルター機能があればどんだけ楽かと思います。 不要なセールス電話を自動的に撃退し、定型的なお問い合わせはコ

BacklogとかサイボウズLiveとかをご存じないクライアント様が結構多くて、そのような方々にとってのコラボレーション・ツールはほぼ間違いなくEメールになります。まずその啓蒙から入って仕事をさせて戴くことが多くなりました。 お打ち合わせの場でAction決めて、その後はちょいちょいメールフォローでだましだましやってこれた時もあったのですが、やっぱこれダメだってことになったので、その話をしたいと思います。 Why Email Collaboration SUCKS そもそも、Eメールは双方向性があるようで無いツールです。Eメールでの各種進捗管理は、以下の点で非常に効率がよろしくありません。 １つのメールに複数の事項が含まれることがある 例えば、Xさんに対してAという事項の修正事項が記載されたメールに対して、Xさんが返信を行ったとします。その返信に対して別のBという事項のご相談があると、追い

ロジカル・コミニュケーションを考えるのにとてもぴったりのエントリが２つ並んでいたので、便乗させて頂きます。 「AともいえるがBともいえる」とか言う人の役立たなさ - Chikirinの日記 「Aしかない」とか極論を言う人の役立たなさ - プロマネブログ このように全く反対のことを２つ並べて考えるのが、最も思考訓練になると思います。「Aは最高や！」と「Aはマジクソ」の本が２つ並んでいる書店って気が効くなぁと思う。 何かを主張するのなら断定的であるべき 特にインターネットで顕著なんですが、何かを意見表明して主張をしたいなら言い切るのがベストです。ネットの文章はタイトルが全てとはよく言われますが、言いたいことが簡潔でないと伝わりにくくなりますし、読まれるかどうかも怪しくなります。読まれないと始まらないという、鶏卵問題がありまして。 実は「AともいえるがBともいえる」言説は、読者のためにならないこ

私の観測範囲が狭いということもあるんでしょうが、ある企業の決算において営業利益が98%減になった事例を知らないので飛びついてしまいました。この会社は平成24年に上場しておりそれ以前の数字はわからない為、2期のみの比較となります。 決算期 売上高 営業利益 H26年第１四半期 3.49億 0.02億 H25年第１四半期 3.98億 1.12億 ソースは平成26年３月期 第１四半期決算短信(PDF)にあります。 売上が12.3%減。不景気ですしまぁこれぐらいはどうってこと無いよなって思ったら、営業利益がとんでもなく減少しています。98%の減少です。トレンダーズのIR資料を読んで、原因は以下の２つにあると思います。 各事業のシナジーが全く見込めない件 １つは、大手顧客企業の開拓が想定通りに進まず大型案件の受注が減少したこと。ステマ問題があったことをほのめかす記述がIR資料に書いてあるので、ペニオ

ご無沙汰してしまっているmark-wadaさんより問題提起を頂いたので、最近話題になった「超高速開発」と絡めて書いていきます。 もしSIerのエンジニアがジョブズのスピーチを聞いたら（１） - Wadit Blog. もしSIerのエンジニアがジョブズのスピーチを聞いたら（２） - Wadit Blog. もしSIerのエンジニアがジョブズのスピーチを聞いたら（３） - Wadit Blog. もしSIerのエンジニアがジョブズのスピーチを聞いたら（４） - Wadit Blog. 僕のエントリに対する和田さんのご指摘をまとめると、ソフトウェアを作るにあたっては上流と下流の断絶があるのはマイナスなのは理解できるし、コードを書く時にはその断絶があると望むものを作ることは出来ないのも確か。だが、システムを作る時にはそもそもレイヤーをもう１つ上に上げるべき。スクラッチでコードを書く必然性など無い

僕はノマドに対しては否定的なのですが、その心情をうまく表現してくれているのがこちらのエントリ。 そもそも個人的な実感として、一つの組織に所属して、社畜と言われようがきちんとした成果を出す形で働き、組織と一緒に自分も成長した上で、その後独立なりなんなりするのが最終的に自由を手に入れる最も現実的な方法であることは間違いない。 (中略) ノマドというライフスタイルが存在するのではなく、自分にとって最適な形を模索したらそれがたまたまノマドだったというのがライフスタイルの正しい形のはずだ。 ノマドとかライフスタイルをテンプレで語ること自体の陳腐化と正社員とノマドの中間解 - Future Insight いや、もう全く同感。ノマドは目的じゃない。単なる結果でしかない。 典型的なノマド像は津田さんや佐々木さんのような、ご自身のメディアをお持ちのジャーナリストなんだろうと思う。publickeyの新野さ

全文は紙面でないと読めないのが残念ですが、非常に気になるニュースが飛び込んできました。 富士通、余剰ＳＥ変身作戦 富士通がグループで抱える約３万人のシステムエンジニア（ＳＥ）の大がかりな職務転換に乗り出した。一つのシステムを複数の企業などが利用するクラウドサービスがこのまま普及すれば、顧客の要望を聞いて個別システムを作り込むＳＥは仕事がなくなり、余剰人員問題が顕在化するからだ。野副州旦元社長の急進的な改革路線を修正した富士通はＳＥ余剰問題で軟着陸を目指すが、クラウドの奔流にのみ込まれる危うさもはらむ。 富士通、余剰ＳＥ変身作戦 実は富士通グループさんには弊ブログを頻繁にご覧頂いておりまして、企業ドメインの中では最もアクセスの多いドメインであります。クロールしにきているのかなと思うぐらい。ブログで言及している「なんでもかんでも受託開発では、もうSIビジネスで成長することは出来ない」という危機

もう何周目になるのでしょうか。｢情報システム部門が経営に貢献できていない｣というこの手の話は。 システム部門再生 - 経企部門が吐露する「システム部門への不満」：ITpro なんか色々ダメだしされていますが、重要なポイントは１つだけです。システム部門がビジネスに貢献するためには、自社の事業に対する理解が必要なだけではなく、その遂行手段である業務プロセスの理解が必要だ、という圧倒的な事実があることだけ。WhatとHowはクルマの両輪だと。で、この手の問題はシステム部門の問題ではなく経営の問題だという水掛け論が水びだしになるまで色んな人にされてFUDが残るのも味わい深いポイントであります。 自分達で管理できないものを改善できるわけが無い システム部門が業務プロセスの改善に貢献できない理由。突き詰めれば１つだけです。自分達で管理できずに、安易に外部に投げているからです。管理できないシステムをたく

株式会社クラステクノロジー代表の四倉氏の連載コラム「第151回」が、とても興味深いのでご紹介します。 【第151回】35歳定年説の真実-株式会社クラステクノロジー 詳しい内容は上記コラムをご覧頂きたく。 プログラマ35歳定年説とは 上記の四倉氏によれば、プログラマ35歳定年説とは｢1Step,1Stepの生産性に比例するので、長い間労働すれば高いアウトプットが出せ収入が増える。体力が下り坂になってきて徹夜や残業ができなくなるのが、大体35歳前後。体力低下と共に収入も下り坂。それに限界を感じてIT業界去ってしまう｣ということのようです。これをプログラマと呼ぶのかとか、ステップ数(笑)という憤りもあるでしょうが、｢ステップ数と売上が比例するため、いっぱいコードを書けば収入が増える｣という理屈は腑に落ちました。是非の問題ではなく、確かにその理屈なら体力勝負という表現も理解できる。 そして、この理

週末スペシャル - “スルガ銀−IBM裁判”を振り返る：ITpro スルガ銀行がIBMを訴えたのは債務不履行とのこと。つまり、債権者であるスルガ銀行が「IBMの責任で」自分たちが望むシステムを作り上げることが出来なかったと言っております。債務者(IBM)の責任である場合は、スルガは契約の解除や、不履行により生じた損害を請求することが民法で認められているそうです。スルガから契約解除＆損害賠償という強烈なワンツーパンチが飛んでいます。 要件定義を3度もやり直すという記述がありましたが、恐らく要件と要求が入り交じった「こーゆーことができるようになりたいです！」という夢と現実の区別が付かない仕様書があって、結局そいつの着地点がスルガもIBMも決められず「そのうちどうにかなるやろ」と宙ぶらりんのまま続けていき、現行業務とのギャップが後から後からザックザク出てきて、そのギャップに＋αされた機能が特盛り

というわけで今日のお話は、「やった！頑張った甲斐があって、就活もうまく乗り切れた！」とか、「まあ、オレのスペックならちゃんと大企業＆大組織に入れるのも当然だけどね。」とか言ってる人は、実は「完全に周回遅れです」みたいな場所で人生最初の｢働く訓練」を受けることがどれだけ自分の将来価値を毀損する可能性があるか、よーく考えてみたほうがいいんじゃないか、ってことなのでした。 将来有望な若者の将来価値を毀損する、大きなワナ - Chikirinの日記 この記述に思うところがありますので、ちょっと書きたいと思います。 僕は6年間新卒で入社した大企業で働いておりました。今は従業員数人の中小企業で働いています。ちきりんさんが指摘する｢完全に周回遅れです｣の意味を身をもって経験しています。 周回遅れの意味は、その企業から一歩出たら全く役に立たないシゴトのやり方やアウトプットに飼い慣らされていることで、外に出

日本のSI業界でこそ、専門の技術者の必要性がもっと見直されるべきではないのか？ - 達人プログラマーを目指してを拝読しました。この手の議論は定期的に出てくる根の深い問題でありまして、1億年と2000年前から多くの方に言及されています。しかし、それほど大きい問題であるということです。一概にああしろこうしろで片付く問題ではありません。 色々論点はありますが、「技術を売って社会貢献している業態なのに、一番重要な技術者を軽視するってどういうこと？」という１点に集約でき、上記エントリの主題も同じです。技術onlyの専門家の存在が認められないのが問題だと。しかしですね、「技術者そのものを売ってるんだから、軽視云々を言ってもどうしようも出来ない」という果てしない平行線を辿っていることが見えているでしょうか？ブルーハーツの「弱いものたちが夕暮れ　更に弱い者を叩く」というフレーズが思い起こされます。 技術者

先日知人と飲みに行ったんですが、こんなエピソードを聞かせてくれました。 とある小売店に納めた商品の伝票が、システム上に打ち込まれていないにも関わらず切られているという食い違いが発生。システム上で計上されていない伝票が宙ぶらりんになっておりました。 ・・・・おかしいですね、と。 「なんで伝票しかないの？」 おっと上司がご立腹でございます。「伝票しかない＝誰かが犯した間違い」という図式が先に浮かんできたんでしょう。伝票を入れずに商品を送るなんてあり得ないだろバカかお前と言う５秒前な、爆弾岩がメガンテしそうなピリピリとした雰囲気を目の前に部内の緊張ボルテージは最高潮。しかし、知人は冷静でした。 だって、先方に荷物が着いているかどうかさえ裏を取ればいいだけの話なんです、と。 納品伝票は後付でも構わないし、単純に知人の会社が手順踏まずにかっこわるいだけ。争うことでもない。出荷のミスを経理が気づいてく

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

人間関係で一番難しいのは、距離感をつかむことじゃないかなと思います。 距離が近すぎれば自分の領域が侵害されますので息苦しくなり、つぶされるような状況に置かれることもあるでしょう。かたや距離が遠すぎると疎外され孤立していると感じてしまう。近すぎても遠すぎても、ダメ。もちろん近い遠いを感じる距離は、各々違うわけなので余計難しい。ウェットな付き合いを好む人もいれば、ドライな付き合いを好む人もいます。僕は気分屋で気難しい上に多少の距離を求めるドライな性格なので、不必要に距離感をつめられるのは結構ツラく感じます。 距離感でぐぐっても今ひとついいなぁと思うのが無かったので、僕が学んだ幾つかのことを書いておきます。 距離は詰めるものじゃない 距離は縮まっていくものであって、詰めていくものではない。 カリスマホストの零二が言ってたんですが、｢相手に何かを与えることが出来るやつはゴマンといるけど、その相手に

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

魅力的な文章はその人なりの色を持っているよね、という所から思考を広げてみました。そもそもその「色」ってどうやって作られるのか、ということです。 僕はギターを数年間やっていて一時期バンドもやっていたのですが、オリジナリティは全く発揮できませんでした。要するに、曲を作るということができなかった。音楽的引き出しが少なすぎて、自分が作ったアウトプットに自信が持てませんでした。そこには、全く自分の色はありませんでした。 楽器を弾いて「作品を追いかける」ことは誰にもできるのですが、「新たな作品を作る」ことは、技能以外の何かが強く求められます。 翻って他のことに目を向けてみます。文章もプログラムもその点については同質なのではないかと考えています。文章を書くことは誰にでもできる、しかしそれが１つの「作品」として世界観を内包しているか・感じられるかは全く別の話です。プログラムも勉強すれば書けるようにはなりま