uzullaさん主催の「みんなで作るテックカンファレンス」のya8に参加してきました。 わたしはアンカンファレンススペース担当として、二日間アンカンファレンススペースの切り盛りをさせていただきました。アンカンファレンスのキモは「一方通行ではなくて参加者みんなで議論する」だと思っているのですが、実際二日間においてほとんどずっと活発な議論が行われていて、参加して発言してくださったみなさんに大変感謝しています。しかも、「いつメン」の同窓会ではなく、いろんな方が発言してくださっていて、ほんとうにいいアンカンファレンスになったなと思っています。 議論の内容については余裕ができたら改めてまとめるかもしれません。 さて、実は私は、約5年ぶりくらいのカンファレンス参加でした。長い間カンファレンスに出席していなかったのには実は理由があります。詳しい理由は控えるのですが、ひとことで言うと、以前「自分とテックコ

組織やチームはそれぞれルールや文化、仕組みを持っている。この仕組みやルール、文化はときに外部から見ると「アンチパターン」に陥っているようなこともある。そのとき、「アンチパターンを抜け出してベストプラクティスを」と言うのは簡単だけど、実際にそこから抜け出すのは「言う」のと比べるととても大変なことだ。なぜなら、多くの仕組みやルールは複雑かつ有機的に絡まり合って現在の「仕事のフロー」を形成しているからだ。自分の職能の範囲だけで改善しようと思っても、仕事は自分の職能の範囲では完結せず、「他の職能のやり方がこうだからベストプラクティスは採用できない」となってしまいがちだ。こういう「変えるのが大変」という状況をぼくは「チームの慣性力が働きすぎている状態」と呼んでいる。 では、この慣性力に負けないためにはどうすればいいのだろうか。ぼくは心構えとしては以下のようなことを考えている。 文化や仕組みを変えるの

資本主義下における労働は資本主義下における労働であるので、利益を追求する必要がある。わたしは、ソフトウェアあるいはインターネットサービスで労働を行なっているので、これからソフトウェアあるいはインターネットサービスの労働の話をする。さて、ソフトウェアあるいはインターネットサービスで労働をする場合、「組織として利益を追求する」という動きにとってボトルネックになっている部分（部署というよりは、仕事におけるいわゆる「バリューストリーム」の構造だったりいち部分だったりを指す）以外をいくら改善したところで、利益には繋がらない。 わかりやすい話として、たとえばビジネスモデルがわやであれば、いくらエンジニアリングやデザインがシャキッとしていたところでそれは売り上げにはつながらない。まあ、エンジニアリングがシャキッとしているとコストの削減にはつながるのはそうだし、自分が直したコードやインフラ構成によってコス

「顧客中心主義」という言葉を振りかざすひとは胡散臭く感じてしまうが、一方で重要な考え方であるとも思うアンビバレントがある 労働についての話。 労働をしていると、「どうしてうちの組織はこうなってないんだ」とイライラすることはだれにでもあると思う。というか、そういうイライラを失ってしまったとしたらそれはもう理想を失っているということで、改善の機会を失っている。理想と現実の間のままならなさにイライラしながらも顧客（その顧客は社内の別の部署かもしれないが、それが最終的にエンドユーザーに届くロジックは強固にたてついていないといけない）に対してなんらかの価値を提供して対価を得るのが労働だとさえ思う。 ところで、この理想を実現するためにはどうしたらいいのだろうか。理想を知ること、理想の状態を想像することは簡単だけど、このままならない現実を理想に近づけるためになにかを変えるというのはすごく大変だ。このギャ

2023年度を迎え、所属するバンドも新しい音源の制作としてレコーディングを開始しました。わたしの所属するバンドは、2度ほどいわゆる「エンジニア付きレコーディングスタジオ」でレコーディングをしたのですが、そのあとの音源制作は、基本的に私がエンジニアをしてDIYレコーディングを行っています。わたしがバンドでDIYレコーディングを始めたときは、まだ音楽のお仕事でお金をもらい始める前のできごとなので、まごうことなき「アマチュアによるDIYレコーディング」です（でした）。 さて、ところで、エンジニアさん付きのレコーディングプランの価格を調べてみたことがありますか？　調べるとみなさんびっくりされると思います。たとえばスタジオノアのレコーディングプランでは、スタジオ代に追加で ￥24,200- 支払えば、きちんとしたエンジニアさんが6時間もレコーディングを行ってくれます。高い？　いえいえ、サウンドエンジ

よく、プロジェクトマネジメントにおいて、「品質、コスト、スケジュール、スコープ」はそれぞれトレードオフにあり、すべてを固定することはできないと言われる。ここにt_wadaさんの「質とスピード」の話を合流させると、品質はスケジュールとトレードオフではなくてむしろスケジュールに対する説明変数である、と見ることができる。結果、これは「コスト、スケジュール、スコープ」のトリレンマと理解することができるし、アジャイルな開発においては「スコープを調整していく」ということがよく行われる。 ここでいう「スコープ調整」については以前書いた。 アジャイルなプロジェクトマネジメントにおける「スコープ調整」でやるべきこと、やるべきではないこと - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く それに対して以下のようなレスポンンスをいただいた。 いろいろなスコープ調整 - 半空洞男女関係 上記の「スコープとスケ

組織やチームにおいて、合意は非常に重要だと思う。そもそもなんらかの合意が存在しないチームや組織はそれはもはや組織やチームではなく、バラバラな個人の集まりとなる。 一方、合意はとても高コストだ。全ての行動に合意が必要となる場合は、動きはとても遅く、目的を達成するためのコストは跳ね上がる。なにをするにしても「根回し」と「合意」をとらなければならなくてとにかく仕事が進まない、というのはよく聞く嘆きではないだろうか。合意は重要だが、一方でハイコストなので、合意を取る必要のないものについては合意なしで済ませることも重要となる。 合意は非常に重要だが、ハイコストである。このジレンマに対しては、「合意を取るべきものはなにか」「何ならば合意を取らずに進めていいのか」の合意、いわば合意に関するメタ合意とでも呼ぶべき合意が重要になると考えることができると思う。メタ合意さえあれば、本当に合意を取るべき（と合意が

謙虚と卑屈の違いについて考えていたら、思い当たったことがある。それは、卑屈は目線が自分だけに向いていて、謙虚は目線が他人とのコラボレーションに向いているのではないか、ということだ。 例えば、自分の作った曲が100万再生されたミュージシャンがいたとして、そのミュージシャンが「100万再生すごいですね」と言われた時の反応を例にとってみる。 それに対して、「いや、私なんてすごくないですよ、歌のピッチだって揺れているし、歌詞だって恥ずかしいものだし」と応えるミュージシャンと、「とても嬉しいですが、自分の力なんて微々たるものです。応援してくれたファンの方々がたくさん感想を拡散してくれたことも大きいですし、形にしてくれたレコーディング・エンジニアの方の力も大きいですし」と応えるミュージシャンを考えてみると、前者は卑屈に、後者は謙虚に見えるのではないだろうか。これは、前者はとことん「自分のダメなところ」

今日は掲題のような文章について。 世の中には「すでにわかっているひとにはよくわかるしとてもわかりやすいんだけど、わかってないひとにとってはなんのこっちゃかわからん」みたいなタイプの文章が存在すると思う。 たとえばソフトウェア開発の文脈で言うと、基本情報技術者試験の勉強の際に読むようなやつを想像してみてほしい。ぼくは基本情報技術者試験って結構役に立つよなあって思っている側の人間で、ある程度ソフトウェア開発の経験を積んだひとからもけっこう「内容はいいよね」っていう言葉は聞くと思う。で、この「内容はいいよね」ってところが結構ポイントだと思っていて、実際にソフトウェア開発の経験をある程度積んで、暗黙知や経験知がある程度溜まった状態、つまり「わかっている」状態であれらを読むと「わかるわかる」となるが、一方でそういう暗黙知や経験知がない状態で基本情報技術者試験に合格しても結構「とりあえず暗記したけどこ

いろんなところで主張してきたことの繰り返しになりますが、ソフトウェアの設計とは、「解きたい問題に対して適切な構造を与えること」だとわたしは考えています。 「解きたい問題に対して適切な構造を与えること」という以上、「解きたい問題」が変われば「適切な構造」も変化する、ということが言えるはずです。これは「まず問題を適切に捉えること」の重要性を示していると言えると思っています。しかし、そのことと同等に問題とされるべきは、「適切な構造は何によって構成されるか」であるとも思います。 わたしは、ソフトウェアの「適切な構造」を構成する二大要素は「関心の分割点」と「分割点によって分割された要素同士の依存関係」だと思っています。 つまり、ソフトウェア設計とは、「まず解きたい問題を理解し、その問題に応じて、適切な関心の分割点を見出し、見出された関心の分割点で分割された各要素に対して最も適切な依存関係を設定するこ

エンジニアの集まるカンファレンス（参加者の多くはソフトウェア・エンジニアだが、ものづくりするひとすべてを対象としたカンファレンスなので、暫定的に「エンジニア」という括りで話します）において、マッチングアプリ上で女性の外見を判別して自動でいいねを押すという発表がなされている現場に居合わせた。このエントリの目的は特定の発表自体の是非を判断することではないので、リンクしない。「リンクしなければそもそもその発表の是非の判断ができないじゃないか」という向きもあると思うけれど、少し調べればわかることだし、その発表自体の是非を議論したいなら、調べるくらいのコストをかけて別のところでやってくれたら嬉しいと思っている。 さて。少なくとも今回参加しているカンファレンスのジェンダーバランスは、めちゃめちゃ偏っている。おそらく、多くの技術系のカンファレンスにおいても、そうなのではないかと思う。これ自体がいびつであ

ぼくはもう35歳で、どうあがいても中年のおじさんであるし、子供もいる「いい大人」のくせに、毎朝きちんと起きることができない。こうやって雑文を書いたり音楽をやったりすることでなんとか自分を保ってるような「現実不適合者」だ。だからいい歳してバンド活動もやめられない。たまたまプログラミングが好きでやってるおかげでなんとか社会との接点を保って経済的にやっていくことが可能になってる。プログラミングのおかげで社会と接点を持つことができて、文章と音楽のおかげでなんとか自己と世界のチューニングを合わせることができている。そんな感覚がある。 で、 まあ、話を戻して（？）バンド活動をずっと続けているわけだけれど、そのバンドメンバーのひとりにタダくんという男がいる。ぼくは彼のことをバンドメンバーとしてもとても信頼してるんだけど、それ以上に文学部の友人としても信頼している。というのも、彼はぼくと同じくらい、ともす

最近、高校の先生が「知識問題」「思考問題」という言葉を使ってらっしゃるのを聞いて、「なるほど、面白い分類だな」と思った。それ以来「知識問題と思考問題」という視点で物事を眺めるのが自分の中でブームとなっている。 もちろん、知識問題と思考問題というのはきれいにスパッとわかれるものではなく、グラデーション状になっていると思う。この問題はやや思考問題よりだね、とか、かなり知識問題に振れてるね、とか、かなり思考問題寄りだね、とか。 ソフトウェアの設計について考えてみると、じつは、ソフトウェアをどのようなレイヤーに分割するか、というような話はかなり知識問題寄りに見える。この問題には先人の知恵がたくさんあって、それらが「傾向と対策」として未知の問題にも流用しやすい。 一方で、レイヤーの内部をどのような責務でどのようクラス、コンポーネントに分割していくのかというのは、かなり思考問題よりに見える。このとき、

前回の記事の続きです。 前回は、「時代が変わるとサーバーアプリケーションの役割も変わるよね。そうすると必要な要素技術も変わっていくよね」という話でした。今回は、じゃあ「サーバーアプリケーションがJSON喋るマンになって、クライアントアプリケーションとの協働でユーザー体験が実現されるようになってきた今、"ビジネスロジック"はだれが持つべきなの？」って話をしたいと思います。 基本的にはサーバーでもってあげたほうが楽 さて、サーバーサイドでなんでもやる牧歌的な時代は過ぎ去り、クライアントサイドとサーバーサイドがコラボレーションしてひとつの体験を提供するようになった昨今、「そのアプリケーションの体験を成り立たせるための"ロジック"をどっちに書くのか」という問題が立ち上がってきます。わたしの私見ですが、これはなるべくならサーバーサイドで請け負ってあげるのがよいのではないでしょうか。その理由は、クライ

最近、2019年のwebAPIの設計まわりの問題について考えていて、問題とその周辺技術の整理を自分の頭の中でしています。　で、その内容をたぶん何回かに分けて書きますが、初回の今日はちょっと導入として浅めの部分を整理してみようと思います。 昨今、サーバーサイドの仕事はもっぱらJSONなどをしゃべることに終始して、エンドユーザーが触る画面をサーバーがレンダリングする事例は減ってきているのではないでしょうか。これはぼくが考えるに不可逆な事態で、今後もユーザーが使うインターネットにつながるデバイスは多様化していくし、それぞれがそれぞれにネイティブな環境を持ち、それらがHTTPSを喋ってインターネットとつながる、という世界はしばらく変わらないでしょう。言葉を変えれば、サーバーサイドでHTTPをしゃべるお客さんが、エンドユーザーからクライアントアプリケーションというプログラムに移行してきている、という

ぼくは空気を読むのが得意な方ではない。と書き始めて思ったけれど、そもそも、おそらく「自分は空気を読むのが得意で」などと自信を持って言えるひとはそうそういないかもしれない。頭ではそうわかっているのだけれど、感情の部分で「"空気を読むのが得意で"と自信を持って言えるひとはいいなあ」なんて思ってしまっている自分もいるのだ。 だって、「自分は空気を読むのが得意で」と自信を持って言えるようなひとは、逆説的なことだけれど、なんだかむしろ「自然体」で過ごしているような気がする。「空気を読む自分」と「その空気の中にいる自分」の間に1mmのズレもなく、「空気の当事者」であることに対して違和感を感じることなく過ごせる、そんな自然体。そんな明瞭な当事者でいられる強さ。「自分は空気を読むのが得意で」とてらいなく言えてしまうひとには、そんな強さを感じ取ってしまう。 翻って自分を見てみると、なんだか空気を読む自分とそ

アジリティ高くすることが重要なわけで、UI変更のアジリティ高くするためにPDSを意識したり、モデルに関してもドメイン層とインフラ層を分離したりするわけで、「その分離によってどういう変更に対するアジリティを高めたいのか」を説明できないならやるな— しんぺい a.k.a. 猫型蓄音機 (@shinpei0213) December 13, 2018 この発言でもうすべてを語っているんだけど、たとえばDDDの流行（？）によりレイヤー化アーキテクチャ、そこにDIPによる依存関係の整理を加えたオニオンアーキテクチャやヘキサゴナルアーキテクチャ、それらを統括した概念としてのクリーンアーキテクチャなどへの関心はますます高まっているような気がする（要出典）。それ自体は喜ばしいことだとぼくは考えているのだけれど、一方で、初学者などがいきなり「ふんふん、これが"正解"か」と思って、その「構造だけ」を真似してみ

世界とのチューニングを合わせることに苦労する、という感覚は、多かれ少なかれどんなひとでも持ってるのではないか、と思っている。 それはたとえば、飲み会でうまく立ち回るみたいな具体的なことから、なんとなくうまく世界に馴染めないみたいな曖昧なこともあるだろう。それは時には「どう働けばいいのかわからない」という形をとって現れたりもするだろう。そうすると大変だよね。 ぼくの知り合いで、めちゃめちゃ仕事ができるのに、「切手の値段がどう決まるかわからない」と言って封筒を出せずに毎回レターパックを使っているというひとがいる（というかさっきそういう話をツイッターでしてるのを見かけた）。「ググればいいじゃん」と思うことなかれ。おそらく彼にとって「郵便システム」という世界の一部とチューニングを合わせることは、ほかのひとには感じることの難しい困難さを伴うことなのだろうと思う。しかし彼は仕事ができる。それは、彼がほ

先日慶應義塾大学日吉キャンパスで行われた builderscon2018、最高のカンファレンスでしたね。わたしも「開発現場で役立たせるための設計原則とパターン」というタイトルで発表させていただきました。今回は恒例「実況中継シリーズ」として、プレゼンの再現をブログで行いたいと思います。 なお、過去の実況中継シリーズは前職の技術ブログにまとまっていますので、そちらからご覧ください。 それでは本編を開始したいと思います。 開発現場で役立たせるための設計原則とパターン アバンパート よろしくお願いします。 まず最初に簡単に自己紹介をさせていただきます。 先月転職をしまして、8/1からClassiという会社で働いています。妻と息子がおります。Scalaが好きですが、仕事ではRubyメインという感じです。 Web+DB PressやSoftware Designで何度か特集を書かせていただきました。と

聴く方 新しく聴いてる中でグッときたのは fusq 「Polarity」とかノンブラリ「SOUND TRACK」とか。 www.nombrari.jp fusqはGoogle Play Musicをdigってて見つけたやつ。最近っぽい音だなという印象がある。最近こういう方面は質のいい音楽ばっかりで、聴くのが追いつかないなあって感じがしてる。そんな中でもこれはけっこう何度も繰り返し聴いてる。 ノンブラリはなにかで偶然に耳にして、それからアルバムをiTMSで買ったのがたぶん2年くらい前？で、去年のりんご音楽祭に来てたから朝イチのライブを観た。すごい演奏うまくて、ぼく的にはスタジオ音源よりもグッと来た。で、最近新しいアルバムが配信に来たこと知って、聴いたらやっぱりよくて、これも最近よく聴いてる。 新しく買ったやつはそんな感じ。けどじつはこれ書いてる今聴いてるのは昔から聴いてるやつで、パステルズの