A common debate in software development projects is between spending time on improving the quality of the software versus concentrating on releasing more valuable features. Usually the pressure to deliver functionality dominates the discussion, leading many developers to complain that they don't have time to work on architecture and code quality. Betteridge's Law of headlines is an adage that says

www.ntt.com これを見てちょっと最近の流れと違うなぁとしみじみ思ったので全力で反論してみる。。 僕自身は８１年代生まれ、小学校6年生のときにPC98シリーズのN88Basicで独学でBasicから入って、中高とDirectX使ってゲーム作ったりして、大学のときにバイトで実務のプログラムを初めて〜、と何故かまぁ小さいながらも経営者として傍らまだ炎上した案件とかに入って消火活動に勤しんでたりしてる。まぁ後半はどうでもいいけど、この世代では日本海外とわず独学で勉強するのは至って普通だと思う。クロアチアだと勿論PC98じゃなくてAmigaとかドイツ製のPCが主流のよう。 で、一方で最近の新入社員たちを見てると最初からスクールに通って、大学で授業を真面目にうけて、インターンでメンターに面倒を見てもらって、バイトも常にメンターがいつつ実務に関わってって流れが普通。プログラミングは常に勉強とし

福岡市の商業施設で21歳の女性が殺害された事件で、刃物を持っていたとして逮捕された少年が、女性を刺したあと、6歳の女の子に馬乗りになり刃物で襲いかかっていたことが、捜査関係者への取材で分かりました。近くの客に制止され女の子は無事でしたが、警察は、少年が無差別に買い物客を狙っていたとみて捜査しています。 警察はトイレの近くの1階のフロアで、血のついた刃物を持っていた自称、無職の15歳の少年を銃刀法違反の疑いで逮捕し、30日検察庁に送りました。 少年は吉松さんと面識はないとみられ、捜査関係者によりますと、1階の防犯カメラにはトイレに向かう吉松さんのあとを少年が追う姿が写っていたということです。 その後トイレで吉松さんが刃物で刺されたとみられていますが、さらに、このあと少年が、周囲にいた6歳の女の子に馬乗りになり刃物で襲いかかっていたことが、捜査関係者への取材で分かりました。 その際、近くにいた

チームで受講することで、クイックにスタートできる研修メニューをご用意しています。チームの立ち上げ時期や、学び直し、認識合わせとしてご活用ください。

出典は列挙するだけでなく、脚注などを用いてどの記述の情報源であるかを明記してください。記事の信頼性向上にご協力をお願いいたします。（2016年6月） 『建築について』をアウグストゥスに披露するウィトルウィウス（右）。1684年の絵画 マルクス・ウィトルウィウス・ポッリオ（ラテン語: Marcus Vitruvius Pollio, 紀元前80年/70年頃 - 紀元前15年以降）は、共和政ローマ末期・帝政ローマ初期に活動した建築家・建築理論家[1]。『建築について』（De Architectura、建築十書）を著した。この書物は現存する最古の建築理論書であり、おそらくは日本における最初の建築理論書でもある。 概要[編集] ウィトルウィウスについては、『建築について』の著者であること以外には知られず、その出生年、没年、家系は不詳である。ただし著作からは彼が建築家であることは明らかであり、またア

期間2週間とAgileに(?)撮影された超低予算傑作映画になぞらえて WFHでNetflixが仕事が捗る今日この頃ですがいかがお過ごしでしょうか。 本を読む時間も取れるようになり、ソフトウェアの名著と呼ばれる分厚めの本も読めますね。 これらの名著の著者はどこかで聞いたことある名前だなと思って調べますと、20年ほど前に定義されたアジャイルソフトウェア開発宣言の宣言者17名に含まれるものも多く、この１７名が一体どんな方々なのかを深堀りしてみます！ （若造ですので知らないことも多くミスなどありましたらご指摘いただけると幸いです！ ） 下記、アジャイルソフトウェア開発宣言です。 参考URL（ググると大量にでました） - アジャイル開発における12の原則を理解する - アジャイルマニフェストはいまだに重要性を持つか 絵では8人しかいないのが気になりますね。 アジャイルチームは基本１０名以下で組織され

Java屋、AWS屋、モデリング大好き、オブジェクト指向、ドメイン駆動設計、Spring Framework

旅行業者向けシステムに含まれるリレーショナルデータベースの著作権侵害が争われた事例。 事案の概要 かつてXの従業員として働いていたYらが，退職後にY会社を設立し，旅行業者用システム（Yシステム）を開発，販売した。Xは，Yシステムに含まれる行程作成業務用データベース（YDB）は，Xが著作権を有するデータベース（XDB）を複製したものであるとして，Y会社に対して，複製・頒布等の差止を求めるとともに，Yらに対し，9億円余りの損害賠償を求めた。 XDBは，いわゆるリレーショナルデータベースであり，42個のマスターテーブルから構成され，そのフィールド数（項目数）は405個ある。 一審（東京地判平26.3.14（平21ワ16019）は，Yシステムのバージョンのうち，「新版」を除く部分について，データベースの著作物に関する著作権侵害を認めた。 ここで取り上げる争点 （１）著作権侵害の有無 （２）損害の額

ポエム。 つまり？予算やチームのリテラシーに合わせて最速で作れて、チーム内で「俺ら高凝集低結合だなー」と思えるなら、アーキテクチャはなんでもいいと思えてきました。 前提・まだ割と収益が安定してないプロジェクトでの話です。お金があるなら好きにやりましょう。Go Bold。 ・DDDやクリーンアーキテクチャがダメとは言ってないです。むしろ自分は直近そこまで厳格ではないクリーンアーキテクチャでAPI書いてます。 ・以前こういうポスト書くくらいにはアーキテクチャのこと試行錯誤してました。 アーキテクチャ導入議論への疲労以前僕は、DDDやクリーンアーキテクチャを導入するという話が出ると積極的に顔を出すようにしていました。でも、最近は「導入しましょう」「既に適用してあるのでキャッチアップしてください」などの議論をするのに少し疲れてしまい、足が重くなったように感じます。もうおじいちゃんなので体力がないん

博多駅「マイング」の顔出しパネルを自宅に迎えた猛者現る　人々の顔ハメ続けて約8年、新たな居場所には仲間も

はじめに 以前Scrum@Scaleについて@tyantya41717651さん、@zakky_devさんとディスカッションしましたが、先日お二人と、大規模アジャイルフレームワークであるSpotifyモデルと先日公開された失敗記事(「Spotifyは "Spotifyモデル "を使っていない(Spotify's Failed #SquadGoals)」)についてディスカッションしたのでブログにまとめました。*1 はじめに Spotifyモデルと取り上げた理由 モデルの失敗ではなく、ヒトの失敗 扱える以上の自由や権限を与えた悲劇 1. チームへの過剰な権限付与による、サイロ化の加速 2. 分隊のプロセスの自由さや能力不足による、分隊間協力の困難化 3. 全員での意思決定を追求したことによる、意思決定コストの増大 まとめ Spotifyモデルと取り上げた理由 今回Spotifyモデルの詳しい解

出自はなんでも良いんだけど、関西弁喋ってる奴に都知事になって欲しくない。 そもそも、地元の仲間内ならまだしもフォーマルな場で方言を使う人には疑問を持っている。 全く関係のない地方の方言を使うような人間に東京都知事が務まるとは思えない。 まともな教育を受けていればTPOに応じて喋れるんじゃないの？ 地方にだって国語の授業あるでしょ。 都知事ってローカルな仕事なんだよ。そこに他の地域のローカルを持ってこないでほしい。 よそが好きならよそでやって欲しい。適材適所。 それか大人しく国会議員やってればいい。国会議員にそんな制約はないから。

僕は、1 日に少なくとも 3,000 行程度、多く書くときで 10,000 行以上のプログラムを書くことができる。その結果、多い月で 10 万行 / 月くらいである。なお、言語は書くソフトウェアの性質上、大半が C 言語である。 また、プログラミングにはバグが付き物だが、ここ 2、3 年の間は、発生するバグの数を極めて少なく保つことに成功している。 とても大きく複雑で、かつレイヤ的に OS に近い処理をたくさんやるプログラムを書く場合は、プログラミングをするときでも、事前の設計が極めて重要となる。設計をうまく行わないと、後になって全面的に書き直しをしないといけなくなったり、パフォーマンスが低下したりする原因となり、開発者の苦痛の原因となる。 当然のことながら、これまで書いたいくつかの大きく複雑といえるソフトウェアの大半の設計も、自分で行った。いかなる場合でも、設計は、最初の 1 回目で確定

記事を書く以上、 「少しでも多くの人に読まれたい」 願望がある。 ブロガー共通の「ホンネ」だと思います。 そのために、どうやって注目を浴びようとするか？ 「ナントカアナリティクス」やら「SEO対策」やらを駆使すれば効果的のでしょうが、私には難解でとても使いこなせません。 テクニカルな工夫もさることながら、やはり基本は「記事の質」。 どれだけ読者の興味を惹くネタを探し出してくるか？ が一番のポイントだと思います。 もっとも、その「決定打」となる解がすぐに見つかれば、苦労はありません。 ブログを続ける上での「永遠の課題」ですね。 また、「読まれやすい記事」「書きたい記事」を両立させるのは難しいものです。 筆が進むのは、やはり後者です。 「自分の気のおもむくままに」「好きなように」でなければ、本末転倒になってしまいます。 どれだけわかりやすい文章にするか？ これなら、自分なりの工夫でなんとかなり

平素は株式会社ライブドアのサービスを ご利用いただきありがとうございます。 提言型ニュースサイト「BLOGOS」は、 2022年5月31日をもちまして、 サービスの提供を終了いたしました。 一部のオリジナル記事につきましては、 livedoorニュース内の 「BLOGOSの記事一覧」からご覧いただけます。 長らくご利用いただき、ありがとうございました。 サービス終了に関するお問い合わせは、 下記までお願いいたします。 お問い合わせ

発売されてから1ヶ月ほど経過しますが、『みんなでアジャイル』を読みました。 書籍は、原田さん(@haradakiro) からスクラム道関西宛に献本いただき、僕が一番最初に読ませていただきました。 まことに、ありがとうございます！ 献本いただいたので書籍に加えて、いろいろな方に知っていただきたい内容も数多くあるので、ブログで書籍の紹介および、僕の感想を記します。 もくじ 本書のもくじは、以下のとおりです。 1章　「アジャイル」とは何か？　なぜ重要なのか？ 2章　自分たちの北極星を見つける 3章　顧客から始めるのがアジャイル 4章　早期から頻繁にコラボレーションするのがアジャイル 5章　不確実性を計画するのがアジャイル 6章　3つの原則に従い、速くて柔軟で顧客第一なのがアジャイル 7章　あなたのアジャイルプレイブック 3章から5章が、本書のオリジナル要素です。 各章のタイトルが、本書で重要だと

陰謀、裏切り、憎悪が渦巻く『ゲーム・オブ・スローンズ』では、悪役キャラクターが数えきれないほど登場してきた。そんな中でも特に強烈な印象を残した極悪キャラクター10人を、独断と偏見でランクづけしたのでご紹介しよう。なお、今回の対象は人間に限定したため、夜の王〈ナイト・キング〉は外している。 ≫≫『ゲー... 10位～8位【『ゲーム・オブ・スローンズ』薄幸キャラクターランキング】周りの人々に振り回され、悲惨な運命をたどることになったキャラクターたちがランクイン。 10位　禁断の恋で運命を狂わせた、将来有望な跡継ぎ息子◇ロラス・タイレル ウェスタロスで最も腕の立つ騎士の一人であり、裕福なタイレル家のハンサムな後継ぎには、明るい未来が待っているはずだった。しかし、妹マージェリーの夫レンリー・バラシオンと愛し合っていたことで運命が狂う。レンリーが兄スタニスに殺された後、そのショックから立ち直れず。七

写真1：対談する野中 郁次郎 一橋大学名誉教授（左）と平鍋 健児 Scrum Inc. Japan取締役 デジタルトランスフォーメーション（DX）への取り組みが本格化するなか、注目が集まるのが、アジャイル（俊敏）なソフトウェア開発手法として誕生した「スクラム（Scrum）」である。最近は企業文化のイノベーションを起こすためのチームづくりのための手法として着目されている。スクラム誕生の理論的基盤となった論文を執筆した一橋大学の野中 郁次郎 名誉教授と、Scrum Inc. Japan取締役の平鍋 健児 氏（永和システムマネジメント代表取締役社長）が、スクラムが今、重要視される背景や、そこでの重要な考え方などについて対談した。（構成は志度 昌宏＝DIGITAL X編集長、文中敬称略） 平鍋 健児（以下、平鍋） 　Scrum Inc. Japan取締役の平鍋 健児です。野中先生が1986年に竹内