マネーフォワードCTOが考えていること（2021年9月） - Money Forward Developers Blog
こんにちは。 マネーフォワード CTOの中出（なかで）です。 CTOの私が、普段「なにを感じて、どんなことを考えているか」について、四半期に一回社内へ共有している内容を一部編集し、エンジニアブログに公開したいと思います。 前回はこちら：マネーフォワードCTOが考えていること（2021年6月） 目次 エンジニア組織の英語化 VPoEがベトナム拠点に赴任 AI領域のエンジニアの採用拡大 名古屋拠点の設立準備 エンジニア組織の英語化 マネーフォワードはグローバル企業を目指します。 今後、より積極的に世界中から優秀なエンジニアの方の採用を進めていく目的で、2024年度中を目処に、社内エンジニア組織における仕事上のコミュニケーション言語を英語にすることを決定しました。 ※ 全社のコミュニケーション言語はこれまで通り日本語となります。 今後の実施イメージ： 英語話者が配属されるチームから順次開始(20
「新機能作成時に開発ブランチに細かくmergeしていく戦略」について社内勉強会で発表しました - Hatena Developer Blog
はてなのアプリケーションエンジニアのid:shiba_yu36です。社内技術勉強会で「新機能作成時に開発ブランチに細かくmergeしていく戦略」という発表をしたので、資料を公開します。 speakerdeck.com 以下、簡単に文字でまとめておきます。 戦略 ユーザーに新機能が見えないようにする工夫をし、新機能のbranchもどんどん開発ブランチにmergeしていく mergeされたものは随時本番にリリースされるが、ユーザーに見えない工夫をしているので問題なし PRは可能な限り細かくする 機能が完成したら最後にユーザーに新機能を見えるようなPRを作り、mergeしてリリースする なぜこの戦略を使うのかいろんな失敗を経験して、この戦略を最近使っている。 失敗パターンその1: 巨大PRパターン 失敗パターンその2: 新機能リリースブランチパターン 失敗パターンその1: 巨大PRパターン 新機
次に何を勉強するかを決めるための作戦 - はこべにっき ♨
Webエンジニアが学ぶべき技術範囲はとても広く、いったい何をどこから勉強していくかは難しい問題です。僕も試行錯誤を繰り返しています。 そんな試行錯誤の中で、新しく何を勉強するか決めるときに使ってる作戦がいくつかありそうだなと思うようになりました。そこでこの記事では、僕が次に勉強すべきテーマに困ったときに使っている作戦を紹介してみようと思います。 各作戦の例のコーナーでは実際に僕がその作戦を使って勉強したトピックなどを紹介しています。 このエントリは、はてなエンジニアアドベントカレンダー2016の20日目の記事で、担当はid:hakobe932です。昨日の担当は id:masayoshi さんでLinuxのARPとL2スイッチのお話という記事でした。 作戦1: 新しいプログラミング言語を学ぶ 新しいプログラミング言語を学ぶのは、比較的手を出しやすい作戦です。プログラミング言語を学ぶことで自分
エンジニア立ち居振舞い: ルーズボールを拾う - @kyanny's blog
お題「エンジニア立ち居振舞い」 チャットや課題管理システムを使って非同期コミュニケーションをしていると、誰かに向けて発せられたけど誰も応答していない、ルーズボールのようなメッセージができてしまう。こういうのを見かけたら、できるだけ拾うようにしている。 Quipper の Slack には #development という公開チャンネルがある。開発者が開発にまつわる話をする場で、開発者向けの #general チャンネルといった位置づけだ（なお、開発者向けの #random に相当する #slackoverflow というチャンネルもある） #development は公開チャンネルなので、開発者だけでなく、営業・マーケティング・カスタマーサポートなどの部門で働く人たちも参加している。時折、彼らがシステムのことで何か困っていて、開発者の手助けが必要なことがある。そういうとき、誰でも構わないか
エンジニアの立ち居振舞い:コミュニケーションを取りにいく - An Epicurean
お題「エンジニア立ち居振舞い」 僕の前職のカヤックという会社では「コミュニケーションは取ったもん勝ち」という言葉が一時期よく使われていて、これは実際そのとおりだな、と思う。 僕自身はおおよそ社交的な人間ではないけど、以前から仕事をする上で自分からコミュニケーションを取りに行くことは意識している。意識してるけど、残念ながらできないこともあるのだけど。だから、ちゃんとできているかは定期的に自問している。 「コミュニケーションを取りに行く」とは例えば以下のようなこと。 不明確な点があったら自分からステークホルダーに聞きに行く 仕様を調整しに行く 偉い人に直接掛け合う 新しく入った人に声をかけに行く 話しかけづらいなと思われていそうな時にこちらから話に行く 声をかけることには誰しも勇気がいる。エンジニアは得てして怖がられがちというのもある。だからこそ自分から行くことを心がけている。声をかけたら大体
エンジニア立ち居振舞い: プルリクエストは全部見る - 平常運転
お題「エンジニア立ち居振舞い」 だいたいタイトルが全て。GitHub (or GitHub Enterprise) で仕事をしているので、コードに誰かが何か変更を加えようとするときはプルリクエストを出すことになる。普段仕事をするとき、仕事のリポジトリに誰かがプルリクエストが submit したらそれを全部一旦眺めるようにしている。眺めると言っても実際にコードレビューを全部僕がしている訳ではなくて、コードベースのどの辺を変えようとしているのか、どう変えようとしているかとかをなんとなく把握しておこうとしている。そのまま本当にレビューすることもあるし、ざっと見るだけのこともある。 把握しておくと何かと便利で、他の人のタスクと競合しそうなプルリクエストを見つけたときに「こっちとぶつかりそうですね」とコメントしておいたり、なんだかたいへんそうなプルリクエストを見つけたときに「ちょっと相談しませんか」
エンジニア立ち居振舞い：自分は出来ないと思い込みすぎない - よこなのへたのよこずき
お題「エンジニア立ち居振舞い」 ↑便乗！！ 自分は出来ない、レベルが低いと必要以上に思わない方がいいに違いない。 なぜ？ 自分が困る 精神的に疲れる 他者からの評価すら下がる、給料アップチャンスを逃し得る いいと思っていないものをアピールするのって難しいからね。 後輩 *1 が困る 適切な説明や指導が出来ない 「自分に出来たのだから万人に出来るはず」「自分がバカだから分からなかったけど、この人には説明しなくても大丈夫」ってなる。 後輩の自信や評価までもをマイナスにしてしまう 先輩 *2 が困る 先輩だって間違える、ということを忘れてしまう 先輩と意見が違ったとき、「自分の方が間違ってるんだろう」と思い込んで事前に分かったミスをスルーしてしまう。もっと良いはずのアイディアを出せない。 その他 自分を評価してくれる人に失礼だ 自分の成果を褒めてくれる人がいるのにそれを否定して嘘にしちゃうの、と
エンジニア立ち居振舞い：重箱の隅をつつかない - 面白コンテンツ探求日記
お題「エンジニア立ち居振舞い」 自分は重箱の隅をつつかないというのを意識してる。 重箱の隅をつつく問題はコードレビューの現場でよく聞く。レビューの場で所詮「書き方レベル」の指摘が横行してしまうというやつ。 誰しも綺麗なコードを追求したい気持ちはあると思うし、自分もそうなんだけど、あまり良くないなと思ってやらない事にしてる。理由は3つ。 時間の無駄 指摘される側の精神衛生上よくない そもそも意味ない 細かい指摘でも修正してマージするまでには結構時間がかかる。コードを直し、手元でビルド・動作確認し、pushしてCIを回し、「修正しました」と報告し、LGTMが付いてやっとマージできる。このプロセスが日に何度も発生すると確実に時間を食ってしまうし、Nitsな内容を何度も何度も受けると精神的にも疲弊してしまう。それで生産性が下がってしまえばもっと大きな問題になる。 こうした指摘をしたくなる時、「コー
嫌いな「エンジニアの立ち居振る舞い」 - 評論家気取り @kitano_ow
お題「エンジニア立ち居振舞い」 個人的に嫌いな、という話。 嫌いな「エンジニアの立ち居振る舞い」を。 立ち居振る舞いかどうかわからないが。 1.自分の得意分野 = 常識 と考えるような人。 「僕らからしたら常識なんですけど、」 「え？知らないんですか？」 みたいなそういうの。 延々と専門用語で話を進め、理解できないなら聞き手が悪いというくらいな 勢い。 自分の常識は他人にとって決してそういうもんでもない 2."今日"の拡大解釈 今日というのは、明日の営業開始時間前まで。 もはや誰とも歩調を合わせる気がないような意気込みさえも感じる。 こういう場合、夜の段階で、まだ8時間もあるとか平気で考えてしまうので 気が抜けてだいたい寝る。 3.デザイナーをちょっと見下してる。 デザイナーに限らず、営業の方などでも可。 ただ、実作業を共にする機会が多いという意味では、デザイナーに対して印象が強い。 上の
エンジニアの立ち居振舞い：情報は一次資料にあたる - tjinjin's blog
お題「エンジニア立ち居振舞い」 流行に乗りたかったんです...！情報の扱いについて。 大学時代に日本史学をやっていて、よく教授に一次史料を確認しなさいと言われました。ソフトウェアエンジニアになっても同じことを言われます。 いくつかのパターンを見ていきます！ ドンピシャの記事を探す よくやりがちなのは何かわからないことがあったとき、ググってヒットした記事を見て満足するケース。これはわかった気になってるけど見になってないので、応用が効かないしそもそも間違っていることがあるのでいまいちです。とくにIT系の技術はアウトプットが盛んなので、これで済むケースも多いですが、いざgoogle先生が解決できない問題に出くわすと非常に脆い状態になります。 ググっていくつかの記事を比較する 次に複数の記事を見るケース。これは良し悪しだと思っていて、時間がないケースとかなら仕方ないかもしれない。ただ、それでもその
エンジニア立ち居振舞い：気になったことは納得行くまで追求する - はのちゃ爆発
流行りに乗っかってみる。 お題「エンジニア立ち居振舞い」 気になったことは納得できるまで追求する エンジニアに限った話ではないとは思いますが。 最近は便利なフレームワーク、便利なライブラリ、便利なサービスで溢れかえっていて、 あまり深く考えなくてもサクッとWebサービスとかアプリを作れてしまうような時代です。 そんな時代だからこそ、なのでしょうか。「どうしてこれが動くんだろう？」という疑問が湧いてくることが多いです。 Railsとかそうでした。コイツはなんでこのプログラムを、このファイルを勝手に読みに行ってくれるんだ…？とか。 （残念ながらRailsの中身を徹底的に追求することは出来てませんが、ある程度自分の中で納得できるところまでは落とし込んだつもりです。） 「これをこうしてこうじゃ」みたいな、めっちゃ簡単に複雑なことが出来るのが、ある意味でとても気持ち悪いのです。 なので、自分の中であ
エンジニア立ち居振舞い: ミスを個人のせいにしない - だいくしー(@daiksy)のはてなブログ
お題「エンジニア立ち居振舞い」 エンジニアという仕事にミスはつきものである。 あってはならないことだけど、自分が障害の原因を作り込んでしまったり、データベースに対するオペレーションをミスってデータが消えてしまったり、そういうミスをしたことがないエンジニアはたぶんいないだろう。 個人の書いたコードや、オペレーションが起因で発生したエラーは、当然個人の責任になってしまうのだが、それを過度に責めるのはよくない。 ミスが続いて、萎縮してしまうことにより、柔軟な発想が失われたり、さらなるミスを誘発してしまうからだ。 ミスがつきものの職業であるからこそ、ミスに寛容になろうとすることで、品質を向上できることがある。 ミスを個人のせいにしないという状況は、責任を分散できる体制を作ることで実現できる。 コードは必ず第三者がレビューする、危険な操作は必ずペアで実施する、などだ。 こうすることで、個人ではなく、
エンジニア立ち居振舞い: 気持ちよりも行動を評価する - ✘╹◡╹✘
「エンジニア立ち居振舞い」 というお題に対しての投稿。 立ち居振る舞いというか、姿勢、それも比喩的な意味での姿勢の話なのだけど、所謂やっていく気持ちよりも、行動した事実に価値を見出すように努めている。エンジニアと言うとその職業柄、仕事の所作みたいな話が多くなりがちだけれど、何も仕事に限った話ではなくて、例えばブログ記事を書くときなどもそうであると思う。こういうものを頑張ってつくっている最中であるとか、こういうところで困っていて大変といった気持ちを吐露したくなることがある訳だけど、そこは矜持としてグッと我慢して、早くいいものを完成させてみんなを驚かせたいとか、苦しい気持ちはひた隠しにして反骨精神を高めるとか、そういう気持ちに変換して、より大きな成果を上げられるようにしたいと思っている。 自分に限らず他人の行動についてもそうで、何かやりたいと言っている人や、あるいは筋の良さ悪さについて考えあぐ
エンジニア立ち居振舞い「自分の担当範囲を意識する」 - マルシテイア
お題「エンジニア立ち居振舞い」 僕は今のチームでフロントエンド担当ということになっている。 一応肩書は「アプリケーションエンジニア」だしサーバー側のコードもガンガン書くけど、他のエンジニアとの立ち位置を考えると自然と担当範囲が決まってくる感じだ。 担当範囲の決め方 うちの会社ではWebサービス開発を行うエンジニアを「アプリケーションエンジニア」として一律に扱っているが、その実メンバー毎になんとなく担当範囲が存在する。 担当範囲は、個人的な嗜好、経緯、あとはチーム内での分担で決まる。 僕の場合は、フロントが好きということもあったし、チームに入ってすぐフロントのタスクをゴリゴリ進めた結果、すんなり現在のポジションに落ち着いた。 チーム内で一番JS書ける必要はなくて、チーム内での比較優位で決まることもある。 今のチームでもう2年以上も働いていて、その割に知らない仕様とか沢山でてくるけど、それらを
エンジニア立ち居振舞い：論理的に考える - えいのうにっき
ひとでくんさんが作ってくれた お題「エンジニア立ち居振舞い」。ぼくはセールスエンジニア...、、あっ、エンジニアじゃんってことで考えてみた。 常に物事を論理的に考え、捉えるようにする 僕のいまの仕事のうちのひとつに、ユーザーさんからの技術的な問い合わせに対する受け答えをする「テクニカルサポート」というものがあって。 hatenacorp.jp ご意見やご要望、動作不良など、日々さまざまなお問い合わせをいただくのだけど、特に「なぜかうまく動かない」といったお問い合わせは、僕の目から見ても「なぜうまく動かないのかわからない」ということも多くて。 特に、起きてる現象に対しての「ひと目見ただけでの時点での感想」は、ユーザーの方が抱くものと殆ど同じだったりする。 ただそこからがやはり大事だと思っていて、 目の前で起こっている事象が起きる原因としては、どういったものが考えられるか。 原因と思われるもの
エンジニア立ち居振舞い：サービスを使い倒す - あんパン
ひとでくんさんが お題「エンジニア立ち居振舞い」 を作っていたので参加します。 toBなサービスを開発しているとなかなか難しいかもしれません。幸いなことに今自分が携わっているプロダクトはどちらかというとtoC寄りなので成り立っています。 サービスを使い倒す おそらくどのエンジニアも自分が携わっているプロダクトに少なからず愛着を抱いていると思います。嫌いなプロダクトに携わるのではモチベーションが保たないはずです。また、プロダクトが好きなので自ずとドッグフーディング*1をされている方も多いと思います。 しかし、自分がいちユーザであるWebサービスなどでは作業が単純化しがち、特定の機能を使いがちになります。例えばブログサービスであれば、毎日PCから書くだけ、購読しているブログの新着記事を読むだけなど。もちろんこれでも良いといえば良いのですが、自分はなるべく意識的にいろんな機能を使うようにしていま
エンジニア立ち居振舞い: 属人性を減らす - 詩と創作・思索のひろば
お題「エンジニア立ち居振舞い」 おもしろそうなお題なので乗ってみる。自分は今は技術組織のとりまとめをしているけど、会社の古めのプロダクトの面倒を見る仕事もしてきた。時を経てサービスに携わる人が変遷し、コードの歴史も重層的で一筋縄ではいかないことが多い。仕事で触れるプロジェクトが多いので、ひとつのプロジェクトに関する知識を深めづらい面もある。 属人性を減らす さまざまなタスクを通じてプロダクトに触れるうちにだんだんと自分の中に知識がついてきて、用件を聞いたときに「あ、それならあのプロジェクトのあのへんのコードだな」、というアタリがつけられるようになってくる。この地図や勘といったものは正直なところ外部化しづらく、ある程度を超えると個々人の中で養っていくしかないものだけれど、日々の仕事において、属人性を減らすように努力することはできる。 普段からやっていることは以下のようなところ。 作業ログを残
エンジニアの立ち居振る舞い: ボトルネックを作らないように - skozawa's blog
お題「エンジニア立ち居振舞い」 僕が意識しているエンジニアの立ち居振る舞いは、チーム開発におけるボトルネックをなるべく発生させないようにすること。 エンジニア、デザイナー、企画、ディレクターなどがいるチームで開発していると、エンジニアリングやサービス仕様の側面で困りごとが発生することがある。 例えば、 チームのエンジニアが仕様や設計について困っている。 チームのエンジニアがレビュー待ちでタスクが進めづらくなっている。 デザイナーの開発環境でエラーがでたり、gitの操作で困っている。 企画、ディレクターなどがエンジニアリングに関して相談がある。 比較的チームに長く在籍していて、サービス仕様などに詳しいということもあるけど、こういったエンジニアリングにおける困りごとをなるべくすばやく解決できるようにして、待ち時間を短く、チームの開発効率を上げようとしている。あとは、一人でできるタスクよりも複数
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
エンジニア立ち居振舞い: _(:3 」∠ )_ - Mitsuyuki.Shiiba
エンジニア立ち居振舞い：今回、何を学ぶのか意識する - あたまんなか
