人に興味、ありますか？👀 改めて問われると、そもそも「人に興味がある」という状態すらイメージが曖昧で、何を指しているのかもよくわからなかったりしますよね。 また「人の噂話が好きな人」といった、ややネガティブなニュアンスに捉えられるケースもあるかもしれません。 それはそれで「興味がある」とも言えそうですが、個人的には興味の矛先が少し違うような気がしています。 （自分の保身に興味があるか、他者の価値に興味があるか…） なので、今回は「人に興味がある」という言葉を「目の前の相手の話に価値を感じる（耳を傾けたくなる）」という状態と定義して話を進めます。 「人に興味がある」と話すと「そっかぁ。私は全然わからない」と言われることがよくあります。 実際、人に興味がない人はそれほど珍しくはありませんし、かつての私もその1人だったと思います。 それでも、やはり人への興味はあるに越したことはないと思うのです

東京・乃木坂から、「真面目に楽しく」をキーワードにした教育でビジネスパーソンを支援する株式会社ヒップスターゲートの主催イベントに、組織マネジメントの専門家で『遊ばせる技術 チームの成果をワンランク上げる仕組み』 の著者である神谷俊氏が登壇。「社員の自律を促す『新・マネジメント術』とは？」をテーマに、子どもから学べる自律レベルを高めるヒントや、刺激も挑戦も「ちょうどいい」がポイントになることなどを語りました。 子どもに学ぶ、自律レベルを高めるヒント 神谷俊氏（以下、神谷）：では、どうやって自律レベルを高めていけばいいのか。セルフマネジメントからセルフリーダーシップに展開していけばいいのか。 ポイントは「遊び」です。先ほど高い自律レベルは遊んでいる状態に近いという話をしました。子どもたちが遊んでいる様子を見ると、自律レベルを高めるヒントが見えてきます。 例えば赤ちゃん。ハイハイしている赤ちゃん

こんにちは、コインチェックCTO室の大村です。 突然ですが、私はコインチェックに転職して一番びっくりしたことは、認知負荷という難解なワードが、極めてカジュアルに利用されていることでした。 言葉のニュアンスは理解できるのですが、「〜〜は認知負荷を高めるのでやめよう」とか「〜〜の認知負荷を軽減しよう」という会話が日常的にに交わされているのは、かなりカルチャーショックでした。 私は監査系の大企業から転職してきたので、何をするにも重厚長大な承認プロセスを通さねばならず、部門間最適という概念など存在しないことが半ば当たり前だと思って働いてきました。 認知負荷を抑えた組織設計にするべきだという、エンジニアリング組織としてのあるべき姿を常に考えながら行動できるメンバーが多いところは、コインチェックの魅力の1つですね。 1. エンジニアリング組織論におけるチームファースト1-1. Team-First t

前提 この記事は内製開発をしているSaaSの中の人であるエンジニアが、SaaSの内製ソフトウェア開発をする上での話として書いています。 前ふり 「スクラムで生産性は上がらないしリリーススケジュールが狂いまくりなんですよ」 「何が原因なんですか？どうすればいいんですか？」 という相談を受けました。 NDAを書いてから、どれどれとチームの状況を見てみました。 該当チームのスプリントゴール 該当チームのスプリントゴールはこんな感じでした。 QAフェーズのプロジェクトAを、QA作業を完了してリリースできる状態まで進める 実装フェーズのプロジェクトBを、フィーチャーの実装率を50%まで進める 設計フェーズのプロジェクトCを、要確認な点を除いて実装レディーな状態まで進める スプリントゴールが3つありますね。とても面白いですね。 思わずボンドルド卿みたいな反応をしたくなりますがここは先に進みましょう。

Webの用語を100秒で解説するチャンネルを作りました！ よかったらチェックしてみてください！ はじめに 以前書いた記事「Webページがブラウザに表示されるまでに何が起こるのか？」で ブラウザレンダリングについて詳細に知りたいという意見をいただいたので、調べてまとめてみました。 全体図 レンダリングの大まかな流れです。 HTMLのダウンロード サーバから送られてきたHTMLをダウンロードします。 HTMLの解析 サーバから送られてきたHTMLファイルは、「0」と「1」でできたデータになっています。 ブラウザは、サーバから受け取ったデータをそのままHTMLとして解釈することはできないので、自分で扱うことができる形、つまりDOMに変換する必要があります。この作業を 解析 ( Parse ) と言います。 HTMLをダウンロードしたら、すぐにこの解析作業に入ります。作業は以下のようなステップにな

ドメイン駆動設計をわかりやすく - ドメインのモデル設計を手を動かしながら学ぼう ドメイン駆動設計（DDD）が近年関心を集めていますが、同時にこの設計思想は難しい、わかりにくい、という見方もあります。さまざまなプロジェクトでドメイン駆動設計を実践してきたかとじゅんさんが、サンプル課題をもとに、ユースケース分析、モデル設計といった基礎を解説します。 はじめまして、Chatworkでテックリードをしている、かとじゅん（ @j5ik2o ）です。 僕は2010年ころより、大小さまざまなプロジェクトでドメイン駆動設計、いわゆるDDD（Domain Driven Design）を導入した開発を実践してきました。ドメイン駆動設計を主題としたワークショップなども主宰していますが、最近では加速度的にこの設計思想への関心が高まっていると感じます。本稿では、なにかと分かりにくいドメイン駆動設計の基本を、架空の

Eberhard Wolffさんのこのプレゼンの要約です https://www.youtube.com/watch?v=B3O-qYM-Kkw 共通のデータモデル 共通のデータモデルを通信に使う 各サービスで必要となるデータの内部モデルは異なるかもしれない データモデルが、共通ライブラリと同じ意味合いになる すべてのサービスが、最新のライブラリを使わなくてはならない 共通データモデルの変更は、す

アプリケーション開発で、「ビジネスロジックは分離しろ」だとか「Controller にビジネスロジックを書くな」といったことをよく言われると思います。 しかし、ビジネスロジックという言葉の意味を聞いたり調べたりしてみても、「システムのコアの部分」とか「システムの目的になる処理をするところ」みたいなことを言われたりして、よく分かりませんでした。 そんな中、クリーンアーキテクチャや DDD の戦術的設計について学ぶことで、「ビジネスロジックとは何か」、「ビジネスロジックはどう実装するか」について、自分なりの考えが整理されてきたので、この記事ではそれをまとめます。 ※ 曖昧な言葉を自分としてどう使っているかという話になります。違う意味で使う方もいると思うので、ご注意ください ビジネスロジックとは何か 「システムのコアの部分」とか「システムの目的になる処理をするところ」といった説明も正しいとは思い

もうちょっと規約的なものを「JavaでのUT作成基準を整理してみた」にもまとめてみました。 はじめに 去年、ブログの方に「ふつうのユニットテストのための７つのルール」という記事を書いたのですが、思ったより反響がありました。 あの記事で書いたのはあくまで原理・原則で、それを実現するためにはいくつかのテクニックが必要です。 特に、ああいうルールを作って「ユニットテストを書く事」を厳守するようにしても、 適切なテクニックを知らなければメンテが困難だったり、品質に寄与しなかったり、実行性能が悪いゴミが量産される可能性があります。 じゃあ、どうすれば良いかというと「最初からユニットテストが書きやすいように元のコードを設計する」ということです。 そう。まず身に付けるべきは「テストコードの書き方」では無く「テスト対象コード」すなわち「プロダクトコードの書き方」なのです。 また、ここで言ってる「最初から」

はじめに こんにちは、webエンジニアの@an_sonyです。 最近、障害対応の振り返りをしていた時に「ポストモーテム」という手法を初めて知りました。これまで「どうやったら良い振り返りができるのか？」と悩んでいた自分にとって目から鱗の知識ばかりでしたので、整理のためにまとめてみます。 ポストモーテムとは？ SRE サイトリライアビリティエンジニアリング1によると、インシデントとそのインパクト、その緩和や解消のために行われたアクション、根本原因（群）、インシデントの再発を避けるためのフォローアップのアクションを記録するために書かれるドキュメントを指します。 言い換えると、失敗（障害）から学び、再発防止策を決める活動です。 障害報告書との違い 障害報告書と内容が似ていますが、ポストモーテムは読者と目的が違います。 障害報告書は、障害発生によって不利益が生じたユーザーに対して、その説明をするため

CyberZ CTO室のメンバーの森 (@at_sushi_at) です。 先日、株式会社サイバーエージェントの2021年度 エンジニア新卒研修でコードの品質に関する講義を行いました。 そこで話した内容とスライドを完全公開します。 45分の内容のため、かなり長いですが、個人的にぜひ一読して欲しい内容になっています。 はじめに こんにちは、森 篤史と言います。2019年度入社で今年で3年目になります。株式会社CyberZのOPENREC.tvというプロダクトでAndroidアプリチームのリーダをやっています。 最近はプログラムを書く仕事以外に、次世代マネジメント室という全社横断組織でDevelopers Blogの改善プロジェクトを実行したり、CyberZ CTO室で組織活性化に取り組んでいます。 あと、2019年度の未踏スーパークリエータにも認定されました。 メインの仕事としては、入社して

Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

西澤です。クラスメソッドに入社してからおよそ5年間クラウドの推進やAWS技術に関する支援をさせていただいております。この経験を何か形にしたいと思い、少し遅れてしまったのですが、Developers.IOイベントに乗じてまとめさせていただきました。 発表資料 資料はこちらにアップロードしております。 夜間に録音したので覇気が無い感じになってしまいましたが、動画はこちらです。 まとめ 「AWS設計でやりがちな失敗パターン」というタイトルで考え始めたのですが、もっともお伝えしたい点は、AWSを利用されるお客さまのマインドセットを変え、クラウドを活用できる組織に変わって欲しい、というところに集約できるかなと思います。技術的な問題以上に、考え方を変えられないこと、組織を変えられないことが、クラウド活用を阻害するアンチパターンになっていると思いました。 どこかの誰かのお役に経てば嬉しいです。

AmazonのクラウドサービスであるAWSは、コンピューティングやデータベース、ストレージなど、膨大で複雑なサービスで構成されています。こうした豊富なサービス群をうまく組み合わせて利用する「ビルディングブロック」がAWSのメリットでもありますが、サービス数が多すぎてなかなか全体像を把握できないのも事実。フリーランスのエンジニアでありコンサルタントでもあるジョシュア・テイセン氏が自身のブログで、AWSのすべてのサービスを「たった1行」で説明しています。 Amazon Web Services https://adayinthelifeof.nl/2020/05/20/aws.html テイセン氏によると、Amazon Dashboardから利用可能なAWSのサービスは記事作成時点で163あるとのこと。そのすべてを正確に理解する必要はありませんが、基本を押さえておくことはいいことであり、問題の

現在私は、世界規模のクラウドの中の人になって一か月が経過しました。グローバルで、クラウドプラットフォーム自体を作って運用する側はどんなスタイルで開発されているのか興味がある人もあるかもしれないと思ってブログを書くことにしました。これは自分のチームや周りのチームを観察しただけであって、私の所属会社全体がそういうスタイルではないかもしれませんが、何らかの参考になるかもと思い書いてみました。 スモールチーム 世界規模のグローバルなシステムなので、ものすごい大人数で、ものすごく厳密に開発されているイメージがあるかもしれませんが、実際のところ小さなチームの集まりです。自分がアジャイルコーチだったころに学んだことですが、開発は２５人ぐらいのチームがマックスで、Amazon でも two pizza team といわれているように、ソフトウェア開発は少人数でないとまわらないのでそうなっているようです。沢

新型コロナウイルスの感染拡大で、私たちの生活、国や企業のかたちは大きく変わろうとしている。これは同時に、これまで放置されてきた東京への一極集中、政治の不透明な意思決定、行政のペーパレス化や学校教育のIT活用の遅れなど、日本社会の様々な課題を浮き彫りにした。 連載企画「Withコロナで変わる国のかたちと新しい日常」の第11回は、コロナの時代を歴史からどう紐解くかだ。立命館アジア太平洋大学（以下APU）の出口治明学長が、Withからアフターコロナの日本と世界を語る。 人間はウイルスをコントロールできない APU出口治明学長 この記事の画像（6枚） ――今回我々はコロナという未知のウイルスと遭遇したのですが、Withコロナという時代をどうご覧になっていますか？ 出口氏： コロナは自然現象です。ウイルスは数十億年地球に住んでいて、我々ホモサピエンスはほんの20万年しか住んでいないので、彼らの方が大

Regional Scrum Gathering Tokyo 2020 https://2020.scrumgatheringtokyo.org/ RSGT初参加＆スクラムビギナーのメモと感想です。 1. Keynote "The Ten Bulls of the Scrum Patterns" by James Coplien メモ：度肝を抜いた登場, 老子→クリストファー・アレグザンダー（都市,建築のパターン）→ ジェフ・サザーランド（Scrum）, Scrumのパターン, 理由を押さえているか, Scrum探求の道筋を禅宗の「十牛図」になぞらえて悟りの道を進むように話は進む, 「無名の質」, 「チームにワクワクしているか？」, 「反省なくして改善なし」, 「Scrumの存在理由は組織を美しくすること」, 「スクラムは門（ゲート）である」,「真の自分を探す門」, 「無名の質」, 本来の

2. 原田 騎郎 Kiro  HARADA アジャイルコーチ ドメインモデラー SCMコンサルタント Twitter:  @haradakiro 認定スクラムプロフェッショナル 認定スクラムマスター 認定スクラムプロダクトオーナー 株式会社アトラクタ 　代表取締役

建物は変化する。刻々と成長し、みずから学んでいくものである。単なる空間的な構造物ではなく、時間というパラメータを考慮に入れ、この世界に生まれ、様々な成長を遂げ、やがては死に至る、一種の「有機的存在」としてとらえなおす必要があるのではないか。 スチュアート・ブランド※1 は、著書『How Buildings Learn』で、時の流れとともに建物に何が起こるのかを探究しました。そのなかでブランドが提示した「ペースレイヤリング（Pace Layering）」の概念は、建築の世界にとどまらず、情報やメディアに関わる分野でも多くの注目を集めてきました。 この本が世に出てから20年後の今、その思想の意味をあらためて考えたいと思います。 スチュアート・ブランドの基本モデル ペースレイヤリングの基本となったのは、この本で示された以下のモデルです。 ［図1］ “Shearing Layers of Chan