大企業で働くということ - GoTheDistance
梅田望夫氏の大企業で働くことについてのエントリの尻馬に乗ろうと思い続け、気がつけば尻馬が100マイルぐらい遠くなってしまったのですが、やっぱりこのネタについて書きたいことがあるので、エントリを書きます。すっげー長いエントリになってしまったので、気長に読んでください。連休の夜長にでも。 他の大企業はどうだかわからないけれど、少なくともウチの会社に限って言えば、以下のような事が言えます。 本部長レベル以上はやっぱりデキる人が多い 何にも考えなくても給料がもらえる仕組みがある 人がいっぱいいる、それだけでも意味がある 基本的に隣の部署が何をやってるかわからない 決定が棚上げされる うっとおしい社内業務が多い こんなところかなぁ。 ウチの会社は社員数4桁の会社です。そんな会社にあって本部長クラスになれる人は、どこか一味違います。先を見据えて物を考えていたり、政治力がすごかったり、オレ様全開だけど明
富士通の3万人SE職務転換大作戦は成功するのか？ - GoTheDistance
全文は紙面でないと読めないのが残念ですが、非常に気になるニュースが飛び込んできました。 富士通、余剰ＳＥ変身作戦 富士通がグループで抱える約３万人のシステムエンジニア（ＳＥ）の大がかりな職務転換に乗り出した。一つのシステムを複数の企業などが利用するクラウドサービスがこのまま普及すれば、顧客の要望を聞いて個別システムを作り込むＳＥは仕事がなくなり、余剰人員問題が顕在化するからだ。野副州旦元社長の急進的な改革路線を修正した富士通はＳＥ余剰問題で軟着陸を目指すが、クラウドの奔流にのみ込まれる危うさもはらむ。 富士通、余剰ＳＥ変身作戦 実は富士通グループさんには弊ブログを頻繁にご覧頂いておりまして、企業ドメインの中では最もアクセスの多いドメインであります。クロールしにきているのかなと思うぐらい。ブログで言及している「なんでもかんでも受託開発では、もうSIビジネスで成長することは出来ない」という危機
IT業界に求められる営業の姿を考えてみた - GoTheDistance
IT業界の営業かくあるべき論 - Togetterが面白かったので首を突っ込んでみます。 上記で言われている営業は「パッケージ導入やオリジナルでの受託開発業をやっているシステム屋の営業」という前提のようです。僕もこの前提で書いていきます。 良く聞く話ですが、エンジニアからすると最たる不満の１つに「営業は不勉強」というのがあると思います。自分が売り込もうとしている商品が技術を武器にしているのにも関わらず、システムや技術のことを知らずに言葉だけで売るのはいかがなものか、という問題です。 これらの知識が無いと何がマズいかと言うと、 顧客の要望のインパクトがどれほどのものかわからない。 できない事に対する代替案が提案できない。 判断できることが少ないのでスピードが落ち、エンジニアに負担がかかる。 などがあります。 システムの営業の難しいところは、顧客のニーズはあくまでシステムがもたらす効用(ソリュ
営業ができる人とできない人の違い - GoTheDistance
営業という言葉に良いイメージを持ってる人はかなり少ないんじゃないかと思います。特にエンジニアは営業さんに「泣かされた」経験がおありの方が多いですし。また、電話爆撃営業や詐欺に近いような営業も多い中、益々うさんくささが先行しやすいのかなぁと思ったりします。 ホントはそういうもんじゃないだろって思うので、自分１人で顧客の所に赴き、話をしに行くことも増え、発注側として営業さんの話を聞くことも増えてきました。そんな中で、営業について感じたことを書いてみます。 1. できる人は相手に問いかける、できない人は自分が話し続ける 相手とのコミュニケーションの中で距離感をつかみ、お互いが負担にならないようなコミュニケーションの土台をまずつかむこと。これが恐らく営業のはじめの一歩なんじゃないか、と思っています。 その土台を作るのに、まず自分のことを立て板に水を流したように話す営業がいますが、その時点で僕は「も
スモールビジネスを興すのに本当に必要なこと - GoTheDistance
スモールビジネスにトライしている僕がやってきました。 利益率の高い商売 在庫を持たない商売 定期的に一定額の収入が入ってくる商売 資本ゼロあるいは小資本で始められる商売 競合商品に比べ低価格 商品の再生産が容易（労働集約型でない） 協力（購入や顧客の紹介）してくれる仲間やメンターがいる 貪欲な学習意欲 顧客、従業員、商材、社会とのトラブルリスクが少ない商売 スモールビジネスを興して成功するための9条件 - 人と組織と、fukui's blog 書かれていることは正におっしゃるとおりだと思うのですが、殆どの場合こういうのはビジネスモデルに対する結果論なので部分的にしか参考にならない。この条件をほとんど兼ね揃えていたけど、｢その条件を売上に転化できなくて｣くたばる会社っていっぱいいる・・・。この条件を否定するのではなくて、モデルは良くてもコケるビジネスがいっぱいあるのはなぜか、ってことを考えた
大手SIerの利益悪化がとどまることを知らない件 - GoTheDistance
田中克己の針路IT - ソフト会社に明日はない？：ITpro ＿＿＿_ ／:::::::::: u＼ ／:::::::::⌒ 三. ⌒＼ ウソだろ！？ 今期、いきなり利益半減？ ／:::::::::: （ ○）三（○）＼ 会社どーすんだろ・・・orz |::::::::::::::::⌒（__人__）⌒ | ＿＿＿＿＿＿＿_ ＼:::::::::: ｀ ⌒´ ,／ .| | | ノ::::::::::u ＼ | | | ／::::::::::::::::: u | | | |::::::::::::: ｌ u | | | ヽ:::::::::::: -一ー_~､⌒)^),-､ | |_＿＿＿＿＿＿__| ヽ::
アジャイルって受託開発との相性が最悪な気がする - GoTheDistance
全くもって、その通りだなぁと思った。 初期段階ですべての意志決定をしても、問題はコードを書き始めてから表れるのです。そして終わりに近い時点で判断する方が、より正しい判断ができるはずです。ですから、できるだけ意志決定は先延ばしにして、正しい意志決定をしようとするのがアジャイルのやり方です。 「有能な人がコードを書くべき」「意志決定はできるだけ先延ばし」「契約を変えるのは難しい」アジャイルの専門家の答え － Publickey ｢ウオーターフォールとは｣のラベル貼りの議論になるとめんどくさいから、とりあえず｢初期段階ですべての意志決定をしようとするシステム開発の進め方｣という定義で話を進めたいと思います。 滝 ｢要件定義｣→｢設計｣→｢実装｣→｢テスト｣という一連の流れがあって、ウオーターフォールなるものは前工程が100になるまでひたすらそこでPDCAを回します。100になると言う意味は、ソフ
電子書籍の今後の展望について思ったこと - GoTheDistance
知的生産物の今後の行方を占うようなエントリが２つ続いたので、思ったことをまとめてみる。 音楽業界がいかに危ないか俺が優しく教えるスレ 働くモノニュース : 人生VIP職人ブログwww それでも出版社が「生き残る」としたら: たけくまメモ どちらの業界にも共通しているのは、Webベースのコンテンツ配信が普遍化してきたことにより知的生産物の商品化コストを著しく削減されて提供できるようになってしまった、ということがあげられる。 本が世に出る流れ ｢製版→印刷→製本→取次→書店｣ 楽曲が世に出る流れ ｢作曲→レコーディング→CD化→取次→量販店｣ 両方とも似たようなプロセスを通るわけだが、両業界においては今まで｢物理的なパッケージ｣に落とし込んで世に出すという部分を担っていた業者が必要だった。ただの著作、ただの楽曲を｢世に出す｣というのは個人の努力では超えられないカベがいくつもあったのですが、誰も
好きだから続けられるワケじゃないよ - GoTheDistance
業務以外でも自分の技術的能力を高めようとすることに対して、そのモチベーションはどっから来るんだろうと不思議に思う人がいっぱいいるというお話。 はてなダイアリー 趣味なんでしょ？ - GoTheDistance そろそろ「好きだからできるんですよね」について一言いっておくか - じゅんいち☆かとうの技術日誌 僕も昔こんなことを言われて、なんでだろって思った。 多くの人は自分の時間を削って頑張っていることに対して不思議に思うようなんですね。どうしてこの人は、がんばっているのだろうと。別に業務上必要ないことなのにって。で、やっぱり｢好き｣だからできるのだろう⇒趣味でやっているんだろう、ということになるらしい。 違うんだよねぇ、それ。物事は好きだから続けられるものじゃないんだよ。簡単に言えば、習慣なんだと思う。溶け込むことができているか、って所だと思う。 僕はクルマが好きで麻雀が好きだけど、それに
ブログをキャリアの礎にしようと思っている方へ - GoTheDistance
色々エントリが書かれていたので、僕も相乗りしてみよっと。 ネタ元(あわせて読みたい) 小飼弾「転職活動する暇があったらブログを書け」 − ＠IT自分戦略研究所 ブログを書く暇があったらプログラムを書け | おごちゃんの雑文 ブログを何に使うのか - (旧姓)タケルンバ卿日記 自分は何を以ってして知られたいのか ブログなんて書きたいことを書けばいいんだよという意見は多いのですが、書きたいものを書くということは、簡単そうで難しいです。書いているだけでは当然物足りなくて、目的なり意思なりがそこに介在しないと他人様に評価して頂く軸が生まれないのですが、そこまで至るまでにクリアしなくてはならないいくつかのハードルがあります。 そもそも書きたいことは探すものじゃなくやってくるもの 書きたいことがあっても、伝えたいように書けるとは限らない 誰かに見てもらえるようになる為には時間の蓄積が必要 書いた内容が
最近SIerがだいぶヤバくなっている件 - GoTheDistance
via IT業界から思ったことを。 Twitterでつぶやいたら結構こんな感じで厳しい状態になっているSIerが増えているようなので、僕なりに現状をまとめてみる。 よくわかるSIer涙目の構図 サブプライム、金融危機でSIerのお得意様の金融・メーカー様が大打撃を食らう。 2008年はとりあえず様子見で予算編成は据え置きだったが、今年に入って財布にチャックがかかる。 先行き不透明なので、GW明けぐらいの今期のIT予算が相当カットされた数字になった所が続出。 計画していた新規案件を中止するなどする。運用でなるべくカバーする方向へお客様が動く。 その結果SIerは新規案件がなくなる。案件自体がなくなっていく。予算が無いから当たり前。 大手がプロパーの仕事がなくなってきたのでプロパーで人数減らしてまわし始める。 プライムで食い込んでいるお客様の仕事が減ってきたので、外注に仕事が依頼できる余裕がな
システム開発に欠かせない契約の基礎知識まとめ - GoTheDistance
先日識者の方に色々教わったのでメモっておきます。知ってそうで知らない、元々よくわからない、そういう方に向けてまとめてみました。 僕がSIにいた頃は大抵｢基本契約｣と｢個別覚書｣ってのがありました。納期とかお金とかそういうのは個別覚書に書かれたりしていました。 開発の契約体系 ｢仕様策定〜開発まで｣と｢保守運用｣で別契約にすることが多い。 ｢仕様策定フェーズ｣で1つの契約にして、別に新しく契約を締結しなおせるほうが望ましい。リスクが低減できる。 仕様策定までは準委任、開発は請負、保守運用は準委任という契約が多い。 ちなみに準委任は｢事務作業の代行｣という意味合い。委任は｢法的効力がある作業｣の代行。サムライビジネスは後者が多い。 別に運用が事務作業とイコールじゃないけど、成果を問わないタイプの契約の場合は役務提供という位置づけになる。 かといって契約で｢僕らのコンサル案を僕らが実施し成果が出
受託開発はプロフェショナル・サービスの領域になる - GoTheDistance
メディアに乗るとなんでも釣りっぽく思えてしまう汚れた僕ですが、本件については数年前からとっくに曲がり角に来ていると思っています。 受注するだけの製品販売や顧客の言うがままに作るSI（システムインテグレーション）、委託されるだけのアウトソーシング、報告書を作成するだけのコンサルティング─。IT業界に染みついた「受託体質」は、ビジネスモデルの転換期を迎えているユーザー企業のシステム構築・維持にとって、むしろ足かせになっているのかもしれない。 乱反射 - 曲がり角にきた受託体質のIT業界 顧客は共同で事業創造を望んでいる：ITpro こちらの記事で使われている｢受託体質｣の意味は｢要件はお任せしますので、労働力だけ提供しますという役務提供型のサービス｣という文脈のようです。それって単なる御用聞きだから、ビジネスモデルの改善・革新を求めているユーザー企業と足並み揃うわけがないよね、という趣旨だと解
プログラマの誇りを減衰しないビジネスモデルを - GoTheDistance
アツいエントリなんで思わずTBうってみる。 この業界の問題、それはプログラムが、新人〜3年目の作業と位置づけられていることだ。 プログラマーの誇りを見せ付けろ - 山本大＠クロノスの日記 正確に言うと上級プログラマも初級プログラマも同じ値段で評価されるってことが弊害である、ってことだと思います。予めXXX万円で作ってねという予算が決まっていて、その予算をオーバーしないことだけが成果の基準にあることが問題だと考えます。このルールにおいては、極論ですがコード品質が高くても低くても大差が無くねっていう力学が働きます。 基本的にニッポンの受託開発のプロジェクトの場合は、大きく２つのプレイヤーがいます。 案件を立ち上げてお客さんへのコミット権限がある人・会社 立ち上げた案件をシステム化してデリバリする人・会社 ですが、今の流れでは工程が分断されちゃっているので、案件を立ち上げる人とシステム化してデリ
得手に帆を上げて、舵を取れ。 - GoTheDistance
yuripopとyamkazuのエントリーを読ませてもらった。 「外注と同じ仕事しかしないなら辞めろ」 - 歩きつづける ゆり 咲きつづける 製造を行っていないSIerで製造出来る社員に育つには - 山本和樹のはてな日記 2人のエントリを読ませてもらって思い起こされたのが、豆蔵の萩本さんのこちらのコラム。たぶん、今の2人にすごく役に立つコラムだと思う。是非全文を。 人のマネジメントと、技術のマネジメント あまり開発経験がないにもかかわらず、若手エンジニアにプロジェクトマネジメントを任せる企業が増えているようだが、私は反対だ。人はマネジメントできても、技術のマネジメントができないからである。 技術のマネジメントとはどういうことなのか。簡単にいえば、開発で使用するソフトウェア技術、開発手法やツールなどの長所・短所を見抜いてその組み合わせを考え、メンバーの開発工数などを見積もることである。人のマ
受託開発がつまらないなんて言わせない - GoTheDistance
本当はこういうのをエンジニアの未来サミットでお話できればよかったんだろうと思って、電車の中でふと思ったことをガンガン書く。 IT業界に携わってシステム開発を行っている方々で最も多い層は、受託開発という形でシステムを作ったりメンテナンスをされている方々のはずです。江島さんのニッポンIT業界絶望論というエントリが出てから「受託開発なんてうんこ」みたいな空気がすごく醸成された感があると思うのですが、無自覚にふわふわとイノベーションにかぶれるのもいい加減にして欲しいと思います。 確かに受託開発には負の側面があります。誰でも始めることが出来る参入障壁の比較的ゆるい世界ですが、どこでも出来るような仕事しかやっていないような会社はすぐに行き詰ります。そういうお話は結構耳にします。受託開発という形態をとって実際には技術者を派遣しているだけの創造性のかけらもないような会社もたくさんあると思われます。こういう
プログラミングファーストには期待しています - GoTheDistance
やっと自分の見解がまとまってきたので、今頃この話題に足を突っ込む。 プログラミングファーストのメリット・デメリット 色々関連するエントリを見させて頂いて*1多分こういう感じだろうと思いました。ざっくりと。 主体者 メリット デメリット ユーザー 早期に最終成果物を共有できる 単なるコスト増になる可能性がある システム屋 エンジニアの能力・創造性を価値に変えられる 少数精鋭・内製志向に適したビジネスモデルの構築が困難 こういうお話は「ユーザー目線｣と｢システム屋目線｣に分けて考えるとわかりやすいと思います。 ユーザーにとってのメリットは早期に最終成果物を見ることができることだと思う。もちろん｢最終｣というまでには設計も必要だろうしテスト結果も必要なんだけど、｢実装してユーザに使ってもらう｣ことによるメリットは少なくない。システムって使ってみて初めて価値がわかるものだし、品質を決める基準はユー
SIerの中の人として生きていく閉塞感 - GoTheDistance
久しぶりのガチンコSIネタ。 「人生のファイナルアンサーが見出せません。」「何なの？スイーツなの？」 SI子会社でのキャリアのメインストリームから外れた俺。 私が感じた範囲で、きっとこういうことでSIerの中にいて閉塞感を感じているのかなぁと思う点を書いていきます。 技術的興味関心にマッチするかどうかは運 私は５年間SIerで働いていますが、自分の興味関心のある技術を仕事(＝プロジェクト)で触れることが出来る機会は基本的に相当少ないと感じます。これが閉塞感を生んでいる一因だと思います。 仕事でJavaやりたいと言ってもJavaが出来る案件に自分がめぐり合えるかどうかは、ちょっと語弊がありますけど基本は運です。SIerは複数のプロジェクトを当然抱えており、あなたが無事プロジェクトが終わった時に次にアサインされるプロジェクトが.NETの案件しかなかった、というのはよくある話。また、会社の方針で
jkondoというロールモデル - GoTheDistance
id:jkondoの奥様、id:reikonのエントリがアツい。こういう自重しない青臭いアツさは大好きだ。背筋が伸びる。 梅田さんの話も、引用されているシリコンバレーの著名人の話も熱く、ひたすら真面目だ。そこには濃密な生き方があり、ひたむきな何かへの熱意がある。世界には、ひたすら真面目に生きている人がいることが分かる。その人たちは、自分の理想を持って、とにかく熱い気持ちを持って働いている。人間それぞれの能力には限界があるし、誰もがシリコンバレーの有能な人たちのように偉大なことはできない。だけど、熱く生きたり、真面目に生きることは、誰だってできる。 それがいいことかどうかは、人それぞれが判断することだと思うけれど、少なくとも自分はそうでありたい、と強く思う。 熱く生きたい これを読んで、id:jkondoとid:reikonご夫妻は歩調が合っているんだなと感じた。いいなぁ。もちろん会ったこと
「いける」と思った数だけプログラミングは上達する。 - GoTheDistance
このエントリを読んでふと思った。 プログラミング能力がある人って、こういう感覚がいっぱい出てくる人なんだと思う。数学で問題をみたときに、あの解法かあの解法のどっちかで解けるだろうという直感。その感覚の質と精度と量を増やしていくには、やはり経験が一番なのかもしれない。 プログラミング能力とは ブクマコメントにも書いたけど、プログラミング能力ってこういうことなんじゃないかなと思う。 「いける」と思った数×「やべぇ」と焦った数＝プログラミング能力(｢できるようになった」数) プログラマーに向いている人は諦めの悪い人です。なんかもうちょっとでできそうなんだよなぁ〜という産みの苦しみを夜な夜なGoogle先生と共に楽しめる人が良い。プログラミングってはじめから答えが無いことが多いしね。何事もそうだと思うけど、「できること」を何度も何度も繰り返してもそれは上達にはつながらない。「やったことないけどいけ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
