Webアプリで動的型付言語や開発管理が流行りIDEが流行らなかった理由などなど - きしだのHatena
考えてみた。 ここんところ静的型付けなんか不要な空気になってたり、プログラムの内容よりも品質だとか開発管理の話題のほうが盛んだったり、IDEはあると便利だけどなくても大丈夫って雰囲気だったりする理由。 この10年Webアプリケーション花盛りだから、その理由はWebアプリケーションの構造にあるとして考えた。 Webアプリケーションの構造 で、まずはWebアプリケーションの構造。 字が汚いけど、左からブラウザ、アプリケーション、セッション、DB。 赤文字は、左がプログラム実行、右がデータの永続と書いてある。つもり。 Webアプリケーションでは、ブラウザからのリクエストを受けて、プログラムが動き、データベースの情報を処理して返す。 ブラウザ側でプログラムが動くことはあるけど、入力補助程度であまりたいしたプログラムは書かないので、主にサーバー側のプログラムを組む。 このとき、サーバー側のプログラム
ひがやすを「SIerは顧客の良きパートナーとなれ」 － ＠IT自分戦略研究所
「クラウド」や「内製化」で変わりつつあるIT業界。その中で従来型のSIerはどうなるのか。そこで働くITエンジニアはどうするべきか。講演やブログを通じてSIerやエンジニアについて提言を行ってきたひがやすを氏へのインタビューから、2010年の「自分戦略」を立案するためのヒントを探ろう。 第4回｜1 2｜次のページ 1週間にわたってお送りしてきた特集「SIerの未来、エンジニアの未来」。最終回は、システムインテグレータ（SIer）に勤めながら従来型のSIerに数々の提言を行ってきた、Seasarフレームワークの開発者ひがやすを氏に、SIerが今後どうなっていくのか、ITエンジニアはどうあるべきかを聞いた。 2010年のあなた自身の「自分戦略」を考えるうえで、参考になれば幸いである。 ■ 従来型SIerは崩壊する ―― 今年はSIerにとって苦しい年となりましたが、今後SIerはどうなっていく
選んだのは「内製回帰」の道――ひとり情シスの挑戦 － ＠IT自分戦略研究所
ITコスト削減によるユーザー企業の「内製化」の波が生まれている。SIerに外注するのではなく、自社のシステムを自ら作り出す。そうした「内製化」にこそビジネスとシステムの未来があると信じ、SIerからユーザー企業へと転身したエンジニアが、「内製化の可能性」と「やりがい」について語る。 第2回｜1 2｜次のページ 「GoTheDistance」というブログを運営している湯本と申します。簡単に自己紹介させていただきます。 2003年に、とあるユーザー系大手システムインテグレータ（SIer）に新卒で入社し、プログラマ、開発リーダー、プロジェクトマネージャ（PM）、コンサルタントというキャリアを歩んできました。 振り返ってみると、とても恵まれたキャリアを歩ませていただいていたと感じます。ですが、さまざまなユーザー企業さまのお話をお伺いしているうちに、システム開発は「内製」に向かうべきである、と感じる
「有能な人がコードを書くべき」「意志決定はできるだけ先延ばし」「契約を変えるのは難しい」アジャイルの専門家の答え － Publickey
日本での開発プロジェクトのほとんどではウォーターフォール型の開発手法が採用されており、アジャイルソフトウェア開発手法の採用はまだ数％程度といわれています。12月8日に都内で開催されたイベント「Agile Conference tokyo 2009」では、米国でアジャイルソフトウェア開発のコンサルタントなどを行っているThoughtWorksのマネージングディレクター、Xiao Guo氏が会場からの質問に答えるトークセッションが行われました。 このセッションでは、多くのエンジニアが現場でアジャイル開発ソフトウェア手法の導入や運用で悩んでいること、疑問に思うことを率直にGuo氏に投げかけています。セッションでやり取りされた質問と回答の一部を紹介しましょう。 意志決定を先延ばしすること 質問 日本のSIerに務めています。日本では、設計書をエクセルを使って画面や処理などの書類を作成しています。海
PR：ひがやすを対談「2010年は若手エンジニアにチャンスの年」
――2009年は景気の悪化により企業のIT投資が慎重な年でした。システムインテグレータ（SI）にとってはつらい年だったのではないでしょうか。どうお考えになりますか。 ひがやすを氏 1992年ISID入社。以後、主に金融業向けシステム開発に従事。NPO法人Seasarファウンデーションのチーフコミッターとして、2004年に開発に着手した“Seasar2”で、2006年「日経BP技術賞」、2007年には日本におけるOSS（オープンソースソフトウェア）開発の振興を図ることを目的とした独立行政法人情報処理推進機構「2006年度日本OSS貢献者賞」を受賞。 ひがやすを氏 確かに、ユーザー企業で内製化が進んだため、新規開発案件に頼るSIにとっては厳しい年でした。しかし、これは産業構造的に見れば良い潮流だと思います。なぜなら、「限られたコストと期間で、プロジェクトを効率的に回すため、技術力を駆使する」と
SIerの解体と再生 - ひがやすを技術ブログ
ござ先輩のところで、SIer涙目な状態が解説されてますね。 最近SIerがだいぶヤバくなっている件 - GoTheDistance 書いていることはだいたいあっているんじゃないかと思います。 じゃ、SIerは、どうやれば生き残ることができるのか。 「今の体制のまま生き残る必要はないんじゃないの」というのが私の考えです。多重下請け構造こそ、SI業界の最大の問題点なわけだから、「ゼネコン型SIビジネスが崩壊する」のは、悪い話じゃない。 もちろん、会社がなくなったりすると職がなくなり困る人も出てくるわけですが、問題のある業界を残しておくより、一度解体し、新たにやり直したほうがいいと思います。 だって、実際に物を作れないような人たちが設計するなんて、おかしいし、効率悪いもの。 効率の悪いことをしている人が淘汰されるのは当然の話です。 だったら、なぜこれまでゼネコン型SIビジネスが生き延びてこれたの
最近SIerがだいぶヤバくなっている件 - GoTheDistance
via IT業界から思ったことを。 Twitterでつぶやいたら結構こんな感じで厳しい状態になっているSIerが増えているようなので、僕なりに現状をまとめてみる。 よくわかるSIer涙目の構図 サブプライム、金融危機でSIerのお得意様の金融・メーカー様が大打撃を食らう。 2008年はとりあえず様子見で予算編成は据え置きだったが、今年に入って財布にチャックがかかる。 先行き不透明なので、GW明けぐらいの今期のIT予算が相当カットされた数字になった所が続出。 計画していた新規案件を中止するなどする。運用でなるべくカバーする方向へお客様が動く。 その結果SIerは新規案件がなくなる。案件自体がなくなっていく。予算が無いから当たり前。 大手がプロパーの仕事がなくなってきたのでプロパーで人数減らしてまわし始める。 プライムで食い込んでいるお客様の仕事が減ってきたので、外注に仕事が依頼できる余裕がな
ひどすぎるネーミング - idesaku blog
UKTKKNSHINF こういう名前の変数が出てくるのだが、意味わかる？ 答え：受付禁止情報 今読んでいるPL/SQLコードは本当にひどい出来なのだが、その中でもネーミングが群を抜いてひどすぎてむしろ笑えてくるので、ここでさらしてみたい。 先ほどの例でわかると思うが、悪しきネーミング習慣である子音母音抜きの嵐である。変数名だろうが関数名だろうがこのルールで命名されているので、暗号文を読んでいるような気分になる。 他には、例えばこんなのがある。 SKSI 作成 HNKN 変換 KKT 確定 CHKN 中間 DTM Datetime DTA Data こうして見ると、ktkrやwktkとなんら違いがない。 "作成"のような、比較的簡単に対応する英単語が見つかるものまで日本語子音母音抜きで書くという徹底ぶり。でも"情報"はINFだったりする統一感のなさ。そしてこれらが単独ならまだしも、複合して出
ウォーターフォールと裏プロセスに関するメモ - kagamihogeの日記
ひとりにはなりきれない空を見あげる のエントリに、俺は下記のような半ばヤケクソ気味に脊髄反射なブクマコメを残してきた。 【建前】『外部設計』の工程ではプログラムを書いちゃだめ【現実】どっかの小人さんがホントに作りこめるのか検証・先行実装してる裏工程がだいたい存在している。スケジュール表には出てきませんがｗ はてなブックマーク - 極道的研修のあらまし「引数と戻り値が分かりません」 - 歩きつづける ゆり 咲きつづける 裏工程って単語を使ったのだけど、これは俺の言葉ではない。どっかで読んだ記事でそんなよーな言葉使ってたよな、と思い出してコメントに使用した。で、何処の記事だったか探し当てられたのでリンクを張っておく。 「ITエンジニアは職人気質を取り戻すべき」− ＠IT自分戦略研究所 この連載シリーズの第三回目。「現状のソフトウェア開発は間違っていないか？」（プロセス編） − ＠IT自分戦略研
理解してもらうための文章 １０ヶ条 - レベルエンター山本大のブログ
あなたは12歳の4月1日午前ごろに何を考えていましたか？ と聞かれても何も浮かばないが、 中学校の入学式で何を考えていましたか？ と聞かれると、様々な記憶が呼び起こされる。 人間は、仕様や定義、数値といった情報を理解するようには出来ていない。 だから、読んで理解するための書き方と、物事を定義する文章の書き方は異なる。 定義する書き方の文章とは、たとえば設計書だ。矛盾が無く、漏れが無いことを重んじる。 また、書き手の個性が反映されてしまうと成果物として成り立たない場合があるので判で押したような文章で書く。 でないと書き手が変わったときにニュアンスを合せるのに苦労する。 しかしながら、こういった文章は読みにくいし理解しにくい。 最近僕は、作ったプログラムを説明するドキュメントを書いている。 これは設計書のように形式的なものではなく、 理解してもらうことが唯一の目的というドキュメントだ。 読んで
テストのエビデンスが品質を下げてる実態 - レベルエンター山本大のブログ
今の現場は、テスト結果の精密なエビデンスが求められる。 今日はバグつぶしそっちのけで、テスト実施結果に対するエビデンスを採っていた。 数100項目のテストケースに対する画面キャプチャやデータキャプチャのエビデンスを採る。 これを綺麗に整理して、お客さんのハンコを貰わなくては本番にあげられないルールだ。 コア部分のバグ改修できるのは僕だけだが、まにあわないのでバグよりもエビデンスを優先した。 品質よりも品質保証を優先したわけだ。 う〜ん、事情はわかるけど、、、あほくさい。 バグを見つければ見つけるほど、強烈なエビデンス編集作業があるから テストをやってくれてるプログラマーさんも、恐る恐るテストを叩くようになってしまった。 っていうか200ページを越えるテストエビデンスをお客さんに確認させるのってどうやろ。 超大手sIerのBigなドMっぷりには、恐れ入りました。 本質的なサービスに集中できる
IBMの問題はアメリカナイズされた老害 - ひがやすを blog
日本IBM周辺でトラブルが続出している。IBMの下請けとしてサブシステムの開発に携わっていたソフトウェア企業が4億円近い負債を抱え、2008年10月中にも破産手続きに入る。同社は、IBMから追加費用の支払いが行われていなかったと主張して訴訟準備に入っていたという。ほかにも、スルガ銀行やソフト開発会社など、IBMを相手取った訴訟も続発しているのだ。 この訴訟続発を問題のように受け止めている人も多いようだけど、IBM自身にとっては、そんなに問題じゃないと思う。ユーザーの発注が確定しなくてもその先の作業を進めるために下請けに先行発注したりすることがなくなったり、不採算案件は最初からやらない、あるいは早期に手を引くことが、徹底されたからだと思うから。 これまで、日本的な空気を読むビジネスから、アメリカ的な白黒はっきりな契約ベースになったということなので、一方的に悪いことではない。 でも、契約を交わ
NTTデータがウォーターフォールから脱却? - ひがやすを技術ブログ
筆者が現役技術者だった頃はプログラミングは創造的で非常に楽しいものだった。サービス開始直前の相当な忙しさは今も昔も変わらないが、少なくともモチベーション溢れるエンジニア達の姿があった。40年近くの間に何が変わってしまったのか。わが国に定着する「ウォーターフォール(waterfall)型」の開発スタイルに、その一因を探ってみる。 浜口さんが、ウォーターフォールの問題点を指摘している。そして、反復型開発のマイクロソフト版である同期安定化型も今後は検討すべきだとしている。 一方の同期安定化型に話を戻す。こちらは、ソフトウエアをスモールチーム（３?８人）で開発できる単位に分割し、各チームが同時並行的に設計・コーディングを行っていくスタイルである。毎日あるいは一定の期間ごとに、各チームの生産物を統合してテストを行い、品質の安定化を図っていく。 わが国の市場の大半を占める企業向けの個別システムに対して
2008-07-22
タイトルだけで全て終わりそうだけどｗ、まあいいか。 メインフレームの事情について興味深く読んだ。 メインフレーム=ホストが最近では崩れ始めてるのはそのとおりだと思うし、 ホストが圧倒的な高可用性が出せるのも事実だと思う。 実際ちょっと前にホストの人と話をしたときには、最近のオープン系の進化も凄いけど ホストまわりの進化も並じゃないって言ってた。ハードウェアの進化の恩恵はかけられるコストと比例したりするので、 オープン系よりもホストなどの方がより直接的に受けれるっていうのもあると思う。 唯一違和感あったのは人材についてのところかな。 続きを読む T2をServlet3.0風に使ってみた。 多分これが一番プリミティブな使い方だと思う。 以下の例だと、通常のWebアプリからはGET/POSTなので、@Defaultがついたメソッドは 呼ばれることはないです。リクエストしたときも@GETのほうが呼
プログラミングファースト開発の必要性 - ひがやすを技術ブログ
ここではフローチャートの是非を論じるつもりはない。クソだから。もっと一般化してしまえば、○○設計書みたいに「設計書」と名のつくものは全部クソだ。だって動かないんだもん。 動かない以上、それら設計書が正しいのか、漏れがないのかは保証のしようがない。机上検証なんていう工程もあるらしいけど、君たちの脳味噌は何MIPSなんだと問い詰めたい。もちろん、机上検証で見つかる凡ミスもあるだろうけど、そんなのはズボンもパンツも履かずに会社に向かうのと同じくらいのレベルの間違いだろう。 結局はコードを仕上げてから動かして初めて「だめだこりゃ」ということになる。 ○○設計書は、動かないから検証ができない。だから、だめだというのは、半分あっていて半分間違っていると思う。システム開発の大多数は、最初に○○設計書を作成する。顧客にレビューしてもらったり、自分たちでも内部レビューしたりするが、あれは、有効性が低い。 動
株式会社マジカジャパンの羽生章洋が書いてるブログ:本当にERPは効果を出しているのか？ - livedoor Blog（ブログ）
ERPと呼ばれるものがあります。エンタープライズリソースプランニングの略で、経営資源計画と訳されます。統合基幹システムという言い方のほうが最近では一般的になりつつあるようです。要するに大きな業務システムということです。 業務システムの世界は大きく二分されていて、フルスクラッチ派とパッケージ派に分かれます。そして日本はスクラッチ派がまだまだ大勢を占めており、パッケージを導入する場合にもカスタマイズと呼ばれる、つまりパッケージに独自修正を加える比率が非常に高いとされています。 この事態をして「日本の業務は」云々をいう方が多いです。いわくもっとパッケージに合わせるべきである、と。独自の業務にこだわるからシステムの導入に膨大な手間がかかるのだといいます。 さて、では海外で業務をパッケージに合わせて導入をした企業がその後いったいどれほどの業績向上を達成したのでしょうか。これを追いかけると、実はさほど
深い業務知識が必要なのは案件の提案者と要件定義者 - ひがやすを技術ブログ
SIerが必要としているのは業務知識だという都市伝説のエントリで、誤解されたのは、「SIerは深い業務知識が不要だ」というふうに私が主張していると思われたことですね。 誤解されるのは、もちろん、私の書き方が悪かったせいなので、続きを書きます。 SIerで深い業務知識が必要とされる人がいます。案件の提案者と要件定義者です。営業がお客様のところから案件を持ってくると、その案件に関する深い業務知識を持っている人がアサインされ、提案書と見積りを作ります。この役割の人は、深い業務知識が必要です。 無事に案件が獲得できたとしましょう。お客様のところにいって要件をつめるのですが、このときのメンバも深い業務知識が必要です。しかし、全員が深い業務知識を持っていなくても大丈夫。全体の半分弱くらいのメンバが深い業務知識を持っていれば大丈夫だと思います。案件の難易度にもよりますが、一人が業務を深く理解していれば大
プログラミングできない元請けがプログラム設計書をレビューするという矛盾 - ひがやすを技術ブログ
人によってプログラム設計書の定義が違っていそうなので、最初に定義しておきます。ここでいうプログラム設計書は、ほとんどプログラムと対応するようなロジックが記述されているようなものです。 プログラム設計書を作るのは「誰が書いても同じコードにするため」だけでなく、元請けがレビューするためでもあります。元請けがプログラミング言語を読めないので、日本語に落としてレビューします。コードを書いてからプログラム設計書を作ることもあります。 プログラミングがあまりできない人が、ちゃんとしたプログラム設計書はかけないのと同じように、プログラミングできない人が、プログラム設計書のレビューはできません。 当然だよね。プログラミングができないのなら、プログラミング言語を自然言語に翻訳したプログラム設計書を理解できるはずがない。 できるとしたら、誤字脱字、単語が統一されていないとか、日本語が変だとかそんな指摘くらい。
浜口さんに贈るSI業界を良くする方法 - ひがやすを技術ブログ
浜口さんの言葉には、ブクマや突っ込みを生み出す何かがありますね。 したがってシステムの大規模化は、必然的に想像以上のコストアップと信頼性リスクの増大を招くものであるとの認識が必要になる。 きました。想像以上のコストアップだそうです。 そんな浜口さんに贈ります。今よりコストダウンさせて、SI業界を良くする方法。 例えば、誰が書いても同じコードにするために、プログラム設計書(内部設計書)を今、書かせているとしたら、そんな無駄なものはやめたほうがいいと思う。 プログラム設計書は、自然言語で書きます。プログラムは、プログラミング言語で書きます。どっちの言語が、プログラムを書くのに適しているかといえば、誰が考えても、プログラミング言語ですよね。 いきなりプログラミングはできない人もいるから、プログラム設計書が必要だという人もいるかもしれませんが、それは、間違っていると断言しましょう。 いきなりプログ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。