こんにちは、ゆのん(id:yunon_phys)です。この記事は Akatsuki Advent Calendar 2021 の22日目の記事です。 アカツキでは数年前よりEngineering Managerの役割をおいているのですが、この度、Engineering Manager(EM)の役割を公式に無くしました。私の個人的な活動で、EMによるEMのためのPodcastをやっているし*1、社内でもそういう活動を知っている人がいるし、世間からするとお前がそれを言うのか〜と言われそうなのでなかなか勇気のいる決断でした。ただ、今後の会社の方針を考えたときに、今見直すタイミングなんじゃないかと思い、思い切って無くしてみました。 本記事ではなぜ無くすことにしたのか、これからどうしていくのかを書いていきます。 EMのやることが消滅したわけではない アカツキのEMはエンジニアのマネジメントと、プロジ

｜DMM inside

この記事はKyash Advent Calendar 2021の14日目の記事です。 KyashでiOSチームのTech Leadをしているtamadonです。 自分が入社当時は2名だったiOSチームも現在は3名になり、以前より機能開発以外でもやれることが増えてきました。 この1年でKyashのiOSチームがやってきた改善についてご紹介します。 Swift Package Manager(以下SwiftPMと略)の導入 iOS版Kyashの依存ライブラリ管理は今までCarthage+CocoaPodsを併用していましたが、Carthage管理しているライブラリの更新を行う際に差分が大量に発生してつらいという問題がありました。 そこで、Xcode12.5から外部ライブラリをDynamic Frameworkとしてビルドできるようになったこともあり、Carthage管理化のライブラリをSwif

誰かから相談を受けた時、後でよくなかったなと思うことがちょいちょいあるので雑に書いておく。 相談の種類や関係性にもよるので、たぶん違和感を覚える内容も含まれるとは思う。 相手の話を聞く 当たり前なんだけど、意外とできてないこともある 自分の話を起点にしてはいけない。相手の話を聞くのが先で、自分の話は聞かれたらするくらいでいた方がいい アドバイスが必要かどうかを見極める 相談をされると解決のための話をしてしまいがちだが、そういう論理の話をしたいわけではないこともある 例えば聞いてくれるだけで救われることもあるし、相談相手が感情的に怒ってくれることで自分が冷静になるみたいなこともある 相手がアドバイスを求めているのか見極めた上で、アドバイスする場合にはバイアスをかけないように慎重に 同調しすぎない 共感と同調は違う。共感することは大事だけど、同調しすぎると相手の負の感情を増幅させることにもなる

気がつけば、この雑なブログを毎月更新していた。今月書けば1年なので、今日も雑に書いてみる。 これから書く話はすごい嫌な意見だけれど、誰かのやる気が他の誰かのやる気を削ぐ現象ってあるよなぁと思っていて、そのことについて書いておこうと思う。これは自分も大いに当てはまることがあって、そういう時は自己嫌悪になる。 例えば月曜日の朝。週末に何かやろうとしていて出来なかった朝。社内のチャットやTwitterで週末やってみました！みたいないわゆる"やっていき"を目撃すると、気分が沈む。あぁ、ここまで書いただけでもすごくネガティブで嫌な奴だということはわかる。わかってる。けどこればっかりは仕方ないよね。 これ原因もわかっていて、要は自分が自分に期待する成果をうまく出せていない時に、他の人のやる気を見せられるとすごく苦しくなるのだ。本来なら、お互いに最高じゃん最高じゃんと空気を高めあっていくのがいいともわか

エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 はじめに 今年、書いた幾つかの記事のタネ本であったり、新卒教育の際に参考書籍としてあげたものを中心にリストアップします。一応amazonへのリンクも貼っておきますが、先輩が持ってたりすると思うので、冬休みに借りて一気に読んでおくのもいいかと思います。 その時々、必要な技術の習得に日々追われているんじゃないかと思いますが、いつまでも使

グレード評価制度において、上のグレードに行けば行くほど期待が抽象的になるよねという話を会社の同僚氏と話していた。 ICでもマネジメントでも影響を及ぼす範囲も広がり、できることも増える中で求められることも自然と多くなってくる。 そんな抽象的な期待を明確にする部分も求められているよねと同僚氏が言っていて、それはたしかにと思った。要するに、自分がどこで成果を出すべきかを自分で定義できるスキルが必要になってくるということである。 ジュニアとシニアみたいな分け方があるが、これはシニアに求められるスキルの一つかもしれない。何をやったらいいのかわからない中でもまわりを見渡して、必要なアクション (must)と自分のやりたいこと (will)とできること (can)をすり合わせて方向を決めるみたいな話である。 それはマネージャーの仕事だろと言われればその通りなんだけど、グレードが上がるとそういう抽象的な期

なぜエンジニアが作る画面はダサいのか…?「理由」と「対策」を徹底解説【エンジニア向け画面デザイン講座】UXUIDesignUIデザイン画面設計 1.はじめに エンジニアの私がデザインを本気で勉強した結果、デザイナーとエンジニアはそもそも思考が大きく違っているということがわかりました。 今回は「それ」をデザインに苦手意識のあるエンジニア方にも理解してもらえたらと思い、わかりやすくまとめてみました。 2.アプリの画面デザインを考えてみよう まず、こんなアプリを考えてみてください。 フィットネストレーナーが使うアプリ トレーニングルームでお客様とお話しながら使う 端末はタブレット そして 会員の個人情報確認 前回までのトレーニング状況の確認 次回の予約受付 といったことをします。 使える情報としては、こんな感じです。 あなたならどう画面デザインをするか、もしお時間があったら考えてみてください。

この記事は Kyash Advent Calendar 2021 10日目の記事です。 こんにちは、Kyash Design OfficeでDesign Managerを担当しているsubaruです。 気がついたら、Kyashに入社して1年6ヶ月経っていたので自分自身の振り返りとKyash Design Officeについて書いていこうと思います。 入社直後の感想自分が入社した2020年6月頃、​​Kyash社内はめちゃくちゃ忙しい時期でした。 開発もコーポレートも全員修羅場で「資金移動ライセンスの取得」と「銀行口座入金の開発」に一丸となって取り組んでいる最中で、まさに決済サービスからバンキングサービスへと移り変わり始めている最中でした。 そして、無事に銀行口座入金機能をリリースした直後に「ドコモ口座事件」が発生し、一部の銀行口座との連携を一時的に停止せざるを得なくなり、銀行口座接続の本人

本記事は、下記の記事の翻訳です。著者の許可を得て翻訳しました。 この記事はフォースクエアの技術的リーダーシップを簡潔に説明したガイドだ。 ベン・ホロウィッツの「良いプロダクトマージャー、悪いプロダクトマージャー」からインスピレーションを得ている。 チームワーク / Teamwork 良いテックリードはチームの一員として振る舞い、自分の成功とはチームが成功することだと考える。面倒で退屈な仕事の一部を担って障害物を取り除き、チームが100%のパフォーマンスで稼働できるようにする。チームの技術的能力を拡大し、システムの重要な知識が属人化しないように務める。 悪いテックリードは注目の集まる仕事で自分の成果を示すことを好む。その成果は部分最適に留まり、開発チームのアウトプットを増やすにはエンジニアの人数を増やすしかない、という状況から脱することができない。 技術的ビジョン / Technical v

こんにちは、Kyash Peopleチーム 採用のまゆゆと申します。 私のバックグラウンド等はよろしければ下記のBlogなどをご覧ください。 プロローグある日突然、Kyashエンジニアの konifarさんからこんなことを言われました。 素直に嬉しかったです。 思い返せばスカウトメールを本格的に書いてこなかった1年前に比べたらグッと上手にかけるようになりました。 たまに本当にスカウトメールの神様が降りてきて、スルスルいろんな言葉がなめらかに出てくることもあるのですが、実際のところはほとんどがひとつひとつ時間をかけながら頭をフル回転させながら書いています。 候補者の方々の個別事情にも深く関わるので具体的に書きにくい部分も多いですが、これまでどんなことをやってきたか、振り返りも兼ねて書きます。 スカウトメールを書くことに困っている方の少しでもお役に立てれば幸いです。 どんなスカウトメールを書い

ABOUT 秋田県出身のエンジニア。 高専で電気情報工学を学んだのち、メーカーで金属プレス加工作業員として従事。 その後ITの魅力に惹かれ独学でプログラミングを学習しIT業界へ転職。 Ruby on Railsエンジニアからキャリアをスタートし、Goによるバックエンド開発、TerraformによるGCPクラウドサーバ構築など、インフラからバックエンドをメインに業務を経験してきました。 X

この記事は NTTコミュニケーションズ Advent Calendar 2021 の11日目の記事です。 はじめに ヒューマンリソース部の岩瀬(@iwashi86)です。普段は、全社の人材開発・組織開発を推進しており、業務の1つとして、"1on1" の全社展開をしております。 本記事では、その"1on1"の効果を高める具体的な技法を紹介いたします。アドベントカレンダーということで、ゆるめに書いてみます。*1 NTT Com における1on1の目的とは？ 技法を説明する前に、1on1の目的について説明します。技法はあくまで目的達成に向けたHowでしかないためです。 1on1の目的とは何でしょうか？1on1それ自体には、複数の目的が挙げられます。代表的なところで言えば次のようなものでしょうか。 信頼関係の構築 離職率の低下 メンバー育成 目標達成へ向けた支援 etc... どれが正解というもの

この文脈では、「編集内容のキャンセル」という処理を続行しても良いかをユーザーに確認しています。続行に同意したい多くのユーザーは直感的に同じ表記の「キャンセル」を押したくなるでしょう。しかしそれでは編集のキャンセルが実行されません。 このキャンセルボタンが意味するのは、「『編集内容をキャンセルする』のキャンセル」なのです。つまり、ユーザーが望み通りに編集内容を破棄するためには、反対側のOKボタンを選ぶべきなのです。このような「キャンセルのキャンセル」は二重否定で意味がややこしくなるので避けなければなりません。 ここで「キャンセルのキャンセル」にならなければ良いということで、次のようにボタン名を変えてみました。 これでもう迷うことは無くなりましたか……？ 私はこの修正は誤りだと判断します。「はい」「いいえ」は結果を予想しにくい表現なので、ダイアログのアクションボタンに用いることはあまり適切では

「もったいない」マインドが逆に効率を悪くする。フロー効率とリソース効率から考えるチームで仕事をする理由チーム開発プロジェクト管理マネジメント はじめに 前回、なぜ、ソフトウェアプロジェクトは人数を増やしても上手くいかないのかの記事において、プロジェクト型の人員規模を柔軟に変化させる開発スタイルに関して、理論的なスケジュール削減の限界について考察しました。その際に、チーム型開発や組織とソフトウェアの紐付けについても示唆しました。 今回は、チームでソフトウェアを開発することに関して、「フロー効率」と「リソース効率」という観点から考察し、なぜ私たちはチームで開発するのか、あるいはなぜプロジェクト型を採用するのかについての考え方を深めていきたいと思います。 そして、組織における効率性の価値観が異なると、新しい効率性に関して理解をする前に「もったいない」と感じてしまい、新しい文化を取り入れづらくして