JTCでアジャイルするには組織としての仕掛けが必要 - arclamp
近年、DXの流れでアジャイルが注目されていますが、JTC（日本の伝統的な大企業）では、組織の問題でアジャイルチームがうまく機能しないことがあります。この問題を解決するために必要なことについて整理してみました。なお、 JTCとは「ウォーターフォール型のシステム開発が中心で、そのために部署の分割とルールが整備されており、文化にまでなっている会社」のことです。 はじめに なぜ、DXにアジャイルか？ アジャイルはタクシーか、電車か 素早さは優先順位の決定回数で決まる JTCでアジャイルをするときの課題 いかに優先順位を調整するか いかに決定するか JTCでアジャイルをするための取り組み いかに優先順位を調整するか いかに決定するか まとめ はじめに このエントリは、2023/1/27に開催されたアジャイル経営カンファレンスでの講演「ビジネスとITをリンクさせるアジャイルな組織のつくり方」の内容に補
アジャイルで「偉い人」はどう振る舞うべきか - arclamp
アジャイルを展開していくうえで、現場の開発チームがどう振る舞えばいいかは具体的なテクニックがあるのですが、「偉い人」がどう振る舞うべきかについての情報が少ない気がしたので整理します。なお、僕の元ツイートはこちらからの一連です。 アジャイルを推進している偉い人の中にはスプリントレビューに出るなど、マイクロマネジメントになりがちな人がいる。理由を聞いたら「成果物が、普通に考えたらそうならないでしょ、みたいなものを作るから目を離せない」という。進言したのは「それはチームに考えさせてないからですよ」（続— 鈴木雄介/Yusuke SUZUKI (@yusuke_arclamp) 2023年2月4日 前提 偉い人、とは 偉い人は関わりすぎてはいけない なぜ、チームは普通に考えないのか 偉い人が関わらないのもダメ 偉い人は適切に関わる 追記 前提 この議論において「そもそも、偉い人やPOやエンジニアに
作業ではなく、仕事をせよ - arclamp
この記事はグロースエクスパートナーズ Advent Calendar 2022の11日目です。 （補足追記：この記事は、一緒に働いている／働くことになる若い後輩たちへのメッセージです） 毎年、メンバーからお題をもらっているのですが「一緒に仕事する相手がこうだったら教えがいがある・やりやすいなと思う言動について書いてほしい」ということなので、僕のキャリア（もうちょっとで四半世紀...）の中で学んできたことも含めて、整理してみます。 心構え：作業ではなく、仕事をせよ まず、一緒に仕事をする上でお願いしたいのは「作業ではなく、仕事をしてほしい」ということです。ここでいう仕事と作業の定義は以下の通りです。 仕事というのは「ある目的を達成するための行動」 作業というのは「ある計画や手順のもとにおこなう行動」 仕事は作業を含んでいます。目的を達成する行動全般が「仕事」であり、仕事の中で具体的な手順を実
マイクロサービスに次に来るかもしれない言葉について - arclamp
2021年9月18日に開催されたXP祭り2021で「マイクロサービスに至る歴史とこれから」という講演をしました。資料は次の通りです。本来は75分ぐらいかかるのを45分で話そうとして、余裕で時間オーバーしてすみませんでした。 テクノロジーとテクニックによる進化の流れ テクノロジーやテクニックは、ITの改善サイクルを向上させるために進化を続けています。「技術そのもの」であるところのテクノロジーに対して、テクニックというのは「人による技術の活かし方」を示します。なので、基本的にはテクノロジーが生まれ、それを使いこなしたテクニックが登場することになります。 テクノロジーとテクニックの進化の歴史現在、進化中のテクノロジーであるCloud NativeやServerlessを前提としたテクニックを示す用語、つまり、マイクロサービスに次に来るかもしれない言葉というのは、時間軸からすると再来年ぐらいに出て
フェアユースは認められたが、Googleは対価を支払うべき - Java API訴訟に寄せて - arclamp
ようやく裁判の結果が出ました。結果としてフェアユースが認められたのはよかったのですが、Googleが勝訴したということは素直に喜べないので、その理由を書いておきます。 関連ニュースは、こういったところから。 約1兆円の賠償金を巡るGoogleとOracleの10年にわたる訴訟が決着、「APIのコピー」は結局違法なのか？ - GIGAZINE Google、オラクルの著作権侵害せず 米最高裁判決: 日本経済新聞 グーグル、米最高裁でオラクルに勝訴--「Android」Javaコード訴訟で - CNET Japan 経緯 では、経緯について時系列に沿って整理していきます。推定可能な事実に基づきますが、一部、妄想も含まれています。 2005年 Google（広告収入増やすには無償で改変自由なスマホOSが重要になるはず。普及させるなら開発者の多いJavaベースだよな。でも、クラスライブラリ改変しな
2016年現在のJavaについて - arclamp
Sun MicrosystemsがOracleに買収されたのが2009年ですから、あれから7年が経ちました。 2013年、Javaは大人になったはずだった 僕は2013年に「イマドキのJavaとORACLEについて - arclamp」という記事をアップし、次のように書きました。 そんなわけで「ORACLEはJavaにコミットしているのか？」という質問が無意味なぐらい、ORACLEはJava技術だけではなく、Javaユーザーの方を向いているのです。 もちろん、ORACLEは（SUNに比べて）イノベーションが足りないとかスピード感がないとか批判もできるのですが、これだけエンタープライズのユーザーが増えた中では、Javaの後方互換性を保ちつつ、着実に進化していく、つまりは引き続き安心してJavaを使うことができるというのは大きな価値でしょう。 そう、Javaは本当の意味でオトナになったのかもし
日本企業にアジャイルを導入して考えたこと #easg - arclamp
2016年11月18日に行われたエンタープライズアジャイル勉強会11月セミナーにて「ユーザー企業へのアジャイル導入四苦八苦」という講演をさせてもらいました。資料は後段に。 エンタープライズアジャイルとは 「エンタープライズアジャイル」の定義は曖昧です。いわゆるエンタープライズ業界でもアジャイルをやっていこう、という方向性を合意しつつ、そのディテールは現場ごとに異なります。 弊社はSIerなので、別顧客で3つの事例を紹介しています。もちろん内容は異なりますが、いずれも以下のような条件になります。 顧客は日本企業で社歴が数十年以上 システムはいわゆるSoE領域（間接的にでも売上に寄与する） 10人ぐらいのチームが継続的に維持される規模 こうした案件を通じた学びはフィードバックサイクル、プロダクトオーナー、アーキテクチャの三点です。 フィードバックサイクル 企業システムではリリースサイクルを「3
ウォーターフォールとアジャイルを考える - arclamp
初めて単独主催の勉強会をしました。ワークショップなので後半の1時間はディスカッションにしたのですが40人のわりには、それなりに面白い話ができた気がしています。資料とワークの結果、あとTogetterは以下から。 togetter.com 今回のプレゼンは純粋な「プロジェクトマネジメント論としてのウォーターフォールとアジャイルの違い」に絞った話をしたので、後半のワークが現実的な話になって面白かったです。話をしたのは以下のようなことです（資料の後半に細かいメモ書きがあります）。 そもそもウォータフォールは必要なのか？ とはいえ、ウォータフォールを採用しなくてはならない状況は？ なぜ、アジャイルを採用できないのか？ チームは重要だけど、どういうメンバーがいいのか？ アジャイルとはいえPM的な人が必要になることってあるよね？ アジャイルの立ち上げってどうするのがいいの？ 偶然、牛尾さんの 私は間違
アーキテクチャ設計に品質特性を使おう - 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)
ITS/BTSは進捗管理に使えるのか - SIの現場で使えるチケット駆動開発 - arclamp
2013年8月24日にグロースエクスパートナーズ主催にて「SIの現場で使えるチケット駆動開発」というセミナーを実施させて頂きました。「チケット駆動開発」の共著者である阪井誠さん（@sakaba37）をお招きしたものです（togetter）。 僕は基調講演で「チケット駆動で加速する、顧客と協業するプロジェクトマネジメント」を話しました。主にプロジェクトマネジメント論の中でチケット駆動の適用箇所について話をしています。 チケット駆動で加速する顧客と協業するプロジェクトマネジメント from グロースエクスパートナーズ株式会社/Growth xPartners Incorporated. 僕はアジャイルでもウォーターフォールでもプロジェクトに合ったものを選べばいいと考えています。どちらの手法にもメリットがありデメリットがあります。ただ、どちらの手法にしてもチケット（駆動）は有用なツールです。SI
アーキテクチャ設計の難しさについて - arclamp
アーキテクチャについては、以下のパワポを見て頂くとして。 なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423 from yusuke suzuki アーキテクチャ設計を要約すると「"何をやるか"と"どうやるか"のバランスを取る事」となります。 "何をやるか"というのは"システムのミッション"のことであり、ソフトウェア品質モデルで言うところの"利用時の品質"、つまりはシステムのユーザーが何を達成したいのかということです。これは「このシステムが動き出した時、どんな価値を生み出すべきか」を考えることになります。 次に"どうやるか"というのは、2つの話があると思っています。1つめは"静的な構成"としてのどうやるか。2つめは"動的なプロセス"としてのどうやるか。 "静的な構成"というのはクラス構成であり、設定ファイルの構成であり、フレームワークの構成であり、つまり、システ
チケット駆動開発で作業管理はしないほうがいい - arclamp
先日、2013/3/23（土）に弊社でチケット駆動と開発環境に関するイベントを開催しました。リンク先には資料も上がっていますので参照ください（※アトラシアン製品関連のイベントです）。 基調講演にはチケット駆動開発を推進されている関西XPUGのあきぴーさんをお招きして「チケット駆動開発をパターン言語で読み解く」という話をしていただき、最終枠ではパネルディスカッションをしました。 チケット駆動開発とウォーターフォール パネルディスカッションでは、僕が「チケット駆動開発を作業計画に使うのは難しく、WBSとの併用が現実的」と話し、あきぴーさんが「作業計画をチケット駆動開発で回していくには」というノウハウを紹介されていました。 この違いは僕がウォーターフォール的な新規案件を、あきぴーさんがアジャイル的な開発/保守運用案件を前提にしているためです。 僕自身はBTS（Bug Tracking Syste
アジャイルがダメだと思う7つの理由 - arclamp
1.全体スケジュールにコミットできない アジャイルはタイムボックス型（一定期間で棚卸しをして、それを繰り返す）のマネジメントをする。だから、全体としての計画は立てられない。「だって、最初に全ての機能を洗い出せないでしょ」というのは分かる、分かるけど全体の計画は立てないといけない。経営者は顧客やVCと全体の計画にコミットしなきゃいけないんだ。そのときに「やってみなきゃ分からない」なんて言えるわけでない。 てか「やってみなきゃ分からない」なんてことは誰でも知っているんだよ。でもさ、それを言わぬが花。大人なんだからコミットメントをしないといけないんだよ。そして、その達成ためには、あらゆる手段を尽くすのです。 2.アーキテクチャ上の無駄が生じる ソフトウェアの構造や構成は工程が進むほどに修正しにくくなり、ずっと残る。だから、アーキテクチャ設計は慎重に全体を考えながらやらなきゃいけない。でも、アジャ
技術的な結合度と設計的な結合度 - arclamp
ささっとBlogを書く訓練。 エンタープライズシステムではシステム間を疎結合に保つことが重要とされます。結合度が下がっていれば両者の依存関係は弱くなります。システムAとBがあったとして、Aが停止した場合に、それによってBが停止しない（縮退はするかも）、あるいはAの内部仕様に変更があった場合に、それによってBが仕様変更を強制されることがない、という示しています。 結合度が低ければシステムのライフサイクルをずらすことができるため、運用上も保守上も大きなメリットになります。 とはいえ、結合度が高いことでのメリットもあります。主にはコストの低下や性能の向上が見込めます。 マスタデータを共有したい場合、ファイルによるデータ交換は結合度を下げることができます。ですが、双方がファイルを入出力する仕組みを作る必要があり、かつ、連携遅延が出てしまいます。そうではなくて、直接データベースを共有するようにすれば
人の役に立つIT（Hondaの挑戦より） - arclamp
2013/2/14-15に開催されたDevelopers Summit 2013（通称：デブサミ2013）で楽しみにしていた講演の1つが「【15-B-3】ICTでクルマと社会をつなぎ、安全・快適で低炭素なモビリティー社会の実現に向けたHondaの挑戦」です。個人的にも感動したのでブログにしておきます。 資料：http://www.slideshare.net/devsumi/2013-16661715 記事：“テレマティクス”でクルマと社会をつなぐ－ビッグデータを活用したホンダの挑戦 Togetter：http://togetter.com/li/454857 詳しい内容は記事に譲るとして、ざっくりと説明を。 より最適なルートを探索できるカーナビを作ろうというビジョンのもと「走行しているクルマをセンサーにして、そのデータを会員間で共有すればいいじゃん」というアイデアで2002年に走行データ
ITに社会は変えられるのか - arclamp
もう2012年も終わりですね。年の瀬に「社会は情報化の夢を見る---［新世紀版］ノイマンの夢・近代の欲望」が面白かったので久しぶりに感想文。 IT業界のトレンドを示すキーワード、いわゆるバズワードの入れ替わりは相変わらずの勢いです。今年はクラウド、ビッグデータ、ソーシャル、モバイルというところでしょうか。特にソーシャルは2011年のFacebook/Twitterブームが頂点と思いきや、LINEの登場で、まだまだ面白いことが起きる可能性が残っていることを示しました。2013年もソーシャルとモバイルの勢いはとどまることをしらないでしょう。 さて、一方で、こうしたバズワードの流行とともに語られるのが「"IT技術"が世の中を変える」という話。本当にそうなのでしょうか？本書は、そんな言説を一刀両断しています。なぜか。それは「技術が進歩したから社会が変化したのではなく、社会の変化によって技術の使い方
歴史から考えるアーキテクチャとマネジメント - arclamp
ソフトウェアアーキテクチャとプロジェクトマネジメントは相互に絡み合う要素です。この関係性を歴史の流れから考えていくと面白い推測が成り立ちます。 アーキテクチャの歴史 「アーキテクチャとは」というのに定まった定義はありませんが、大枠では「システムの目的や環境を前提とし、様々な利害関係者の関心事を整合させた、システムの構成や構造」のことです。 これはもちろん「あるべき姿」です。完成されたシステムには必ず構成や構造がありますが、それが「システムの目的や環境、あるいは様々な利害関係者の関心事」と完全に合致しているとは限りません。 （ソフトウェア）アーキテクチャという言葉、あるいは（ソフトウェア）アーキテクトという用語は2000年前後から一般的になってきました。逆にいえば当時は「システムの構造や構成」と「システムの目的や環境、あるいは様々な利害関係者の関心事」の不一致があったということでしょう。 で
「ソフトウェア開発プロジェクトをとりまく６つの誤解」は真実でもある - arclamp
「ソフトウェア開発プロジェクトをとりまく６つの誤解〜プログラミングを経験しないとわからないこと」に釣られてみます。 6つの誤解は次の通り。 既にあるソフトウェアを流用した方が速く作れる ソフトウェアはハードと違って後から容易に直せる 誰が作っても中身は同じ品質になる 共通部品から先に作ることが出来る 人を増やせば一度に沢山の機能が作れる 正確な見積もりを出すことが出来る 記事の前提は"お客さんはITにそれなりに詳しい（けどプログラミングはしたことがない）情報システム部門の人"ということだと思います。 この6つは誤解しやすいし、僕もお客さんと会話する内容です。でもね、お客さんがそう感じていることも事実です。なるべく安く早く、そして変更に強いシステムを作りたいと願うことは当然のことです（もちろん予算どおりに）。 ソフトウェア開発に職人的（あるいは芸術的）要素があることは間違いありませんが、それ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
おじさんにも分かるITトレンド説明と日本のエンプラITの限界 - arclamp