地方都市でエンジニアのコミュニティーを立ち上げた話 - 虎の穴開発室ブログ
福島県いわき市に住みながらフルリモート勤務をしている、エンジニアのJ.Wです。 今年の7月に私が住んでいる地域で活躍しているエンジニア有志でWEBアプリケーション開発の活動を立ち上げました。 その立ち上げの背景や初回のキックオフMTGまでのストーリーを語らせていただきます。 活動を思い立った背景 地域に限定した活動を思い立った背景を説明をします。 1. 地域のエンジニアの技術的知見を広げたい 私の住む地域にも小規模ながら製造メーカーや行政のシステム開発を受託するソフトウェアベンダーが数社活動しています。 ただ、顧客のシステム特性から利用技術も限られ、かつモダンな技術に刷新も容易に行うことができません。 そして、顧客も限定的で新しい技術知見を得る機会が少なくなっています。 そのため、私が今まで経験してきた技術的知見、経験を共有したいと考えました。 2.地域のソフトウェアベンダーの会社間交流を
OSS Forwardするエンジニアにインタビュー！なぜOSS開発文化が育っていないマネーフォワードで活動をおこなうのか？ - Money Forward Developers Blog
企画概要 今回は最近マネーフォワードが公開したOSS開発の消費税計算GemJctを主導したTaKOBKiさんに、なぜ社内ライブラリをOSSで公開しようと考えたのか、を根掘り葉掘り聞いてみたいと思い、インタビュー企画を実施しました。 OSSとは？ オープンソースソフトウェア（英: Open Source Software、略称: OSS）とは、利用者の目的を問わずソースコードを使用、調査、再利用、修正、拡張、再配布が可能なソフトウェアの総称である[1]。 wikipedia参照 それでは早速インタビューしていきたいと思います！ 聞き手は技術広報の luccafort です。 プロフィール: 株式会社マネーフォワード CTO室付 前田 喬之（TaKO8Ki） luccafort： まずは自己紹介からお願いします TaKO8Ki：2019年11月からマネーフォワードの京都開発拠点にインターンとし
マネーフォワード vs freee、もし名古屋で開発するなら？ - freee Developers Hub
こんにちは、DevBrandingのellyです。11月19日に配信した「マネーフォワード vs freee、もし名古屋で開発するなら？」の様子をご紹介します。 これから名古屋に開発拠点を立ち上げるマネーフォワードと 2020年に拠点を構えたfreee。 なぜ名古屋に開発拠点が必要なのか、作っているプロダクト、本社との関わり方、 両社のエンジニア組織の違い等を対比しながら1時間たっぷり赤裸々に語ってもらいました。 とても爽やかな両社の自慢対決となりました 長島圭祐 (Kei) さん: マネーフォワード 名古屋開発拠点 拠点長兼サーバーサイドエンジニア。 福岡でマネーフォワードクラウド債務支払の開発を担当しつつ、名古屋に新設される開発拠点の立ち上げを進めている。最近はサーバーサイドKotlinに夢中。 moai: freee 中部開発組織長。中部開発組織を2020/7に立ち上げた。地域技術イ
プロダクトオーナーを経験してドメインを理解する感覚が身についたかもしれないという話 - pospomeのプログラミング日記
現在自分は会社の仕事で認証基盤とマイクロサービス向けのアプリケーションプラットフォームを構築していて、 役割としてはテックリードとプロダクトオーナーを兼任している。 自分が開発、運用するシステムは主に社内のエンジニア向けの仕組みなので、 問題解決対象が技術領域となっている。 "技術的な課題を技術で解決する" という性質上、 プロダクトオーナーもある程度技術を分かっていないといけないので現状兼任している感じである （正確に言うと People Management もしているので、Engineering Manager も兼任していることになるが、 今回の内容と関係ないので触れないでおく）。 チームに興味ある方は連絡ください。 1年前にチームを立ち上げて、今は8名体制になりましたが、まだまだエンジニアが足りません。興味ある方は連絡ください。DMMマイクロサービスアーキテクトチームでサーバサイ
マネジメントも「技術」のひとつ。技術志向だったエンジニアが、開発チームのディレクターに挑戦するわけ - Findy Engineer Lab
こんにちは。粕谷大輔（@daiksy）です。インターネット上では「だいくしーさん」と呼ばれることが多いです。現在は株式会社はてなで、Mackerel開発チームのディレクターを務めています。Twitterなどで使っている、地獄のミサワ風のアイコンをご覧になった方もいらっしゃるかもしれませんね。このアイコンは、前職のフロントエンドエンジニアに描いてもらったものです。 今の自分の仕事は、エンジニアとデザイナーで構成される開発チームを指揮し、プロダクトの安定稼働と、定常的なデリバリーに責任を持つことです。「エンジニアリングマネージャー」という言い方をすると、分かりやすいかもしれません。 自分のこれまでのキャリア選択を振り返ると、もちろん結果論のようなところもありますが、ある程度狙いを定めてキャリアを歩んでこられたのではないかと思います。本記事では自分のこれまでのキャリアについて、「どのように狙いを
BASEでエンジニアリングマネージャーから再びエンジニアに戻って感じたこと - BASEプロダクトチームブログ
こんにちは、CommerceDevというチームでエンジニアをやっています島田です。 このチームは、Eコマースプラットフォーム「BASE」のサービスの根幹を作る事をミッションとし、ショップオーナーの管理画面や決済機能の改善に取り組んでいます。チームができる前は決済チームのエンジニアリングマネージャー(以下EM)をやっていたのですが、いまはEMを移譲しエンジニアとして働いています。 今回はマネジャーを移譲した理由を含め僕がBASEに入社してからのチーム変化を書きたいと思います。 EMになるまで 僕が入社した当時、社内にエンジニアは10名程度でした。現在は約50名のエンジニア組織になりました。 エンジニア以外の社員も増え、それに伴ってかつて問題ではなかったことが問題になったり、これから問題になるだろう課題も抱えるようになっていきました。人が増えると組織としてやることが増えますが、エンジニアも例外
「Misocaのリモートワーク」を支える仕組み - 弥生開発者ブログ
こんにちは。 今年4月にMisocaにジョインしました@KawamataRyoです。 最初に自己紹介を。 少し変わったキャリアで消防士歴が6年、エンジニア歴は1年と半年です。*1 入社後は、こちらの記事のTypeScript化や、開発合宿の副産物（Print.jsを使った印刷ダイアログ表示）のリリースを行ったりしていました。 今は茨城県からフルリモートで開発をしています。 リモートワークはメリットだけではなくネガティブな意見を聞くこともあります。 私自身、エンジニアとしての経験が浅いだけに入社前はリモートワークに不安がありました。 ですが、今はとても充実した開発ライフを送っています。 それもMisocaのリモートワークの仕組みのおかげだと思ったので、今回紹介します。 昼休みに走っている家の近所のランニングコース。どこまでも続く田んぼ道。 常時接続のWebミーティング 出勤から退勤までZoo
【中の人に聞いてみる】目の前の人に喜んでもらいたい Kyashのサーバーサイドエンジニア 井上 智士 - Kyash Product Blog
プロフィール サーバーサイドエンジニア 井上 智士 2013年芝浦工業大学 工学部卒業 株式会社サイバーエージェントに入社し、同社子会社に出向。 スマートフォン向けゲームの開発・保守・運用を担当。エンジニアリーダーとして、シス テムの設計やメンバーのマネジメントを経験。 2018年1月にKyashへ参画。サーバーサイドエンジニアとして様々なプロジェクトを手掛けている。 Kyashのサーバーサイドエンジニア satoshiさんこと、井上 智士氏は入社して約1年。何でKyashに入社したの？最近どう？など、色々聞いてみました。 転職先はKyashと決めていた 前職ではゲーム開発に携わっていました。そこで開発から保守、運用まで一通り経験しました。ゲームの世界では全てのプロジェクトがリリースされるわけではなく、途中でクローズされるものも多々あり、完成させるまでには2、3年かかります。 30歳までに
Figmaでアイデア発散会をやったら盛り上がった件 - 弥生開発者ブログ
こんにちは、デザイナーのとりみずです。 最近Misocaでは全社的にデザインツールにFigmaを導入しました。 Misocaではリモートの社員も多く、モバイルアプリを開発しているチームは 東京…デザイナー 名古屋…サーバサイドエンジニア 京都…デザイナー 鳥取…Androidエンジニア 福岡…iOSエンジニア という日本各地の集まりになっています。 このメンバーで、とある価値仮説に対して「俺の考える最強のアイデアぶつけあい大会」をすることになりました。 そこでFigmaを活用したところ、リモートでのアイデア発散会にとても向いていたので、その様子を紹介したいと思います。 当日までの準備 課題とターゲットをすり合わせを行い、当日のアイデア発散会までの準備に下記を宿題としました。 アイデア発散会の日までに各自手書きでアイデアイメージをA1の紙に書く 匿名性を考慮してアイデアに考えた人の名前はつけ
最近困ってることは時間の配分 - hitode909の日記
ブログに困っていることを書いていけばインターネットの全世界の仲間たちからアドバイスを貰えると思って書いてみます。 会社で、いまエンジニアとして複数のチームに所属していたり、シニアエンジニアをやっているので人々と1on1をしたり、採用系の仕事もちょっとやっている。 開発系の仕事を2つ持っていると切り替えやスケジューリングが難しい チームAの仕事とチームBの開発系の仕事どっちをどういう順序でやるか難しくて困っていて、時間の使い方としてはこのような配分でいきましょう、という話はしていても、たとえば、金曜だけぱちっと切り替わるとか、午前中だけ切り替わる、みたいなことをするのが難しい。 ソフトウェアを作る仕事は、これまで誰も考えたことがないものを作る仕事で、そうでなければすでに完成品のソフトウェアがあるはずなので、集中が必要で、正しく作らないと正しく動かないので、間違いは許されない。そういうものを複
年末なのでBug Bashしてみたら盛り上がった - 弥生開発者ブログ
Misoca開発チームの北村です。 年末の寒波で山に雪が増えることを期待しています。 年末だしBug Bashやってみた 年越しまでWork-In-Progressな作業を持ち越したくない（年明けに記憶を取り戻すのが大変そう） 休暇直前に大きなリリースはしたくない ということで、この機会にBug Bashをやることにしました。Misocaで開催するのは初めての試み。 Bug Bashのやり方などはKyashさんの下記の記事を参考にしました。 blog.kyash.co Bug Bashやってみた 普段一緒に仕事しないメンバーで3チームを作り、Misocaを叩いてみました。 いじわるな入力：めちゃくちゃ長い文字列、HTMLの要素を書き換えて本来想定しない値を設定する ブラウザを2つ立ち上げて、同じデータを同時に編集する URLを書き換えて他の人の情報が見れないか 何度もreloadしたりsu
富士通SEを1.5年務めて辞めた結果、得られた3つの手札 - #がみぶろ
こんにちは、gamiです。 この記事は、楽しかった職場 みんなのF2 Advent Calendar 2018 - Adventarの9日目の記事です。 僕は文系卒で2015年4月に富士通に入社してから公共系SEになり、2016年11月に退職して当時40人規模のベンチャーにWebエンジニアとして飛び込みました。 今は楽しくて仕方がない仕事生活をしています。 また、その経験を活かして「SIerのSEからWeb系エンジニアに転職したんだが楽しくて仕方がないラジオ」という燃えそうなタイトルのポッドキャストをやっています。 略して「しがないラジオ」といいます。 テーマ 以下を書きます。 富士通に入った理由 富士通を辞めた理由 転職前後の違い 富士通にいたことで得られた3つの手札 富士通に入った理由 富士通に入った理由は、主に以下の2つです。 もともと公務員志望で、公共系システムの開発に関わりたかっ
エンジニア向けの体験入社制度ができました - SmartHR Tech Blog
こんにちは、SmartHR で人事をしているぷりんたいです。 このたび「期間限定」で人事チームに異動のもと、エンジニア採用強化に向けた制度作りや採用プロセスのシステム化などを行っております。今回は以前からケースバイケースで実施していた体験入社という取り組みを社外にも公開できるように制度として整備しましたのでご紹介をさせていただきます。 まえがき 共にプロダクトを開発してくれる仲間と出会えず涙ぐましく空回りしていた上半期、サイゼリアで行った歓迎会の練習会が功を奏したのかは不明ですが、幸いなことに下半期では本日時点でエンジニアチームに新たに7名が入社してくれました 🎉 入社後のメンバーからもオープンな社風・文化については良い評価を頂いていますが、これって入社して中の人になってみないと実感できない部分がどうしてもあると思います。特に企業内におけるエンジニア組織って、会社によって位置づけや文化が
Kyashに入社して半年くらい経ちました - Konifar's WIP
早いもので、2017年12月にKyashに入社してから半年が経ちました。 最近は 「勢いある」「Kyashよさそう」と言っていただくことも増えてありがたいなぁと思うと同時に、中にいるとちょっと過大評価されているなと感じることもあります。 自分自身も後で見返せるように、実際どうなの？という話を自分の視点から書いておこうと思います。Kyash実際はこんな感じなんだーというのがなんとなく伝われば嬉しいかぎりです。 ちなみにこういう話は思いもしないところ思いもしないツッコミを受けるものなので結構緊張しています。何か気になる表現があれば@konifarまで直接連絡をもらえるとありがたいです。 入社直後の感想 2017年12月に入社した時、Kyash社内はめちゃくちゃ忙しい時期でした。開発もマーケも全員修羅場で、「オッやっとるな」という感じでした。 自分が入った時にすでに佳境だったので、そのプロジェク
人月単価で80万円ぐらいの仕事 - terurouメモ
Twitterでこういうことを書いたら、そこそこ反応があった。 今のご時世、技術難易度が並ぐらい（一人でWebシステムが構築できる程度）で、2‐3人月ぐらいの小さなシステムを一人でヒアリング～実装～運用引き渡しができて、説明責任ちゃんと果たせれば、人月単価換算で80万円ぐらいは一杯転がってる（常にあるとは言ってない）し、その他要因で単価はもっと上がる— てるろー (@terurou) 2018年4月17日 意図通りには伝わらないだろうなぁと思いつつ、所詮Twitterだしなーと思いぶん投げたんだけど、想定してた範疇の誤解が広まってきたので、一応補足する。 「人月単価で80万円ぐらいの仕事」の難易度 ちゃんと書いてないから伝わらなくて当然といえば当然なんだけど、行間をちゃんと補うと、 エンドユーザー直案件 技術難易度的には、いわゆるマスタメンテナンス機能に毛の生えた程度のもの 一覧/詳細/編
工数見積もりのコツ - Qiita
はじめに 本稿では、仕事をする上での作業工数の見積もり方法について説明します。 工数とは何か 工数(こうすう1)というのは、仕事において、あるひとつの作業を完了するまでにかかる総累計時間のことです。情報処理技術者試験に出てくるTAT(ターンアラウンドタイム)とは意味合いが異なります2。 例えば、ある作業に40時間(40H3)かかるとした場合、工数は40時間であるといえます。1日8時間勤務だとした場合、40時間は5人日(にんにち)と表現することができます。さらに、1ヶ月20日勤務だとした場合、0.25人月(にんげつ)と表現することもできます。 一般的に工数の単位は「人日」および「人月」で扱います。 学生時代は工数を気にすることはないですが、ITエンジニアとして会社で働くようになると、かならず工数を意識する必要があります。 なぜ工数を意識する必要があるのか なぜ工数を意識する必要があるのかとい
ソフトウェア開発技術者が知っておくべき５つの法則 - スタジオ・アルカナ技術ブログ
はいどうも～。 本日はhidetarouの番ですが休業中のため代打でしゃしゃり出たエンジニア吉田です。 「○○○な●●つの○○○」なんて感じのタイトルを付けると、 なんだか興味が惹かれるというのを目にしたので活用してみました。 ※個人的にはそうでもない気がしている。 というわけで、今回はソフトウェアに関係しそうな「法則」を５つほど紹介し、 それをソフトウェア開発業務にどう生かしていくかを考えてみます。 本日ご紹介する法則は以下の5つです。 ブルックスの法則コンウェイの法則パーキンソンの法則マーフィーの法則ハインリッヒの法則 でわでわ、早速。 ブルックスの法則 「遅れているソフトウェアプロジェクトへの要員追加はさらに遅らせるだけだ」 これは、IBMのOS/360（メインフレームOS）の開発者であるフレデリック・ブルックスが 名著「人月の神話」で提唱したプロジェクトマネジメントに関する法則です
提案：エンジニアに気軽に「バグ」というのはやめませんか？ - worker experienceの日記
もしかしたら私だけかもしれないです。ずれているかもしれません。 一般論ではないかもしれません。 でも、同じような気持ちになっているエンジニアがいるかもしれないので、 代表して言わせてください。 エンジニアに、気軽に「バグ」と言うのをやめませんか？ 最近立て続けに以下のようなことが起こっており、私と同僚が消耗しています。心がすり減ってます。ワーカーエクスペリエンスが低下しています。。。 ～～～～～～～～～～～～～～～～～～～ 「○○さん、この数値がバグなんだけど直してもらえる？」 →調べたらその週は祝日影響で、営業日が少ないだけだった。 「あのデータのバグはいつ直りますか？」 →データの集計定義の変更の依頼があり、変更前の状態をバグと呼ぶ 「この前入ってなかったバグなんだけど、次の開発に入れてもらっていい？」 →スコープ外のこと（担当がそれを忘れていた）をバグと呼ぶ ～～～～～～～～～～～～
良いテックリード、悪いテックリード - 小さなごちそう
本記事は、下記の記事の翻訳です。著者の許可を得て翻訳しました。 この記事はフォースクエアの技術的リーダーシップを簡潔に説明したガイドだ。 ベン・ホロウィッツの「良いプロダクトマージャー、悪いプロダクトマージャー」からインスピレーションを得ている。 チームワーク / Teamwork 良いテックリードはチームの一員として振る舞い、自分の成功とはチームが成功することだと考える。面倒で退屈な仕事の一部を担って障害物を取り除き、チームが100%のパフォーマンスで稼働できるようにする。チームの技術的能力を拡大し、システムの重要な知識が属人化しないように務める。 悪いテックリードは注目の集まる仕事で自分の成果を示すことを好む。その成果は部分最適に留まり、開発チームのアウトプットを増やすにはエンジニアの人数を増やすしかない、という状況から脱することができない。 技術的ビジョン / Technical v
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
地方在住の方を応援！地方に開発拠点がある企業の求人特集 | IT/Webエンジニアの転職・求人サイトFindy – GitHubからスキル偏差値を算出
