サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
買ってよかったもの
konifar.hatenablog.com
1ヶ月くらい前、 「バグをドラゴンと呼んだらどうなるか」というTweetを見ました。 確かに、バグをドラゴンと読んだ場合「Sクラスのドラゴンが出ました!」「Aクラスのドラゴンを相手にしてる最中だってのに!」って会話になるし、ドラゴンは結局人の手で生み出されたものってところが中二ファンタジーっぽくて良い— 尾野(しっぽ) (@tail_y) March 18, 2015 これは天才的発想だなと思って職場で雑談で話してみたところ、 同僚のスペイン人エンジニアにバカウケしまして、 それからちょいちょいバグのことをドラゴンと呼ぶようになりました。 せっかくなので、どんな雰囲気になるのかまとめてみようと思います。 先に言っておくと、自分ともう1人スペイン人エンジニアが時々チャット上で使っているだけで、 正直そんなに流行ってないです。 なんかテンションが上がる バグ修正ってマイナスをゼロにするだけで何
最近Twitter眺めたりブログ読んだりしていると、 「伝えたいことがある時は汚い言葉は使わない方がいいんじゃないかなぁ」と感じることが多いです。 自分もブログを書くようになったので、自戒を込めて考えをまとめておこうと思います。 汚い言葉のエネルギーすごい 汚い言葉や過激な言葉の与える印象ってすごく強いです。 政治の話題だと特にありがちなんですが、例えば「老害は引退しろ」とか「馬鹿な政治家に任せてられない」とかよく目にするんですけど、すごく目立ちますよね。主張や印象がどうかは置いといて、とりあえず目立つ。 そう考えると、汚い言葉のエネルギーはやはりすごいなぁと思うわけです。 汚い言葉を使うと伝えたいことがブレる エネルギーはすごいんですけど、どうも主張が伝わってこないなぁと感じてしまうことが多いです。主張したいことに意識を向けてみるとそんなに悪いことは言っていないのに、言葉の汚さの方に気が
他の人はどうかわからないですが、自分は 会社から帰宅する前にやる気が異常に高まることがあります。 仕事でも個人の活動でも「今日は家帰ったら朝までやってやるぜ」みたいな感じで、何でもできそうな気がするくらいやる気に満ちあふれるんですよね。完全にやる気MAX状態なんですが、そのほとばしるやる気のままに行動するかというと、まぁ実際はうまくいかないことが多いです。 参考までに、自分のダメパターンを書き出してみます。 まず家帰って飯食って、ちょっとゆっくりしたら 「あれ?俺のやる気どこ行っちゃったの?」ってなり始めます。 23時くらいに 「よっしゃ23時半からやるぞ!」と思ってアニメ見てたら23時34分くらいになります。 「キリが悪いから0時からオールで頑張るぞ!」とか思ってたらいつの間にか1時になってて、 「まぁ6時まで5時間もある!俺たちの夜はここからだ!」とか考えつつTwitter見てたら2時
「ここ、こんな感じにできませんかね?」と言われたエンジニアが、「うーん、それはちょっと厳しいですね。できないです」と返すみたいなやりとりは結構見かけます。 この「できますか?」⇒「できない」というやりとりなんですが、「できない」という言葉にはいくつか裏が考えられます。言葉足らずだっただけでちょっとした調整をすればできるよね、というケースもあるので、「できない」という言葉の裏側をまとめておこうと思います。 先に補足しておくと、「エンジニアの人の言葉が足りなすぎるでしょ」という意見ももちろんあると思います。こういうコミュニケーションは、お互いの信頼度によっても変わってくるので難しいところです。お互いが相手に伝わるように意識すべきだと思うんですが、 エンジニアから「できない」と言われた時にどういう意味で言ってるのか想像しやすくなればいいなという思いで書いておきます。 ちなみに、「(できるけどやり
早いもので、2017年12月にKyashに入社してから半年が経ちました。 最近は 「勢いある」「Kyashよさそう」と言っていただくことも増えてありがたいなぁと思うと同時に、中にいるとちょっと過大評価されているなと感じることもあります。 自分自身も後で見返せるように、実際どうなの?という話を自分の視点から書いておこうと思います。Kyash実際はこんな感じなんだーというのがなんとなく伝われば嬉しいかぎりです。 ちなみにこういう話は思いもしないところ思いもしないツッコミを受けるものなので結構緊張しています。何か気になる表現があれば@konifarまで直接連絡をもらえるとありがたいです。 入社直後の感想 2017年12月に入社した時、Kyash社内はめちゃくちゃ忙しい時期でした。開発もマーケも全員修羅場で、「オッやっとるな」という感じでした。 自分が入った時にすでに佳境だったので、そのプロジェク
非エンジニアのメンバーと話していると、 なんだかもどかしい気持ちになることがあります。 なんか話が噛み合わないというか、すごく他責な言い方をすると 「もっと開発のこと理解してほしいなぁ」と感じてしまう時があるんですよね。例えば、難易度の高い修正をさらっとできそうな感じで話されたりとか、逆に超簡単なのに難しいと思って遠慮されてたとか。そういう認識の違いから来るもどかしさです。 最近、このもどかしさを解消するには エンジニアから非エンジニアに歩み寄る方がいいなぁと思い始めたので、考えをまとめてみます。 相手の立場に立って考え直す このもどかしさ何とかならないかなぁと考えていた時に、 SHIROBAKO 17話『私どこにいるんでしょうか…』を見ました。 anicobin.ldblog.jp この回では、新人制作の佐藤さんがアニメーターの遠藤さんにちょっとキツいスケジュールの仕事をお願いし行くシー
SHIROBAKO Advent Calendar 2017 始まりました。ということで、興津さんの話をします。 出典 : http://shirobako-anime.com/character-12.html 興津さんは、現場の第一線を退き総務として武蔵野アニメーションを裏から支えるベテランです。序盤は朝礼で事務連絡をしているただのクールビューティーとして描かれていましたが、次第に周囲のキャラクターの反応から伝説じみた過去の実績と信頼が垣間見えてきます。 それらのエピソードを全て語ってもよいのですが 今回は興津さんの左眼にフォーカスを当てて紹介しようと思います。興津さんの左眼は通常時は前髪で隠れていますが、実は何度か両目が見えるシーンがあります。 アニメにおいて、半眼や片眼のキャラが"開眼"する時というのは、何らかのチート能力が発揮されるなど物語の見せ場であることが多いですよね。両目が
個人のアプリ開発は楽しいです。けど時々寂しいです。 例えば深夜にアイコン作ってる時とか。 「いつもはデザイナーさんに助けられてるけど自分でやらないとなぁ…」とか考えて、無性に寂しくなったりします。ちょっと前からこの寂しさを何とかしたいなぁと思っていました。 で、今は Slackにhubotを住ませて1人じゃない感を演出することである程度解決しているので、どんな雰囲気で開発しているかまとめておこうと思います。 先に言っておくと、あくまで自分はこうやってるよという話なので 趣味がかなり入っています。以後その点だけ注意をお願いします。 統一された世界観を作る プロジェクトごとにSlackのチャネルを作ってそこに全て集約しています。GitHubのアクティビティ通知、CI結果通知、メール問い合わせ通知などですね。 ここで自分が大事にしてるのは、 統一された世界観を作るというところです。 例えば この
これは Kyash Advent Calendar 2024 1日目の記事です。 2022年1月から VP of Engineering という役割でKyashの開発組織全体のマネジメントを始め*1、2024年1月から 執行役員 VP of Engineering になり1年くらい経ちました*2。 当初は「今までどおりいいプロダクトを作っていけるように行動していくだけだし大きくは変わらん」と思っていたのですが、想像以上に変化もあったので備忘として残しておきます。 ここに書ききれないこともたくさんあります。「1年近くやってこんな抽象的なことしか書けないのか」と感じられるかもしれませんが、まああまり背伸びせず反省も込めて今のスナップショットをそのまま書くことにします。 結果として事業はよくなっている Kyash のようなカード発行型の決済サービスというのは、決済単体の収益性で見ればいわゆる "
Android開発していると、なんかMVCうまくいかないなぁとモヤモヤしてきました。そろそろ他のアーキテクチャを模索してみた方がいいんじゃないかと思い始めまして、ある程度考えがまとまったので自分なりの指針を残しておこうと思います。 そもそもアーキテクチャ必要なのか 世の中には色々なアーキテクチャが存在するんですが、なんか概念を読んでもスッと理解できることが少ないんですよね。これはなぜかと言うと アーキテクチャが解決しようとしている問題を理解できないからです。 極端に言うと、HelloWorldを表示するアプリにMVCを導入する必要があるの?って言うと答えはNoですよね。じゃあ猫の名前をリストで表示するアプリだったらどうかと言われると、これもまだ必要ないかもしれません。 つまり、アーキテクチャを適用しなくても問題がないほど小さなアプリにおいては、ただ冗長になるだけなので別にいらないわけです。
SHIROBAKO Advent Calendar 2016 始まりました。ということで、瀬川さんの話をします。 出典 : http://shirobako-anime.com/character.html 瀬川さんと言えば、宮森も見惚れる風貌や、最終回でのほろ酔い姿で視聴者を魅了したことは言うまでもありませんが、やはり最も印象的なのは ベテランの風格溢れる仕事への姿勢と言えるでしょう。 第1話でタイトなスケジュールで割り込みの仕事をこなす中、額に冷えピタを貼って 「綱渡りか…」と独り言をつぶやく様は、さながら情熱大陸のワンシーンのようでした。 もちろんアニメなので脚色は入っているとは理解しつつも、瀬川美里という1人のフリーランスアニメーターについて振り返ることは非常に有益だと思うので、印象的なシーンを例に上げて簡単にまとめておこうと思います。 クオリティに対する意識 実は、瀬川さんの登場
思いついた勢いのままに Chrome extension『Kotoha』を作って公開しました。 chrome.google.com コードもGitHubに公開してます。 勢いのままに作ったと言いましたが、Javascript触るの久しぶりな上に初めてのChrome extension開発ということで、 実質15〜6時間くらいかかりました。 完全に俺得Extensionなんですが、せっかく作ったので何を考えてたのかまとめておこうと思います。 知らぬ間にGIGAZINEにも紹介されていました。圧倒的感謝。 gigazine.net どんなExtensionか イケてるアニメの名言を簡単に引用できるようになるExtensionです。 名言をキーワードで探せます。 作品タイトルやキャラクター名でも探せます。 名言はアドレスバーの隣のアイコンから登録できます。 詳細はREADMEに全部書いてあるので
SHIROBAKOはアニメ制作の現場を描いたアニメです。全24話全てが神回と言っても過言ではなく、仕事をする上での姿勢やチームワークの大切さなど本当に学びが多いです。 shirobako-anime.com 人に好みのアニメを押し付けるのは申し訳ないので普段は何も言わないんですが、 SHIROBAKOはどうしても社内のメンバーにも見てもらいたくて、ついに布教してしまいました。少し前の話なんですが、どんな空気になったのかまとめておこうと思います。 結論から言うと、意外とみんな温かく受け入れてくれた上に実際に見てくれたメンバーもいたので、個人的には満足しています。 QiitaTeamに投稿 チームの情報共有にQiitaTeamを使ってるんですが、 『チームメンバーに見てもらいたいアニメSHIROBAKO』というタイトルでしれっと投稿してみました。 反応なければやめようと思ってたんですが、投稿し
嫁は専業主婦なんですが、エンジニアがどういうことをやっているのかをある程度理解してくれていて色々と捗ります。ただ嫁に限らずエンジニアじゃない人にエンジニアのことを理解してもらうのは結構難しくて、どう実現していったかを簡単に残しておこうと思います。 問題意識 仕事柄、突発的に問題が起こって帰りが遅くなることはざらにあります。特にリリース前は忙しくて帰りが遅くなることも多く、帰るたびに説明責任を果たす必要がありました。 また仕事以外でも勉強のために家で開発をしたりブログを書いたりすることも多く、ジトっとした目で不満を訴えかけられていました。 これは毎回同じような対応をするよりも、根本的に教育した方がいいかなぁと考えていました。問題の本質は 何をやってるか想像もつかないことにあると思ったからです。 クイズを出す こんな会話をしてました。 俺「(画面を見せながら)このボタン何%くらいの人が押すと思
この記事は Kyash Advent Calendar 2021 2日目の記事です。 2020年1月から2021年6月まで、1年半ほどKyashでEngineering Managerをやっていました。2021年7月からはロールを変えて、QAチームのいちメンバーとしてAPIのテストやテストの効率化に取り組んでいます。 EMをやめた経緯とやめた後の所感を備忘として残しておきます。 EMとしてやっていたこと 2020年にやってきたことは去年まとめました。 konifar.hatenablog.com 2021年は、共有口座やイマすぐ入金、セブン銀行出金などのリリースに向けてMobile / サーバーサイド / QAのチームでプロジェクトを進めたり、プロダクト開発フローを整えたり、エンジニア採用のリードをしたりしていました。 EMをやめるきっかけ そんな中で、3月くらいに「なんだか最近仕事が面白
若いヨルダン人エンジニアの後輩がいるんですが、彼は本当に前のめりで成長に対して貪欲です。 入社してすぐに「家で勉強するのに良い資料はありますかッ?!」と聞いてきたり、GW前には「何を作ったらいいですかッ?!」と聞いてきたり、とにかく勢いがすごいです。こういう訳がわからない前のめりさはとても重要だと思っていて、何かしら力になりたいなぁと思ったりします。 で、この前も昼時に 「konifarさんは新卒の時どんな風に成長したんですかッ?!」と聞かれまして。覚えてることを話したんですが、ふわっとしたことしか話せなくて申し訳なくなってしまいました。 自分でも成長とは何なのかよくわかってないなぁと感じたので、思考整理してみようと思います。 未来の成長は想像しにくい 自分は正直、『成長する』というのがどういうことなのかよくわかってません。 就活の時に、「他の会社の5年分を1年で身につけられますよ!」みた
DroidKaigi2018が来週に迫ってきましたね。 自分もコードで見るFlutterアプリの実装というテーマで発表します。 その題材として、DroidKaigi2018のiOSアプリを作りました。コードも公開しています。 github.com 作った理由は、以前の記事に書いたとおりです。 また、公式アプリではないですが今年はiOSアプリも用意したいなぁと思っています。iOSDC2017に参加した時にAndroidアプリが欲しいと思ったからです。 まだ申請中なので間に合うかどうかわかりませんが、iOS端末がメインの方に使っていただけると嬉しいです。 DroidKaigiの発表では、時間の都合上Flutterの基本的な部分の説明は省くつもりなので、ここで簡単にまとめておこうと思います。 Flutterとは Flutterは、iOS / Androidで動くアプリを作れるクロスプラットフォー
最近、本業のTaptripで新機能の開発やコードレビューの数が多くなってきた中、 やはりエンジニアに必要なのは説明能力だなぁと感じることが多々あります。 これは受託の場合は全然違うよと言われるかもしれないし、裁量のある環境だけの話なのかもしれないですが、あくまで自分の感じたこととして考えをまとめておこうと思います。 エンジニアは説明することが多い 開発職じゃないとピンと来ないかもしれないですが、何かを説明することって意外と多いです。 例えばバグ修正をする時に、一番理想的な修正をするとテストも含め2日かかるけど、暫定修正なら半日で終わるみたいな場合。 「ユーザーへの影響が大きいので暫定修正で直して、次のリリースで回収できるように調整します」みたいな説明をしたりします。 もっとコードレベルの話で言うと、例えばこんなやりとりをしたりします。 ほとんど伏せているのでわかりにくいかもしれませんが、
時が経つのは早いもので、入社半年くらいの時に近況を書いてから9ヶ月くらい経ちました。 課題はたくさんありますが、今までの経験の中では結構楽しくやっているので、あとで見返せるように記録を残しておこうと思います。 やっていたこと プロダクト開発全般 : ユーザーサポート : 採用 = 6 : 3 : 1 くらいでやっていました。 プロダクト開発全般 Android、API、Webサイト、社内ツール ユーザーサポート SNS対応、レビュー対応、問合せ対応、効率化のためのツール開発 採用 ブログ執筆、Meetup登壇、スカウト、面談・面接 プロダクト開発全般 ユーザーの目に触れる大きめの開発だと、以下の3つくらいです。見返してみると結構少ないですね。 polcaやAudiostockから報酬をKyashで受け取り Android セブン銀行チャージ Android カードから金額指定してチャージ
最近若いヨルダン人エンジニアが入社してきまして、新卒の頃の自分を見ているようですごく懐かしい気持ちになります。 当然わからないことも多いので色々質問してくれるんですが、 質問の仕方をもう少し工夫した方がお互いに効率いいんじゃないかなぁと感じて注意することがあります。すごく素直な子なので、注意するたびに「はいッ!すみませんッ!」と流暢な日本語で答えてくれるんですが、逆に何度もそんなやり取りさせて申し訳ないなぁと思ってしまいます。 で、注意しつつも「自分自身こういうところに気をつけて質問してるよ」というのをちゃんと整理できてないなぁと思ったので、今後のためにもざっとまとめておこうと思います。 自分は小さい会社でエンジニアとしてしか働いたことがないので、他の会社では当てはまらないかもしれないです。あくまで 自分が仕事で質問する時に意識していることとしてまとめます。 タイミングを見計らう 大体みん
Engineering Manager Advent Calendar 2023 15日目の記事です。 KyashでEngineering Managerとして1年半、VP of Enginneringとして2年やってきました。 体系的な話は HIGH OUTPUT MANAGEMENT や エンジニアリング組織論への招待、エンジニアリングマネージャーのしごと といった素晴らしい書籍にまとまっているので、自分はケーススタディとしてVPoEになってからの具体的な意思決定の記録を残しておきます。EMの時の話は過去にまとめています。 KyashでEngineering Managerとしてやってきたこと / やっていくこと - Konifar's WIP Engineering Managerをやめた - Konifar's WIP 先に書いておくと、綺麗にうまくいった / いっているという話は
クックパッド社の 朝Lint活動の記事を見て、最高じゃん…!と思い自分も真似して運用してみることにしました。 techlife.cookpad.com とりあえず自分だけで勝手にやることにしたので 「Lint警告解消に限らずやりたいこと好き勝手やってやるぞ!」って感じで2週間くらいやってみました。わりと進捗よくて成果出てきた気がするので、どう考えて何をやったかを残しておこうと思います。 なぜやろうと思ったのか 普段の開発タスクに追われて細かいところに手がつかず歯がゆい思いをしていたからです。 今作っているTaptripはグロースフェーズにあり、新規ユーザーの流入やDAU・MAUの向上といった数字から逆算した施策を高速にこなすべく開発を進めています。 この方針自体には納得しているんですけど、直近で数字が出るかよくわからない細かい改善というのはやはり優先度が低くなってしまうんですよね。そしてそ
株式会社奇兵隊からQuipper Limitedに所属が変わって3ヶ月ほど経ったので、忘れないように状況を記録しておきます。 先に言っておくと、まだ3ヶ月しか経験しておらずわかっていないことも多いです。なので、「まだ慣れきっていない人から見たらこんな風に見えてるんだなぁ」という感じで軽く読んでもらえるとありがたいです。 また、入社の経緯については、文章で説明すると誤解を生みそうので省略します。と言っても別に話せないようなことは何もないので、直接聞いてもらえれば話します。 今のチーム Quipperは日本と海外向けに教育サービスを展開していて、今はその中のAndroidチームで働いています。 隣にPermissionsDispatcherを作った@hotchemiさんがいたり、後ろに元柔道世界チャンピオンで低レイヤーに詳しい人がいたり、癖のある人ばかりのチームです。 仕事は忙しいかとよく聞か
組織にとって新人は期待の風です。しかしその期待の振り幅が大きい分、逆にイラついてしまうこともあります。 「何回も同じこと注意するの嫌だなぁ」とか「もっと考えてきてほしいなぁ」というのがよくある話ですが、ふとした時につい強く言ってしまうことがあるんですね。で、あとでいつも後悔するわけです。イラつきというのはそれ自体で何かがよくなるわけではないし、無駄に疲れるし、自分にとっては害でしかないです。 あとで自分で見返せるように、新人にイラついてしまった後に後悔しながら考えていることをまとめておこうと思います。先に言っておくと、ほとんどマインドセットの話なので万人に共通するような話ではないです。 期待を共有する 「なんでこんな完成度で出してきたんだ。。全然ダメじゃん」とイラついた時は、アウトプットに対する期待が相手の考えるレベルと食い違っているのかもしれません。その場合、「ちゃんとやれよ」という注意
2022年1月からKyashで VP of Engineering(以下、VPoE)という役割で開発組織全体を見ています。VPoEになった背景はまた別途書くとして、この3ヶ月は反省も学びも多かったので振り返りを書いておきます。 自分がVPoEになった時、VPoE README というドキュメントを社内に共有しました。同じ内容をKyashの採用GitHubリポジトリで公開しています。 github.com 今回はこれを自分で読み返して引用する形で振り返ってみます。先に注意をしておくと、体系だった話やどこでも応用が利くような話というよりは、完全に自分個人の振り返りの内容になっています。 README書いてよかった READMEを書く目的を以下のように書いていました。 VPoE の最初にやるべきことは、何をミッションにして何をやっていくかを定義し、周囲に理解してもらうことだと考えています。その一
DroidKaigi2018で『コードで見るFlutterアプリの実装』というタイトルで話をしてきました。 speakerdeck.com 聞きに来ていただいた皆さん、資料を読んでフィードバックをくれた皆さん、運営の皆さん、発表前に場を温めていただいた @mhidakaさん、ありがとうございました。 スライドだけだと話がわかりづらいところもあると思うので、書き起こし形式で補足しておこうと思います。当日用のスライドを一部削ったり、アドリブの台詞を省いたりはしています。 ちなみにこのやり方は、@yanzmさんが去年、今年にやっていてとてもよいなぁと思ったので真似させていただきました。 コードで見るFlutterアプリの実装 今日はFlutterアプリのコードの話をします。Flutter自体の内部の詳しい実装ではなく、Flutterでアプリを作る時にどうコードを書くのかという話です。よろしくお願
Kyash Advent Calendar 2023 23日目の記事です。 Kyashに入社して6年が経ちました。 Androidアプリのエンジニアとして入社し、Androidを書いたりiOSを書いたりGoを書いたり、CSチームで問合せ対応をしたり、MobileチームのEMをやったりQAとしてテストの自動化をやったりして、今は開発組織全体のマネジメントをしています。あと4年前には子も産まれました。色々ありましたね。 最近他社のマネージャーに時間の使い方の話を聞いた時にとても面白かったので、自分の6年間のGoogleカレンダーのスケジュールの変遷を書いてみます。 2017/12 1週間 Android開発に集中する 真っ白ですね!Android開発に集中って感じでした 3週間くらいはこんな感じで、その間に送金時の39アニメーションとアプリロックの指紋認証機能を作ってリリースしました 2018
昨日のDroidKaigiの@operandoOSさんのセッション Android学ぶを君へ。生き抜くためのナレッジ共有の中で『ひたすらクソコードを書く』という話がありました。 もちろんこの話はほんの一部でしかないんですが、とても印象に残りました。 誰と話したか忘れてしまったんですが、懇親会で 「クソコードでも公開した方がいいんじゃないか」みたいな話が出て、なるほどなぁと思ったのでちょっと思考を整理しておきます。 書けば何がクソコードかわかってくる 何も書かないよりクソコードでもいいからまず書いてみる方がいいと思います。 そもそもクソコードっていうのはよいコードの基準があってこその価値観なんですよね。書かなくても何がよくて何がクソかわかるよって人もいると思うんですけど、自分はやっぱり頭で理解するより書いて理解する方が腹落ちしやすいです。 例えば、GoFのデザインパターンはよくある問題を
写真投稿系のアプリだと必ず問題になると思うんですが、ユーザーが増えてくると ポルノを投稿をするユーザーが0.7〜1.0%くらいは出てくるんですよね。 本業のTaptripは海外のユーザーが99%以上なんですが、やはりポルノを投稿するユーザーが1%くらいいます。中でも中東地域のユーザーが投稿するポルノ写真は結構ヤバくて、 中学生が見たらトラウマになっちゃうんじゃないかってレベルです。 Googleの提唱するFamilySafetyの理念にも反しますし、電車の中でいきなり表示されると気まずいということもあって、昨年 『肌色フィルタ』というのを作って暫定対応しました。 ですが、最近もっと良い対策を入れたことで肌色フィルタは役割を終えることになったので、供養を兼ねてまとめておこうと思います。 先に言っておくと、AIやディープラーニングみたいな技術的なチャレンジはやっていません。あくまで工数かけずに
次のページ
このページを最初にブックマークしてみませんか?
『Konifar's WIP』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く