アジャイルプラクティスマップはアジャイル開発においてよく使われるプラクティスを鉄道の路線図の形式でまとめたものです。単なる用語集とは違い、二次元で視覚的にプラクティスの位置づけを理解することができます。またアジャイル開発で用いられる各種手法の関連性をつかむことができます。 過去にも、Agile Alliance からアジャイルプラクティスの地下鉄地図（Subway Map to Agile Practices）が公開されるなど、多くの路線図形式のマップが存在しますので、このサイトはさながら Yet Another Agile Practices Map ということになります。 Agile Studio の識者たちにより、過去の歴史を踏まえたアジャイルのトリビアとも呼ぶべき豆知識も充実させました。 マップでは、「手法」を路線で、「プラクティス」を駅で示しています。プラクティスによっては、いく

IIJ ネットワーク本部アプリケーションサービス部・(兼)社長室所属。 メールサービスの運用業務に従事し、日々世界の悪と戦う一児の父親。社内 Power Automate エバンジェリスト(自称)。M3AAWG member / openSUSE Users / WIDE Project メンバー。趣味は大喜利。はがき職人。 皆さんは、子どものインターネットの利用ルールってどのように決めているでしょうか。 文部科学省が提唱した GIGA スクール構想が実現され、今や小学校に入学すると 1人 1台、学校からノートパソコンやタブレットが配布される時代です。来年度 4月に小学校へ入学するお子さんをお持ちの親御さん、共通の悩みなのではないでしょうか。 登場人物 私 世界の悪と戦う一児の父親。 家庭内情報システム部 DX 担当部長、(兼)24時間パソコンなんでもお助けサポートセンター・カスタマーサク

これはなに ども、レバテック開発部のもりたです。最近めっちゃ元気！！ 今回は『データベースについて勉強したいあなたに送る技術書17冊(+11冊1講義7link)』として、もりたがここ半年くらいでわーっと集めたデータベース周りの書籍（とか）を紹介していきます。アプリケーションって結局はデータベースみたいなところがあると思うんですが、おれは長いことデータベースをどう学んだら良いのか分かりませんでした。同じような気持ちを抱えているITエンジニアの人もいると思うので、学習ロードマップと合わせて紹介していきます。 なお具体的な対象読者は業務でなんとなくSQL書いてるけど、ウィンドウ関数とか言われると分からんな……くらいの人です。 扱う領域と扱わない領域 扱う領域としてはだいたい以下 再入門本 SQL 内部構造 論理設計 周辺知識 データベース理論 その他高度なもの モデリング、NoSQL、分散データ

「オブジェクト指向の継承を使うな」という主張が広まっているようです。なんでダメになったんでしょうか。 インターネットで見かけた「継承はダメ」という主張をいくつか眺めて、友人と議論しつつ、考えてみました。 「コードが読みにくくなる」 継承があると、メソッド呼び出しが実際にどのメソッド定義を呼び出すのか字面でわからない。 デバッガを使って、親クラスのメソッドに飛んだり、子クラスに飛んだりするのを追いかけないと行けない。 つらい。という主張。 めっちゃわかる。わかるんですが、これは「高度に共通化されたコードは読みにくい」という一般的な側面がかなり大きいような。 たとえば継承の代わりに高階関数を使うと、関数呼び出しがどのクロージャに飛ぶか字面でわからなくなる。 ひどいとコールバック地獄になって何が何やらになります。 継承がことさらにまずい理由を想像すると、すべてのメソッド呼び出しがポリモーフィック

以前は、DDDでどう実装したらいいかなぁって考えてたんだけど、最近は、そういうことへの興味があまりなくなっている。エンティティや値オブジェクト、集約やリポジトリなど、そのあたりにあまり興味がない。ヘキサゴナルアーキテクチャなども、そんなに考えなくなった。 TypeScriptを使うことが多いので、型でしっかり守るとかカプセル化するとか、そのあたりがどっちでもいっかという気持ちになっていることが影響してるとは思う。TypeScriptでクラスを使おうとはあまり思わないし。BrandedTypeみたいなのを使ってまで型で守ろうとは思わない。 じゃあ何に興味があるんだっけ？って考えてみると、トランザクション境界とユビキタス言語かな。 トランザクション境界 トランザクションの境界を作って、DB（RDBMS）を小さく保ちたいと思っている。DBが大きくなると、すぐに複雑になっていく感じがする。 だから

1年をふりかえる 年の瀬ご多端の折、皆様におかれましては本年も大変お世話になりました。crowdworks.jpの開発をしているプロダクト開発部部長の@hihatsです。 本記事はクラウドワークスAdvent Calendar 2023 シリーズ2の25日目の記事です。 今回は、プロダクト開発部として今年取り組んできたことと、その中での気づき、「Think Like a CTO」という書籍の話にも触れていきます。 今年やってきたこと 技術的負債解消への取り組み 昨年のアドベントカレンダーでも書きましたが、2023年も技術的負債の解消に取り組んで参りました。 結果としては、フロントエンドでの注力の割合が大きかった一年でした。詳しくは@okuto_oyamaさんの1日目の記事をご覧ください。 記事にもありますが、Vue.js化をフロントエンドを触る全チームが行える体制に整えることで加速させてい

こんにちは、リファクタリング大好きなミノ駆動です。 株式会社スタメンでは、企業エンゲージメント構築サービスTUNAG（ツナグ）の技術的負債解消と今後の持続的成長のため、ドメイン駆動設計(DDD)の導入を検討しています。 ところでDDDはとかく理解しづらく、何のためのDDDなんだという議論になりがちです。この記事では、DDDの真の主人公コアドメインを中心に、DDDが何を解決するものなのか、全体像を改めて整理します。 この記事で扱う内容 DDDが解決したい課題と解決方法の全体像。 この記事では扱わない内容 設計パターンの実例などの実装詳細。 大事な前提　〜利益を得るためのサービス開発 会社でのサービス開発は、趣味や道楽でやるものでしょうか。違いますね。ビジネスとして、企業活動としてサービス開発しています。当たり前の話ですが、利益を得られるように開発しなければなりません。 ドメイン駆動設計は、継

www.oreilly.com オライリー・メディアのコンテンツ戦略部門のバイスプレジデントであるマイク・ルキダスの文章だが、彼が数週間前、「コードを書くことが問題なのではない。複雑さをコントロールすることが問題なのだ」というツイートを見かけた話から始まる。彼はこれに感心したようで、これから何度も引用すると思うので、誰のツイートか思い出せればいいのにと書いている（ご存じの方は彼にご一報を）。 件のツイートは、プログラミング言語の構文の詳細や API が持つ多くの関数を覚えることは重要じゃなくて、解決しようとしている問題の複雑さを理解し、管理することこそが重要だと言ってるわけですね。 これは皆、覚えがある話だろう。アプリケーションやツールの多くは、最初はシンプルである。しかも、それでやりたいことの80％、いやもしかしたら90％をやれている。でも、それじゃ十分ではないと、バージョン1.1でいく

TL;DR 技術に興味がなくても、エンジニアとして生きていくことはできる。 対象読者 自分を技術に興味がない側の人間だと思う方 筆者について Webアプリケーションの開発エンジニア。主な仕事はプログラム詳細設計、画面設計、コーディング。 技術にあまり興味がない。 初めに エンジニア界隈では、以下のような主張がしばしば見られる。 休日に勉強するべきである。 最新の技術動向は常にチェックするべきである。 技術イベントには参加するべきである。 毎日コードを書くべきである。 レガシーな技術ではなく、モダンな技術を習得するべきである。 etc... そしてこれらの"べき論"がさらに加速すると、 「技術に興味がない人はエンジニアに向いていない」 という主張すら出現し、それに同調する声も少なくない。 最近、とあるSNSで以下のようなやり取りを見かけた。 駆け出しエンジニアの質問 休日に勉強するべきですか

5月2日夜、しんと静まった川崎市役所庁舎。唯一明かりがともるサーバールームに、情報端末の操作キーをたたく乾いた音が響いていた。富士通子会社、富士通Japan（ジャパン、東京・港）のIT（情報技術）エンジニアたちだ。同日朝に同市のマイナンバーカードを使った証明書交付サービスで他人の戸籍謄本が交付された。個人情報流出の報告を受けた戸籍住民サービス課長の大貫久は、住民票や印鑑証明書などあらゆる証明書

会議、押印、官僚的儀式、なんとかコンサルタントになんとかエグゼクティヴ……私たちはなぜ「無意味な仕事」に苦しみ、「いい感じ」で働く自由を阻害されなければならないのか？　話題沸騰のデヴィッド・グレーバー『ブルシット・ジョブ　クソどうでもいい仕事の理論』（岩波書店）の訳者・酒井隆史氏による、日本人のための「ブルシット・ジョブ」入門。 クソどうでもいい仕事！ 「ブルシット・ジョブ」って、なんだろう？ おそらく初耳というひとが大半かもしれない。が、最近はそうでもないかもしれない。というのも、他でもない『ブルシット・ジョブ』の訳者のわたしも、ひとからこの話題を出されることがよくあるからだ。 少しずつ紹介されているからだろうが、それがたぶん、たくさんのひとの心の、多少なりとも琴線にふれなければ、それほど話題にもならないだろう。 それでは、まず「ブルシット・ジョブ」（以下、BSJ）とはなにか。筆者であり

（続きを書いたのでよろしければそちらも） 続・インボイス制度の問題の本質 - novtanの日常 セルフまとめで絶賛とかタイトルつけてるやつがいるのでイラッとして書いた。 togetter.com 個人的にはインボイスの制度自体は事務コストの問題とか（何とかするって答弁かなんかで言ってた気がするんだけど）本名開示問題とかそういう話があって可哀相だしなんとかしろよって思っている反面、制度自体がおかしいとは思わないので、そのあたりも含めて簡単に説明しておいたほうが良い気がした。専門家でもなんでも無いけど、とにかくさっくり免税事業者は益税だから悪みたいに結論づけるこのまとめにイラッとしたので。 まず言っておくと、免税事業者が益税云々という話は「必ずしも当たらない（役所並）」と思っているのでそういう立場だと思ってください。 さて、問題によくなるフリーランス事業者の免税問題についてはまず消費税がどこ

リンクアンドモチベーションでUXデザイナーをしている辻井です。所属している開発チームのとある会議が、想像以上にいろんな効果を生んでいた、というお話です。 どんな会議だったのかそれは週次のKPT会議でした。（Keep / Problem / Tryの観点で、成果・課題を棚卸しするミーティング） 会議は週に1回、1時間 全職種から全員が参加 Miroで、「今週やったこと」「来週やること」を書き出す 他メンバーの振り返りを見て、「感謝コメント」を記入する チームや開発に関するGood Newsを自由に記述する 感じている懸念があれば、それも自由に記述する というルールで実施していました。 この会議体、半年近く運用していて、大きな問題があったわけではありませんでした。ただ、期初のタイミングで会議体を見直し、「週次で1時間はややToo muchかもしれない。感謝・リスペクトを伝える会議体は月末に納会

ソフトウェア開発における品質のメトリクスについて、新旧2冊の本を比べてみました。 1冊は、『初めて学ぶソフトウェアメトリクス』。 原著『Five Core Metrics: The Intelligence Behind Successful Software Management』（Lawrence H. Putnam、Ware Myers著）は、2003年に出版されています*1。 初めて学ぶソフトウエアメトリクス~プロジェクト見積もりのためのデータの導き方 作者:ローレンス・H・パトナム,ウエア・マイヤーズ日経BPAmazon もう1冊は、『アジャイルメトリクス』。 原著『Agile Metrics in Action: How to measure and improve team performance』（Christopher W. H. Davis著）は、2015年に出版されて

開発スピードが遅いのか、作っているものの筋が悪いのか 前口上: rails statsで企業価値は測れるか？ rails stats はRailsリポジトリの統計情報が取れる便利コマンドです。LaravelでもLaravel Statsを使って php artisan stats で同様のことができます。 結構リポジトリの内情を丸裸にするコマンドで、モデルやコントローラーのサイズからアプリの規模感が掴めますし、コードとテストの割合からしっかりテストが書かれているかがわかります。 Webサービスの事業価値は大きく見れば売上や成長率、より細かく見ると業態やtoBかtoCか、どこの産業向けか、アクティブユーザー数などで決まります。一方でIPO以降の売上成長率は従業員数に比例しているという話もあり、ビジネススキームが決まってしまえば後は頭数に比例するとも言えそうです。 Four Keysなどの開発

この記事は ANDPAD Advent Calendar 2022 の 8日目の記事です。 リアーキテクティングチームの白土 (@kei_s) です。 最近は、ボーアとアインシュタインに量子を読む - 量子物理学の原理をめぐってという本がとても面白く、ちまちま読んでいます*1。 去る2022年10月21,22日に開催された Kaigi on Rails 2022 で、実践 Rails アソシエーションリファクタリングというタイトルで発表しました。今回の記事では、この発表の補足をしようと思います。 Kaigi on Rails に参加して 本題の前に Kaigi on Rails に参加した感想を書かせてください。 私個人として、対外的に技術コミュニティで発表を行うのがとても久しぶりでした。 オンラインのカンファレンスで発表するのも初めてで緊張しましたが、リハーサル含めて運営チームのサポート

はじめに 今回は外部キーを張るときに最低限意識したいことについて書きました。 何か間違えがあったり、もっとこういうところも意識してますという人がいたらコメントお願いします。 この記事で伝えたいこと ①リレーションシップ先のデータを消したときに同時にリレーションシップ元のデータが消えても自然な状態を作る ON DELETE CASCADEをうまく利用できる状態を作る つまり親子関係を正確に表現する。 リレーションシップ先は親テーブル、リレーションシップ元は子テーブルを意味しています。 ②データを作成するときのことを考えてデータの生成順序がおかしくならないように外部キーを張る ③関連を表現するときに中間テーブルを利用したほうが良い場面がある 注意 下記【例を交えながら説明】の説明に出てくるテーブル設計に関しては、上記の【この記事で伝えたいこと】の①と②と③の項目に対して想像しやすいように、理解

AIブームが過ぎ去ったいまが「本番」 現在、第四次産業革命が起こりつつあると言われています。その中でいちばん重要な技術がAIです。2016年からAIブームが起こり、コロナ前の2019年頃にはおよそ収束して、かわりに「DX（※1）」（デジタル・トランスフォーメーション）というロボットアニメめいたかっこいい（ちょっと恥ずかしい）キャッチコピーがビジネス界を席巻しています。 とはいえ、DXとは「AIを含めてデジタル技術をもっと活用していきましょう」という趣旨のコンセプトなので、名前がすりかわっただけでAI活用が重要だという点は変わりません。技術の導入は、むしろブームが過ぎ去ってからが本番なのです。 アメリカのガートナー社が毎年発表している「ハイプ・サイクル（※2）」というテクノロジーが登場した後の動きを視覚的に説明した図があります。図表1はそのイメージであり、実際には、「AI」だとか「5G」とい

ソシオテクニカルアーキテクチャとは 2021年は個人的にこの言葉をよく目にしたが、日本ではまだ多くの人にとってなじみがない新しい用語で、かつ英語圏でも正確な定義がない。概念として真新しいものではないため解釈によって齟齬を引き起こすのは容易に推察され、今のうちに定義を整理しておく。 ところで、ソシオテクニカル・システムというのは昔からある用語で、組織開発分野に専門性がある人は耳にしたことがあるかもしれない。組織開発において「業務遂行のために人間と技術が相互作用しなければならないシステム」を指す用語として使われる。現代社会において、テクノロジービジネスに携わる私たちは常にソシオテクニカルシステムの一部として生きていて、毎日このようなシステムにさらされていると言える。 ソシオテクニカルシステム ソシオテクニカルという言葉は、1951年に発表されたEric TristとKen Bamforthの研