はぶさんの日記にわが意を得たりという記述があったので、脊髄反射TB。 エンジニアはともすれば「正しさ」を追求します。他者に対する説明も、いかにそれが正しいかという観点で話をします。ですが正しいだけで他人の心に対して鈍感であっては、決して魅力的な存在にはなれないと私は感じます。 閉塞感を越えて 私はいわゆる｢スーツ｣という立場に立ってクライアントの所に向かいますが、まだまだこの「正しさ至上主義」から脱することが出来ません。コンサルタントというのも、エンジニアと同様に「如何にそれが正しいか」という観点で話をするのが基本です。御社にはこれが必要なんです、こうすべきなんです。その情熱をPowerpointを武器に伝えていく。正しさを追求することはエンジニアもコンサルタントも同じなのですが、その正しさがクライアントの「コンテキスト」に沿っていない場合が問題です。単なる押し売りになってしまいます。理屈

各所で「SIerは泥のように10年働くのか？」「いやだ」とか、 何やらいろいろと議論されているが、私自身はファーストキャリアが SIerでよかったと思っている。 それを「SIerとしてキャリアを積んで良かったと思える10の理由」 として具体的に述べたいと思う。 今後、SIerとして日本のビジネスプロセスをバックグラウンドで 支えていく、多くのエンジニアの参考になれば幸いである。 1〜6はマインド面にとって良かった事。 7〜9はスキルセットとして身につける事ができた事。 10は私自身が確信している事。 ここで述べるSIerは「クライアントのシステム構築の請負を主な業務 とするシステム構築業者」の事だと思っていただきたい。 1.勉強ぐせがつく。 テクノロジーの陳腐化するスピードが早いため、常に知識を アップデートしていかなければならない。 資格の種類もOS、アプリケーションサーバ、データベース

昨日、NTTデータに「お前は最近、NTTデータに批判的でけしからん」ということで、呼び出されました。もちろん、「批判的でけしからん」というのは冗談ですが、私が、NTTデータを嫌っていると思っているデータ関係者は、実際多いようです。 データの偉い人の発言に対して、それはちょっとおかしいんじゃないのといったことはありますが、データを嫌いといったことはもちろんないはず。 データの社員の中に根強くある(と思う)「プログラミングがあまりできない人でも何とかなるように、ガチガチにルールやツールで縛る。できる人はスキルを発揮できなくなるかもしれないけど、それはしょうがない。」という考えは、個人的には好きじゃないけど。大規模なプロジェクトをまかされるSIerとして、そう思う気持ちは良くわかるんだけどね。 話し合いの中で、私が言ったのは、できる開発者が力を発揮できるように、体力勝負になってしまうような縛りは

日本のソフトウェア産業とかSI業界が世界に出て行けない要因は気合いとか技術力ではなく産業構造や規制に起因していることが分かったし、日本でトップに立った会社が世界に出て成功するかというと難しいと感じている。 日本のSI業界は、「世界に出て行けない」んじゃなくて「世界に出て行く必要がなかった」というのが、事実だと思いますよ。国内で儲かっていれば、リスクを犯して海外に進出するメリットがないもの。 自動車産業だって、国内では十分に成長できなくなったから、海外に進出したんでしょう。 国内のSI市場が既に飽和しているかというと、そんなこともないと思います。これは、あくまで自分の感覚ですが。 でもうまみのある儲けの機会が減ってきているのと、海外から黒船が来日している、だからNTTデータのようなこれまで成長を続けていた企業が騒ぎ出しているんだと思う。 「自動車のような産業構造に再編すべきだ」。NTTデータ

人によってプログラム設計書の定義が違っていそうなので、最初に定義しておきます。ここでいうプログラム設計書は、ほとんどプログラムと対応するようなロジックが記述されているようなものです。 プログラム設計書を作るのは「誰が書いても同じコードにするため」だけでなく、元請けがレビューするためでもあります。元請けがプログラミング言語を読めないので、日本語に落としてレビューします。コードを書いてからプログラム設計書を作ることもあります。 プログラミングがあまりできない人が、ちゃんとしたプログラム設計書はかけないのと同じように、プログラミングできない人が、プログラム設計書のレビューはできません。 当然だよね。プログラミングができないのなら、プログラミング言語を自然言語に翻訳したプログラム設計書を理解できるはずがない。 できるとしたら、誤字脱字、単語が統一されていないとか、日本語が変だとかそんな指摘くらい。

浜口さんの言葉には、ブクマや突っ込みを生み出す何かがありますね。 したがってシステムの大規模化は、必然的に想像以上のコストアップと信頼性リスクの増大を招くものであるとの認識が必要になる。 きました。想像以上のコストアップだそうです。 そんな浜口さんに贈ります。今よりコストダウンさせて、SI業界を良くする方法。 例えば、誰が書いても同じコードにするために、プログラム設計書(内部設計書)を今、書かせているとしたら、そんな無駄なものはやめたほうがいいと思う。 プログラム設計書は、自然言語で書きます。プログラムは、プログラミング言語で書きます。どっちの言語が、プログラムを書くのに適しているかといえば、誰が考えても、プログラミング言語ですよね。 いきなりプログラミングはできない人もいるから、プログラム設計書が必要だという人もいるかもしれませんが、それは、間違っていると断言しましょう。 いきなりプログ

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

「自動車のような産業構造に再編すべきだ」。NTTデータの山下徹社長はインドや中国など海外ソフト会社が日本市場に本格進出してくる前に、ソフト産業の構造改革を実行する必要性を説く。日本のソフト産業が崩壊の危機にあるからだ。 パッケージベンダが自動車産業を参考にするのは、100歩譲るとありかもしれない。消費者に受け入れられるだろうという予想にもとづきプロダクトを開発していくモデルだから。 でも、やっぱないな。車は、多少の違いがあっても、どれも基本的な構造は同じ。パッケージは、いろんなものがあるからね。 それに対して、SIは一品ものだもの。規格(パッケージ)通りじゃないものを作るのがSIです。 マフラーだけを作るソフト部品会社、タイヤだけを作るソフト部品会社と、システムインテグレータと呼ぶシステム組み立て会社に分業化することで、インテグレータはソフト部品会社から調達した部品を組み合わせてシステムを

皆さん，2008年の目標は何ですか？ 私の目標は「健康的に太る」。そう思って食生活を変えようと牛タンを食べましたが，すぐにギブアップ。うーん，パスタなどの穀物で太るか。エビちゃんのように筋肉もつけたいんだけどなぁ。 最近，業態としてのSI（System Integration）は不人気だ。3Kと言われたり，クリエイティブじゃないと言われたり。確かに，SIer様と働くことが多い私としては，正直この業界で魅力的な人と会うことは少ないとは思う。 ただ，これだけは言える。プラクティカルという意味で，SIerの方々は非常に優秀だ。なぜなら，物事を構造化してまとめる能力と，決まったゴールを目指して何かを作るという点では，他の業界の人に比べて抜きん出た力を持つから。 しかし，それでも一緒に働いていると「オヤ？」と思うことは多い。今回は「SIerのジレンマ」と題してSIの実態を紹介したいと思う。 地獄の社

やっぱこれかなって思う。 よくあるパターンなのですが、｢顧客側の意思決定者」⇔「顧客側の担当者」⇔「私たち」という構図。直接の対面する相手は担当者の方で、実際にプロジェクトの意思決定をされる方は後ろにいらっしゃるというパターン。逆にこういうのが多分一番多くていきなり最終的な意思決定者と直接コンタクトが取れる、意見を述べることが出来る、というのは少ないと思います。 こういう時に最も起こりやすい葛藤は「顧客の担当者がYESなんだけど、顧客の意思決定者がNoで巻き戻る」というもの。これを経験したことが無い人はいないと思うのです。また「自分のチームリーダーがYESなんだけど、他会社のPMがNoでしわ寄せが来る」なんていうケースも基本的なケースです。結構ウェットです。立場が違う複数の人間が交じり合った中で共通なYESを作ることが、どれほど難しいことか。 こういう状況には一貫した類似点があって、「問題

情報システムは「見た目」である――。こんなテーマの特集を執筆しながら、ふと我に返った。これは自分自身の仕事にも、全く同様に当てはまる、と。 「読んでもらえれば分かります」。記者という職業にとって、これは「禁句」である。いくら素晴らしい内容の記事でも、読んでもらえなければ無価値。だから記者は、見出しに最大の努力を払わなければならない。読者が雑誌や新聞をめくって、パッと目に入ってくるのは見出しだからだ。記事レイアウトの見やすさ、図や写真の的確さも欠かせない要素だ。 読んでもらえて初めて記事に価値が生まれるのだとすれば、記事の「見た目」がその価値を左右すると言える。 こう言っておきながら、自身を振り返ってみると非常に心許ない。もちろん気を遣ってはいたつもりだが、まだまだ足りないと思い至った次第である。 「使ってもらえれば」は禁句 実はほかにも、これと同じ感覚にとらわれたことがあった。Window

勢いで書く。 スーツ側の人は業務内容が密接にプロジェクトや会社の中の話と結びつくことが多いので、はてな界隈ではなかなかスーツ側の人はスーツ側の濃ゆい話を書くことが出来ないことが多いようだ。圧倒的にスーツ側の人間がはてなを始めとしたブロゴスフィア全体で少ないなぁとつくづく思う。QAも少ないけど。この辺をアツく語るブロガー出てこないかなー。 私は200X年に今の会社に入社して、数年間WEBアプリケーションの開発をやった。多くはJavaの案件だった。最後の案件は去年の夏ごろだ。前任のPMが逃げるように辞めていってしまい、非常に複雑なロジックを自分が担当することになった。1500行越えktkr。それを参考にして(これが大間違いだったんだよセニョールorz)２週間かけて作ってみたはいいものの、テストを繰り返しているうちにどんどんボロがでて、結局その当時のPMとパートナーさんに相談して設計からやり直し

そうそう人月はなくならない。世界の何処だってヒトを売るときは人月だ。同じヒトを買うならユーザー企業が直接雇用した方が方が安いし組織の壁がなく合理的だ。米国で日本よりパッケージの活用が進むなど合理的な情報システムが構築されやすいのは、一時的なコンサルティングやプロフェッショナルサービスはともかく、システムの企画とか調整はユーザー企業の従業員が行っていることが大きい。きっちり業務プロセスから見直すことができるし、ちゃんとコストを下げるインセンティブが働いているのだ。 日本でそういった企業が少ないのは、ジョブローテーションの中で情シス部門のスペシャリストを育て、しかるべき処遇を用意することが難しく、減点法の人事評価ではリスクを取って新しい技術を導入するより、付き合いの長い業者に丸投げして失敗を避け、或いは失敗しても責任を押し付けた方が得だからだ。 つまりユーザー企業の発注能力が低いとか、重層的な

コラム〜リサーチャーの日常 人生を通じてマッチクオリティーを追求する 知識の幅が最強の武器になる という本で初めて知った「 マッチクオリティー 」という言葉は、経済学の用語で、ある仕事をする人とその仕事がどれくらい合っているか、その人の能力… 2021.05.04 2021.05.13 311 view 2．ビジネスリサーチの情報収集 日常的な情報収集・整理術（Feedly＋Dropbox） 【 ビジネス 情報収集 と 情報整理 の基本 】いま目の前にあるリサーチプロジェクトとは別に、普段からデジタル時代の「新聞 切り抜き」に相当する情報収集・整理を行う必要が… 2021.02.10 2021.05.08 289 view 5．ビジネスリサーチのビジネスモデル ビジネスリサーチがアウトソースされる理由 ビジネスリサーチを社外に依頼する理由①〜信頼できる人「すべては依頼から始まる」からでも書

なんかはてブってば情報サービス産業の悲惨さを訴えると急速にブクマが伸びるものらしく、お前らダラダラ職場からブクマチェックしないで、とっとと帰れよと思うこともあるが、きっと帰れない深い事情もあるのだろう。 しかし分かってないなあ。10兆円台に乗せた情報サービス産業にあって、経済産業省のIT関連予算ってイマドキ400億円もなくて、これって腐りきった社保庁システムの年間保守費用より小さいんだぜ。それが日本のIT業界発展を阻害しているなんて過大評価じゃね。 日本のSI業界の過酷な労働条件を改善したければ、やるべきことは労基法の改正とかじゃなくて、市場メカニズムを正しく機能させることだ。日本のIT業界を発展させたければ、援助交際をやめて何もしないことだ。 最近こそ郵政4分割とか、自民党の参院選対策で大見栄を切った年金の名寄せとか、政治に皺寄せされた不条理なデスマ案件が散見されるけれども、官公需って昔

日本のIT業界は救いようがない。絶望的としか言いようがない。 IT業界不人気なんて、この業界に重くのしかかる決して晴れることのない暗雲の氷山の一角に過ぎない。はてなの匿名ダイアリーにもどうせ理系出身者なんていらねえんだよ。なんて書かれていたけど、これが現実なのだよ、学生諸君。 ちょっと補足しておくけど、ここでIT業界っていうのは、SIerのことだ。お客さんの要件をヒアリングして、その要求に沿ったシステムを受託開発するっていうビジネスのことを指している。 ぼくもその昔、その世界のループに組み込まれていた。そして華麗なるコミュニケーション能力とやらをいかんなく発揮し、場の空気を読み、生意気なぐらいのチャレンジ精神で、それなりに仕事のできるよい子だったようだ。 いや、正直に言うよ。正直に言うとだね、結構楽しかった。 だって、考えてみてごらん。お客さんのところに出向いて行って、その業界のことをじっ

こんなに美味しいネタをPOSTしてくれてありがとうございます。＠ITさん。 ネタ元 IT業界不人気の理由は？ 現役学生が語るそのネガティブイメージ IT業界を不人気にした重鎮たちの大罪 IPAフォーラム2007で討論してきた IT業界のネガティブイメージ 日本語を話せていない重鎮様 ネガティブイメージを突きつけられた浜口氏は、「必ずしも全員が3Kではない」と反論。岡本氏も「3Kの“帰れない”は、帰りたくない人が帰れないだけ。スケジュール管理の問題だ。 IT業界不人気の理由は？ 現役学生が語るそのネガティブイメージ 帰りたくない人が帰れないって日本語おかしいんですが。帰りたくない人が帰らないの意味だとしても、そりゃスケジュール管理の問題なわけが無い。すんごく好意的に解釈すると「個々人のスケジュール管理がダメだから帰れないだけだ。この仕事特有のものではない。」という意味だろうけど、多くの場合は

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