2 9XZP @Q [T( ) Twitter: @cobasparxxx I6:!+!(3#)3#)13,* #/ EM: ruby,java,php AW: SIer→$"/2 -57→Fablic<7 FablicYH8U201847:RLjoin 0,>?;%-FN%- .3+BV G%-CDSK 3"&3'=JO

前の記事で軽く触れた通り、Todoistでタスクを管理している。そのあたりの話。 masawada.hatenablog.jp 割と忘れっぽい性質なのと、いろんなイベントを同時並行でやることが結構あって、破綻しないようにTodoistを使ってタスクを管理している。加えて無為に過ごしたくないなあという思いからここ数年はゆるく目標みたいなものを持っていて、Scrapboxで管理している。これらは一度設定してそのままにしてしまうと見るのすら忘れてしまうので、ある程度定期的に見直すタイミングを作っている。以下はざっくりどういうことをやっているかの紹介。 タスク管理 Todoistではレイアウトにリストとボードの2種類があって、それぞれ利用シーンに応じて使い分けている。 リストとボード リスト 進捗を考えなくていいものについてはリストを利用している。アイディア帳的な使い方が多い。例えば前の記事で挙げ

これはアソビュー！ Advent Calendar 2022の14日目です。 こんにちは。 アソビューでバックエンドエンジニアをやってる島田です。 最近、車購入を検討していて試乗したところ近年の安全装備が充実していたり、サイドブレーキすらないことにビックリしました。 今回は、アソビュープロダクト内のコミュニケーションについてご紹介できればと思います。 はじめに 個人のコミュニケーション 直属の上長との1on1 チームリーダーとの1on1 直属以外の上長との1on1 チームのコミュニケーション スクラムイベント チーム内勉強会 モブプロ・ペアプロ coffee chat 組織のコミュニケーション プロダクト部会 ポストモーテム Real Tech Talk 最後に はじめに 採用面談の中で、希望があれば実際働いているメンバーと話す機会があります。(当社では、面接という言葉は用いず、全て面談と

（この感想記事は人生において「スラムダンク」を全く読んだことのない人間が、『THE FIRST SLAM DUNK』を鑑賞した感想です。そんな人間がここにはいるんです。そんなやつがあの映画を観たらどうなるのか。ご注意下さい。） これまでの人生で「スラムダンク」を全く通らずに生きてきた。 いや、敢えて通ってこなかったと言ったほうが良いのかもしれないが、もちろん全く知らなかったわけではない。自分の中にある「スラムダンク」の知識とは・・・ ・バスケットボール部の漫画 ・赤毛の桜木春道が主役らしい("花道"な) ・「君が好きだと叫びたい」のOPが超有名 ・流川というイケメンがいる ・安西先生の名言が結構有名らしい ・でもストーリーを何も知らない ・原作を1ページもめくったことがない ・もちろんアニメも全くの未視聴 以上の通りである。 この話をすると「お前は一体これまで何をしてきたんだ・・・どうすれ

この記事は ANDPAD Advent Calendar 2022 の 21日目の記事です。 はじめに こんにちは。 アンドパッドでエンジニア組織のマネージャーをしている櫻井です。EMと言われたりもしますが、何をしているかというとエンジニアリングの現場での課題解決と向き合っています。 課題にも様々な種類がありますが、今回は昨今のリモート・オンライン業務におけるコミュニケーション課題の解決を目指した施策を紹介します。 そもそもリモート・オンラインの課題とは何か コロナ禍において、エンジニアの業務はリモートで成されることも増えてきたと思います。アンドパッドでも通常業務も然ることながら、ご入社いただく際の選考面談・面接段階からリモートが中心となってきています。 リモート業務にはメリットも多々ありますが、なかなかなデメリットもあると思います。私も元々オフラインコミュニケーションが好きなタイプの人間

リモート下で入社してもう2年経つんですが、ぶっちゃけま〜ほんとに誰からも誘われないんですね。みんなそれぞれやってんなあ〜と思いながらやや不貞腐れてました。 誘う側の立場に立ってみればそりゃそうという話で、会ったこともないよくわからない人間誘わないですよね。どこからくるのかがわからないし、好きな食べ物もわからないし、酒好き（tymikiiはほぼ下戸です）というわけでもなさそうな人をどう誘ったらいいのかわからないですよね。 というわけでまずは自分から誘ってみるか〜ということで2023年の目標は「自分から誘ってみる」ということにしました。月1回自分から誘ってどこかに行くのが目標です。誘われたら「あぁ、こいつの個人的な目標に付き合ってやろう」ぐらいの気持ちで応じてくれると嬉しいです。 とはいえなんとなく乗っかってれば人間関係がそこそこできるという感じじゃなくなったのもなんかしんどい時代になったなぁ

マーケターがよくやっているけど意味のない業務 まこりーぬ：垣内さんはよく取材記事やTwitterにて「○○（マーケティング施策）には意味がない！」とズバリ断言されていらっしゃいますが、本日はあらためて、意味ない度合いの高い施策から順に教えていただけないでしょうか……！ 垣内：成果には影響がないし、やっていてつまらない施策には意味がないですよね。しいて序列をつけるとすれば、よく実施されがちな「ABテスト」「アトリビューション」あたりが最悪で、時間はかかるし一番やってはいけないです。 まこりーぬ：（出ました垣内節……！）しょ、詳細を聞かせてください……！ 代表例1：ABテスト まこりーぬ：ABテストについては前回の取材でもお話しいただきましたね。「細かなABテストで成果が劇的に変わることはない」という言葉は当時とても印象に残りました……。 垣内：ヒートマップを一度でも使ったことがあれば、ページ

みなさん、新機能は好きですか。ソフトウェアへの機能追加は、ユーザ目線で単純に考えると「できることが増えていくのでよい」という響きを帯びています。しかし実際は、長く使われるソフトウェアであればあるほど、新機能を追加すべきかどうかはものすごく気を使って決めるものであって、やればいいというものではないのです。この記事の目的は、新機能の追加には細心の注意が必要だとわかってもらうことです。おもな対象読者はソフトウェアを長期間メンテしたことがないかたがたです。 みなさんが使っているOSSに新機能を追加するPRを送った場合を考えてみましょう。ここで重要なのは、PRが送られてきたメンテナやコミッタといわれるコア開発者たちの立場になって考えることです。彼らの役割は、自分たちを含むユーザがそのソフトウェアを使い続けられるようにメンテし続けることです。このメンテのコストに注目すると、機能追加は基本的にコストを上

発表資料作り、全体的な流れは 1 週間ぐらいかけて構想して、半日使って 15,000 字ほど書いて (コード片含む)、半日使ってスライドに起こす(結果として 6000 字ぐらい使う)、って感じですね。貯めた文字列を組み合わせている最中に構想とは別のストーリーが降ってくることも多い。— Takafumi ONAKA (@onk) July 3, 2018 このツイートの「文字を組み合わせる」のところについて、もうちょっと掘り下げてみる。*1 この記事は はてなエンジニア Advent Calendar 2022 の1月2日の記事です。昨日は id:stefafafan で 『UNIXという考え方―その設計思想と哲学』を読んだ - stefafafan の fa は3つです でした。 3 つのポイント 知っていること 7 割、聞いたことがあること 2 割、知らないこと 1 割 引用しやすいワー

はじめに VScodeを愛用していくうちに設定ファイル（settings.json）がだいぶ煩雑になってきたので、それらを見直しがてらZennに記事としてまとめてみました。 主にwebサイト制作者向けの内容になっております。 どなたかの参考になれば幸いです！ settings.jsonのコードの中身だけを見たい方はこちらへどうぞ！

恥の多い生涯を送って来ました。 システムを開発していると、本当に多くの恥が生まれます。たとえば、こんな恥です。 テーブルの名前を付けミスったりは日常茶飯事。私が付けた変な名前が、自社の営業どころか他社のユーザーにまで浸透してたりもする。例えば、唐突に商品マスタに出てくる「グルーピングタグ」というカラムとか。（まじで意味不明） いま商品マスタと呼ばれているマスタの物理名が「kiosk_pricings」とか。日本語でおｋ。kiosk_pricings.grouping_tagってなんだよ。 「pricing」テーブルにはpriceカラムがあるが、全てのレコードで0になっていて、システムでは一切使っていないとか。（そのうち消したい） システムで使われている"正解"はkiosk_pricings.priceでした〜。 親子関係を間違えた事もある。チケットと決済の親子関係を入れ替えたりもした。 ま

この記事ははてなエンジニアのカレンダー | Advent Calendar 2022 - Qiitaの9日目のエントリです。 会議を司会として設計する際に、司会だけでなく、皆で今やってる会議をより良くしたいし今後の会議もより良くしていきたいと思って実践しているいくつかの手法を紹介する。非常に一般的な良くある手法が多いと思うが、実際に私がやってみてどうだったか、というのも記載している。 最近の私の状況 最初に会の目的を宣言する 狙い 実際にやってみてどうだったか 予備時間を作っておく 狙い 実際にやってみてどうだったか 議題ごとに細かく時間を決め、宣言しておく 狙い 実際にやってみてどうだったか いつでも誰でも感想が書き込めるコーナーを議事録会場などに作って会の最初に宣伝しておく 狙い 実際にやってみてどうだったか このエントリを書いての感想 まとめ 最近の私の状況 最近いろんな会議を設計・

この記事はコネヒトアドベントカレンダー2022の6日目の記事です。 こんにちは。2017年11月にAndroidエンジニアとしてjoinした@katsutomuです。 前回のエントリーで、髪の毛のアップデート予定について触れましたが、今は黒髪7割金髪3割りといったところです。 さて今回は、コネヒトの開発組織で行われている定例的*1なMTGについて紹介させていただきます。 目次 目次 コネヒト開発組織の定例的MTGはどんなものか？ 対象読者 MTGの変遷 一歩MTG時代 2018年 ~ 2019年 課題と背景 各チームでやったこと・これからやることシェア みんなに質問・共有・相談したいことタイム 戦略MTG時代 2019年 ~ 2021年 課題と背景 OKR進捗確認 テックビジョン小噺 みんなに話したい！タイム ボックスMTG時代 2021年 ~ 現在 課題と背景 コンセプト 目的 かためな

In version 2.0 you can now compare new vs old design on the company's page!

デザインの推進は簡単なことではありません。デザインの定義が広がり過ぎてしまったことで人によって解釈や期待が異なりますし、デザイナーの責任範囲も様々です。あれこれ挑戦を続けても物事は思うように早く進まないですし、時には悲観的になるかもしれません。 物事が進むのが遅いのはごく自然なことです。何か実践するだけであれば、一週間あればできるかもしれません。ただ、そこで作ろうとしている価値を組織全体に浸透させるのは時間がかかります。組織が大きければ数年かかることもあります。長期戦だからこそ難しいですし、諦めてしまうこともありますが、うまく進める方法もあります。 中核へいくほど進みが緩やかですが、インパクトが大きくなります手段の目的化にある罠例えば UI ライブラリを作ることを目標とします。とりあえず作ることはできるかもしれませんが、作業コストに担う効果は得ることができるでしょうか。 UI ライブラリを

ソフトウェア開発で、より早くより多く価値を届けたいと考えた時、エンジニアの増員は有力な選択肢です。もちろん、人月の神話などで語られるように、人を増やしただけ線形に生産力が向上するというシンプルな世界ではありません。それでも多くの現場でエンジニアの増員が行われます。自分のチームでも、とりあえずエンジニアを増員すれば、いくつかの問題が解決してくれるような気もします。雑談ベースでメンターなどにこういう話を出してみるわけですが、改めて「なぜエンジニアを増員したいのか」と問われると、これが意外と広がりのある議論であることがわかってきました。本記事では、エンジニアを増員するロジックについて、自分が思考を広げられた範囲で書いてみます。 作り切りの場合は明快 まずエンジニア増員のロジックを素朴に立てられるのは作り切りの場合です。ある程度の規模のものを丸々作り切らないといけないケースです。締め切りがあること

ウェブサイトの表示スピードはサイトの健全性における重要な観点の一つです。Googleが提唱するCore Web Vitalsコア・ウェブ・バイタルズと呼ばれる指標の中にもサイト表示スピードに関する項目があり、表示されるまでの時間が単なるユーザー体験だけでなく、SEOでも無視できない存在です。表示スピード低下の要因はネットワークやサーバーサイド、そしてフロントエンドまで広範囲におよびます。本記事ではその中でも画像の読み込みについて改善できるテクニックを改善前と改善後を比べながら紹介します。 改善前サンプルを別ウインドウで開く 改善後サンプルを別ウインドウで開く 画像読み込みBefore / Afeter 上図はLighthouseによるチェックの結果です。Lighthouseはウェブサイト検査ツールで、ウェブページのパフォーマンス、アクセシビリティ、SEOなどの状態を計測できます。Googl

はじめに 事業としてソフトウェア開発を行う企業にとって、自分たちの開発チームの生産性が十分に高いのか、あるいはそうでないのかについては大きな関心があります。 そのこと自体は、何かを計測し、改善するというのは営利企業としては健全です。一方で、ソフトウェアエンジニアリングの世界で「生産性の高さ」だと主張できる汎用性の高い指標は存在しません。こういった状況の中で、「生産性」を巡る議論は経営やビジネス部門とエンジニアチームとの間で繰り広げられ、場合によっては大きな不和や不信感につながることも珍しいことではありません。 今回は、エンジニアの開発生産性について、さまざまなステークホルダーと議論する上で把握しておきたいさまざまな論点について解説します。それによって、「我々が本当に議論すべきテーマは何か」についての共通認識をつくるための土台を構築することを目的としています。 もしかしたら改善したいことは「

DMやPrivate Channelを使うな、といっても意味がないから、 なんでDMを使ってしまうのかをまず考える、 そこからPublic channelの使い方を考えましょう みたいな話 https://eof-github.github.io/eof2019/ Read less