技術的負債の返済プロジェクトが失敗する 11 のワケ - jfluteの日記
ワケ一覧 序の口: フレームワークだけが負債だと思ってる 序二段: ビジネスサイドに理解してもらう努力がない 三段目: 技術で遊び過ぎてしまう 幕下: 太り過ぎアーキテクチャ 十両: 過去に目もくれず、現状だって見ない 前頭: 技術に詳しいだけでアーキテクト 小結: アーキテクトの知識と覚悟が足りない 関脇: スパンが長く、モチベーションが続かない かど番大関: スパンが長く、人の入れ替えでチグハグ 大関: アーキテクチャデザインはどこへ？ 横綱: 実は人間的負債だった 序の口: フレームワークだけが負債だと思ってる みんな、フレームワークが大好き。とはいえ、さすがにみんな、「フレームワークが古いことだけが負債」だなんて思ってないはずだが...なのに多くの人が、あたかもそのような振舞いと判断をしてしまう。潜在意識の Big Issue だから？ o 信用できないテストデータ も負債 o 現
Rebuild: 126: Anti-Democratic Product Management (higepon)
Taro Minowa さんをゲストに迎えて、テックリード、プロダクトマネジメントなどについて話しました。 Show Notes Nguyen Tech Lead（TL/テックリード）の役割 honcho Good Tech Lead, Bad Tech Lead What are the job responsibilities of a Technical Product Manager? Rebuild: 98: Superhumans Wanted (Naoya Ito) Rebuild: 123: The Grail Dialogue (Naoya Ito) Bad Boss vs. Good Leader Image Microservices Google’s product strategy: Make two of everything Product Manager の
プロジェクトが失敗する10の兆候
今年こそは失敗プロジェクトをなくしたいと思っているみなさんこんにちは。ryuzeeです。 先日海外のサイトを見ていたところ、10 Signs When Projects Are Doomed to Failureという面白い記事を見つけたので、10の兆候それぞれをご紹介しつつ私の私見を述べておきたいと思います。 なお、アジャイルなのかウォーターフォールなのかは関係なくあてはまります。 失敗プロジェクトの兆候(1) プロジェクトメンバーが自分たちのタスクをこなすよりもプロジェクトの悪い状況について話し合いをするのに時間を使っている よくあるパターン。 たとえばなかなか仕様が決まらないので見切りで発射してみたら、途中で色々な仕様変更がおこったり考慮漏れが出てきたりして常に対策会議をしなければいけなくなったり、 品質が悪すぎて品質改善のための会議を頻繁におこなうことになったりといった状況。 タス
はてなでの10年戦える新技術採用戦略の話 - Hatena Developer Blog
この記事ははてなデベロッパーアドベントカレンダーを始めます - Hatena Developer Blogの最終日の記事です。昨日は id:ichirin2501 の MySQLでINSERTのデッドロックに嵌る人を1人でも減らすために - ichirin2501's diary でした。 こんにちは、id:stanaka / @stanaka です。今年のはてなデベロッパーアドベントカレンダーも最終日です。 2015年もSwiftのOSS化から、JavaScriptでデスクトップアプリを書けるElectronや、 Chainer, TensorflowなどのDeep Learningライブラリ、AWS RDSのAuroraの東京リージョンでのリリースなどなど、 大小様々な技術が登場しました。 はてな社内でも新しい技術の採用方針については時々議論になるのですが、 社内向けに書いた技術選択を
エンタープライズ・アーキテクチャの選択について - JavaDay Tokyo 2015
20. 19 品質特性 特性の概要 副品質特性 概要 機能適合性 実装された機能がニーズを満たす 度合 完全性 ニーズを機能がユーザの目的やタスクを包含している度合 正確性 必要な精度で正確な結果を与える度合 適切性 機能が定められたタスクや目的を円滑に遂行する度合 性能効率性 システムの実行時の性能や資源効 率の度合 時間効率性 実行時のシステムの応答時間、処理時間などの処理能力の度合 資源利用性 実行時に使用する資源量や種類 キャパシティ 要求を満たすための製品やシステムのパラメータの最大許容値 互換性 他製品やシステムと機能や情報を 共有、変換できる度合 共存性 他製品へ負の影響を与えず、共通の環境や資源を共有して効果的に実行する度合 相互運用性 2つ以上の製品やコンポーネント間で情報を交換、利用できる度合 使用性 効果的、効率的に利用できる度合 適切度認識性 ニーズに適した利用かど
技術選択とアーキテクトの役割
特定のプロジェクトがあり、要件定義をし概要設計をする。 それがアーキテクトの仕事だと思われがちですが、大きな視点を持ち様々な課題を自らリードして解決していく立場としても絶好のポジションです。 このセッションでは、Mobage オープンプラットフォームの立ち上げから、 グローバルプラットフォーム展開、さらには mixi 社との共同プラットフォーム構築、 JavaScript SDK と認証技術の組み合わせによる新しい HTML5 プラットフォーム構築をアーキテクトという立場でリードし続けた立場から、技術選択のみならず実現したい事に対する俯瞰的な捉え方を、これまでの実例と共に紹介し、アーキテクトという役割について、お話します。Read less
アーキテクチャ設計の難しさについて - arclamp
アーキテクチャについては、以下のパワポを見て頂くとして。 なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423 from yusuke suzuki アーキテクチャ設計を要約すると「"何をやるか"と"どうやるか"のバランスを取る事」となります。 "何をやるか"というのは"システムのミッション"のことであり、ソフトウェア品質モデルで言うところの"利用時の品質"、つまりはシステムのユーザーが何を達成したいのかということです。これは「このシステムが動き出した時、どんな価値を生み出すべきか」を考えることになります。 次に"どうやるか"というのは、2つの話があると思っています。1つめは"静的な構成"としてのどうやるか。2つめは"動的なプロセス"としてのどうやるか。 "静的な構成"というのはクラス構成であり、設定ファイルの構成であり、フレームワークの構成であり、つまり、システ
Devlove2012 どうしたら良いシステムが作れるのか
2012年12月15日に開催されたDevLOVE2012での「どうしたら良いシステムが作れるのか� - あなたが進むべき道を決めるための�アーキテクチャとマネジメントの話」の資料です。Read less
君はパラダイムシフトに生き残れるか？ | オブジェクトの広場
［レポート］ 君はパラダイムシフトに生き残れるか？ 株式会社オージス総研 山海一剛 ここ数年、ＩＴ業界に大きな変化が訪れつつあることは、誰もが感じているのではないでしょうか。 そしてそれは、クラウド、オープンソース、アジャイルといった技術的の台頭だけではなく、 もっと大きな社会の変化に関連付けて考える方が良いのかも知れません。 では、このような変革のときを迎えて、日本のＩＴベンダはどのように変わらないといけないのか。 エンジニア、特にアーキテクトと呼ばれる人たちの仕事の仕方は、今までどおりでいいのか。 さらには、生き残りのために何を身につけないといけないのか。 オージス総研のプロフェッショナルコミュニティのひとつである「ＩＴアーキテクトコミュニティ」でも、 このような議論が行われました。 答えはひとつではないのでしょうけれど、是非皆さんにも考えていただきたいテーマです。 コミュニティで発表
日立技術研修所にて、「ソフトウェア・アーキテクトへの道」セミナーの講師をしました。：An Agile Way：オルタナティブ・ブログ
12/15、日立の技術研修所にて、「ソフトウェア・アーキテクトへの道 –アーキテクト自らが語る、今日の自分を形成した学習と経験-」と題した研修の講師をさせていただきました。 今回は、日立情報制御ソリューションズ渡辺滋さんのとってもおもしろい企画です。講師陣は、ビースラッシュの山田大介さん、メタボリックスの山田正樹さん、東海大学の清水尚彦さん、グロースエクスパートナーズの鈴木雄介さん、そして私の5人で、5人が自身の経験とアーキテクトとは何か、を語るという趣向です。 ソフトウェア・アーキテクト、または、ＩＴアーキテクトという職種、称号は、最近、よく話題にのぼります。あるプロジェクトが開発する製品、システムの全体像を把握して、そのソフトウェアの基本設計、方式設計をするプロジェクトの最高技術責任者といった意味で用いられることが多いようです。しかし、実際にアーキテクトの活躍を目の当たりにする機会も
DDD/Six Essentials for Strategic Design Decision Making - Java EE勉強会
Menu Top JavaEE勉強会 参加するには FAQ MakingSenseofStreamProcessing MicroservicesVsSOA ModernJavaEEDesignPatterns BSA EIP DSL DDD 議事録 最新の20件2023-11-24 MicroservicesVsSOA/The World of Service-Based Architectures 2020-11-14 DDD/Knowledge-Rich Design MakingSenseofStreamProcessing/Example Implementing Twitter 2020-10-28 EIP/Aggregator 2019-12-18 EIP/Publish-Subscribe Channel 2018-06-10 FrontPage 2017-07-08 Ma
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
2011年4月23日の「DevLOVE 今、未来に繋がるために帆を立てるとき」での講演内容です。 http://kokucheese.com/event/index/9778/Read less
エンタープライズアーキテクトの役割
原文(投稿日：2010/07/28)へのリンク Interarbor SolutionsのプリンシパルアナリストであるDana Gardner氏が司会するラウンドテーブルは次の宣言によって幕を開けた。 EAの必要性は以前よりも切迫しています。しかし、EAを専門職にする努力が必ずしも、EAの信頼性を向上し、EAが採用されやすくなるわけではありません。 このラウンドテーブルの参加者は、MITの情報システム研究センターの主任研究者兼ディレクターであるJeanne Ross氏、Integritas Solutionsのアーキテクチャプラクティスプリンシパルであり、Open Group Architecture Forumの議長も務めるDave Hornford氏だ。そして、このOpen GroupのSkills and Capabilities部門のバイスプレジデントであるLen Fehskens
アーキテクチャの戦略と原理
原文(投稿日：2010/07/07)へのリンク エンタープライズアーキテクチャ(Enterprise Architecture，EA)の役割，およびビジネス戦略との連携を扱った出版物が最近多くなっている。Chris Curran 氏によると， EAは多くのケースで，その潜在的な能力に到達できていません。それは "EA" 自体をあまりに強調しすぎて，結果について重視しないことが多いからです。もっと堅実で協調的なビジネスプランの方に注目するべきです。EA はそれを支える役割でよいのです。 16 のエンタープライズアーキテクチャ戦略苦心談 (16 Enterprise Architecture Strategies Learned the Hard Way) の議論の中で，Curran 氏は次のように述べている。 ビジネスと IT パートナーの間の信頼と信用の強さが，EA 成功の指標となります。
アーキテクトのソフト・スキル（1/2） - ＠IT
本コーナーは、マイクロソフトが季刊で発行する無料の技術論文誌『アーキテクチャジャーナル』の中から主要な記事をInsider.NET編集部が選び、マイクロソフトの許可を得て転載したものです。基本的に元の文章をそのまま転載していますが、レイアウト上の理由などで文章の記述を変更している部分（例：「上の図」など）や、図の位置などを本サイトのデザインに合わせている部分が若干ありますので、ご了承ください。『アーキテクチャ ジャーナル』の詳細は「目次情報ページ」もしくはマイクロソフトのサイトをご覧ください。 ■概要 優秀なアーキテクトには優れた技術力が欠かせないことに異論はないでしょう。しかし、私がこれまでに会った中で最も優れたアーキテクトは優れた技術力を持っているだけではなく、周りの人と協力できる資質も持っています。 このような “ソフト スキル” を向上させることにより、普通のアーキテクトを効率の面
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「ITアーキテクトの役割と責任」デブサミ2015 20-C-1
Javaエンジニアのためのアーキテクト講座-JJUG CCC 2014 Fall
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。