軽量からアジャイルへ - 機械猫の日記
id:yamazaさんの日記になぜ「軽量言語（Lightweight Language）」というのかという疑問が投げかけられていた。軽量という意味は何か、というような疑問だと思うんですが、ふーむ。そういえば、同じような話をどこかで聞いたなぁ・・・あ、Agileか。笑 アジャイルも元々軽量プロセスと呼ばれていたけど、「軽量って何？」みたいな話になってアジャイルという言葉が誕生したのだった。であれば、今言語に対しても同じことが起きるんじゃないかなぁ。つまり、軽量言語ではなくアジャイル言語（？）に。 では、アジャイルって何か？というと、これはアジャイル宣言で明文化されていて、そのおアジャイル宣言の価値を共有するものがアジャイルなのだ（ですよね？汗）では、今一度ここでアジャイル宣言を振り返ってみる。 プロセスやツールよりも、個人と相互作用 包括的なドキュメントよりも、動作するソフトウェア 契約交
わたしが知らないスゴ本は、きっとあなたが読んでいる: 名著！「デッドライン」
長くなりすぎたこのエントリのレジュメ …というか、見出しの一覧。これ見てご興味ある方はお読み下さいませ。 マネジメントの4つの本質 マネジメントおける簡潔で痛切なエッセンス（一部） 設計とデバッグに関する恐ろしい事実 残業と生産性とプレッシャーに関する恐ろしい事実 生産性の測定について 管理者の怒りについて 会議を効率よく行うための、たったひとつの冴えたやりかた 大事なことが、ずばり書いてある。背中を押したのは「ソフトウェア開発の名著を読む」なんだけど、確かに名著だ。初読は物語を楽しみ、再読、再々読で血肉にすべきだな。 延ばし延ばしにしてた一冊を読み始めて「どうして今まで読まなかったんだあぁぁっ」と叫びだすような逸品がある。本書がまさにそう。デマルコは「ピープルウェア」がピカイチと決め付けてた自分が恥ずかしい。 「ピープル」がプログラマ・チームリーダーの視点で書いているが、「デッドライン」
kuranukiの日記 改善型開発について
現在のシステム開発という開発モデルを考えてみると、そのシステムを必要としており開発の依頼を発注する発注側と、実際の開発作業を請け負う開発側の間で、プロジェクトに対し契約を結んだ段階からシステム開発は始まる、というのが当たり前の話。そして、この当たり前と思われている関係でビジネスを続けると問題があるのでは、と考察したのが以前のエントリ、「ディフェンシブな開発*1」だった。 今回は、その当たり前だと思われているところについて、発想の転換を取り入れて考えてみようと思う。社会における通念や物事を大きく変えるためには、コペルニクス的転回が必要だからだ。 ノウハウを集約できないSI企業 まずこの「プロジェクト開始してからシステム開発を始める」という点について、ディフェンシブであるということ以外にも、SI企業として重大な問題点が隠されている。それは、IT技術に対するノウハウの蓄積に関する問題である。今の
続マジカのひみつ
マジカを使って若手に実験。なかなか興味深い結果が得られた。前回のマジカのひみつはここ。 実験対象 入社2-4年の若手社員（♂3人） SEとして分析・設計をやるかたわら、テスターとして試験もやってる java読み書きはできるが、プログラマではない 予備知識なし (゜Д゜)ハァ? まじかァ? という連中 実験1：マジカなし マジカの説明なし。ある企業の業務フローをポンと渡し、「明日このヒアリングを顧客とする、という状況で、疑問・質問・ツッコミをピックアップしてね、15分でね」 対象となった業務フローはセミナーでもらったもの。どこの企業にもある「与信業務」「受注業務」に限定して分析を行う。 マジカなしの場合、出てくる質問はさもありなんなものばかりだった。つまり、誰でも思いつく質問だし、回答する方もそれなりな準備がされているものばかり。 手続きのフォーマットはありますか? 与信の基準となるものはあ
■ - ( ・ω・)ノ＜しすてむ開発。
プログラムを組むとき、ソフトウェア開発時に経てきた取捨選択。 ・何はともあれ作り始める事。 作るものの形すら見えずに何ができよう。 仕様書という名の書類にある画面は完成形ではない。 機能を作りながら考えても、作り直す事ができなければ バグが消える事はない。 事前に構築する形を想定し設計し試しようやくプログラミングする。 遠回りだと思えたこの行為が最速と平均値を叩き出せる行為であると実感できた時からやめた。 ・とりあえず動くもので完成と言い張ること。 ちょっと触ればエラーがあふれ、 直しても直しても収束しないｸｻﾚｿｰｽ。 後の改変時にも読むのが辛くなる神経衰弱剤。 目先の納期に合わせようと走り始めても目標は自分で遠くしていと気づいた時にやめた。 ・メソッド分割しない事。 用件を考えながらコード化するとしばしば行が長くなる。 これを分割しないことはその場では楽な選択肢なのだが、後が辛くなる。
分析設計手法のスタイルとオフショアの脅威 - 設計者の発言
顧客との打合せの場でどんどんモデリングするやり方を「その場方式」と筆者は呼んでいる。いっぽう、ユーザからヒアリングしたことをメモして持ち帰って机上でモデリングして、次回の打合せでその結果を示して検討するやり方を「持ち帰り方式」と呼んでいる。「持ち帰り方式」で対応できる案件も一定の比率で存在するので、そればかりを受注できる職場にいるのなら「その場方式」を身につける必要はない。しかし、「持ち帰り方式」の実践者はオフショアの脅威にさらされていることを知っておいたほうがいい。 ◆スクラッチ案件とリプレース案件 「持ち帰り方式」が有効なのは、メインフレームのオープン化プロジェクトを典型とする「リプレース案件」だ。顧客の生の声よりも、既存のコンピュータ内部のあり方をじっくり調査することで新システムを構想できる。もともと使っていたシステムが使いやすいものだったのであれば、新システムは「建材の刷新された住
「As-is先行」か「To-be先行」か - 設計者の発言
前回、ＤＯＡとＯＯＡとの対立の話を書いたが、ＤＯＡとて一枚岩ではなく、いろいろな考え方をする人たちがいる。だから、筆者も参加している「ＤＯＡ＋コンソーシアム」の集まりは、椿正明博士や佐藤正美氏といった歴々の方法論者や、商売上競合しそうな営業担当者同士が呉越同舟で語り合うという、奇跡のような企画である。参加者の考え方の違いは想像以上で、「どうも偶然にも、我々は全員『ＤＯＡ＋コンソーシアム』という集まりに名を連ねているらしい。一致点が見つかってよかったなあ」なんて冗談が出るほどだ。それほどに違いを楽しめるというのも、本質的な部分が共通している余裕ゆえなのだろう。 ＤＯＡの中でも議論になりやすいのが、「現状分析と基本設計のどっちを先にやるべきか」という問題だ。その前後関係が分析・設計手法の前提をまったく変えてしまうからだ。まあ、けっきょくは「個別の案件毎に特性が違うから、どっちが正しいとはいえな
SI業界で起きているデッドロック:渡辺聡・情報化社会の航海図 - CNET Japan
先週末土曜に久しぶりの通常開催版となったEmerging Technology研究会にて、頭に汗をかく議論に参加してきた。テーマはいつかどこかでやらなければとなっていたSIビジネスの今後について。当日の簡単な感想と参加者のエントリクリップはこちらでまとめているので、個別参照頂くとして、幾つか論点を絞って追記を。 参加者は大きいところにちょっと偏りがあるとはいえ、 ・SIer ・ソフトベンダー ・サービスベンダー（ネットの） ・コンサルファーム ・メディア と周辺領域も含めて充実したやりとりとなった。 SIのI シンプルに考えると、そもそものSIビジネスの存在価値はSIのIにある。インテグレーション。プログラム開発を行うことももちろんあるが、ハードやデバイス、アプリケーションを適時組み合わせて足りない部分を足し（ソフトに限らず、場合によってはハードの調整も行い）、顧客の要望に
Emerging Technology研究会: 4月開催報告：SIビジネスの今後、あるいはSIer2.0
非常に抽象的なところまで行ってしまい、「一旦メディアはいいかな」となってしまった先々月、外をお借りして大規模イベントとなった先月から会場も戻り、テーマも実務の（泥臭い？）ところに戻りということで、現場の難しさを延々語り会う回となりました。 大きいところにちょっと偏りがあるとはいえ、 ・SIer ・ソフトベンダー ・サービスベンダー（ネットの） ・コンサルファーム ・メディア と関係しそうなところがあらかた（ユーザー側は割合からすると少ないですが）揃っての議論というとても良い布陣で進められました。いつもながら、ご参加のみなさまありがとうございます。 細かい業界固有の話は山ほどありますが、最近様々な議論でたどり着くのが、そもそものサービスを取引するようなしきたりが色んな業界で見られないこと。結局この国の基本は箱売りになってしまってるんじゃないかという議論は情報社会学序説でも強く語ら
アジャイル分析設計をする前に、ユースケースをひとつだけに絞り込もう - 今日の役に立たない一言 － Today’s Trifle! －
「アジャイル開発」に先行して「アジャイル分析設計」をというの記事で言っている「アジャイル分析設計」の要旨は、以下の部分にまとまっている。 ユーザーからの要望にもとづいて素早く『ユーザーが理解できるモデル』を描き広げ、それを用いて要望をより具体化しつつモデルに反映させる でもここでひとつ問題。「ユーザからの要望」というのが何なのか、ユーザ自身が分かっていないことが多いのも事実。 そしてそれを解決するには、ユースケース図をひとつだけに絞る方法がとても有効だ。ユーザはいろんなことを実現したいと思っている。でも、それらの要望の大半は、実はひとつの目的を達成するための部分集合であることが多い。たくさんの要望を俯瞰して、何を達成したいのかという目的を絞り込む。 たくさんでてきたいろんな要望は、それぞれが点として存在している。しかし、ユーザが達成したいひとつの目的がわかれば、大半の要望が線でつながる。
要件を要件として深追いしてはいけない - 設計者の発言
ユーザ要件は海に浮かぶ氷山のようなものだ。言語化可能な部分は海上に出たごく一部で、大部分は水没していて言語化どころか意識にのぼることさえない。このような要素をシステム設計においてどのように扱うかによって、上流工程のスタイルはまったく違ってくる。 ◆スクラッチ案件での要件の位置づけ 前回のエントリーで説明した「スクラッチ案件」において、要件はとくに重要視される。新システムを構想するためのレファレンスとなる現行システムが存在しないか、あっても貧弱すぎてアテにならないからだ。 そのような案件向けであっても、要件の扱い方は２つの流儀に分かれる。ひとつは要件全体を正面から定式化するやり方。もうひとつは言語化が困難であるような要件については深追いせずに搦め手（からめて）を用いるやり方。便宜上、前者を「Ａ方式」、後者を「Ｂ方式」と呼んで検討しよう。 ◆要件をじっくりモデル化するＡ方式 上流工程手法の多く
ビジネス設計とシステム設計の分離は可能か？at 要求開発サミット２００６パネルディスカッション：An Agile Way：オルタナティブ・ブログ
3月17日に行われた要求開発のパネルディスかションで、「ビジネス設計」（ユーザ側、発注側）と「システム設計」（ベンダー側、受注側）の間をどう埋めるか、という議論がおもしろかった。 日本総研の細川さんが、その２つの間に点線を引いていたのを、システム側からビジネス側に食い込む斜め線をひき、システム側からビジネス側に押し出すような三角形にし、このデルタ地帯を「黒い三角形」と呼んだ。 豆蔵の萩本さんは、「現にビジネスの設計においてITを抜きでは語れない」ことから、そもそも現在、この点線分割が出来ないことを主張した。動くものを見てみないと、話にならないことが多いのだ。これは、アジャイルの立場とも強く符合する。 ぼくが最もおもしろいと思ったのは、甲府市役所の土屋さんの意見。「システムの側からも、工夫してビジネスの要求を聞き出して欲しい」ということ。「射止めたい異性のためには、さまざまな工夫をしてコミュ
失敗しない情報システム調達 - 顧客の視点で、アジャイルを説明
失敗しない情報システム調達 - 顧客の視点で、アジャイルを説明 目次 はじめに 気をつけろ！ 目的を明確にしよう 予算を明確にしよう システムの初期仕様で契約するのはやめよう 決定権を持った人を担当にしよう 絶えず監視しよう 現物で報告させよう 定期的に短期間で報告させよう ふりかえらせよう 早く稼動させよう 開発技術を身につけよう 良い人を演じよう 信じよう コメントお待ちしています 顧客の視点で、アジャイルを説明 はじめに この文書は、情報システムを調達するときに、情報システム開発会社（以下、「やつら」と略記）から不当に搾取されないように、気をつけることや、予防策について書いています。 よく読んで、情報システムの調達に失敗しないようにしてください。 この文書が、読まれた方のご参考になれば幸いです。 気をつけろ！ 目的を明確にしよう なぜ、その情報システムを必要としているのか、その目的を
「アジャイル開発」に先行して「アジャイル分析設計」を - 設計者の発言
ソフトウエア開発の世界でアジャイル手法が注目されている。「アジャイル」というのは「俊敏な、素早い」という意味の英単語(agile)で、「アジャイル開発」とは、 ユーザーからの要望にもとづいて素早く『動くソフトウエア』を組み立て、それを用いて要望をより具体化しつつソフトウエアに反映させる といった開発スタイルを意味する。 筆者自身もアジャイル開発には共感を覚える。ユーザーが事前に表明できるシステム要件は非常に限られたもので、それに頼って仕様を固めることには無理がある。どうしても、ユーザー要件を漸進的に具体化するための「動くソフトウエア」のような仕掛けが要る。 とはいうものの、その適用に関しては疑問もある。アジャイル開発では、小さなモジュール毎の「設計・構築・テスト・評価」の繰り返し（イテレーション）で作業が進むが、そもそもその「小さなモジュール」を切り出す根拠がよくわからない。この問題はシス
DOA vs OOA対決(その1) - UMLモデリングレッスン執筆日誌
渡辺幸三さんが自身のblog「設計者の発言」で、DOA（データ中心アプローチ）とOOA（オブジェクト指向アプローチ）の違いについて議論している。渡辺さんとはこのテーマについて、過去にも何度かメールなどで直接議論したことがある。とても面白いテーマだし、せっかくの機会なので、今回はblog上で議論してみようと思う。 実はこの議論の時はいつもそうなのだが、議論の中身と関係なく、強いストレスを感じる。この最大の理由は、渡辺さんが強く主張する意見に対して、自分が十分に反論しないからだと思う。正確には「反論しない」というよりも「あまり強く反論する気になれない」といった感覚である。 この原因は、方法論に対するスタンスの違いにあると思う。 自分は方法論を使う立場である。既存の方法論の中で役に立ちそうなものを選んで、実務で利用する。使いづらいところがあれば、自分の解釈で一部を割愛したり、内容を補うこともある
CNET Japan
人気の記事 1「Android 15」で何が変わる？特に楽しみな新機能6選 2024年03月19日 2次期マイナンバーカードのデザイン公開--「マイナカード」の名称廃止も検討 2024年03月19日 3「iPhone 16」より「iOS 18」に注目すべき理由 2024年03月18日 4KDDI、AI事業のELYZAを傘下に--ソラコム等に続く「スイングバイIPO」狙う 2024年03月19日 5アップル、「iPhone」へのグーグル「Gemini」搭載に向け交渉か 2024年03月19日 6「Rakuten Music」に楽天モバイルユーザー向けの「バンドルプラン」--0円で5時間再生 2024年03月18日 7アップルのDarwinAI買収はAIを強化した「iPhone」の登場を示唆するのか 2024年03月18日 8本田圭佑氏✕藤田晋氏が語る「今25歳だったら」--起業、投資、チーム
「XPは押しつけるものではない。自分が変われば必ず伝わる」，XPの提唱者Kent Beck氏語る
「自分を変えられるのは自分しかいない」。2006年9月5日，ソフトウエア開発プロセスの一つ，eXtreme Programming（XP）を提唱しているKent Beck氏を囲んで記者懇談会が開催された。自分が変われば，必ずまわりは変わる。そんな信念が感じられた懇談会だった。 Beck氏の著書である「XPエクストリーム・プログラミング入門 第2版」は「XP is about social change.」という文章で始まっている。日本語版では「XPとは社会改革のことである」と訳されているが，ソーシャルのニュアンスが少し違うという意見もある。そこでまず「XPでいうソーシャルとはどういう意味か」と質問した。 Beck氏はソーシャルの例として「14歳になる私の娘は，ある友人と1時間くらい話をし，別の友人と同じ話をまた1時間くらいする。彼女はソーシャルな子供だ」と語った。つまり「社交的」「コミュニ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://blog.nikkeibp.co.jp/itpro/it-service/archives/2005/06/post_2.html
nri-aitd.com - このウェブサイトは販売用です！ - 野村総合研究所 情報技術本部 エンジニア 野村総研 採用 研究所 リソースおよび情報
リードテック - SQLException検索