大企業
たまには実情を書いてみる。愚痴大会なので読み飛ばしてくだしあ。 SIer の経営方針としては、｢どんなカタチにせよ、生産性を高めるのである｣という方向に行くと思います。生産性を高める要因は２つしかなくて、｢開発プロセスの改善｣と｢ソフト生成の自動化｣…
コトあって同期で集合研修を受けています。これまでやってきた仕事の棚卸しとか、これからの目標とか、そういった話なので、お互いの仕事内容を知る良い機会です。そこでまわりとのギャップを感じたので書きます。私はパッケージソリューションの企画手伝い …
正直なところ、マネージャ兼プログラマで仕事を進めるのは、自分+メンバー4人程度までが限度でしょう。4人に加え、顧客とのコミュニケーションコストでプログラムはほとんどできないはずです。物分りの良いお客様なら運が良い方です。 それ以上のチーム編成…
大手SIerでは、社内人件費単価が外注の単価と比べて、べらぼうに高いことが多い。だから、プロジェクトマネージャも利益を出すために、社員の数を抑え、できるだけ外注しようとするのです。（中略）実際にコストを大きく占めているのは、外注費です。だから…
コメントありがとうございます。 id:ysakata 確かに私もさんざん体験していますが、あり得ないコードをみても、そういうコードを書く人をマネージすることが当社の役目と言われるよ。けど、それでもそのマネージする人は少なくとも本人ではなく手の自社内で…
組織内ではインターネットと違って曲がりなりにも情報の作成/維持の責任者は決まっていて、当然それを格納する場所も大まかには決まっている。（中略）企業内検索ではインターネットは違った考慮点がいくつかある 各文書のアクセス権を検索結果に反映する必…
コメントを頂きました。ありがとうございます。 id:katzchang改めてちょっと伺いたいんですが、知識集約と労働集約を決定付ける要素って一体何なんでしょう？ 「今まで人ができなかったことを実現する領域」は知識集約だというのは理解できます。が、例えば…
社内Twitterの検討会をやってると、どの層をターゲットにするかという話がよく出ます。この議論は、昨今のはてな賛否両論と本質的に同じかなと思ってます。ウェブ世界の人は面白そうなサービスをすぐ使いますが、リアル世界の人は何かの取っ掛かりが必要です…
日本のIT産業は、30年前の技術に最適化されている。しかも、当時のプログラミングで解決できなかった問題を、企業文化の中に取りこんで属人的に対応して、そのままになっている。それを「業務知識」と呼び、それを暗黙知のまま継承することを強いている。だ…
社内Twitterの検討をやっていますが、予想していた課題が顕在化してきました。課題とは、ネットのこちら側とあちら側の溝です。ネットのこちら側の人たちが考えるサービスはメッセンジャです。多くの開発プロジェクトが（公式か非公式かともかく）IP Messeng…
私は大企業SIerに対して悲観的なエントリを書くことが多いのですが、現実はやや違います。自分がいま何をすればいいのか、どう役に立つのかを考えます。アーキテクチャに疎い人が多いのであればそこをカバーすればいいし、企画に近いことをしたければ新しい…
プログラミングしたい人々は、物が出来るまでの過程を楽しみたい人である。だから、「DBにクエリーをかけてHTMLにぶちまけるだけの簡単なお仕事」が退屈で仕方がない。しかし、アプリ開発したい人々にとって、物ができるのは出発点にすぎない。彼らが楽しむ…
IT業界に限らず多くの業界で、大企業の本社に入った人は新人の時から管理系の仕事をすることが多いです。上司の話やブログを読む限りでは、10〜20年前に比べてこの傾向が強くなっているらしい。単価の高い仕事と安い仕事の構造は、子会社やパートナーへのア…
また講演を聴きたいなぁ。。。 ん・・・これって何の講演かしら！私の講演？ id:amachangとやったやつかな。大阪のかな？ http://d.hatena.ne.jp/dropdb/20080416/1208358116 id:dropdbさんとid:amachangさんの講演を聴きたいです！私みたいな初心者には敷居…
今までベンチャーにいて声がすごく通っていたんだけど 大きな会社では自分レベルじゃ通じないんだなってわかった。 社会人歴7年だけどこの会社（大きな会社）のやり方・動き方については1年生なわけで。 http://d.hatena.ne.jp/dropdb/20080416/1208310409 …
設計書の定義は、おおよそ開発標準や慣例で決まっています。逆に言うと、設計書名やその中身を書くと社名がバレるかもしれません。だからみんな書きたがらないのでは。中でもプログラム設計書はベンダによる違いが大きく、結果的に技術力の差となることが多…
プログラミングができないのなら、プログラミング言語を自然言語に翻訳したプログラム設計書を理解できるはずがない。できるとしたら、誤字脱字、単語が統一されていないとか、日本語が変だとかそんな指摘くらい。そんなレビューは意味がない。だって、全然…
大御所のブログを引用するのはおそれ多いのですが、それでも元請けの視点で書きたいことがあります。 例えば、誰が書いても同じコードにするために、プログラム設計書(内部設計書)を今、書かせているとしたら、そんな無駄なものはやめたほうがいいと思う。プ…
社内Twitterに関する記事を探していたら、非常に興味深い記事に出会いました。縦割りの弊害と社内Twitterの必要性を考察されています。 病院にはいろんな職種がいます。医師、看護師、コメディカル（薬剤師・臨床検査技師・放射線技師・臨床工学技士、歯科衛…
社内Twitterの検討会をやっていて、よく思うことがあります。私は（リアル世界と対比して）ウェブ世界のタコツボに陥っているのではないかと。ここでいうウェブ世界は、RSSリーダーで情報収集しブログを書く習慣のある人々の世界です。 最近話題のサービスに…
日経ビジネスに鋭い指摘が載っています。 一般の人は勘違いしているかもしれないが、建物を造っているのはゼネコンちゃうで。ゼネコンは現場を管理しているだけ。実際に造っているのは職人や。その職人も、ゼネコンが雇用しているわけやない。抱えているのは…
「社内Twitterは大企業病の特効薬となるか」の続き。 まわりしか見えない症候群 縦割りの世界では、人や物や情報といったリソースが組織を超えて自由に動くことはありません。原則として、社内取引でお金が動きます。お金が動くということは、自組織の利益に…
大企業ほど、社内のコミュニケーションは狭く偏ったものになります。縦割りやプロジェクト制によるセクショナリズムで、自分が属している組織の人間としか情報交換しなくなってしまいます。私は小さな検討グループで社内Twitterを検討しています。正式に予算…
