これはいま、おれの中にひとつわりと明確な答えがあって、それは "スーパーセンタートライアルに向かう途中の田んぼ道"です おれの住んでる田舎は、市の人口5万人とかなんで、かなりザコいんだけど、24時間営業のスーパーセンタートライアルを抱えている そんで俺はそっからチャリで5分程度のとこに住んでいる そうすっと、夜10時からでも、思い立ったらチャリに乗って、でけえスーパーで買い物ができるわけですよ まずこれはひとつの文化資本と言って良い　スーパー　って博物館だからさあ！ そんで、そこまで行く途中の道、これもまたいいわけ 中規模の川が近くにあるから、いまの季節、サワガニが地面を這い回っているんですよ まず、玄関からチャリまで歩く過程で、スマホのライトに照らされて、聞き取れるくらいデカい足音を立ててカニが逃げる、おれはウオっと思ってちょっとのけぞる、こういう体験が、よくわかんねえけど、ひとつの原体

ソフトウェアアーキテクチャの基礎 ―エンジニアリングに基づく体系的アプローチ 作者:Mark Richards,Neal FordオライリージャパンAmazon とても良い本だ！アーキテクチャのパターンは体系的に整理されているし、アーキテクチャを議論する上で、共通の語彙となり得る用語を解説している（コンウェイの法則や、凝集度など）。 後半は、リスクや、チームビルディング、交渉術まで多岐に渡るトピックを網羅している。 必要なことは全部書いてある...けれど、なんとなく初めてPMBOKを読んだときに抱いた感想...読み始めてからすぐに「果たしてこの本に書かれている通りの考え方に沿って振る舞えばアーキテクトになれるのか？」という気持ちになりはじめたところで1章の最後の方に出てくる「ソフトウェアアーキテクチャの法則」が出てきて、「そうだよなー」という気持ちに。 ソフトウェアアーキテクチャはトレード

個人でもチームでも「ふりかえり」をすることは一般的だと思う。今回はその中で個人的に気をつけていることをまとめた。 なぜふりかえりをやるのか まずはなぜふりかえりをやるのかについて書く。いろいろな意見はあると思うが、個人的にはふりかえりは以下の点で有用だと思っている。 改善のため まずは単純に日毎、スプリント毎に改善していくためである モチベーションをあげるため 自分のやってきたことを見て充足感、達成感を得ることもあるだろう メタ認知のため 他の項目と直交ではないが、そもそも日々すごしている中で自然とメタ認知するのはなかなか難しい。よって明示的に時間をとる必要がある どうやるのか ふりかえりは以下のようにして行うことが多い。 できごと(エピソード)をフラットに書き出す ここでは特によかった、悪かったなど評価をせずに列挙する 心に残ったことを全て書き出す よかったこと、悪かったこと、気になるこ

メルカリでは「無意識（アンコンシャス）バイアスワークショップ」を実施しています。これは「無意識バイアス」（無意識の偏見）について理解し、そしてそれを日常で意識する習慣をつくることでD&I（ダイバーシティ＆インクルージョン）を推進することが目的です。2021年2月、社内のみならず日本社会全体でのD&I推進にも貢献すべく、研修資料用スライドを一般公開しました。ワークショップを開催する際に合わせて公開しているファシリテーターガイド（進行ガイド）もご利用ください： https://storage.googleapis.com/prd-about-asset-2020/2021/02/c19a9ab4--1.pdf

https://ginzarb.github.io/kaigi01/

色々と思うことがあったので乱文を書いていく 便利リンク集 前回の記事 purintai.hateblo.jp 面談に応じてくれた企業紹介（鋭意執筆中・ベストエフォート） note.mu 数字的なもの お声がけ頂いた企業数: 120 ( Twitter / 知人紹介 / 転職エージェント経由 ) アポが組めた企業数: 82 面談済企業数: 76 節操なく全ての企業と面談している理由 自分自身の持っている先入観に負けないため。先入観でフィルターした場合だと会っていなかったが、それでも会ってみて実際に良いと思えた企業があった。 どれくらいの企業規模を狙っているの？ ターゲットは定めておらず、大企業でもベンチャーでも老舗でも創業直後でもよい。それよりも問題になるのは事業内容、構造、マーケット、チームメンバーの質や経営方針によることが多い。 これが最後の転職ならド安定しそうな大正義大企業の正社員狙っ

アイザック・ニュートン卿は、自分が賢い 人間だと信じていた。微分積分学や重力理論 を発明(inventing)したのだから、金融投資(investing) ができるくらい賢いはずだよね？まぁとにかく、短く まとめると、1720年 に起こった南海泡沫事件という全世界 的な投機ブームで、彼は(現在の価値で)$4,600,000を失ったんだ。 後にニュートンはこう言った。 “私は天体の動きを計算することはできるが、 人々の狂気については計算できない” 彼のために勉強しよう これまで市場、制度、民主制全体は 何度もおかしくなってきた。— 群衆の狂気だ でも君が人間に失望していたときですら、 ハリケーンが起きれば、みんなで協力してきたし、 コミュニティは問題を解決してきた。人々はよりよい 世界のために戦ってきた。— 群衆の英知だ！ しかしなぜ 群衆は狂気に向かったり 賢くなったり するのだろうか。

「コードを憎んで人を憎まず」 コードレビュー時のレビュアー（レビューする側）の考え方（レビュー時に人格攻撃にならない、感じられないように気をつけるなど）として、良く使われる言葉です。 一方で、レビュイー（レビューを受ける側）はどのように考えればよいでしょうか。 マシンやプログラムからエラーメッセージが出ることを「怒られる」と言ったりします。 実際には、マシンやプログラムはエラーを伝えているだけで「怒っている」わけではありません。 しかし、マシンが出すエラーメッセージは無機質なので怒られているように感じることから「怒られた」と言うようになったのでしょう。 このように同じエラーメッセージでも、人の捉え方によって（エラーを）親切に伝えてくれているのか、怒っているのかが変わってきます。 怒られてる・責められてると感じた場合の人の反応 Slackやチケットなど文字のコミュニケーションも無機質になりが

Bootstrap Night! vol.2 でお話させていただきました https://selfree.connpass.com/event/71944/

こう言うと当り前だが、同じ内容でも、人や場面によって伝え方は変える必要がある、という話をする。 例えどんなに正しいことでも、指摘するときは細心の注意を払わないと、結局、指摘された側は指摘されたことで逆にムキになったり、単に落ち込んだりして改善に繋がらないことが多い。 — Kota Yoshitsugu (@_yoshitsugu) 2017年9月14日 相手によって伝え方を変化させる 例えば、天邪鬼のA君がいたとする。A君は天邪鬼なので、何かをするように言うと、言ったことと必ず反対のことを実行する。ある時、A君が友達のB君に乱暴しているのを見かけた。やめてほしいときに何と伝えるだろうか。 例えば、「もっと乱暴してほしい」などと言うことでA君は乱暴をやめてくれるだろう。ここで脊髄反射的に「乱暴しないでください」と伝えてしまうとA君の乱暴はさらに加速してしまう。 単純化するとこういう話なのだが

心理的安全性ということばはだいぶ浸透してきて、とくに説明なくみんなに通じるような感じになってきているけれど、まあなかなかに難しいものだなあと思う。 組織やチームのまとめ役となる側からすると、心理的安全性が確保できるチームをどのように作っていくか、という点に注目があつまりがちなんだけど、個々人が心理的安全性を獲得するときにも、それぞれの性格によって難易度に差があるよね、ということについて書きたい。言葉を変えると、多くのひとが問題なく心理的安全性を獲得できるような状況やチームであっても、自己肯定感を適切に持つことが難しいようなタイプのひとは、なかなか心理的安全性を獲得できないという問題（問題、というと語弊があるかもしれないけど、problemというよりもissueという意味での問題）があるんじゃないか、というような話だ。 自分にそういうところがあるからこの話をするのだけれど、わたしは「他人が自

抽象的なことをつらつらと書く。 「目標: 現状維持」は現状維持できるか 私達は日々変化していく時間の中に生きている。 何もしなくても体は老化していく。どんなに頑張っても今のところ110年だか115年だかの寿命の限界がある。もし不死の肉体を手に入れたとしても、50億年後には太陽の寿命も尽きてしまう。 ミクロ的な視点で見るとあまり変化していないように見えても、あらゆるものが確実に変化している。 そんな中で目標を「現状維持」とすることは「何もしない」ことを意味しない。何もしないと様々な内的、外的環境の変化により陳腐化する。 受動的な決断 私達は「何もしなければ何もおこらないだろう」と考えてしまいがちだ。 何かを変えるという決断にはエネルギーが要るため、受動的な姿勢で「何もしない」ことを選択してしまう。しかし、現実には何もしなくても勝手に変化は訪れる。受動的な姿勢＝安全ではあり得ない。 「知らなか

『エリック・エヴァンスのドメイン駆動設計』（以下DDD本と呼ぶ）の原著出版から十数年が経過した今、DDD本に書かれている内容は、吟味されアップデートされるべき時が来ている。このアップデートに盛り込みたい内容を、4つの原則という形で考えてみた。 なお、以下では「EvansのDDD本の内容」と「ドメイン駆動設計というコンセプト」は重なる部分があるにせよ、それぞれが指す対象は異なるものだとしている。この違いは本文中で触れるが、表記として「DDD本」は本を指し、「ドメイン駆動設計」はコンセプトの方を指すようにしている。 DDD本とドメイン駆動設計 DDD本では、ドメイン駆動設計というコンセプトが導入された。ドメイン駆動設計というコンセプトは、ソフトウェアエンジニアの一般教養といえるほど、今ではその価値が認められている。同様のアイデアは、EvansがDDD本を執筆した時代ですら、すでに先人たちが口に

ソフトウェア開発者の勉強会などに参加すると、最初に持ち時間一人30秒くらいの全員自己紹介タイムがあったりする。「好きなプログラミング言語は？」だとか「使っているフレームワークは？」など、勉強会の参加者層に対して比較的通じやすいお題が都度用意されたりもする。 そんな自己紹介のお題として「あなたのソフトウェアシステムに対する世界観は？」なんて出される勉強会があったら面白い、と思うのは少数派だろうか。 私の尊敬するエンジニアの先輩方は、必ずと言ってよいほど溢れんばかりの世界観をお持ちだ。システム観、モデル観、設計観、設計者観。そう呼べる何かが話す言葉の端々から滲み出ていて、興味をそそられずにはいられない。 しかし果たして、私自身はどんな世界観でもってソフトウェアシステムを眺めているのだろうか。自己紹介でネタにできるほどの世界観を持ち合わせてはいないのかもしれない。自分の世界観を客観的に考えるため

インタビューや観察の結果を整理する方法として「親和図法（affinity diagram）」がよく用いられます。また、そこからチームでアイデアを出す方法として「ブレインストーミング（brainstorming）」が用いられます（そこから再び親和図法に戻ることもありますね）。いずれも有名な手法なので詳細は省きますが、付箋紙をホワイトボードにペタペタ貼りながら、みんなでワイワイやるようなイメージです。 https://www.flickr.com/photos/jakecaptive/49915119よく用いられるからには、きっとそれなりの理由があるのでしょう。ですが、私はいずれに対しても（めちゃくちゃ）懐疑的です。使っていないわけではないのですが、使ってもいまいち感が残るというか、まるでうまくできる感じがしないのです。こんなのでいいアイデアなんか思いつくはずがない。それこそ「机上の空論」みた

Cookpad TechConf 2017 発表資料

検索事業部の須藤です。 クックパッドの検索周りのサービス開発を担当しています。 はじめに 最近ではプロトタイピングツールも充実し、コードを書かなくとも動的なモックアップが作れるようになるなど、思いついたアイデアをより早く、より最終的なアウトプットに近い形でメンバーに共有することができるようになったと感じています。 また、実際にコードを書いてユーザーに公開するための効率的な手法や、公開後の検証方法についても様々なツールや知見が共有されており、より精度の高い定量評価ができるようにもなってきたかと思います。 一方、これらの効率化が進んでも、実際に打った施策の数を増やせたか、最終的にサービスインできたプロダクトの数が増えたかというと、そこまで実感がありません。 その理由のひとつは、思いついたアイデアを具体化して作り始めるまでの初期段階と、実際にそのプロダクトを（テスト目的であっても）公開に耐えうる

転職して数ヶ月が経ち、今回は自分の研修に関して書いておきます”(\( ⁰⊖⁰)/)” ※このエントリは完全に謙遜でない、凡人のための研修を紹介するものです 転職前のスキル ◯前職でHTML・CSS Java・MySQL・Perl・PHPは触ったことは。保守作業で必要なことは。程度。 後はマネジメント方面でした ◯Rubyコミュニティで 基本のGit操作、 仮想環境構築なんとかできる、 RailsのCRUDの理解、gemの使い方など 特筆するスキルありません 凡人初心者は本当に進まない 最近「〜はプログラミングじゃない」とバズった方も他のエントリで書いておりました(リンク貼ろうとしたらページにアクセスできない・・あぁいうことに２ヶ月で気づくのは良いことなので気にせずブログ再開したら良いと思います)が、初心者はコード書くまでが本当に長いです。 セミコロンの付け忘れ、Gitのミスで数時間とかそん

高校生までは、留年（原級留置）は、全日制の普通科の高校であれば、たいていの学校においては１パーセントにも満たない少数の生徒のことであろうかと思います。 けれども、大学ではそうではありません。文部科学省の学校基本調査によれば、４年制学部を４年で卒業するのは、入学者のおおよそ８割弱です。超過して在籍せずに４年で退学したり、それ以前の学年ですでに退学している学生もいますので、残りの約２割のすべてが５年目に突入するわけではないのですが、それでも高校の場合と比べれば桁違いに多くの学生が既定の年限を超えて在籍します。留年も含めてとにかく卒業までこぎ着ける人は、入学者のおおよそ９割です。 京都大学においても事情はほぼ同じです。ただし学部により留年の発生率はかなり違っており、入学定員の３割台に上る学部もあれば、１割台に留まる学部もあります。けれども、大学全体ではおおよそ２割の学生が留年しています。 これだ

毎週金曜の定時後に弊社でアーキ部なるものが開催されています(✌'ω' ✌) 9/16のアーキ部は「自分のエンジニアスキルを客観的にどうやって知るか」がテーマでした！ （アーキテクチャの話ではない？！！） 自分のエンジニアスキルの評価として陥りやすい考え方のお話があり、それに対して少人数のグループに分かれて自分はどちらに分類されるかを話あいをしました。 （この会はとりあえず意見を発散する場でした。次回は、今回の話し合いに対しての深堀りなのかな？？） 評価の分類 自己評価は（バランスがとれている人もいるとは思いますが）過大評価をしているか、過小評価をしているかに分かれると思います。 アーキ部の最初に、自己評価の考え方として陥りやすい傾向が二つ紹介されました。 詐欺師症候群 ダニング＝クルーガー効果 詐欺師症候群 参考にしたサイトから説明を抜粋しています！ 詐欺師症候群とは、自己評価が低く、自分