オランダの銀行INGの「アジャイル」な組織作りがとても面白い - グローバル経営の極北
オランダの金融機関INGが取り組んできたアジャイル型組織への変革が興味深いので、マッキンゼーによる彼等へのインタビューについて冒頭の部分を訳してみました。ぜひ読んでみてください。 マッキンゼー: 「アジリティ」をどう定義しますか？ ING: アジリティとはまず「柔軟性」、そして新しい方向に向かってすばやく適応できる組織の力がポイントです。前例踏襲や官僚的な部分を避けて、みんなの力を引き出そうとするわけです。 また、能力が高くバランスの取れたプロフェッショナルを「育成する」という側面も重要です。「アジャイル」であること、は単にIT部門やその他いろいろな部門を「変える」というのに留まりません。大切なのは、End to Endで一貫した原理を持つ、マーケティング、プロダクト、そして営業の専門家、UXのデザイナー、データアナリスト、そしてITエンジニアといった多様な分野の人たちからなるチーム -
エンタープライズにおけるマイクロサービスアーキテクチャについて - arclamp
エンタープライズ業界でもマイクロサービスアーキテクチャの議論が盛り上がりはじめてて、それは良いのですが、やはり本質的ではない技術論にばかり夢中になっている気がしています。 エンタープライズシステムの現状 モノリシックな巨大システムでは一部分の改修であっても、システム全体対する影響調査やリグレッションテストによる工数増加が発生し、共通機能をいじるとなれば関連機能も含めた改修が発生するなど、スピード感は落ちる一方です。 つまり、従来型のコンポーネント集約のような手法で巨大システムを作ると、開発効率が上がったとしても、保守における変化効率が極端に下げることが分かっているわけです。 一方で、旧来から部門別で構築されてきた中小規模システム達は、いつのまにやら複雑に連携しあっており、相互に影響を与える中では、個別システムの都合だけでリリーススケジュールを決めることが困難になってます。 特に場当たり的に
技術なきマネジメントの衰退とその対策 - メソッド屋のブログ
今回は、マイクロソフトにいて自分が感じているIT業界の大きなスタイルの変化の兆候とその対策について書いてみた。今回もいつも通り、単に自分の意見をシェアしているだけであって、他の人にどうこうしろと言いたいわけではない。ただ、日本のIT業界が米国に追いつき、追い越すための議論のきっかけになるといいなと思っている。自分も楽しみながらも、もがいていることと、そこで見えた光について書いてみたい。 世界は「技術力」の重視に向かっている 私のキャリアは、某大手SIerを12年勤めた後、ITコンサルティング企業に３年在籍して、主に超上流を実践した。その後独立し、ビジネスモデリングから、アジャイルや、DevOpsの導入支援、マネジメント、開発などを実施していた。 私がマイクロソフトを受けてみようと思ったのは、友人からの推薦の要素が大きかったのだが、その背景では、海外で勤務したいという希望があったのと、「技術
Shibu's Diary: 僕のプログラマ人生を賭けてITエンジニア本大賞2016に推薦したい本はこれ
渋日記@shibu.jp 渋川よしきの日記です。ソフトウェア開発とか、ライフハックを中心に記事を書いていきます。 岩切さんがITエンジニア本大賞の募集をしていました。技術書とビジネス書の2カテゴリがあるんですが、それぞれのカテゴリで、2015年に出会った本で、「やばい、これは10年以上待ち望んでた次の時代の道標になる本だ」というものがあったのですが、清き平等な一票ではこの気持ちは伝わらないと思い、筆を執った次第です。 一応僕のことをあまり知らない人も多いと思うので一応説明しておくと、学生のころに日本XPユーザグループの設立準備から関わっていて、アジャイルという言葉が出る前から「仕様書通りにしかコーディングできない世界つまらなそうだし、XPなんか面白そうだな！」と思っていて、イベント運営をしてみたり、C++やらPythonやらRuby(とちぎ)やらのコミュニティに参加したり、ドキュメントツー
テストコードは「書けるようになる」ものじゃなく「書きたい」と思うもの（ポエム） - give IT a try
「Railsチュートリアルを見ながらテストコードを写経しても、自分でテストコードが書ける気がしない」という新人さんのつぶやきに思わず反応した僕の、斜め上から目線の感想を書きなぐっておきます。 テストコードは「書けるようになる・ならない」の問題じゃなくて、「テストコードって便利！テストコードって大事！！」って思えるかどうかじゃないかな～と思ってる。 僕みたいなおっちゃんが働き始めた頃は「テスト = 手で動かして目で確認してスクリーンショットを撮ってエクセルに貼り付ける」という肉体労働だった。 コードを変更したら、もう一回「手で動かして目で確認してスクリーンショットを撮ってエクセルに貼り付ける」を繰り返さなきゃいけなかった。 ところが、テストコードを書けば「自動化できる！何回でも繰り返せる！すぐ終わる！自動テストすげー！！」ってなって、「こりゃテストコード書けた方が100倍いいわ」っていうモチ
ITアーキテクトとは何か - 勘と経験と読経
割と身近なところで頻繁に「ITアーキテクト」という単語か飛び交っていて、もやもやしたので情報を整理しながら書く記事。オチはない予定。 photo by SantiMB.Photos ITアーキテクトの定義 例えばIPAの共通キャリア・スキルフレームワークでの(システムアーキテクトの)定義はこんな感じ。 http://www.ipa.go.jp/jinzai/itss/csfv1.html システムアーキテクト 人材像の役割 ビジネス戦略 に対して最適 なシステムを デザインする。 IT戦略を受け、ソリューションを構成する、又は組込み製品開発に必要となる要件を定義し、それを実現するためのアーキテクチャを設計する。 情報処理技術者試験における(システムアーキテクトの)定義は次のとおり。 IPA 独立行政法人 情報処理推進機構：制度の概要：システムアーキテクト試験 情報システム戦略を具体化するた
「納品」をなくさなくてもうまくいく - arclamp
倉貫さんから直接献本をしていただいきましたので感想がてらに。 本書はいわゆる“アジャイル”を清く正しく実践している実績と、その仕組みを丁寧に解説した本です。しかも、開発体制は「事業会社の内製化」ではなく「外部のソフトウェア開発企業を継続的に利用する」というスタイルであることに大きな意味があります。 （ソフトウェア開発企業という名称ですが、もはや「ソフトウェアだけを開発している」わけではないので、本来は「ITサービスを開発している」企業というような名称が最適なのですが、ここでは一般的な名称として使います） これまでアジャイル開発方法論は「事業会社における保守運用フェーズの内製開発」に最適であるとされてきました。実際、多くのウェブ企業が社内にエンジニアを抱え、継続的な保守運用の中でイテレーティブに開発を行うスタイルを実践しています。 しかし、実際には世の中の大半の企業が“優秀なエンジニア”を雇
アジャイル導入コンサルタントという名前でスクラムだけを導入しようとする人は死ねばいいのにと思った - 水まんじゅう2
この文章中で表現されるアジャイルとはアジャイルソフトウェア開発宣言に沿ったものとします。 なぜか定期的にアジャイル開発をしようとしている人を食い物にしようとしている人のお話を聞くので。 タイトルですべてです。それ以上のことはない。 スクラムはアジャイルな開発を実現するためのプラクティスではあるけれども、スクラムをしてもアジャイルになるわけではないという事実。 それだけなのですが。 今まで見たり聞いたりしてきたアジャイルの失敗例 突き詰めると以下の二つではないかと思っています。 設計ができない 失敗ができない 設計ができない アジャイルだから設計書を作らなくてもよいよね。という人たちはいまだにいるらしい。 設計書という体裁では不要の場合もありますが、設計は必要です。 思いつく限り書き上げると以下の通り。 プロダクトオーナー(お客さん)との合意形成のため 全体で何を作るのかを明確化するため 必
アーキテクトと要求もしくは技術について[追記あり] - arclamp
2014年2月27日の要求開発アライアンス２月定例会で「アーキテクチャの発掘に見る要求変化の発見」、そして翌2014年2月28日にはEnterprise ☓ HTML5 Web Application Conference 2014で「JavaエンタープライズアーキテクチャにおけるHTML5」という講演をさせていただきました。 前半は（ここ数年間は同じですが）、ITサービスの提供において「利用価値、提供機能、構成／構造、プロセス」の４つの要素のバランスが重要であり、そのバランスを取る事がアーキテクチャ設計だという話です（そのバランスを保ちながらモノを作るのがマネジメントですね）。そして、後半はそれぞれのイベントの趣旨に従って変えています。 要求定義がきちんとできても、どんなにHTML5に詳しくても、あるいは、どんなにアジャイルがうまく回っても、それ"だけ"で良いITサービスを提供する事は出
![アーキテクトと要求もしくは技術について[追記あり] - arclamp](https://cdn-ak-scissors.b.st-hatena.com/image/square/6d8216e64106bac7e18f0344459bda51cb85fdba/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F12704346814673873149%2F12921228815719241700%2F1396502451)
未決定を決定する - アーキテクトの考え方 - arclamp
「アーキテクチャ設計の難しさについて」というエントリをしましたが、続きとして「未決定を決定する」という話を。 決定していないことを決める アーキテクチャは「作り方」を示すものなので作り始める前に決定している必要があります。つまり、アーキテクチャ設計はプロジェクトの最初に行います。ところが、皆さんもご存知の通りプロジェクト開始時点で全ての要件が出ることはありません。要件定義＞基本設計と進んで行き、さらには実装も後半になってからアーキテクチャ上で対応すべき問題が発覚することもあります（後工程で問題が発覚するというのはアジャイルでも同じことです）。 ですから、アーキテクチャ設計では「決定していないことを決める」必要があります。 どう決定していないかを決める 決定していないことの設計方法は「どう決定していないかを決める」ということです。 前回のエントリで「接続先のサーバが決まっていない」という例を
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
