負のDXを乗り越えるデザインの力 -「感じさせる」ことの重要性 - arclamp
この記事はグロースエクスパートナーズAdvent Calendar 2024の12日目の記事です。DXはすっかりバスワードになり、提案しても嫌な顔をされることが増えてきた今日この頃です。 もうDXは起きている DXを提唱したとされるのはエリック・ストルターマン氏（当時スウェーデン・ウメオ大学教授）です。2004年の論文「Information Technology and the Good Life」（ITと「良い生活」）では、デジタルトランスフォーメーション（以下、DX）を「デジタル技術が人間生活のあらゆる側面に引き起こす、あるいは影響を及ぼす変化」と定義しています。 the changes that the digital technology causes or influences in all aspects of human life. すでに我々の日常生活も会社での活動も、デ
プラットフォームエンジニアリングとはモダンな標準化のこと - arclamp
マイクロサービスによって起きた「標準化、死すべき」の揺り戻しとして、イマドキの標準化を実現するのがプラットフォームエンジニアリングなんだろうな、と思っています。JJUG CCC 2023 Fallで「アーキテクチャの進化から学ぶ、プラットフォームエンジニアリングへのアプローチ」という講演をするにあたり、今更ながらプラットフォームエンジニアリングについて整理をしてみました。 クラウドさえあればOpsチームはいらない？ DevOps Topologiesに記載されているDevOps Anti-Typesでは、以下の8つのアンチタイプが記載されています。 A: Dev and Ops Silos B: DevOps Team Silo C: Dev Don't Need Ops D: DevOps as Tools Team E: Rebranded SysAdmin F: Ops Embedd
アジャイルやマイクロサービスを阻む「今までのやり方」 - arclamp
デブサミ2023夏でスポンサー枠を取って「見えない壁を越えよう！アジャイルやマイクロサービスを阻む「今までのやり方」」という講演をしてきました。資料はこちら。 「アジャイルやマイクロサービス」という「これからのやり方」に取り組む時、苦労するのは「今までのやり方」とのギャップです。これは「ウォーターフォールやモノリス」との手法的な違いというよりも、その裏側にある組織やITの仕組み、さらには文化に起因するものです。 なぜなら、今までは「安定して効率的に対応し続ける」ことが正解であり、そのために仕組みを作り上げてきたからです。このような「今までの組織やITの仕組み」のままで、ただ単に「これからのやり方」に取り組んでも失敗してしまうのです。 「今まで」と「これから」のギャップ 失敗1：半島型 新しい手法を試すにあたり、これまでの仕組みとは意図的の距離を置く必要があります。そうしないと、これまでの仕
アジャイルがダメだと思う7つの理由 - arclamp
1.全体スケジュールにコミットできない アジャイルはタイムボックス型（一定期間で棚卸しをして、それを繰り返す）のマネジメントをする。だから、全体としての計画は立てられない。「だって、最初に全ての機能を洗い出せないでしょ」というのは分かる、分かるけど全体の計画は立てないといけない。経営者は顧客やVCと全体の計画にコミットしなきゃいけないんだ。そのときに「やってみなきゃ分からない」なんて言えるわけでない。 てか「やってみなきゃ分からない」なんてことは誰でも知っているんだよ。でもさ、それを言わぬが花。大人なんだからコミットメントをしないといけないんだよ。そして、その達成ためには、あらゆる手段を尽くすのです。 2.アーキテクチャ上の無駄が生じる ソフトウェアの構造や構成は工程が進むほどに修正しにくくなり、ずっと残る。だから、アーキテクチャ設計は慎重に全体を考えながらやらなきゃいけない。でも、アジャ
アジャイルにおける事前合意について - arclamp
昨年末、ブログをネタにTwitterで議論したことを akipii さんが「アジャイル開発にはモデリングや要件定義の工程はあるのか、という問題とその周辺: プログラマの思索」というエントリにまとめてくださいました。ありがとうございます！。 ブログで書かれたことに直接の返答にはならないのですが「アジャイルにおける事前合意はどうあるべきか？」ということを書きたいと思います。 アジャイルは最初に全てのCDSを決めない まず、狭義のアジャイル開発プロセスは優れたマネジメント手法です。システム開発を評価するQCDS（品質/コスト/期日/スコープ）ですが、Q（品質）というは「そのシステムにとって問題ないレベルにする」でしかないので、CDSの調整が論点になります。 ウォーターフォール型開発というのは、 「スコープは最初に確定」し、 「コストや期日はスコープを達成するために必要な分を最初に設定」し、 必要
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
おじさんにも分かるITトレンド説明と日本のエンプラITの限界 - arclamp