「アート・オブ・アジャイルデベロップメントへの道」へ行ってきた - 虎塚
木曜の夜、平鍋健児さん、木下史彦さんと岡島幸男さん（id:HappymanOkajima）のトークセッション「アート・オブ・アジャイルデベロップメントへの道」へ行ってきました。 アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング (THEORY/IN/PRACTICE) 作者: James Shore,Shane Warden,木下史彦(監訳),平鍋健児(監訳),笹井崇司出版社/メーカー: オライリージャパン発売日: 2009/02/18メディア: 大型本購入: 18人 クリック: 336回この商品を含むブログ (100件) を見る アジャイルを仕事で実践する方々のお話を聞けて、とても面白かった。復習がてら、ノートと記憶から抜粋してまとめてみました。参加しなかった知人にいつか読んでもらうことを想定して書いたら、長くなってしまいましたが。 導入 開始前
クラウド時代にSIerはどう生き残るのか？ 人月ビジネスからどう脱却するのか？ 大手SIer役員にインタビューしました
クラウド時代にSIerはどう生き残るのか？ 人月ビジネスからどう脱却するのか？ 大手SIer役員にインタビューしました リーマンショック以降の決算が軒並み大幅減収だった大手SIer。この状況は、景気が回復すれば持ち直すなどと楽観視できません。その背景には、クラウドや仮想化技術などによるシステム単価の下落や、ユーザー企業による内製化の進展による案件の減少といった構造の変化があるからです。 こうした構造変化の中で、SIerは今後の成長戦略をどう描こうとしているのでしょうか？ また、その中でどんなエンジニアが今後必要とされるのでしょうか？ ブログ「GoTheDistance」のブロガーで、「ござ先輩」として知られる湯本堅隆氏から、こんな主題でインタビューしてみたい、という企画がPublickeyに持ち込まれました。湯本氏は、自身もかつてSIerに勤務し、現在は中小企業の情報システム担当に転職した
SEマネジャーとして“SEのモノ扱い”と闘う
昨年、「今日の一言 2010年版」で述べたが、筆者はSE時代に“SEをモノ扱いするビジネスのやり方”や理不尽な営業担当者と闘った。それは大型コンピュータなどを売るために「このシステムを買って頂ければSEを無償で○人常駐させます」というビジネスのやり方や、SEを子分扱いする営業担当者を筆者のSEとしての誇りが許さなかったからである。筆者はその後SEマネジャーになったが、SEマネジャーになってもこの問題と真正面から闘った。今回はそれについて述べる。 SEマネジャーになった筆者には、「自分はSE時代にSEのあり方について結構悩んだ。その苦い経験を部下のSEにはさせたくない」という思いが強かった。また、SE時代の経験から「SEが顧客をつかめばビジネスはうまくいく」ということも確信していた。 部下のSEを徹底指導した そしてそれを自分のグループでぜひ実現したいと考えていた。それは、とりもなおさず、S
IT業界離れ - Wikipedia
IT業界離れ（アイティーぎょうかいばなれ）[1] とは、労働者が新卒や中途採用において、就業先としてIT業界、すなわち情報処理産業を選択しなくなる、また情報処理産業からの離職が増加する傾向のことである。 韓国におけるIT業界離れ[編集] 大韓民国においては、毎日のように午前1-2時まで残業がある状況の上に、年収が3000万ウォンに満たない[2] 労働環境や学歴と勤続年数から決まる時給に、人月をかける開発費算定方法、斬新なアプリケーションソフトウェアのアイデアを出しても全く見向きもされない風潮、経験年数が増えると時給が高くなるため、開発に携わることができなくなり、管理職に上がれなければ、IT業界に残ることができない[3] など理由から、IT業界離れやIT技術者の海外流出が進行している。 日本におけるIT業界離れ[編集] 日本においては、労働環境が下記のような劣悪な状況であるため、IT業界離れ
間違いだらけの業務システム開発（プロジェクト編その１） (mark-wada blog)
システム化プロジェクトは開発するもの 前回は、はなからITシステムを入れるということではなく、それぞれの会社の事情や成熟度に応じて、場合によってはITを使わないでシステム化をする方がいいケースもあるというようなことを書いた。ここでは、システム化プロジェクトで開発をしてしまうという間違いについての話です。 こう言うと、怪訝な顔をする人も多いと思います。だれしもが、普通に”システム開発“と言います。しかし、業務アプリケーションのことでいえば、業務の仕組みを開発するのですかとツッコミたくなる。ソフトウエアやツールであれば確かに開発ですが、業務の場合、開発するとはいったいどういうことなのだろうか。 そのまま字句通りに解釈すると、業務の仕組みあるいは業務プロセスをそうしたプロジェクトで開発すなわち新たに作り出すことを意味する。そんなことをシステム化プロジェクトでやるんですか。そもそも何とか管理システ
情報システムについての誤解 (mark-wada blog)
ITproに連載された記事でいつも感心し参考になるものに「ダメな“ユーザー企業”を叱る！」というのがある。前シリーズ「ダメな“システム屋”にだまされるな！」も好評ですぐに書籍になった。著者は佐藤治夫さんで、元野村総研にいてその後スタッフサービスのCIOを務めた人である。 実は、ぼくはその佐藤さんを知っている、というか佐藤さんが野村総研時代に一緒に仕事をしたことがある、というか正確に言うと仕事をしそうになったことがある。あるプロジェクトの依頼先の一つだったが、残念ながら最後の最後でうまくいかった。その時の対面にいた佐藤さんとのおつきあいはおもしろいものであった。 話はそのことではなく、つい最近書いた記事についてである。その記事は、「日本の国民性は情報化に向かない？」と題したもので、その「“シロウト”が情報システムに口を出す」というくだりのところでちょっとひっかかるものがあった。そこにはこう書
想像以上にガラパゴス化した日本のIT業界？ - 達人プログラマーを目指して
出版されている技術書のタイトルやネット上での情報を元に、なんとなくシステム開発で使われる技術が国によって差があるように感じるということを、これまでいろいろな記事で書いてきたのですが、はたして実際のところはどうなのでしょうか？300年前なら、Manningのin actionシリーズの表紙に描かれている人物*1のように国ごとにいろいろな衣装があって多様な文化が存在していたのでしょうけれど、文明化された現代では、服装も食べ物もそれほど違いがないというところがあります。IT業界は文字通り情報を扱う産業なのですから、世界中の最新の情報が集まってきてしかるべきなわけであり、どの国でも大差がないはずという推測もできないわけではありません。 あくまでも目安なのですが、Google Insights for Searchというサービスを利用すると、単語の検索回数を地域ごとに集計することで、各地域でどういっ
SIは面白くないけどエンタープライズは面白い - きしだのはてな
ここんところ、SIという業態はもうダメという話になってます。 で、エンタープライズ(=企業向けシステム)というのは、SIという業態で開発されるので、エンタープライズ=SIという前提で、企業向けシステムは面白くないという話になっています。 そこから、企業向けアプリは面白くないからサービスを作りましょう、という流れになって、GREEやDeNAなどに人材が流れてます。 実際は、サービスや企業向けというアプリケーションの種類と、SIや内製、パッケージという構築側の業態は独立なので、別に語るべきです。 たとえば、このインタビューを見ると、ゲーム業界もSI化していて、面白くなくなっていそうなことが伺えます。 稲船敬二氏は，何を思い，何を考え，何を目指してカプコンを辞めていくのか。渦中の氏に直撃インタビュー また、GREEやDeNAが提供するゲームは急激に大規模化していて、おそらくSI形態での開発が増え
フレームワークの見極め - ソフラボの技術ブログ
プログラミング言語やフレームワークの選定は見極めが必要だと思います。 仕事ではJavaで業務Webアプリケーションの作成をしています。 今まで使ってきたJavaフレームワークは Struts 社内独自FW(Struts) Seaser2.3+S2JSF+S2DAO Seasar2.4+SAStruts+S2JDBC Seasar2.4+Teeda Doma Wicket です。 少しかじっただけのものあります。 プログラミング言語、フレームワークで言えることは、 バージョンが上がると便利になることが多いということです。 「これいいやん」「ちまたで流行ってるから使ってみよう」 という感じで使い始めますが、使っているとなんか違和感ある、使いにくい、用件を満たしていないと いろいろと問題が出てきます。 すべての問題を解決できるものはないとは思いますが、 使っててめんどくさいという比率が多くなって
alternative dvamp project 技術の空洞化
自称Javaが出来る人でも設計書をまともに書けない。先週は社内の諸事情からプログラミングをする機会を得た。 既にプロパーによってプログラム設計書は記載済で、製造工程以後を担当というもの。 早速プログラム設計書を見てみると…。会員No登録チェックメソッド(引数int型で会員番号)：戻り値はなしtry-catch宣言をする。try-catch宣言をする。try-catch宣言をする。Connection conn = new Connection();PreparedStatement pstm = new PreparedStatement();ResultSet rs = new ResultSet();DBに接続する。pstm = conn.prepareStatement(strSQL);pstm.setString(1, 会員番号);pstm.executeUpdate();conn
受託開発が抱える本質的な非効率性に関する考察 - GeekFactory
受託開発が抱える本質的な非効率性について考えました。ここで挙げたことはどの開発プロセスでも発生しうる問題と思います。 外注のオーバーヘッド 契約に係るコスト。 限られた場所や時間で質疑応答を行うことによる損失 情報の伝達コストは「機会」により決まる。拠点の違い、限られた時間、組織の壁により機会は減り、伝達コストは高くなる。 打合せや質問票を中心に質疑応答を行うため、情報の伝達コストが高くなる。 発注側の縦割り部門、受託側の下請け構造により、情報の伝達コストが高くなる。 決定に要する時間が長くなる。 開発者が業務プロセスを学習するコスト 前提として、どんな要件でも学習コストは必ず発生する。 過去に学習した知識を再利用できるとは限らない。受託側に業務スペシャリストが存在するとは限らない。 発注側から業務に関する説明を受ける機会（＝教育）が十分にないため、極めて非効率な学習にならざるを得ない。
グルーポンのおせち事件を受けてSI業界が本当に教訓とすべきこと - 達人プログラマーを目指して
共同購入サイトのグルーポンでバードカフェというお店が販売したおせちの話題がネットで大いに盛り上がっています。 痛いニュース(ﾉ∀`) : グルーポンの割引で買ったおせち料理が酷すぎると話題に - ライブドアブログ 痛いニュース(ﾉ∀`) : グルーポンおせち騒動で、「バードカフェ」社長が辞任発表 - ライブドアブログ ネット上のネタとしてだけでなく、最終的にNHKのニュースでも取り上げられたみたいです。 http://www.nhk.or.jp/news/html/20110103/t10013172511000.html 昔なら、こういう事件があっても食中毒事件でも起こさない限りここまで大きな話題になっていなかったかもしれませんが、正月早々、ネットの怖さを思い知らされた感じですね。以前なら消費者もこうした商品を購入してだまされたと思っても泣き寝入りで我慢してしまう人も多かったかもしれませ
前向きなヒューマンエラー対策をしよう。 - Sacrificed & Exploited
SIerが仕切っている開発現場でありがちなのが、何かミスを犯すと、そのミスを防止するようにすごく手間がかかるチェックが追加されて、開発効率とモチベーションが下がるというダメなパターン。 たとえば、「今年度は申請書(EXCELシート)書いて上司の判子もらわないと svn commit すらできない職場で仕事することになりました。 - SiroKuro Page」とか。 これはプロセスマネジメントでもなんでもない、管理ごっこだ。管理したつもりになって自己満足しているに過ぎない！！ プロセスをマネジメントしたければプロセスを削れ: DESIGN IT! w/LOVE では、次のように述べられている。 プロセスマネジメントにありがちな間違いのひとつに、ミスを減らそうとして、そのチェックをするプロセスを増やしてしまうということがある。 もちろん、すべての場合にそれが間違いというわけではない。 そのチ
「SE」は和製英語にあらず
本欄を読んでおられる読者の皆様の職業は何であろうか。ITproというサイトではあるものの、「SE」の方が一番多いと筆者は思っている。 にもかかわらず、SEという言葉はどうも人気がなく、使われなくなってきている。筆者がそれに気付いたのは昨年、日経コンピュータという雑誌の編集長をしていたときだ。 編集長は当然、一冊の雑誌に掲載されるすべての記事を読む。『SEよ大志を抱こう』という連載はあるものの、それを別にするとSEという表現は案外出てこない。若い記者はSEと書かずに「ITエンジニア」と書いてくる。筆者はこの表現が好きではなく、編集長の権限ですべてSEに書き直そうと思ったが徹底できなかった。 SEに統一しようと思った理由は二つある。SEのほうがITエンジニアより歴史が長い。「システム」のエンジニアのほうが、「IT」のエンジニアより、仕事や知識の範囲が広い。SEは、ビジネスのシステムを作るエンジ
企業向けアプリのUIはどう設計されているの？――日立デザイン本部に聞いてみた
企業向けアプリのUIはどう設計されているの？――日立デザイン本部に聞いてみた：「モックアップを何十個も作る」 アプリケーションの使い勝手には、機能と同等にそのインタフェースが影響する。実際のデザイン業務はどのように進められているのだろうか？ デザイナーに聞いてみた。 「デザイン」という言葉に対して、どのようなイメージをお持ちだろうか。記者の場合は、雑誌編集を経験していることもあり、誌面やポスター、パンフレットなどのデザイン（いわゆるDTP）を連想する。もちろんインテリアや、あるいはファッションデザインを想起する人もいるだろう。 こういった分野では、プロダクトに占めるデザインの役割が明示的であり、分かりやすい。だが実際には、われわれが手にし、あるいは目に、耳にするプロダクトは（程度の差こそあれ）デザインされたものであり、そこに意匠を施した組織、人物が存在する。もちろん工業製品においても例外で
プログラマーの成長を考えないSIerの仮説は間違っている - 達人プログラマーを目指して
Java EEや.NETはCOBOLやVB6よりも本当に生産性が高いか？ - 達人プログラマーを目指してのコメントで 熟練者も居ることは理解しているが、開発をする上で熟練者ばかりを集めることはできない。このため初心者側にレベルを合わせざるを得ない。 というコメントをいただきましたけれど、これは実に典型的なSIer（の上司）の考え方ですね。SIerの仮説と呼んでもよいくらいですね。とにかく、この仮説の前提となっているのは プログラマーのスキルレベルは一定で成長しない プログラマーは容易に交換可能なリソースである プログラマーは単純労働者である というモデルです。とにかく、この仮説がはびこっているから、いまだにSIerのフレームワークは「初心者側にレベルを合わせざるを得ない」という思い込みで作られていることが多いのでしょう。 COBOL（の初期の）時代ならまだしも、少なくとも現在の開発環境にお
［作業指示、進ちょく管理編］気付いたときにはもう遅い、手戻り・遅延は起こさない
今回は、「バッファー込みで作業をさせてはいけない」「報告を待ってはいけない」など、「作業指示」と「進ちょく管理」という2つの場面における、7種類の禁じ手を解説しよう。 作業指示：バッファー込みで作業をさせてはいけない PMはスケジュールを見積もるとき、問題が起こった場合などに備えて、作業や工程ごとに遅延を見込んだ「バッファー」を確保しておく。そしてそのスケジュールをユーザーと合意した上で、プロジェクトを進めていくことになる。 このときPMがやりがちなのは、バッファー込みのスケジュールを、バッファーが含まれていることを伝えないままチームリーダーやメンバーに示して、作業指示をしてしまうことだ。みずほ情報総研の百井氏は「PMが忙しいときは特に、ユーザーに見せたスケジュール表を、そのまま示しがちだ」という。 しかし、バッファー込みのスケジュールで、リーダーやメンバーに作業をさせてはいけない。「作業
プログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指して
最近はアーキテクトという役割で客先に常駐し、フレームワークの選定をしたり、事前に共通部品を設計したりする役割を担う仕事を引き受けることが結構あります。そこで運よくお客様のマネージャーがオブジェクト指向開発の経験が十分にある方だと、IDEなどの開発環境やインターネット接続環境を当然のように用意してくれるので最初から仕事がスムーズにできるのですが、そうでないとMS Officeしか入っていないロースペックのノートPCを渡されて、要件定義フェーズの期間中、フレームワークの設計をお願いしますとか、私としてはちょっと首をかしげてしまうような困ったことを言われてしまう場合があります。開発フェーズが始まる半年後まではコーディングは基本的に不要という考え方です。アプリケーションのアーキテクトという役割では少なくともコーディング規約を考えたり、ツールやフレームワークの選定をしたりする必要がありますし、プロジ
第3回 なぜ日本のソフトウェアが世界で通用しないのか | gihyo.jp
日米で異なるソフトウェアの作り方 私がシアトルに来たのは1989年なので、こちらに来てもう20年以上になる。最初の10年をMicrosoftのソフトウェアエンジニアとして過ごし、後半の10年は起業家としてソフトウェアベンチャーを3つほど立ち上げている。こうやって1年の大半を米国西海岸で過ごしながらも、日本には毎年数回仕事で帰国しているし、日本語でブログや記事を書いてもいて、ある意味で「日本のソフトウェアビジネスを、一歩離れてちょうどよい距離で見る」ことができる立場にいる。 そんな私が常々感じているのは、日本でのソフトウェアの作り方が米国のそれと大きく違っていること。そして、日本のソフトウェアエンジニアの境遇が悪すぎること―そして、それが「日本のソフトウェアが世界で通用しない」一番の原因になっていることである。 そもそもの成り立ちが違う日米のソフトウェア業界 日米のソフトウェアの「作り方」の
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
超上流を極めるための「要求開発」入門