南米発のツールがIT業界に与えるインパクト
「プログラマはもう要らない」。大手物流会社のシステム子会社で新技術の社内展開を進めるマネージャーはこう言い切る。ここでいうプログラマとは、企業情報システムの開発プロジェクトでプログラムを作成する担当者を指す。ある開発ツールを検証したところ、こうした役割の要員は不要との結論に至ったというのだ。 このマネージャーは記者に対して、ツールを導入した場合の効果をこう語る。「様々な開発言語を知っていて、バグのないソースコードを24時間、延々と高速で書き続ける。そんなスーパープログラマを雇ったのと同じ効果が得られる」。 同社が検証したのは「GeneXus（ジェネクサス）」という開発ツールである。ご存知の方はまだ多くないかもしれない。一口に言えば、アプリケーションの自動生成ツールである。データ項目や画面、業務ルールといった設計情報をGeneXusの表記法で入力すると、ソースコードとテーブル定義情報を自動生
ユニケージ開発手法という古臭いが革新的な開発手法によって - Javaの日々
その業務専用のDSLを早く安く作るという手法は確立されたと言っていい。 Common LispによるDSL作成能力は残念ながら否定されてしまったに近い。 ユニケージ開発は、シェルスクリプトと独自コマンド群から成り、 シェルスクリプトはLinux標準のbashを使い、独自コマンド群はそれぞれ 目的にあわせて独自の開発言語を使うという柔軟な手法を提供する。 シェルスクリプトという最高級言語でありながら、独自コマンドによって 詳細な処理の補完と拡張を可能にしている。 シェルスクリプトの最大の欠点は、それが粒度の細かい処理がほぼできない という点と、関数による拡張性を持たないという点だった。 しかし、独自コマンドの作成という使い古された手法によってそれが 解決されてしまったのである。 さらにユニケージ開発手法はもう一つ重要な主張をしていることになる。 それはシステム開発につきもののRDBを不要であ
アジャイル開発とクラウド（SaaS）利用の位置づけ、SIerの生きる道
早口の関西弁でつっこみまくって笑いを誘い、でも最後にアジャイル開発とクラウド利用の棲み分けについて「なるほど」と思わせる素敵なライトニングトークのビデオを見つけました。 それはPublickeyでも何度か紹介している9月4日に行われたイベント「XP祭り2010」での、市谷聡啓氏によるライトニングトーク「始まらなかったAgileの話をしよう」です。 アジャイル開発、セールスナントカに敗退す ライトニングトークのあらすじを紹介しましょう。市谷氏がある海岸沿いのSIerにいたころの話。 お客様から「特定の期間しか使わない。できるだけ早く利用したい。ただし仕様は変わる可能性がある」というシステム開発案件の依頼を受け、「これはアジャイルしかないだろう」とお客様に提案。 市谷氏はこの提案で「勝利を確信したなと」。 「ところがこいつが出てきたんですね、黒船ですわ」と思わぬ競合が出現。「具体的に言うとセー
NTTデータのHadoop報告書がすごかった - 科学と非科学の迷宮
業界トップ のエンタープライズ Hadoop 企業 Cloudera に入社しました http://www.cloudera.co.jp/ 今年の6月に、「平成２１年度 産学連携ソフトウェア工学実践事業報告書」というドキュメント群が経産省から公表されました。 そのうちの一つに、NTTデータに委託されたHadoopに関する実証実験の報告書がありましたので、今更ながら読んでみることにしました。 Hadoop界隈の人はもうみんなとっくに読んでるのかもしれませんけど。 http://www.meti.go.jp/policy/mono_info_service/joho/downloadfiles/2010software_research/clou_dist_software.pdf 「高信頼クラウド実現用ソフトウェア開発（分散制御処理技術等に係るデータセンター高信頼化に向けた実証事業）」という
Agileの現状に対する漠然とした不安 - masayang's diary
去年のAgile2009では漠然としか感じていなかったのだけど、今年のAgile2010ではその不安がより確実になってきた。去年はCode Smellのたとえで言えば「どこかでタバコ吸ってる人がいるな」くらいの感覚だったのが、今年は「同じ部屋でタバコ吸ってるバカがいるぞ」、みたいな。 ただしCode Smellみたいなものなので、何かおかしいぞ、という程度の感覚でしかないのも事実である。 その漠然とした不安を抱かせる要因は何かというと「Agileのコモディティ化」なのであります。 自己紹介に「Certified Scrum Masterです」と説明を入れたり、「アナーターハーCSMデースカァー？」みたいな質問をしてきたりする人が今年は昨年よりも確実に目立つ。 あるいは...「わが社は自分では作りません。計画管理と実装は、コントラクタ(契約ベースで請け負う別会社)に任せてます。」みたいな丸投
昭和の名残 - masayang's diary
例の岡崎図書館事件以後、まったりと追っかけている#Librahackだが、今日も面白いねたが出て来た。 →中野区の図書館システムにおけるテスト報告書。中身をみればわかるけど、「ああ、昭和を思い出すねぇ」という感じに懐かしさが先にでてくる。 詳しくは元の資料を参照のこと。どうやら受入テスト相当の内容と思われるが、 テスト担当が何か作業して 問題なければOKでしたと書き込み。 問題があったら、だめですた、と書き込んで対策を実施。で、「今度はOKですた」と記入して次の項目へ。 なんか懐かしいよね こういう検査をしている現場がまだあるということにびっくり。全部で350項目ほどあるようだが、環境設定〜テスト準備〜テスト実施〜結果記録、という作業を一件あたり10分としても3500分。ざっと60時間。テスト結果一覧にある記入が日付だとすれば、確かに一週間かかっている。筆跡からすると一人でやってるようだし
Agile2010 Day One - masayang's diary
本日はワークショップやチュートリアル中心の日。コマ数が多い中、Organization & Enterprisesを「持続可能な範囲で*1」聞いてきた。 目次 How Agile Taught IBM about New Leadership Competencies Agility@Scale - Experiences from the Trenches at IBM Rational Beyond Scope, Schedule, and Cost: Optimizing Value How Agile Taught IBM about New Leadership Competencies 現在はPitney Bowes社の国際技術担当副社長をのSue McKinney女史による「大企業のAgile化に求められる指導者の資質」に関する発表。彼女は去年まではIBMにて「世界各支社のI
選んだのは「内製回帰」の道――ひとり情シスの挑戦 － ＠IT自分戦略研究所
ITコスト削減によるユーザー企業の「内製化」の波が生まれている。SIerに外注するのではなく、自社のシステムを自ら作り出す。そうした「内製化」にこそビジネスとシステムの未来があると信じ、SIerからユーザー企業へと転身したエンジニアが、「内製化の可能性」と「やりがい」について語る。 第2回｜1 2｜次のページ 「GoTheDistance」というブログを運営している湯本と申します。簡単に自己紹介させていただきます。 2003年に、とあるユーザー系大手システムインテグレータ（SIer）に新卒で入社し、プログラマ、開発リーダー、プロジェクトマネージャ（PM）、コンサルタントというキャリアを歩んできました。 振り返ってみると、とても恵まれたキャリアを歩ませていただいていたと感じます。ですが、さまざまなユーザー企業さまのお話をお伺いしているうちに、システム開発は「内製」に向かうべきである、と感じる
ソフトウェア開発の落し穴
ソフトウェア開発の落し穴2013-09-01ソフト開発はプログラムの文法だけを知っていてもうまくいきません。 ソフトウェアのよい開発の仕方について考えます。 ソフトウェア開発はよくトラブルに巻き込まれます。納期がずるずる延びたり、 プログラムがスパゲッティ状態になったり、非常に使いにくいものが出来てき たり。こうした問題をどう解決するかについては今までに多くの人が研究して きました。そして「よいソフトウェアを作るには」という方法論について一定 の成果が上がっているにも関らず、ソフトウェア開発に携わる実務者にまでは 浸透していないのが実状です。 近年では、「ソフトウェア開発方法論」あるいは「ソフトウェア工学」という 名前でこうした成果を本にしたものを数多く見かけるようになりました。これ はこれで望ましいことです。しかし、こうした本を読んだだけでその精神をよ く理解しないまま適用するとかえって
じゃあ見積りもアジャイルでやりましょう！:グロースハッカー研究所
はじめに断っておきますが今回の記事は私の持論ではなく、私の会社のS氏が普段主張してる意見を私の言葉で書いたものです。 お客様はアジャイルがお好き 私はWebアプリケーションの構築を生業としていますが、Webアプリケーションの特性上、よく「アジャイルで開発して欲しい」という要望を受けます。顧客もアジャイルの定義を正確に知っているわけではないと思いますが、アジャイルの具体的な手法として XPがあり、XPは短期のリリースサイクルを繰り返すことで顧客の要求を柔軟に吸収できる開発手法であるという理解はあるようです。これは正確な定義とは異なりますが、アジャイルとXPについて概ね正しい理解だと思います。アジャイル開発について詳しくはウィキペディアをご覧下さい。 顧客から「アジャイルで開発して下さい」と頼まれた時の私の切り返しは、「じゃあ見積りもアジャイルでやりましょう」というものです。アジャイルのメリッ
業務ってなんだ。システムってなんだ。 - Float on the flow
SIerの世界で言われる「業務」って何だろう。 「SEはお客様の業務を熟知していなくてはならない」とか言われる、あれ。 自分は「業務＝仕事の手順」だと思う。 販売管理の手順、経費精算の手順、輸出入の手順、…。 この「業務」の中で、システム化できる部分は、データの記録や照会をするところ。 どういうデータを記録するか。そして、そのデータをどのようにDBに記録するのか、どのように画面に表示するか、DBと画面間の変換はどうするか、データのチェックはどうするか、…。 ちょっと考えると、これってルールの話だということに気づく。 記録・照会したいデータがあって、それをどういうルールで処理するか。 そのルールを定義すること＝基本設計。 で、そのルールを手続き的な言語に落とし込むのが詳細設計と製造。*1 今はこのルールを手続き型言語で書いているので効率が悪い。 処理フェーズを適切に分けて、各フェーズをルール
システム業界向け「モデルハウス」開発快調 - 設計者の発言
持ち家を欲しいと考えた人は、たいていモデルハウス巡りをする。その過程で、曖昧だった家のデザインや予算もはっきりしてゆく。依頼すべき業者も決まってくる。顧客が満足できる家を手に入れるために欠かせないもの、それがモデルハウスだ。 ところが、システム業界にはモデルハウスに相当するものがない。簡単にダウンロードできて、簡単にインストールできて、いきなり動かせる業務システムがない。これはおかしい。その異常さを理解するためには、モデルハウスのない住宅建設がどんなふうになるかを考えてみたらよい。たとえばこんな風だったりするのだろう。 持ち家を欲しいと考えたある若夫婦が住宅建設会社にやってくる。担当営業は「わが社はお客さまの持ち家に対する要求をモデリングして、わかりやすくフィードバックします」と言う。何だかわかりにくい言い方をするなといぶかりつつも夫婦が了承すると、数日後、彼らのもとにひとりの技術者が現れ
スクリプトエンジンの可能性 - 設計者の発言
Java SE 6には、JavaScriptやRubyを含むさまざまなスクリプト言語の実行エンジンが組み込まれている。その結果、Javaプログラムの中でスクリプトを読み込んで実行できるようになった。Javaとスクリプトの実行環境間でオブジェクトをやりとりすることも、一方の環境で作ったオブジェクトのメソッドを実行することも簡単だ。 この機能強化がどんな役にたつのかと思われるかもしれないが、この話を初めて聞いたとき筆者はわくわくした。業務システム向けの実装用フレームワークの中で活用できると直感したからだ。じっさい、現在開発中のフレームワークの中で、スクリプトエンジンはすでに重要な役割を果たしている。 筆者が現在開発している実装用フレームワークを用いると、データ処理パターンを組み合わせてシステムを組み上げることができる。一次テーブルから複数行を読み出したうえで絞込み条件にしたがって一覧するための
もうこういうのやめようよ... - masayang's diary
日経SYSTEMS実践セミナー 手戻りなしの要件定義テクニック 要件定義書の内容が不十分なまま設計作業に着手したところ，要件の追加や変更が相次ぎ，そのたびに手戻りが発生した──。システム構築に携わるITエンジニアであれば，誰しもこんな経験があるでしょう。手戻りにつながる仕様変更を防ぐには，要件定義をしっかりと行い，業務改善に役立つシステム要件を明確にし，構築時におけるユーザーからの協力体制を確保することが重要です。本セミナーでは，手戻りを起こさない要件定義の方法を徹底解説します。要件定義の経験が少ないITエンジニアでも実践しやすいように方法を分かりやすく解説するのに加えて，演習によって理解を深めていただくのですぐに現場で役立ちます。 要件定義が充分かどうかは作ってみないとわからないんだってば。 むしろ、要件定義が不充分であることを前提として、物事を進めるようにするべきなんだってば。 （株）
Kanazawa.processで挙がった話題の補足
Kanazawa.processというテスト駆動開発の勉強会が開催されたので参加してきました。話題に上がったネタの技術的な部分をいくつか補足しておきます。 副作用 この勉強会ではテキストとしてテスト駆動開発入門を用いました。 第一章で出てくる「副作用」という表現。あまりにも一般用語然としていますが、プログラミングの専門用語として「副作用」と言う場合、 状態の変更によって得られる結果が変わることを言います。 wikipediaにも 副作用 (プログラム)という項がありますね。変数の破壊的代入というような言い方もします。 関数型言語では関数が副作用を持たない、つまり、同じオブジェクトを引数に渡したとしても、オブジェクトの状態が変わったことによって メソッドの呼び出し結果が異なる、といったことが起きません。そのために変数への代入は初期化のみが許されて、 再代入(破壊的代入)は許されないという特色
過ぎたるは及ばざるがごとし 作りすぎたRFPの悲劇：ITpro
「これは大作ですね…」と思わず筆者はうなってしまった。本当にRFP（提案依頼書）として作られたものなのか？とにかく分厚い。内容を見ると業務フロー図がその大半を占めている。一つ，質問をした。「この業務フローは誰が作成したのですか？」「エンドユーザー数人に作らせました」と情報システム部のマネージャA氏は回答した。それで筆者は合点がいった。 ある中堅企業B社でのことだ。現行業務システムの陳腐化が目立ち，再構築が必要という判断が下った。情報システム部を中心にRFPを作成することになった。そこでA氏を中心としたRFP作成チームが編成され，RFPを作成した。だが，ベンダー数社を呼んで提案依頼を行ったところ，すべてのベンダーから提案に対して積極的な姿勢を示してもらえなかったのである。 「提案したいが，これはちょっと…」というのが共通した態度であったらしい。その後，どうせ再構築するなら別の業務システムも対
SW開発で火を噴くパターン - プログラマの思索
【1】SW開発ではいつも結合テスト以降で火を噴く。 設計、開発、単体テストまで順調であっても、結合テストから受入テストに至るまでに致命的な問題が発覚する。 例えば、下記のような問題がいつでもどこでも噴出するのではないか。 設計書には、複数の画面遷移による業務フローが考慮されていなかった。 業務のインターフェイスがシステムとして整合性が取れていなかった。 シナリオに従ってテストしたら、設計時には気付かなかった業務フローが見つかったり、想定しなかったデータが作られて、その対応が漏れていた。 つまり、設計漏れ。 実際に結合テスト環境で動かそうとすると、そもそも動かない。 実は、DB環境にViewやプロシージャがもれていた。 あるいは、帳票出力やPDF出力、バッチ処理などに必要なサードパーティのライブラリがテスト環境に無かった。 モジュールをビルドして、Webサーバーを再起動する作業が手順化されて
投資と負債は違うよ(2) - masayang's diary
売り切れました: そりゃ投資と負債は違う id:shivashantiさんからトラックバックをいただいた。 １億円かけてシステムつくれば１億の投資。 運用保守に年間１５００万円で耐用年数５年なら７５００万の負債。 システム導入は投資の結果として負債が手元に残る。 だから導入による効用は投資額＋負債総額を上回るように計画しなくてはならない。 開発費1億円のシステムを5%で5年かけて償却していくと、月額212万7135円 運用保守費年間1500万円=月額125万円 つまり、このシステム投資は月当たり337万7135円以上の付加価値を生まないと「投資に見合った収益がでない」、ということになる。 まあ、普通なら「月に400万円の付加価値を生むシステムを作ろう。そのための投資は月に337万7135円だから、毎月63万円弱の利益が出る」と判断するから、投資に踏み切れるわけで。 で、その開発費分は積んで
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。
インハウス開発とか | 眠る開発屋blog