KAIZEN合宿のススメ - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは！kintone開発チームの刈川です。オフィスが日本橋に移転したので毎日新鮮な気持ちでお仕事している今日このごろです。 さて、今回はkintone開発チーム内で行っている開発合宿、もといKAIZEN合宿についてのご紹介をしたいと思います。 KAIZEN（改善）って？ KAIZENとはその名の通り、製品コードや開発プロセスで生じた技術的負債を返済し改善していくことです（ローマ字表記に深い意味はありません）。私達のチームではKAIZEN DAYというものを定期的に開催し、技術的負債を一日かけて返済する取り組みを行っています。KAIZEN DAYについては過去の記事で詳しく紹介してるのでこちらも参考にしてください。 一日じゃ足りない！集中できない！ 先の記事でも取り上げましたが、一日で行える改善にはいくつかの課題がありました。 一日では終わらない規模の改善にどう取り組むか サービス本体
エンジニアからみた良いプロダクトマネージャとは？ - サンフランシスコではたらくソフトウェアエンジニア - higepon blog
エンジニアからみた良いプロダクトマネージャ（以下PM）とは。rebuildfm #98で id:naoya さん(@naoya_ito)から PM についての話があったので便乗して書いてみる。※プロダクト（製品）マネージャはプロジェクトマネージャとは全然違う職種なので注意。 結論から先に。エンジニアから見た良い PM とは「つねにユーザーのことを考えた上でプロダクトに信念を持っている人」だと思う。それは当たり前じゃないか？と思った人は正しい。でも常にそれをできる PM は多くはない。幸いにも僕は多くの優秀な PM と仕事をさせてもらったのでそこから学んだことをまとめてみよう。 PM の役割 まずは PM の役割から見ていこう。スタートアップの CEO の役割からエンジニア、デザイナーをマイナスした感じと言ったら伝わるだろうか。 もう少し具体的に PM がやっていることを挙げてみよう。 自分
僕がお話しているプロジェクト管理とチームの作り方などについて | 株式会社ヌーラボ(Nulab inc.)
2015年3月25日に、株式会社ロフトワークさま主催の『ビジネスを躍進させる創造的チームの作り方』にて、千葉県の柏にある柏の葉オープンイノベーションラボ（KOIL）にて、「小さなままで世界を相手に冒険できる自己組織化したチーム」というタイトルでお話をさせていただきました。また、最近ではないですが、2012年9月には、Movida School にて「スタートアップは自己組織型であるべき」といったタイトルでスタートアップの起業家に向けてお話させていただきました。 いづれも、「チームの作り方」に触れるような内容でした。 また、同様の内容で、台湾のお客様の社内セミナーや、その他多くの場所でお話させて頂いてます。 自分自身もまだまだ勉強中だということもありますが、このような題材は、「こうすることが正解」というケースは無いと思います。なので、いずれも「会社の文化や、背景、業務内容などにあわせて、良さ
グーグル元社員がエンジニアに「酔っぱらいテスト」を薦める理由
おたくの社員が失敗作を生む たいていのテクノロジー企業は、発売前の商品のベータ版を社員に使わせて反応を見る。「ドッグフード」と呼ばれるこのプロセスは、バグや、使い勝手が悪いところを見つけて、商品の完成度を高める貴重なチャンスだ。 もちろんグーグルもドッグフードをやっている。 ただ、「ちょっと問題があるんだよね」と複数の元社員は明かす。グーグルは社員におたくっぽい人間が多いから、商品の評価におかしな偏りが出るというのだ。「商品を世に出すには、グーグル社員の支持を集めないといけない。グーグルの社員が使いたいと思うものでないといけないんだ」と元幹部は語る。 とはいえ、社内トライアルで確実に支持を得る方法があると、この人物は言う。データ機能とチャートを加えることだ。必ずしも一般ユーザーには重宝されない機能かもしれないけれど……。 「社内トライアルでいい結果が出るように、グーグル社員の好みを意識しす
家族がいる起業家の働き方
ABOUT ME Goodpatch Inc.という会社をやってる人のブログ。http://goodpatch.com/ RSS Archive Random Find me on Facebook Linkedin Twitter Website 僕は23歳で結婚して27歳で最初の子供が生まれた。グッドパッチを起業したのが28歳。つまり起業した時には妻と小さな娘という家族がいた。その結果どうなったかと言うと起業という人生で最もハードに働かなければいけない時期に僕の働く時間は制限された。もちろん、起業家の中には家族がいても成功のためにやむなく家族を犠牲にして夜遅くまで働き土日も仕事をする起業家もいるが、僕はそれができなかった。 妻は決して理解がないワケではない、むしろ27歳の時に会社を辞めてサンフランシスコに行くと言った時に8カ月の娘を連れてサンフランシスコに一緒に行き、言葉も通じない見知
より良い組織を作るために - クックパッド開発者ブログ
はじめに こんにちは、投稿推進部部長の勝間です。 突然ですが、皆さんは「組織における課題」について考えたこと、意識したことはあるでしょうか。 「組織における課題」なんて言葉を使うと、たとえば 事業戦略の方向性 人事評価制度 マネジメント層の育成 など、少し高いレイヤーの話が思いつくでしょうか。 ともすれば自分とは無関係な話のように思えるものかもしれません。 一方で、このようなものはどうでしょうか。 なんとなく、最近社内の空気変わった気がする なんとなく、隣の部署が何やってるかよくわからない このような、もやっとした感覚、は普段働いている中で感じたことがある人も少なくないかもしれません。 こういった「具体的な何か」というより「抽象的な違和感」を私たちが抱くことも組織における課題といってもいいかと思います。 このような組織における課題、違和感を認識したとき、私たちはどのように向かい合うべきでし
2015年Webサーバアーキテクチャ序論 - ゆううきブログ
2023年03月31日追記：この記事を基に、@sadnessOjisanさんより、コードレベルにより踏み込んだ、かつ、グリーンスレッドベースの新しいWebサーバアーキテクチャも含めて整理された記事 Webサーバーアーキテクチャ進化論2023 | blog.ojisan.io が公開されました。 主に新卒のWebエンジニア向けに、古典的なWebサーバアーキテクチャを学ぶ道のりと代表的な実装モデルの概要を紹介します。 この辺りの話題がWeb界隈で流行っていたのは数年以上前というイメージですが、Webサービスは相変わらずWebサーバの上で動いているので、流行り廃り関係なく学ぶべき内容だと思っています。 また、HTTP/2がいよいよRFC化し、既にh2oやtrusterdなどのHTTP/2のサーバ実装があり、今後Webサーバアーキテクチャを再訪することが増えるような気がしています。 ところが、We
ドリコムさんに「社会人交換留学」してきました - pixiv inside [archive]
こんにちは。4月からリードエンジニアという肩書になり、会社の技術選択などに一定の責任を持つことになったedvakfです。 少々前のことになりますが、4月に株式会社ドリコムさんへ「社会人交換留学」として1週間行ってきました。さらにその後ドリコムさんからスーパーRailsエンジニアのonkさんを1週間迎えてピクシブの業務に携わってもらいました。 面白いけどあまりない試みで手探り状態でしたが、やってみると案の定大成功と言えるものとなったと思っています。「社会人交換留学」の事例がもっと増えるように、何が良かったのかを書いてみます。 発端と目的 常に新しい技術を学びたい意欲はエンジニアなら誰でも持っていると思いますが、常に刺激を得られるような取り組みとして社内で短期間だけ別のチームにインターンのような形で行くことを頻繁にやっていけたら、という話を弊社マネージャーのbashさんとしていたところ、bas
![ドリコムさんに「社会人交換留学」してきました - pixiv inside [archive]](https://cdn-ak-scissors.b.st-hatena.com/image/square/8e06358fc6e2272b0a1032eaf66324bd3d597f17/height=288;version=1;width=512/http%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fd%2Fdevpixiv%2F20140325%2F20140325045217.png)
Qiita:Teamとesa.ioを使ってみた感想 - shibukk.io
はじめに 今の会社ではQiita:Teamを使っている。 一番古いのを見たら1年以上前の投稿があったので、けっこう使ってますね。 で、使っているうちにいろいろ気になるところが出てきた。 なので、今お手伝いしている会社にesa.io使ってみません？と言ったら使ってくれることになった。 使ったのは大体5ヶ月くらい。 両方ガッツリ使ったので、誰かのために書いておこうと思う。 情報をどうやって分類するか Qiita:Teamではストック型ツールにもかかわらず情報が流れちゃうっていうのにすごくストレスが溜まっていた。 投稿した時に分類がされないから、どんどんいろいろな情報が流れていってしまう（日報とか書いてたときはエライことになってしまってた）。 まあ、気をつけてタグ付けしていったらいいんだろうけど、タグ付け自体エンジニア以外の人にとってはハードルが高い。 esa.ioは/で区切ってね。と教えるだけ
エンジニアとしていかに成長するかについて、GMOグループの新卒エンジニア・クリエータの皆さんにお話した - Kentaro Kuribayashi's blog
GMOグループにはGMOテクノロジーブートキャンプという新卒エンジニア・クリエータ向けの研修メニューがあって、そこでなんか話してくれという要請があったので、「エンジニアになる」というタイトルで、エンジニアとしての成長について、少しお話をしてきました。 自分自身がエンジニアとしていままでどうしてきたかみたいな話は、まとまった形ではこれまでしたことがなかったわけですが、立場上とか年齢的にも「僕ごときが……」とかいってもいられないので、恥を忍んでスピリチュアルな話をしてみました。以下、ご笑覧くださいませ。 いいたいことはだいたいスライドに書きこんだのですが、以下、ちょっとだけ補足。 このスライドを作っていた時に、ちょうど「現場ロックイン」についてのエントリが話題になったり、また、このエントリを書く直前にも似たような話題のエントリを見たりしました。 現場ロックインが技術力さげてるのかもしれない -
人事がそっとつぶやく「こんなマネージャーが会社を潰す」８つのタイプ - ひかる人財プロジェクト
会社はヒト・モノ・カネで動いている。カネ・ヒト・モノでもなくモノ・ヒト・カネでもなくヒト・モノ・カネの順番で必ず表現される。ただ単にこれは偶然の並びで慣れてしまっただけではなく、間違いなく組織においてもっとも重要な経営資源はヒトなのだと考えている。 その中でも会社が成長するうえで最も重要なヒト（ポジション）と言えるのがマネージャー（中間管理職）であることには異論はないと思う。マネージャーにはほぼすべての会社において共通したミッションがある。それは「目標を達成すること」と「会社を成長させること」である。この２つのミッションを遂行できないマネージャーしかいない会社はもしかしたら近い将来潰れてしまうかもしれない。 そこでこの２つのミッションを遂行できない、会社を潰すタイプのマネージャーの意識と行動について考えてみたいと思う。チョイスしたものは偉そうに書いている私自身も耳の痛いものばかりである。こ
子育てありきのエンジニア業 - HDE BLOG
日の出とともに起きるエンジニア この春で意図的に自分のライフスタイルをそれまでの「渋谷で月曜から飲んじゃうぜ！」パターンから完全に変えてから2年半が経ちます。現在自分は朝8時半に出勤、午後3時半〜4時くらいに退勤、あとは午後7時〜8時頃にまたオンラインになり家から必要な事を行う…という基本スケジュールをとっています。ステレオタイプなエンジニア象では夜中遅く暗い部屋でハックしているイメージがありますが、現在の自分は日の出とともに起き午後11時すぎには寝てしまう生活をしているエンジニアなのです。 幸いな事にプログラマー・エンジニアという仕事は周りの理解さえあれば伝統的なサラリーマンのステレオタイプから見たら明らかに異常なスケジュールでも特に生産性を落とさずに仕事を続けることができると仕事ですので、これを最大限利用させてもらっています。 自分は子育てのために意図的にこのような形を取っており、転職
DELETE_FLAG を付ける前に確認したいこと。 - Qiita
DELETE_FLAG という思考停止フラグ DELETE_FLAG という boolean の列が DB 設計でよく話題になります。 論理削除という言葉で上手に論理武装し、スキを見せるとすぐに入れたがる人がおり、 一方でそれにつよく反対する人もいます。 自分の経験としては、広義の論理削除はありえると思いますが、実現方法が DELETE_FLAG だとなった時、それはあまり考えてないでなんとなくパターンとして盛り込んでる場合が多いと感じます。 ただし、設計に唯一の答えは無いので、もしかしたらそれが妥当な設計である場合があるかもしれません。 今回は「DELETE フラグがなぜダメなのか？」などという話をするつもりも、アンチパターンだと断言するつもりもありません。 問題は、仕様をきちんと把握すると、「最適な設計は DELETE_FLAG ではない」という場合が有って、その場合は、その最適な設計
Kazuho's Weblog: 「技術的負債」は避けるべき？ - 割引率を使って考えてみた
「技術的負債」をコントロールする定量評価手法への期待 からの続きです。 ソフトウェアサービス企業における技術責任者の最も重要な仕事のひとつが、エンジニアリングの効率化です。そのためには、サービスの初期開発コストだけでなく、運用コストを織り込んだ上で正しい技術的判断を行っていく必要があります。 「技術的負債」という言葉は、この運用コスト最適化の重要性を指摘する上で、とてもキャッチーなフレーズだと考えられます。しかし、「技術的負債」を産まないように、あるいは負債を早めに返していこうとすると、開発工数が大きくなってしまうという問題もあります。 初期開発コストと運用コストのバランス注1を、どのようにとっていけば良いのでしょう？ 同等の機能を提供する「ソフトA」と「ソフトB」を考えてみます。ソフトAは、初期開発工数が6だが、２年目以降の維持工数が毎年4かかるとします注2。ソフトBは、初期開発工数が1
秒速でLGTMするコマンド - 詩と創作・思索のひろば
LGTM するときはよさげなアニメーション GIF を探し出してきて lgtm.herokuapp.com にかけるのがデファクト[要出典]だけどこの「よさげなアニメーション GIF を探し出す」というのがくせ者で、大量のアニメーション GIF をブラウザで開くと CPU パワーを浪費するし選択にかける人的な労力もばかにならない。エコではない。そこで Tumblr のランダムな画像を LGTM 化するコマンドラインツールを書いた。その名も lgtm.sh だ。Tumblr には /random というエンドポイントがあるのでこれを利用して特定の Tumblr ブログ群からランダムに画像 URL を得ている。 ./lgtm.sh -m | pbcopy -m オプションをつけると Markdown フォーマットで出力する。つけない場合は画像 URL のみ。 /random へのアクセスには少
共通化でモチベーションと効率が低下した話 - Qiita
自分は普段ソーシャルゲームの開発に関わっていますが、群雄割拠のグリモバ全盛期にその開発を効率化するために社内ではいろいろな取り組みがなされました。そのひとつにアプリ別ではなく機能別のチームを作るということがありました。結果としてそれは失敗だったと言えるのでそのことについて書いていきます。 背景 当時のソーシャルゲームの主流はカードゲームで、クエスト・レイドをこなしつつガチャで引いたカードを合成して強化していくスタイルが一般的でした。そしてその多くがシステムはほとんど同じで見た目だけを変えた「柄替え」アプリでした。 その中で行われたのが二つの共通化です。 コードの共通化 今までのアプリでは元のアプリのソースからフォークするなどして別のプロジェクトとして独立させそれに対して各チームが開発を行うと言う感じでしたが、今回の共通化ではゲームのコアとなるロジック部分をサブモジュールとして分離し、各アプ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
エンジニアtype 技術者のキャリアを考えるWebマガジン - 転職＠type
LINEが開発体制、グローバル対応の秘策、サービス基盤の変遷を解説
Amazon.co.jp: ロジクール ワイヤレスマウス 無線 薄型 ワイヤレス マウス M557GR Bluetooth 6ボタン M557 グレー 国内正規品: エレクトロニクス
Amazon.co.jp: FILCO Majestouch MINILA Air Cherry MXスイッチ赤軸 日本語配列カナなし Bluetooth3.0ワイヤレス接続 ダブル親指Fnキー配列コンパクトメカニカルキーボード 6キーロールオーバー ブラック FFBT68MRL/NB: エレクトロニクス