プログラミングだけできればいい、なんてことは無いさ。 - GoTheDistance
なんで管理について書きたいのか 動機です。 単純に「プログラミングだけできればいい」「SIする人は要件定義だけやれ」という声を聞くと切ないからです。 ただし、わたしは個人的に、開発というお仕事においてプログラミング技術が何を差し置いても最重要だと思っていますから、その軸は絶対にぶれない、ということを念押ししてから始めたいと思います。 ひとりにはなりきれない空を見あげる これも昔思ったことなので、取りとめも無く書いておきたいと思います。 技術リテラシーが死んでいる人間が立ち上げた or 回しているプロジェクトは高い確率で砂上の楼閣のように崩れ落ちていく。だからプログラミング技術に代表される技術リテラシーは必要不可欠。だけど、全員が全員その道を突っ走ると今度はビジネスにならない。取ってきたシーズをプロジェクト化できない。僕は後者が出来ない自分でありたくないという思いから、スーツ的な何かを２年ぐ
「仕事力」に散りばめられた金言の数々 - GoTheDistance
最近この本を読んだのですが、随所に素晴らしい言葉が散りばめられていました。僕が特にこれはと思った言葉を貼り付けておく。というか、伝えたくてしょうがない言葉が多すぎる。私が自信を持っておすすめできる一冊です。是非。 大前研一 優れた経営者はみな提案グセのDNAを持っている。 常に自分のやる仕事を文章化して棚卸しせよ。 朝倉摂 専門家として生きる、そういったハッキリとして目標があるのは大切だが、それだけに向かって細い道をひた走る生き方は豊かな仕事を生まない。 感じたことを自分の手で表現する訓練をきちんと積まなければならない。自分のハートをここに込めたとわからせる力量が重要です。 素直になれない人と仕事をすることほど、つまらないことはない。 安藤忠雄 仕事は生涯をかけて自分の可能性を探すことである。 青春とは目標を持って生きている時間のことをいう。 精神を萎えさせないためには、常に勇気を持って挑
営業はセールスのことではなく、会社を継続させる仕組みのこと。 - GoTheDistance
羽生さんの起業・経営の必要条件を読んだ。個人的には名エントリだと思う。 つまり「営業と財務」がちゃんと出来てなければ、いくら優れた技術力があり、優秀な人材が揃っていて、明確なビジョンと戦略があって、人を大切にする気持ちがあっても、簡単に潰れます。腐ったOSの上では優れたアプリケーションも安定して動作できないのです。 株式会社スターロジックの羽生章洋が書いてるブログ:起業・経営の必要条件 腐ったOSの上では優れたアプリも動くわけ無い、というのは本当にその通りだと思う。僕の叔父の会社が10数年生き残っているのも、OSが優れているからという点に尽きる。特に営業力が優れているから、会社を継続させるために最も必要な顧客を捕まえる能力が恐ろしく高い。財務は・・・、これからｗ どういう会社かというと、雑貨・アパレルの卸を主にやっている会社。簡単に言ってしまえば、小売店に対して｢ウチが扱っている商品を仕入
ハイテクの日本がエンジニアを枯渇させている - GoTheDistance
NewYorkTimesにこんな記事がありました。日本の理系離れについてまとめられた良記事です。今日はこの記事の紹介。ぜひ原文にトライしてください。 High-Tech Japanese, Running Out of Engineers 理系離れが日本で進んでいるから理系の大学がやっきになって入学者集めにやっきになっていることや、日系の会社でもゆっくりと外国人エンジニアの採用やインドやベトナムに仕事を発注し始めているという記述から始まっています。 It was engineering prowess that lifted this nation from postwar defeat to economic superpower. But according to educators, executives and young Japanese themselves, the youn
プログラマが仕様を決めればいい - GoTheDistance
最近よく思います。 システム開発の上流工程においてはコードは出てこない。言葉や図解で埋めつくされて、最終的には日本語でしかない。設計書とか仕様書とか。で、この大抵上流工程ではこれらのドキュメントに対するレビューなるものがあるのですが、これが実に無益なものだと感じることが多い。こんな所でPDCAまわして何が面白いんだろうとよく思う。 ここでチェックする多くのことは、言葉の解釈に関することがほとんどです。 この言葉はプロジェクトで使われていない 書き方が統一されていない 誤字脱字が多いので直せ。 この文章ではこのように解釈される恐れがある ここではこのような話になっていたがどうなのか こんなんばっか。どこもそうだと思う。解釈の違いは、要件の違い。なんちゃって。 で、結局こういうことを繰り返していくうちに段々とドキュメントがグダグダになっていく。そして繰り返していっても前提が変わってしまえば全部
28才のリアル〜スーツとギークのあいだを彷徨う〜 - GoTheDistance
ここ１年ばかりスーツとして仕事をして感じたことを一気に書きなぐる。 端的な表現を使うとスーツは「システム開発において直接開発作業に携わらないマネージャ、営業、コンサルの総称」です。ギークというのは「プログラムを書いてソフトウェアを組んでいる人、もしくは何かしら世にプロダクトを出している or 出していた人の総称」ということにします。 日本のITビジネスは脆弱なビジネスモデルです。最も品質を問われるべきソフトウェアにおいて派遣による偽装請負なんかがまかり通っているのは、日本だけです。70〜80年代にプログラマの絶対数が足りなくてとにかく人をかき集めて現場に派遣するようなスキームが横行したのと、時間がかかればかかるほどコストがかかり結局その分売上が立つという人月商売モデルの２つの悪因が両輪となって、今のような奇形児になりました。 簡単に言うと、腐れエンジニアをかき集めて仕事を進めるスキームにな
ヒョウタンツギな現代システム事情をRESTでぶっとばせ！ - GoTheDistance
昨日休日出勤して3冊に及ぶKINGJIMを斜め読みしてふと思ったことをTwitterにぼやいた。 ものすごーく高いお金をかけて基幹システムを作っても現場で使っているのはExcelで、そのExcelをベースに手で個別システムに打ち込んで基幹にバッチでつないでいる会社がどれほど多いことか。 http://twitter.com/gothedistance/statuses/721944022 何でこんなことになってしまうかというと、この辺りが大きな原因かな。 基幹システムで管理したい単位と業務で管理したい単位が違う。 基幹システムは情報システム部が、業務アプリは個々の部が勝手に作っている。 1番においては、基幹システムで管理したい単位は仕訳を行うために必要な単位で業務に必要な単位はそれよりもっと細かい商品単価であるとか商品単位であるとか業界標準の何とかコードであったりとかする。特に流通・小売と
JavaとRubyの間にある、ベルリンの壁 - GoTheDistance
ネタ元はこのあたり。 SIer と Rails とエンタープライズと エンタープライズにおけるRailsの価値とは 弊社の某エロい人がRoRに萌えており「おお、なんて生産性が高いんだ。もうWebアプリなんて全部これでいいじゃないか。」とか本気で思ってそうなので萎える。言語の違いは時にはビジネスモデルの違いにつながることが理解できないようだ。言語ってのは文化なの！これからはRubyを全面的に取り入れ開発標準もRubyだぁぁぁぁとか言い出したらどうしよう。グーで殴るしかないかｗ 本来、コード量の少なさや、CoCを前提とした設定の少なさが価値を発揮するのは、メンテナンスの場面です。読み込まないといけないコード量の少なさと、少ないコードの変更で修正ができることが、その理由です。そのためには、大前提として、Ruby（on Rails）らしい、プログラムを作っておくことが必須なので、マネージャはその辺
アメリカにはSIerなんて存在しない - GoTheDistance
知人のmark-wadaさんのBlogからTB。 親子丼的ビジネス奮闘記(4) IT業界構造 SIerなんてものは無い 米国と日本との大きな違いは、米国の企業は基本的に内製なのだ。すなわち、社内のＩＴ部門に開発エンジニアを抱え、そこでシステムの開発から運用を行なう。 ですから、米国のベンダーはそこに製品を供給する役割であり、日本でいうSIerというのはほとんどなく、あっても企業でリソースが不足したらそれを補う役割でしかない。契約にしてもはっきりしますよね。提供されるプロダクトやサービスに対する対価を払えばよいわけで、かかった人月で支払ういう出来高払いのような形態は少ない。日本のようにベンダーやSIerに丸投げして、できてからこんなはずではなかったなんて事態にははじめからならない構造なのだ。 親子丼的ビジネス奮闘記(4) IT業界構造 言われてみれば・・・、っていう感じですが改めて目が鱗です
第0回BPMオフ会で、羽生さんが語ってくれたこと - GoTheDistance
先日、id:wkzkさんと共謀した第0回BPMオフ会が無事終了しました。人生初めてのOFF会でしたが、「ちょｗｗｗ みんなキャラ立ちすぎｗｗｗｗ」って感じですげー楽しかった。皆様、御忙しいところご参加ありがとうございました。wkzkさん、幹事役ありがとうございました。次回は私めが頑張りますｗ みなさん色々な思いがおありの上でご参加頂いており、今後は空手では参加できねぇなと猛省した次第です。そんな中、2次会でid:habuakihiroさんがお話してくれたことが勉強になったので、メモっておきます。記憶を呼び覚まして書いているため、微妙に細部が違うかも。 スイムレーンは悪 スイムレーンは悪だ！ 何が悪かと言えば、組織ありきでフローを記述しなければならないというのが悪だと。AS-ISの可視化には有益だろうが、ではToBeを設計するにあたってどうして組織ありきのフローにならねばならないのだ、と。本
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
