DXの現状分析はコミュニケーションを目的にしよう - arclamp
この記事はグロースエクスパートナーズ Advent Calendar 2023の11日目です。 近年のシステム開発案件では、DXが目的として設定されることが多いでしょう。よく知られている通り、DXには組織や文化の変革を伴うため、その実現は簡単ではありません。DXのはずが、ただの再構築になったという話もよく聞きます。この記事では、自分の経験から、企画段階でDXを外さないために何をすべきかについて書いてみます。 はじめに システム開発の企画段階では、現状分析を行なって課題を洗い出し、そこから目的をまとめるアプローチが一般的です。ところが、ただ現状分析をするだけではDXの目的が見つけられないことがあります。 以下の3つの観点に注意が必要です。 ペインだけではなくゲインを考える 虫だけではなく鳥の視点で見る 関係者とのコミュニケーションのために現状分析する ペインだけではなくゲインを考える 「ペイ
論理を突き詰めてもDXは進まない - EQ（感情知能）の可能性 - arclamp
コンサルタントとして外部からDXの推進を支援していても、当然ながら思ったように変革が進まないことがあります。そこには様々な理由がありますが、なかなか論理だけでは語れない部分もあるなと思っていたときにHyper-collaboration社の吉田さんに出会い、EQ（感情知能）というものについて知りました。 感情的になるのは良くない ビジネスの場で「感情的になる」のは良いことではないでしょう。「嫌いだからやらない」「好きだから優遇する」というのは許されない行為です。感情の反対は「理性」であり、ビジネスの場では理性的な行動が求められます。論理を組み立て、その整合性と正当性によって物事は判断されるべきです。 一方で、人間というものは「感情を切り離して何かをする」ということが簡単にできるわけでもありません。であれば、感情を上手にマネジメントし、理性とつなぎあわせて成果をあげたほうがいいよね、というの
アジャイルやマイクロサービスを阻む「今までのやり方」 - arclamp
デブサミ2023夏でスポンサー枠を取って「見えない壁を越えよう！アジャイルやマイクロサービスを阻む「今までのやり方」」という講演をしてきました。資料はこちら。 「アジャイルやマイクロサービス」という「これからのやり方」に取り組む時、苦労するのは「今までのやり方」とのギャップです。これは「ウォーターフォールやモノリス」との手法的な違いというよりも、その裏側にある組織やITの仕組み、さらには文化に起因するものです。 なぜなら、今までは「安定して効率的に対応し続ける」ことが正解であり、そのために仕組みを作り上げてきたからです。このような「今までの組織やITの仕組み」のままで、ただ単に「これからのやり方」に取り組んでも失敗してしまうのです。 「今まで」と「これから」のギャップ 失敗1：半島型 新しい手法を試すにあたり、これまでの仕組みとは意図的の距離を置く必要があります。そうしないと、これまでの仕
スクラム導入には組織の取り組みが必要なことを電車にたとえてわかりやすく説明してみる - arclamp
スクラムは、アジャイル開発方法論の中でも最も広く知られており、実際に適用されることも多い手法です。しかし、人に依存する面や精神論が強調されてしまい、マネジメント手法としての仕組みについて理解が広まっていないように思います。そこで、スクラムを電車にたとえながら、その仕組みと、メリットや副作用について説明してみます。 Yamanote Line 山手線 | Melvinnnnnnnnnnn (FN2187) | Flickr CC BY-SA 2.0 はじめに 私はエンタープライズ領域でのアジャイル導入に関わり、様々な立場の方にスクラムの説明していますが、その中で、2つの誤解があると思っています。 1つ目は「スクラムは開発部門が取り組むもの」という誤解。スクラムを機能させるには、経営層とビジネス部門と開発部門が協力しなければなりません。 2つ目は「スクラムの成功には、スクラムマスター（SM）や
JTCでアジャイルするには組織としての仕掛けが必要 - arclamp
近年、DXの流れでアジャイルが注目されていますが、JTC（日本の伝統的な大企業）では、組織の問題でアジャイルチームがうまく機能しないことがあります。この問題を解決するために必要なことについて整理してみました。なお、 JTCとは「ウォーターフォール型のシステム開発が中心で、そのために部署の分割とルールが整備されており、文化にまでなっている会社」のことです。 はじめに なぜ、DXにアジャイルか？ アジャイルはタクシーか、電車か 素早さは優先順位の決定回数で決まる JTCでアジャイルをするときの課題 いかに優先順位を調整するか いかに決定するか JTCでアジャイルをするための取り組み いかに優先順位を調整するか いかに決定するか まとめ はじめに このエントリは、2023/1/27に開催されたアジャイル経営カンファレンスでの講演「ビジネスとITをリンクさせるアジャイルな組織のつくり方」の内容に補
作業ではなく、仕事をせよ - arclamp
この記事はグロースエクスパートナーズ Advent Calendar 2022の11日目です。 （補足追記：この記事は、一緒に働いている／働くことになる若い後輩たちへのメッセージです） 毎年、メンバーからお題をもらっているのですが「一緒に仕事する相手がこうだったら教えがいがある・やりやすいなと思う言動について書いてほしい」ということなので、僕のキャリア（もうちょっとで四半世紀...）の中で学んできたことも含めて、整理してみます。 心構え：作業ではなく、仕事をせよ まず、一緒に仕事をする上でお願いしたいのは「作業ではなく、仕事をしてほしい」ということです。ここでいう仕事と作業の定義は以下の通りです。 仕事というのは「ある目的を達成するための行動」 作業というのは「ある計画や手順のもとにおこなう行動」 仕事は作業を含んでいます。目的を達成する行動全般が「仕事」であり、仕事の中で具体的な手順を実
システム開発で曖昧な要望を形にしていく方法 - arclamp
このブログはグロースエクスパートナーズ Advent Calendar 2021の10日目です。 社内メンバーから要望があったので、僕自身がどのようにシステム開発の初期段階において、どのように要望を整理し、形にしていっているのかについて書きたいと思います。 なお内容は弊グループの案件を前提にしているので、システム開発は以下のような状況が一般的です。 クライアントは直接契約（プライム） 要望を出すのはクライアント企業内で事業運営側の人で、システム開発にかかわった経験がないことがある 対象システムはSoE/mode2で、一般消費者や取引先などの外部ユーザーと、社内で業務を回す内部ユーザーがいる 相手の話を整理するフレーム まず、相手から得られる情報を4つの階層にわけて整理する必要があります。 目的：達成すべきこと 戦略：目的を確実・効率的に達成するためのシナリオ 戦術：戦略を実行するための具体
マイクロサービスに次に来るかもしれない言葉について - arclamp
2021年9月18日に開催されたXP祭り2021で「マイクロサービスに至る歴史とこれから」という講演をしました。資料は次の通りです。本来は75分ぐらいかかるのを45分で話そうとして、余裕で時間オーバーしてすみませんでした。 テクノロジーとテクニックによる進化の流れ テクノロジーやテクニックは、ITの改善サイクルを向上させるために進化を続けています。「技術そのもの」であるところのテクノロジーに対して、テクニックというのは「人による技術の活かし方」を示します。なので、基本的にはテクノロジーが生まれ、それを使いこなしたテクニックが登場することになります。 テクノロジーとテクニックの進化の歴史現在、進化中のテクノロジーであるCloud NativeやServerlessを前提としたテクニックを示す用語、つまり、マイクロサービスに次に来るかもしれない言葉というのは、時間軸からすると再来年ぐらいに出て
大きなアーキテクチャ設計と小さなアーキテクチャ設計 - arclamp
2017/12/15（金）にエンタープライズアジャイル勉強会2017年12月セミナーで「アジャイル開発を支えるアーキテクチャ設計とは」という話をしました。資料は以下から。 アジャイル開発を支えるアーキテクチャ設計とは 僕の話したかったのは「アーキテクチャ設計といっても『大きなアーキテクチャ設計』と『小さなアーキテクチャ設計』というレベルがあり、後者はチーム内で解決すべきだが、前者はチーム外で解決すべきだ」ということです。 大きなアーキテクチャ設計：システム間連携のレベル→アジャイルチームの外で実施 小さなアーキテクチャ設計：システム内連携のレベル→アジャイルチームの中で実施 なぜ分けるのか、というと、それぞれのレベルで求められる性能も可用性も保守性も違うからです。 小さなアーキテクチャ設計は「チームが好きにすればいい」わけですが、大きなアーキテクチャ設計は「チームをまたがって企業内でそれな
日本企業にアジャイルを導入して考えたこと #easg - arclamp
2016年11月18日に行われたエンタープライズアジャイル勉強会11月セミナーにて「ユーザー企業へのアジャイル導入四苦八苦」という講演をさせてもらいました。資料は後段に。 エンタープライズアジャイルとは 「エンタープライズアジャイル」の定義は曖昧です。いわゆるエンタープライズ業界でもアジャイルをやっていこう、という方向性を合意しつつ、そのディテールは現場ごとに異なります。 弊社はSIerなので、別顧客で3つの事例を紹介しています。もちろん内容は異なりますが、いずれも以下のような条件になります。 顧客は日本企業で社歴が数十年以上 システムはいわゆるSoE領域（間接的にでも売上に寄与する） 10人ぐらいのチームが継続的に維持される規模 こうした案件を通じた学びはフィードバックサイクル、プロダクトオーナー、アーキテクチャの三点です。 フィードバックサイクル 企業システムではリリースサイクルを「3
JJUG CCC 2016 Springで基調講演してきた - arclamp
JJUG CCC 2016 Springで「JJUG運営の戦略と戦術」という内容で基調講演をしてきました。資料はこちら。 資料の訂正としては6ページ目にある参加者が「700名予定（申込：1,233名＋α）」は「810名（申込：1,267名）」で確定しました。昨年は670名ぐらいで安定していたので100名以上増えて最高記録を更新しました。なお、年代と参加回数の分布は実際の参加者を母数にしてもほぼ同じ割合いでした。 世の中に「標準的なコミュニティ」なんてないので、あくまでもJJUGの話として見てください。櫻庭さんが副会長を退任されて幹事会を離れるということもあったので、この2年間で櫻庭さんが果たした役割を紹介したかったのですが、ちょっと写真が怖すぎましたかね...。なにか間違ったことが伝わっていないか心配です。 （【追記】を参照ください。ご本人からは公認いただきました！） JJUGの成長はひと
ソフトウェア開発におけるデザイン視点の変化 - arclamp
2015/11/14（土）に開催されたJavaOne2015報告会で話をしてきました。資料は以下。 この資料を作る中で気づいたというか、思ったことは、この20年でソフトウェア開発におけるデザインの視点が変化しているな、ということです。 ユニットテストとDIコンテナが変えたもの ユニットテストは衝撃的なものでした（はい、僕も@t_wadaの薫陶を受けたのです）。 ユニットテストを端的に説明するなら「自分で書いたコードを、自分のコードで確認する」ということですが、いわゆる「テスト」というよりは「実装技法」であると考えたほうがよいと思っています。 （それはTDDの事だとか、UATとしてのテストコードは別の意味があるとか、そういう話を含めたとしても、僕はユニットテストを実装技法だと理解しています。話がややこしいですが、「単体テスト」はテストでしょうね） もちろん、DIコンテナも大きな変化でした。「
アーキテクチャ設計の意味を問う - クリストファー・アレグザンダーの思考の軌跡 - arclamp
建築家クリストファー・アレグザンダーが「パターン」という概念を広め、それがウォード・カニンガムとケント・ベックによってソフトウェア開発のデザイン・パターンに応用されたことをご存じの方も多いでしょう。 （ご存じでない方には、江渡さんの「パターン、Wiki、XP ~時を超えた創造の原則 (WEB+DB PRESS plusシリーズ)」をお勧めします） 「クリストファー・アレグザンダーの思考の軌跡―デザイン行為の意味を問う」は、そのアレグザンダーがパターン・ランゲージに至った経緯、そしてパターン・ランゲージの限界を超えていった流れを追うことができる本です。 この本を読むと、アレグザンダーは一貫して”数学的”であり、客観的に証明可能な構造を求め続けたからこそ、近年では”神”の視座へと導かれていったのだと分かります。 パターン・ランゲージと設計プロセス アレグザンダーはパターン・ランゲージによって、
マイクロサービスアーキテクチャとは何か - arclamp
マイクロサービスアーキテクチャ（以下、MSA）という言葉を聞くようになりました。きっかけはファウラーのブログ「Microservices」（2014年3月）ですが、昨年10月のJavaOne SFでも多くの講演でMicroservicesという言葉を聞かれ、多くのエンジニアがすぐに共感していたことが分かりました。今後、日本でも広く知られる言葉になることでしょう。 一方でMSAは誤解を招きやすいバズワードとも言える気がします。というわけで、僕なりのMSAについての考えをまとめてみました。 MSAは「優れたウェブサービスを観察したところ同じようなアーキテクチャだったので、それをマイクロサービスアーキテクチャと名付けた」というものです。逆に言えば「大きなウェブサービスを作ろうと思ったときの定石」といえます。「各要素を疎結合に構成し、連携する」「それぞれの要素に適した技術を使う」といったアイデアは
ITサービス運営におけるアーキテクチャの役割 - arclamp
2014年11月15日に開催されたJJUG CCC 2014 Fallにて「Javaエンジニアのためのアーキテクト講座」と題して発表を行いました。資料は以下です。 「良いアプリケーションを作る」時代から「良いITサービス運営を実現する」時代になったことで、アーキテクトの役割はどうなったか、という内容を話しました。 今回は自分なりにITサービス運営というものをモデルを書いてみました。v0.1となっていますが、まだまだ見直せることはあると思っています。 元ネタはソフトウェア品質モデルです。ソフトウェア品質モデルでも「外部」「内部」といった静的な要素に加えて、「利用時」「プロセス」といった動的な要素も含めて、お互いに依存したり影響を与えたりするということが定義されていました。ITサービス運営ということを考えて、もう一歩、複雑な構成となっています。大きく分けて「ITサービスを構成する要素」と「IT
アーキテクチャのトレンドサマリ（2014） - arclamp
今年はJavaOneに参加できたので、標準Java系は詳しい人に任せて、僕はアーキテクチャ関連の技術紹介や事例系のセッションを回ってきました。このサマリをJavaOne 2014 サンフランシスコ報告会 Tokyoにて発表しています。資料はこちらから。 動画はこちらから（コミュニティアップデートの途中からがアーキテクチャトレンドになります）。 発表時間が30分なのでコンパクトになっていますので、さっくりと見ていただければと思います。 もちろん「明日から案件に使えます」という話ではありません。ただ、JavaOneということもあって、話者はエンタープライズへの適用を前提にしています。よって、単純なスケーラビリティだけではなく、システム連携や信頼性についても意識はしています。意識したうえで「まだ簡単にはいかないけど、こうやっていくべきだ」という話です。 サマリとしては、アーキテクチャ設計をする上
アジャイルが否定したものを見直そう - arclamp
2014/9/6に開催されたXP祭り2014で「アジャイルを手放して得られたこと」という講演をしてきました。Togetterはこちらから。 元々は「アジャイルのダークサイド」の話がしたくて応募したのですが、その後、いろいろと考えているうちに僕自身にも気づきの多い内容となりました。 さて反応を見てると前半のアーキテクチャとマネジメントの話に興味を持っていただいたようです。なので、このブログでは「なぜアーキテクチャとマネジメントの話からアジャイルの話をしたのか」ということを書いてみます。 アジャイルがさまたげたもの アジャイル開発手法が大きく注目されるのは1999年の「Extreme Programming Explained」の出版であり、2001年の「アジャイルソフトウェア開発宣言」です。1990年代後半から2000年代初頭というのは、IT産業が大きく成長する時代であり、同時に、当時主流で
アーキテクチャ設計に品質特性を使おう - arclamp
アーキテクチャ設計をするうえで重要なのは「利害関係者の合意を得る」ことです。利害関係者全員の要件が全て理解できても、それぞれの要件には必ずトレードオフが存在します。すべて完ぺきに満たすことは不可能なので、トレードオフをバランスよく判断して利害関係者に納得してもらうのがアーキテクトの腕の見せ所です。 このトレードオフを上手に行うために、そのシステムに求められる品質特性を明示し、コミュニケーションの基礎とする必要があります。ざっくりステップを説明すると、以下のようになるでしょうか。 利害関係者にインタビューをして重視しているポイントを聞き出す そのポイントからシステムに求められる品質特性を整理する 整理された品質特性を元に、実際のアーキテクチャの設計を行う 設計されたアーキテクチャを品質特性に照らし合わせて評価を行う 品質特性というのは色々なところで定義がありますが、経産省が公開している「情報
アーキテクトと要求もしくは技術について[追記あり] - 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)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
おじさんにも分かるITトレンド説明と日本のエンプラITの限界 - arclamp
