エンジニアtype 技術者のキャリアを考えるWebマガジン - 転職＠typeエンジニアtypeは、各種エンジニアをはじめ「創る人たち」のキャリア形成に役立つ情報を発信する『＠type』のコンテンツです。
ひがやすを「SIerは顧客の良きパートナーとなれ」 － ＠IT自分戦略研究所
「クラウド」や「内製化」で変わりつつあるIT業界。その中で従来型のSIerはどうなるのか。そこで働くITエンジニアはどうするべきか。講演やブログを通じてSIerやエンジニアについて提言を行ってきたひがやすを氏へのインタビューから、2010年の「自分戦略」を立案するためのヒントを探ろう。 第4回｜1 2｜次のページ 1週間にわたってお送りしてきた特集「SIerの未来、エンジニアの未来」。最終回は、システムインテグレータ（SIer）に勤めながら従来型のSIerに数々の提言を行ってきた、Seasarフレームワークの開発者ひがやすを氏に、SIerが今後どうなっていくのか、ITエンジニアはどうあるべきかを聞いた。 2010年のあなた自身の「自分戦略」を考えるうえで、参考になれば幸いである。 ■ 従来型SIerは崩壊する ―― 今年はSIerにとって苦しい年となりましたが、今後SIerはどうなっていく
PR：ひがやすを対談「2010年は若手エンジニアにチャンスの年」
――2009年は景気の悪化により企業のIT投資が慎重な年でした。システムインテグレータ（SI）にとってはつらい年だったのではないでしょうか。どうお考えになりますか。 ひがやすを氏 1992年ISID入社。以後、主に金融業向けシステム開発に従事。NPO法人Seasarファウンデーションのチーフコミッターとして、2004年に開発に着手した“Seasar2”で、2006年「日経BP技術賞」、2007年には日本におけるOSS（オープンソースソフトウェア）開発の振興を図ることを目的とした独立行政法人情報処理推進機構「2006年度日本OSS貢献者賞」を受賞。 ひがやすを氏 確かに、ユーザー企業で内製化が進んだため、新規開発案件に頼るSIにとっては厳しい年でした。しかし、これは産業構造的に見れば良い潮流だと思います。なぜなら、「限られたコストと期間で、プロジェクトを効率的に回すため、技術力を駆使する」と
報酬にこだわらないとプログラマの地位は低下するよ - ひがやすを技術ブログ
プログラマーはお金とは無縁の存在です。 プログラミングに誇りを持ちたいなら単価を上げること - ひがやすを blogには全く賛成できません。 なぜなら「プログラム」は本質的に経済的価値を持っているわけではないので、プログラムを作る人、すなわちプログラマーは本質的に経済的価値をもつ存在ではないからです。 こう思っている人は、そこそこいるかもしれないけど、だからこそ、プログラマーの地位が低いんだと断言しておこう。プログラムは本質的に価値がないって思っているのがそもそも間違い。 良いプログラムは価値がある。元の山本さんの話にも出てくるけど、きちんとしたプログラムによって、システムは、サクサク動くようになり、業務上の使い道が大きく広がるのです。 価値のあるものからは、対価(金)を得なくてはならない。 エンジニアに限った話ではないけど、自分の成果に対する報酬は、こだわるべきだ。じゃないと優秀な人が入
NTTデータがウォーターフォールから脱却? - ひがやすを技術ブログ
筆者が現役技術者だった頃はプログラミングは創造的で非常に楽しいものだった。サービス開始直前の相当な忙しさは今も昔も変わらないが、少なくともモチベーション溢れるエンジニア達の姿があった。40年近くの間に何が変わってしまったのか。わが国に定着する「ウォーターフォール(waterfall)型」の開発スタイルに、その一因を探ってみる。 浜口さんが、ウォーターフォールの問題点を指摘している。そして、反復型開発のマイクロソフト版である同期安定化型も今後は検討すべきだとしている。 一方の同期安定化型に話を戻す。こちらは、ソフトウエアをスモールチーム（３?８人）で開発できる単位に分割し、各チームが同時並行的に設計・コーディングを行っていくスタイルである。毎日あるいは一定の期間ごとに、各チームの生産物を統合してテストを行い、品質の安定化を図っていく。 わが国の市場の大半を占める企業向けの個別システムに対して
開発生産性が低い方が収入が多いって変だよね - ひがやすを技術ブログ
開発生産性が低い方が収入が多い（人月がかかるほどお金がとれる）というビジネスモデルを根底から覆す可能性があります。開発生産性をあげればあげるほど収入が減ってきます。SIビジネスが立ち行かなくなる方向に向かうのです。 実際の現場では、開発生産性が低くて、人月がかかるほうが売上が増えるというのは、紛れもない事実です。大手SIerの開発手法が、生産性よりも失敗しないことを重視するのは、この事実が原因なのは間違いありません。失敗せずに多くの工数をかけたほうが売上が増えるのです。 だから、ソースコードと一対一に対応するような無駄なドキュメントを「誰が書いても同じようなソースコードにするため」なんて理由で書かせるのです。 詳しくは「誰が書いても同じコード」は大事なことなのかのエントリを参照してください。 営業は、売上で評価されることが多いので、営業の力が強いところは、売上至上主義に走りがちです。でも、
プログラミングファーストでもまだ中途半端 (mark-wada blog)
ひがやすをｂlogで「プログラミングファースト開発の必要性」が書かれている。このひがさんのプログラミングファーストは以前あるセミナーでプレゼンを直接聞いたことがあるのでだいたいの考え方や内容も理解しているが、ぼくの感想はまだ中途半端のような気がする。まずはそのブログから。 プログラミングファースト開発とは、ドキュメントを書いてからソースコードを書くのではなく、動くソースコードを書いてユーザに実際に触ってもらうということを何度も繰り返して、仕様を固める開発手法。ドキュメントは仕様が固まった後に書く。 プロトタイプ開発との違いは、最初に作ったものを捨てずに、本番で動かすものとして開発し続けること。アジャイルとの違いは、全工程をテレーション（筆者注：イテレーション？）でまわすのではなく、顧客と仕様をつめるところのみを何度も繰り返し仕様が固まるまで行なうこと。 これは、現在のような人月ビジネス化し
プログラミングファースト開発の必要性 - ひがやすを技術ブログ
ここではフローチャートの是非を論じるつもりはない。クソだから。もっと一般化してしまえば、○○設計書みたいに「設計書」と名のつくものは全部クソだ。だって動かないんだもん。 動かない以上、それら設計書が正しいのか、漏れがないのかは保証のしようがない。机上検証なんていう工程もあるらしいけど、君たちの脳味噌は何MIPSなんだと問い詰めたい。もちろん、机上検証で見つかる凡ミスもあるだろうけど、そんなのはズボンもパンツも履かずに会社に向かうのと同じくらいのレベルの間違いだろう。 結局はコードを仕上げてから動かして初めて「だめだこりゃ」ということになる。 ○○設計書は、動かないから検証ができない。だから、だめだというのは、半分あっていて半分間違っていると思う。システム開発の大多数は、最初に○○設計書を作成する。顧客にレビューしてもらったり、自分たちでも内部レビューしたりするが、あれは、有効性が低い。 動
jQueryでリストをリンクに変える方法 - ひがやすを技術ブログ
こんな感じのリストがあったとします。 <ul> <li>http://www.google.co.jp</li> <li>http://www.yahoo.co.jp</li> </ul>もちろん、リストをクリックしてもなにもおきません。これをjQueryを使って、リンクに変えてみましょう。 each()とwrapInner()を組み合わせます。 <html> <head> <title>sample08</title> <script type="text/javascript" src="jquery.js"></script> <script type="text/javascript"> $(function(){ $("li").each(function(i){ $(this).wrapInner( "<a href=\"" + $(this).text() + "\"></a
深い業務知識が必要なのは案件の提案者と要件定義者 - ひがやすを技術ブログ
SIerが必要としているのは業務知識だという都市伝説のエントリで、誤解されたのは、「SIerは深い業務知識が不要だ」というふうに私が主張していると思われたことですね。 誤解されるのは、もちろん、私の書き方が悪かったせいなので、続きを書きます。 SIerで深い業務知識が必要とされる人がいます。案件の提案者と要件定義者です。営業がお客様のところから案件を持ってくると、その案件に関する深い業務知識を持っている人がアサインされ、提案書と見積りを作ります。この役割の人は、深い業務知識が必要です。 無事に案件が獲得できたとしましょう。お客様のところにいって要件をつめるのですが、このときのメンバも深い業務知識が必要です。しかし、全員が深い業務知識を持っていなくても大丈夫。全体の半分弱くらいのメンバが深い業務知識を持っていれば大丈夫だと思います。案件の難易度にもよりますが、一人が業務を深く理解していれば大
「テストをすべきなのは知っているが，現実にはできない」という現場の状況をいかに打破するか，気鋭のソフト開発者とテスト技術者がパネル討論
「テストをすべきなのは知っているが，現実にはできない」という現場の状況をいかに打破するか，気鋭のソフト開発者とテスト技術者がパネル討論 Developers [Test] Summit 2008（デブサミTest） 「建前ではなく実際にテストを普及させるにはどうすればいいのか」。2008年4月23日，東京・九段で開催されたテストに特化したソフトウエア開発者向けカンファレンス「Developers [Test] Summit 2008（デブサミTest）」で「【徹底討論】テストなんていらない？！-テストを，どこまでやるべきか？」というパネル・ディスカッションが開催された。 司会を務めたのはタワーズ・クエスト プログラマ兼取締役社長であり，テスト駆動開発（TDD）の日本での第一人者である和田卓人氏。同氏に，オープンソース・プロジェクト「Seasar」のチーフコミッタであるひがやすを氏，テストの
日米トップJ2EEアーキテクトが語るフレームワークの未来---Gavin King氏にひがやすを氏が聞く
O/Rマッピング・ツールHibernate，JBossのフレームワークSeamの作者Gavin King氏。King氏はEJBなどJavaのコンポーネントを統合するWeb Beansを提唱し，Javaの標準化プロセスである「The Java Community Process」で標準化が行われている。金融業のシステムや商用フレームワークに採用されているDI(Dependency Injection）コンテナSeasar2の作者ひがやすを氏。ひが氏はSeasar2で，アジャイルな開発を実現するためのツール作成に取り組んでいる。日米のトップJ2EE(Java2 Enterprise Edition)フレームワーク・アーキテクトがWebアプリケーション・フレームワークの未来について語った。
プログラミングできない元請けがプログラム設計書をレビューするという矛盾 - ひがやすを技術ブログ
人によってプログラム設計書の定義が違っていそうなので、最初に定義しておきます。ここでいうプログラム設計書は、ほとんどプログラムと対応するようなロジックが記述されているようなものです。 プログラム設計書を作るのは「誰が書いても同じコードにするため」だけでなく、元請けがレビューするためでもあります。元請けがプログラミング言語を読めないので、日本語に落としてレビューします。コードを書いてからプログラム設計書を作ることもあります。 プログラミングがあまりできない人が、ちゃんとしたプログラム設計書はかけないのと同じように、プログラミングできない人が、プログラム設計書のレビューはできません。 当然だよね。プログラミングができないのなら、プログラミング言語を自然言語に翻訳したプログラム設計書を理解できるはずがない。 できるとしたら、誤字脱字、単語が統一されていないとか、日本語が変だとかそんな指摘くらい。
浜口さんに贈るSI業界を良くする方法 - ひがやすを技術ブログ
浜口さんの言葉には、ブクマや突っ込みを生み出す何かがありますね。 したがってシステムの大規模化は、必然的に想像以上のコストアップと信頼性リスクの増大を招くものであるとの認識が必要になる。 きました。想像以上のコストアップだそうです。 そんな浜口さんに贈ります。今よりコストダウンさせて、SI業界を良くする方法。 例えば、誰が書いても同じコードにするために、プログラム設計書(内部設計書)を今、書かせているとしたら、そんな無駄なものはやめたほうがいいと思う。 プログラム設計書は、自然言語で書きます。プログラムは、プログラミング言語で書きます。どっちの言語が、プログラムを書くのに適しているかといえば、誰が考えても、プログラミング言語ですよね。 いきなりプログラミングはできない人もいるから、プログラム設計書が必要だという人もいるかもしれませんが、それは、間違っていると断言しましょう。 いきなりプログ
みえてきたSpringの戦略 - ひがやすを技術ブログ
ロッドジョンソンのこのエントリやHibernateの中の人のエントリをみるとSpringの戦略が大体見えてきます。 まず、Springの現状を整理すると VCから出資を受けた 教育中心のビジネスモデルでは、VCの期待するリターンを稼げない ということ、意外なのは、サポートはあまりビジネスになっていないということですね。 教育のビジネスは、長く続けるのは、実は難しいんですよ。一度教育を受けたお客様は、次の案件で引き続き同じプロダクトを使う場合でも、教育は二度は買わないから。ビジネスを継続させるためには、新規のお客様が、増え続けなければいけない。それに対して、サポートビジネスは、案件が続く間、サポートフィーを払ってもらえるし、次のプロジェクトでもきっと、サポートを買ってくれる。 教育ビジネスは、かならず人を張りつけなければいけないので、スケールしにくい。売上を増やそうと思えば、人を増やさなけれ
『Seasar2によるスーパーアジャイルなWeb開発』発売記念 ひがやすをさんインタビュー［後編］（WEB+DB PRESS plusシリーズ）］｜gihyo.jp … 技術評論社
『Seasar2によるスーパーアジャイルなWeb開発』発売記念 ひがやすをさんインタビュー［後編］ ひがやすをさんインタビューの後編は，本書のコンセプトにもなっているSeasar2の「スーパーアジャイル」にまつわる話題から，今後のSeasarはどうなっていくのか？ そして本書を読まれる皆さんへのメッセージをいただきました。 スーパーアジャイル－生産性を上げるために ―Seasar2で開発者の生産性に貢献したいとおっしゃいましたが，それを端的に表したのが，「スーパーアジャイル」ということですよね。 「スーパーアジャイル」自体はマーケティング用の言葉です。Agile（アジャイル）というのは本来，きっと精神的なところが一番大きいと思うんです。たとえば，モチベーションを重要視したり，人と人との会話を大切にするというのが，もともとあったアジャイルの考え方だと思うんですけど，それは少し置いておいて，マ
技術が枯れる瞬間の見極め - ひがやすを技術ブログ
ギークなら、わくわくするような新しい技術をいつも試してみたいと思っているでしょう。しかし、現実の開発の現場では、ギーク以外の人がほとんどなので、新しい技術には興味がないわけです。たぶん、新しいことを覚えること自体面倒だと思っているでしょう。 そういう中に新しい技術を導入するには、「生産性が高くなる」「開発が楽になる」ということをまわりに納得してもらわなければいけない。最初は、反対されるでしょう。自分が責任取るからと強引に導入しようとするときに、考えて欲しいのは、その技術の枯れ具合です。 新しい技術なので、枯れていないのは当たり前です。なにかあったときに、頼れる場所があることが重要です。頼れる場所とは多くの場合、MLやフォーラムなどでしょう。そこでのレスポンスが早ければ、多少枯れてなくても何とかなります。 何とかなるとはいえ、枯れていない状態が長く続けば、それだけ利用者の負担も増える(MLな
『Seasar2によるスーパーアジャイルなWeb開発』発売記念 ひがやすをさんインタビュー［前編］（WEB+DB PRESS plusシリーズ）］｜gihyo.jp … 技術評論社
WEB+DB PRESS plus（ウェブディービープレスプラス）シリーズは, Webアプリケーション開発のためのプログラミング技術情報誌『WEB+DB PRESS』編集部が自信を持ってお届けするシリーズです。 『Seasar2によるスーパーアジャイルなWeb開発』発売記念 ひがやすをさんインタビュー［前編］ ひがやすをさんは，Seasar／Seasar2の生みの親であり，現在もSersarファウンデーションのチーフコミッターを務めています。Seasarの啓蒙活動をはじめ，ソフトウェア開発やエンジニアの仕事などをテーマにした著作や講演活動でも知られるひがさんですが，意外なことにSeasar2について単独で書き下ろす書籍は，『Seasar2によるスーパーアジャイルなWeb開発』が初めてです。そこで，本書の発売を記念して，ひがさんにあらためてSeasar／Seasar2，そして本書誕生の背景に
なぜ、SIerが「なにを」作ったのかを公開しないのか - ひがやすを技術ブログ
なぜ、SIerが「なにを」作ったのかを公開しないのか、それが私には不思議でならない。同じくソフトウェアを開発するものとして、納得が行かない。もちろんNDAの壁はある。私でさえ、開発に携わった事実そのものを公開できない案件をいくつか手がけて来た。しかし誰がどの案件を手がけたかすらデフォルトで非公開というのは理解に苦しむ。 あいかわらず弾さんの突っ込みは、内藤のフェイント(相手を見ずに自分の打ちたいところに打つ)のようだと思いつつコメント。 「NDAがあるから」デフォルトで非公開というのは、「あたりまえ」だと思うけど、これだけだとつまらないので、もうちょっと突っ込んで書きます。 一番の原因は、「公開することがお客様にとってメリットがない」あるいは「公開するとマイナスになる」ことが多いからです。 特に社内に閉じているようなイントラ案件は、自分たちの動きが同業他社に知られないように隠しておきたいも
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
