ya8 2024に参加してきた #ya8 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
uzullaさん主催の「みんなで作るテックカンファレンス」のya8に参加してきました。 わたしはアンカンファレンススペース担当として、二日間アンカンファレンススペースの切り盛りをさせていただきました。アンカンファレンスのキモは「一方通行ではなくて参加者みんなで議論する」だと思っているのですが、実際二日間においてほとんどずっと活発な議論が行われていて、参加して発言してくださったみなさんに大変感謝しています。しかも、「いつメン」の同窓会ではなく、いろんな方が発言してくださっていて、ほんとうにいいアンカンファレンスになったなと思っています。 議論の内容については余裕ができたら改めてまとめるかもしれません。 さて、実は私は、約5年ぶりくらいのカンファレンス参加でした。長い間カンファレンスに出席していなかったのには実は理由があります。詳しい理由は控えるのですが、ひとことで言うと、以前「自分とテックコ
組織やチームの慣性力に負けない心構え - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
組織やチームはそれぞれルールや文化、仕組みを持っている。この仕組みやルール、文化はときに外部から見ると「アンチパターン」に陥っているようなこともある。そのとき、「アンチパターンを抜け出してベストプラクティスを」と言うのは簡単だけど、実際にそこから抜け出すのは「言う」のと比べるととても大変なことだ。なぜなら、多くの仕組みやルールは複雑かつ有機的に絡まり合って現在の「仕事のフロー」を形成しているからだ。自分の職能の範囲だけで改善しようと思っても、仕事は自分の職能の範囲では完結せず、「他の職能のやり方がこうだからベストプラクティスは採用できない」となってしまいがちだ。こういう「変えるのが大変」という状況をぼくは「チームの慣性力が働きすぎている状態」と呼んでいる。 では、この慣性力に負けないためにはどうすればいいのだろうか。ぼくは心構えとしては以下のようなことを考えている。 文化や仕組みを変えるの
ナレッジワーカーの集団にとってのアクセルは文化、ブレーキはルール。文化は行動が作る - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
よく、「仕事の属人性を排除して、仕組みやルールで標準化すべき」ということが言われる。これは決して間違えていないと思うけど、一方で片手落ちだと思う。たしかに、労働集約型の事業においては、「人数を増やせば増やすほど利益につながる仕組みやルール」を作ることが大事になるだろう。一方、知識集約型の事業においては、これは必ずしも真ではないと思う。 言ってみればあたりまえのことだけれど、ルールや仕組みは、増えれば増えるほど労働は平準化されていく。労働集約型の事業においては、「ローパフォーマーを減らすこと」のほうが、「ハイパフォーマーにさらに高いパフォーマンスを発揮してもらうこと」よりも重要だ。だって数がたくさん必要なんだもん。そのため、ハイパフォーマーにとっては「枷」になってしまうようなルールや仕組みであっても、その仕組みを課すことでローパフォーマーでも一定のアウトプットが出ることが重要となる。つまり、
言うんじゃなくてやる以外に方法がない - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
「顧客中心主義」という言葉を振りかざすひとは胡散臭く感じてしまうが、一方で重要な考え方であるとも思うアンビバレントがある 労働についての話。 労働をしていると、「どうしてうちの組織はこうなってないんだ」とイライラすることはだれにでもあると思う。というか、そういうイライラを失ってしまったとしたらそれはもう理想を失っているということで、改善の機会を失っている。理想と現実の間のままならなさにイライラしながらも顧客（その顧客は社内の別の部署かもしれないが、それが最終的にエンドユーザーに届くロジックは強固にたてついていないといけない）に対してなんらかの価値を提供して対価を得るのが労働だとさえ思う。 ところで、この理想を実現するためにはどうしたらいいのだろうか。理想を知ること、理想の状態を想像することは簡単だけど、このままならない現実を理想に近づけるためになにかを変えるというのはすごく大変だ。このギャ
アマチュアバンドこそセルフレコーディングしようぜって話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
2023年度を迎え、所属するバンドも新しい音源の制作としてレコーディングを開始しました。わたしの所属するバンドは、2度ほどいわゆる「エンジニア付きレコーディングスタジオ」でレコーディングをしたのですが、そのあとの音源制作は、基本的に私がエンジニアをしてDIYレコーディングを行っています。わたしがバンドでDIYレコーディングを始めたときは、まだ音楽のお仕事でお金をもらい始める前のできごとなので、まごうことなき「アマチュアによるDIYレコーディング」です（でした）。 さて、ところで、エンジニアさん付きのレコーディングプランの価格を調べてみたことがありますか？ 調べるとみなさんびっくりされると思います。たとえばスタジオノアのレコーディングプランでは、スタジオ代に追加で ￥24,200- 支払えば、きちんとしたエンジニアさんが6時間もレコーディングを行ってくれます。高い？ いえいえ、サウンドエンジ
すでにわかっているひとにはわかるけど、まだわかってないひとにはわからん文章 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
今日は掲題のような文章について。 世の中には「すでにわかっているひとにはよくわかるしとてもわかりやすいんだけど、わかってないひとにとってはなんのこっちゃかわからん」みたいなタイプの文章が存在すると思う。 たとえばソフトウェア開発の文脈で言うと、基本情報技術者試験の勉強の際に読むようなやつを想像してみてほしい。ぼくは基本情報技術者試験って結構役に立つよなあって思っている側の人間で、ある程度ソフトウェア開発の経験を積んだひとからもけっこう「内容はいいよね」っていう言葉は聞くと思う。で、この「内容はいいよね」ってところが結構ポイントだと思っていて、実際にソフトウェア開発の経験をある程度積んで、暗黙知や経験知がある程度溜まった状態、つまり「わかっている」状態であれらを読むと「わかるわかる」となるが、一方でそういう暗黙知や経験知がない状態で基本情報技術者試験に合格しても結構「とりあえず暗記したけどこ
継続してプロダクトの品質を保つためにはプロダクトに向き合うだけでは足りないという話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
ソフトウェアの内部品質への投資を怠ったが故に、その内部品質がビジネスの足枷になってしまった、という失敗はよく聞かれる例だと思う。 そういう場合、「なのでソフトウェアの内部品質を直しましょう！」と言う発想になりがちだし、当然そのための投資を始めることは必要なのだけれど、それ以上に注目しなければならない問題がある、と最近は思うようになった。 「内部品質が落ちたので内部品質を直しましょう」というのは、単なる対症療法である上に「いつんなったら直って内部品質への投資やめられるの」という誤った問いを誘発してしまう。よくある話として、一定の内部品質を達成するために「リプレースプロジェクトです！」と言って書き換えを進めて、それが終わったらまた内部品質は鑑みられなくなるような話があるし、内部品質だけではなく「EOL対応」とかでもそういうケースはまま聞く。 じつは直面すべき課題は「内部品質の低さ」や「依存ライ
ソフトウェアの「適切な構造」の構成要素とは？ - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
いろんなところで主張してきたことの繰り返しになりますが、ソフトウェアの設計とは、「解きたい問題に対して適切な構造を与えること」だとわたしは考えています。 「解きたい問題に対して適切な構造を与えること」という以上、「解きたい問題」が変われば「適切な構造」も変化する、ということが言えるはずです。これは「まず問題を適切に捉えること」の重要性を示していると言えると思っています。しかし、そのことと同等に問題とされるべきは、「適切な構造は何によって構成されるか」であるとも思います。 わたしは、ソフトウェアの「適切な構造」を構成する二大要素は「関心の分割点」と「分割点によって分割された要素同士の依存関係」だと思っています。 つまり、ソフトウェア設計とは、「まず解きたい問題を理解し、その問題に応じて、適切な関心の分割点を見出し、見出された関心の分割点で分割された各要素に対して最も適切な依存関係を設定するこ
いつのまにかVPoTになって1年以上経ってた - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
軽く振り返りたい。 去年の10月からVPoTになって、ずっと手探りでやってきていつのまにか1年以上経ってた。 正直言って、始めてから半年くらいは「何を期待されていて、自分ができることが何で、それをどう進めるべきか」が全然わからなくて、自分が何をすべきかということを探る期間だったし、ちゃんと機能できていなかったと思う。具体的に何をやっていたか、と言われてちゃんと応えられる成果がない。まあ、半年くらいそんな感じで右往左往しながら、今までと違う立場で社内を観察していたのはまるっきり無駄とは言えず、今の仕事につながってはいるかな、とは思う。けど正直機能できてなくてすまんかった、とも思っている。 では今何をやっているかと言うと、課題を抱えた現場に対してアドバイザリーとして入っていって改善おじさんをやったり、そういう現場レベルのことよりもでかい粒度で「全社レベルでの仕事の構造を変える」ことに注力してい
シン・エヴァンゲリオン劇場版:|| 観た - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
ひとによってネタバレの範囲は異なるし、いつまでネタバレを回避すべきかもというのも明確なラインはないように思うし、情報は受け手がフィルターすべきだと思っているので、受け手がフィルターできるように最初に書いておくけど、直接的なネタバレらしいネタバレは書いてないつもりではあるけど人によってはネタバレだと感じる内容かもしれないので、ネタバレ嫌な人は読まない方がいい文章かもしれません。 それでも構わないひとだけこの先をどうぞ。 すでに大人になったひとたちのためのアニメだと思う。 シン・エヴァンゲリオン劇場版:|| 観た。結論から言うと、今の自分にとっては良かったと思える作品ではあったけど、ATフィールドをめぐる物語ではなくなってしまっていたし、ATフィールドによって傷ついていた過去の自分を救うものではなく、その頃の自分の切実さが少しずつ見えなくなっていく自分を救うものだな、とぼくは受け取った。 ぼく
VPoTになった - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
この10月から、VPoTという肩書がついた。公式な経緯などは会社のブログのほうに書いたのでそちらを読んでいただきたいのだけれど、こちらは個人の日記なので個人の日記レベルのことを書く。 VPoTになるまでは、テックリードという肩書で、社内を見渡して「あ、ここちょっと自分が入っていった方が物事がうまく進みそうだな」というところに入っていっては手を動かすというようなムーブをしていたのだけれど、冒頭に貼った記事のような経緯で、今は手を動かすことよりも、仕組みづくり、組織構造に起因する問題に対する解決となる構造を作ることなどが主な仕事になった。 じつは、ぼくは今の会社に入るときに明確に「CTOやそれに準ずる仕事はしたくない」と伝えた上で採用してもらっている。なのになぜ心変わりをして、いままたCTO業の一部のようなことをやっているか、ということを今日は書きたい。 そもそも、ぼくがなぜCTOやそれに準ず
builderscon2019振り返り(not技術編) - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
builderscon2019に参加してきました。以下技術的ではない部分の振り返りです。技術的な部分の振り返りはまたあとで書きます。 今年はすごく自分のメンタルが乱高下する、とてもヘヴィなbuildersconとなった。というのも、まさに前回の記事に書いたことが起こったのがbuildersconの前夜祭だったからだ。前回の記事は自分もまだ混乱のさなかにあるときに書いたものなので、だいぶ落ち着いた今、再度そのあたりの話をするところからはじめたい。 前回の記事にも書いたけれど、「マッチングアプリのいいね自動化」という内容そのものが悪である、という立場にぼくは立たない。マッチングアプリというのは、そもそも男女ともに「性的に選別」しあうものである。そうである以上、「マッチングアプリ上での性的な選別の自動化」は問題ないはずだ、という立場ではある。「どんな文脈であれ人間を性的に選別するような発表はそも
エンジニア・コミュニティにはオープンであってほしい - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
エンジニアの集まるカンファレンス（参加者の多くはソフトウェア・エンジニアだが、ものづくりするひとすべてを対象としたカンファレンスなので、暫定的に「エンジニア」という括りで話します）において、マッチングアプリ上で女性の外見を判別して自動でいいねを押すという発表がなされている現場に居合わせた。このエントリの目的は特定の発表自体の是非を判断することではないので、リンクしない。「リンクしなければそもそもその発表の是非の判断ができないじゃないか」という向きもあると思うけれど、少し調べればわかることだし、その発表自体の是非を議論したいなら、調べるくらいのコストをかけて別のところでやってくれたら嬉しいと思っている。 さて。少なくとも今回参加しているカンファレンスのジェンダーバランスは、めちゃめちゃ偏っている。おそらく、多くの技術系のカンファレンスにおいても、そうなのではないかと思う。これ自体がいびつであ
マネジメントの放棄を正当化するような格言めいたものがこの世には流通しているかもしれない - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
ちょっと前にツイッターで以下のようなことを書いた。 「自分で考えて動く」みたいなのすごい大事だとぼくも思うけれど、それをするためには「どんな役割を担ってほしいか」「達成してほしいことはなにか」「どこまで自分の裁量でやっていいか」がそれぞれ明確になってないと無理だよね。逆にそこさえ揃ってれば、よほどのタコじゃない限り自分で動くと思う これに対して、「マネージャーがそれをやらないのはマネジメントの放棄だよね」というリプライがついて、「なるほどたしかにそうだなあ」と思ったのだけれど、マネジメントの放棄と呼ぶべき状況ってのは、これの他にも、ちょっと注意して見てみるといろいろなところで目にすることがあるかもしれない。 たとえば、たまに耳にする「社会人は結果が全て」という言葉について。ここでいう「結果」というのはなんだろう。マネジメントするひととされる人の間で「あなたが達成すべき結果はこれですよ、これ
hayajoさんとの思い出 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
hayajoさんがはてなに入社されたそうです！ http://hayajo.hatenablog.jp/entry/2017/11/05/055756 ところで、hayajo さんというエンジニアと新潟で出会ったのは、ぼくが新潟に引っ越してすぐだった。2011年のことだ。そのときの記録は http://d.hatena.ne.jp/nkgt_chkonk/20110804/1312460118 に書いてある。この記事はエモくてちょっと面映いんだけど、まあ、当時の素直な気持ちがよく出ている文章だな、と改めて他人事のように思ったりする。 新潟にいる間、Niigata.pmを通じて @civic さんの主催するNDSという開発者コミュニティに非常にお世話になった。東京に比べるとやっぱりプログラマ人口がそもそも少なすぎる新潟で、ぼくがプログラマとして腐らず、発信し続けられたのはNDSのひとたちがぼ
#builderscon 2017で「複雑なJavaScriptアプリケーションに立ち向かうためのアーキテクチャ」という発表をしてベストスピーカー賞第三位を頂いてきた - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
先週開催されたbuildersconで表題の通りの内容をしゃべってきました。発表内容については、スライドもアップしてますが、いつもどおり実況中継シリーズを会社ブログのほうに書きます。ただ、あれ書くのすごい大変なのでもうしばらく時間かかりますすみません。書きました。 自分のトークについて 弊社はまだまだメンバーが少なく、わたしもJavaScriptが専門、あるいは専任というわけではないという状況の中で、「なるべくJavaScriptに独特の概念などはプロダクトに持ち込まず、他のプラットフォームにも通用するような考え方ややり方で保守性の高いコードを書く」ということを考えて設計/実装をしています。 その試行錯誤の結果得てきた知見を対外的に発表することで、みなさんに「JavaScriptに限らず有用なトークだった」と言っていただけたのは本当に嬉しいです。 ただ、逆に考えると「JavaScript全
プログラマとコミュニティ あるいは SD8月号に記事を書かせてもらいました - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
表題にあるとおり、Software Design8月号の特集記事を書かせていただきました。GitHub入門的な記事です。 今書店で売ってる号は7月号ですので、今売ってるやつには載ってません（でももちろん買ってくださってもいいんですよ？）。発売日は7/18ですので、その後書店で購入したり、Amazonなどでお求めください。 www.amazon.co.jp 今年に入ってから、web+DB Pressの91,92号、SD8月号と、技術評論社さんの雑誌に記事を書かせていただく機会を立て続けにいただけて、ほんとうにありがたい限りです。 ところで、web+DB vol. 91の記事はYAPC::Asiaでの発表がきっかけでチャンスをいただいたのでした。92はPerlコミュニティつながりで頂いたお話でした。今回の記事に関しては、「Gitをはじめからていねいに」というドキュメントをGitHub上で公開し
適切に抽象化されたコードとはなにかって話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
適切に抽象化されたコードを書く、というのはまさに言うは易し行うは難しだ。 最近私が心がけていることのうちのひとつに、「未来を予測しない」というのがあって、「ここはあとから変更とか追加があるかもしれない」と思って抽象化しておくみたいなことはやめようと思ってる。ひとことで言うと、よくYAGNIとか言われるアレです。 そもそも、なんのために抽象化するのかというということを考えると、ひとつは「一塊の手続きに名前を付けて隠蔽して外から中を意識しないで済むようにする」ってことと、その副産物として「交換可能性が高まる」っていうのがある。 抽象化して実装を隠蔽することで、 コードが理解しやすくなる インターフェイスさえ合ってれば交換可能な部品として扱えるようになる という利点があるから、わたしたちは抽象化を行うわけだ(だからこそ「名前重要」なわけですね)。 この後者の利点に注目すると、ついつい「あっあとか
プログラミングの「抽象化」ってどういう意味で、なぜ必要なのか - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
＜追記＞いろいろ反応あってたしかになーって思いましたが、ここで説明されてるのは「汎化」とか「パラメタライズ」としたほうが正しいですね。抽象化というと、一塊の手続きをブラックボックスにして、実装を隠蔽する面のほうが正解に近いです。でもまあそこを差し引いて読んでいただければ、それなりに有用ではある記事だと思うので、このまま残しておきます＜/追記＞ プログラミングに限らない話かもしれませんが、ふだんの生活で触れないような概念というのは、一度わかってしまえば便利なんだけど、どうしてもとらえどころがない、というようなことが多いと思います。プログラミングにもそういう概念はたくさんあって、わたしのような凡人は新しい概念にぶち当たるたびに苦労しています。今日はそんな中で「抽象化」という言葉について、「昔の自分にこうやって説明してあげたかったな〜」という説明をします。 プログラミングを学んでいく中で、「とり
よけいなプライドは捨てたほうがいいという話について書く - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
雑文を書く。 ぼくはどちらかとプライドが高いほうで、単なる趣味であるところの音楽でも「下手なところは見せられない」とか、「アレを聴いてないことが恥ずかしい」みたいな気持ちを強く持ってる。なんというか、「下手なところを見せたら舐められるんじゃないか」とか「アレを聴いてないとバカにされるんじゃないか」みたいなふうに感じてしまう。 で、こういう話をしてるとよく、「プライドを捨てよ、そして楽になるがよい」みたいなことを言う人間がどこからともなく現れてOSEKKYOを始めたりするのだけれど、そういうのに対しても結構大きな違和感を持っている。こういう「舐められたくない」みたいな気持ちがないと、クオリティの低いものばかり作り出す邪悪な人間になってしまうし、プライドがあるからスキル上がって行くみたいなところはあると思う。 一方で、こういうプライドがじゃまになることもたしかにあって、馬鹿にされるのが嫌だから
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
