ブルーオーシャンには手を出すな、「苦手なこと」こそ人に任せるな……ドワンゴ創業者・川上量生が語る、常識外れの事業創造論【連載 FastGrow Conference 2021】| FastGrow
「僕は嘘が嫌いなので、まず最初にお伝えしますが、今日参加した目的は『勧誘』です。“撒き餌”として新規事業立ち上げのポイントはお話しますが、伝えたいのは『ドワンゴに来てくれ』ということです」 セッションの冒頭、川上氏が口にした言葉にはその人柄がよく現れていた。イベントに参加する目的が採用であっても、開口一番、それを身も蓋もなく明かしてしまう起業家は珍しい。建前を嫌い、言いづらい"真実"も平然と語る──そんな川上氏のスタンスが、このセッションを唯一無二のものにした。 株式会社ドワンゴ 顧問 川上量生氏 本セッションで語られたのは、新規事業のつくり方。1997年にドワンゴを創業してから、多くの事業を生み出し、成長させてきた川上氏が事業創造のポイントとして挙げたのは、「競争しない」「専念する」「すべてをマイクロマネジメントする」の3つだ。「今日のお話の中心となるのは『競争しない』ことについて。まず
セルフマネジメントの必須スキル「タスクばらし」そのポイント | Social Change!
私たちソニックガーデンでは、指示命令のマネジメントを捨て、メンバーそれぞれが自分で考え自律的に行動することで、高い生産性を発揮しつつ様々な変化に対して柔軟に対応できる組織づくりに努めている。 そんなメンバーたちに求めるのはセルフマネジメントができることだ。セルフマネジメントができるために身に付ける素養は少なくない。しかし、セルフマネジメントを身につける最初の一歩は何かを聞かれたら「タスクばらし」だと答えるだろう。 本記事では、セルフマネジメントをマスターするための最初の必須のスキル「タスクばらし」について紹介する。 「タスクばらし」とは 「タスクばらし」とは、読んで字のごとく、仕事をタスクにバラすことである。仕事に取り掛かる前に、その仕事の要素を分解し、どのように進めるか道筋を立てることで、どれくらい時間がかかるか、リスクは何か、見通しを得ることができる。 当たり前のことだと思っていたが、
45の仕事力チェックリスト ～「会議の進め方」から「タスク管理の方法」まで～ | 採用ブログ | 才流
「仕事で成果を出す人」と聞いて、どのような特徴を思いうかべますか。 才流はコンサルティング会社であり、ビジョンとして「メソッドカンパニー」を掲げています。顧客へ価値を届けるにあたって、営業やマーケティング、新規事業などの専門知識はもちろん、ベースとして強固な「仕事力」が欠かせないと考えています。 本記事では、社内で実際に活用している仕事の進め方マニュアルの中身をテーマ別に厳選し、チェックリスト形式で紹介します。 ※本記事が多くの方々に読まれていることもあり、このたび内容を最新版にアップデートしました。 ビジネスパーソンの心得1. ビジネスの原理原則を理解するビジネスで価値を提供するためには原理原則が存在するビジネスの原理原則とは、相手＞自分であり、顧客＞外部パートナー＞自分であること具体的に表すと「顧客や社会、チームメンバーに価値を提供する→顧客や社会からお金がもらえる→自分たちの給与が出
Vol.05 Connect によるスキーマ駆動開発のススメ - connect-go バックエンド編 - Sansan Tech Blog
はじめに こんにちは！ 技術本部 Bill One Engineering Unit の市川です。 私の所属するチームでは Bill One の新規マイクロサービス開発に Go 言語と Connect を採用してスキーマ駆動開発を実践しています。 今回は Connect を導入して実感した良いところを、バックエンドの話を中心に実例を交えながらご紹介していきます。 なお、本記事は【Bill One 開発 Unit ブログリレー】という連載記事のひとつです。 目次 はじめに 目次 Connect とは Connect の良さ・メリット Protocol Buffers ベースのスキーマ駆動開発 Connect を用いた開発の大まかな流れ Proxy 不要でブラウザから直接 API が呼べる connect-go が net/http ベースであること REST API との共存が可能 net/
SRE の原則に沿ったトイルの洗い出しとトラッキング | Google Cloud 公式ブログ
※この投稿は米国時間 2020 年 2 月 1 日に、Google Cloud blog に投稿されたものの抄訳です。 作業効率を検証するために Google のサイト信頼性エンジニア（SRE）が使用している主な測定指標の一つが、日々の時間の使い方です。長期間のエンジニアリング プロジェクトのために時間を確保する必要がありますが、エンジニアには Google のサービスを稼働し続ける責任もあり、そこにも手作業が生じることがあります。Google の SRE は、いわゆる「トイル」に費やされる時間を勤務時間の 50% 未満にすることを目指しています。では、トイルとは何でしょうか。トイルに邪魔されずに開発スピードを維持するには何をすべきでしょうか。本稿ではこれらの問いについて見ていきます。 まずトイルの定義ですが、『Site Reliability Engineering』の第 5 章には次の
GitFeatureFlow風ブランチ運用がうまくハマって、少しずつズレてきた。そんなブランチ運用の話｜Showcase Gig Product Team Blog
GitFeatureFlow風ブランチ運用がうまくハマって、少しずつズレてきた。そんなブランチ運用の話 こんにちは。Showcase Gigでバックエンドエンジニアをやっている カピバラ です。最近本名で呼ばれなくなってきました。 今回は、弊社プロダクトである O:der Table のバックエンド開発のブランチフローの話をします。 対象読者は社内のエンジニアですが、せっかくなのでテックブログにします。 ブランチ運用を振り返ります O:der Table の開発をもともとGitFlowでやってきたところ、1年前くらいにGitFeatureFlow（風）ブランチ運用を導入しました。 なかなかよい感じに運用できてきたのですが、最近社内でちらほらと課題感も耳にします。 運用1周年のよいタイミングかなと思い、そのあたりの経緯について書きます。 GitFlow 1年前くらいまではこのブランチフローに
GitFlowは使わない！シンプルな「GitFeatureFlow」を紹介します - ぐるなびをちょっと良くするエンジニアブログ
こんにちは！テニスはじめました、小山です。開発部門でウエディンググループのリーダーをやっています。 今回は私が考えた新しいGitのブランチモデル「GitFeatureFlow」についてお伝えしたいと思います。 GitFeatureFlowとは Gitを使った開発をより快適にするため、GitFlow,GitHubFlow,GitLabFlowではない、新しいGitのブランチモデル「GitFeatureFlow」を考えました。 Gitを利用して開発を行う場合、Gitのブランチモデルをどうすべきか悩むことが多いかと思います。私自身もこの悩みに直面しました。既存のブランチモデルでは問題が解決できなかったので、GitFeatureFlowという新しいブランチモデルを考え、ウェディンググループに導入。今では快適にGit開発を行っています。 GitFeatureFlowで使う主なブランチはこの3つです。
Go言語のFunctional Option Pattern - Qiita
オプション パッケージを作る際、柔軟性を持たせるためにオプションを持たせたい時がしばしばあります。 しかしオプションは知っての通り設定しないことが少なくありません。 単にコンストラクタに並べるようでは無用な複雑さをはらむことになります。 JavaなどではOptional Parameterなどのように、デフォルト値が指定できる機能があります。 機能の厳選されたgo言語ではそのような機能はありませんが、 "Self Referential Functions Design"というテクニックがあり、 それについての記事がRob Pike氏の記事を筆頭にいくつか説明されています。 オプションと相性が非常に良いため、合わせて"Functional Option Pattern"とも呼ばれています。 Dave Cheney氏の記事を参考におおまかに説明したいと思います。 様々な解決策 あるServe
Functional options for friendly APIs | Dave Cheney
What follows is the text of my presentation, Functional options for friendly APIs that I gave at dotGo this year. It has been edited slightly for readability. I want to thank Kelsey Hightower, Bill Kennedy, Jeremy Saenz, and Brian Ketelsen, for their assistance in preparing this talk. I want to begin my talk with a story. It is late 2014, your company is launching a revolutionary new distributed s
「ChatGPTの出現でプログラマーの需要はむしろ増えてくる」 ひろゆき氏が説く、これからのエンジニアリングのかたち
技育祭は「技術者を育てる」ことを目的としたエンジニアを目指す学生のための日本最大のオンラインカンファレンスです。「技育祭2023【春】」に登壇したのは、元2ちゃんねる管理人のひろゆき氏。エンジニアを目指す学生からの質問に答えました。全5回。2回目は、「ChatGPT」がエンジニアに与える影響について。前回はこちら。 酒を飲んでコードを書ける気はしない ひろゆき氏（以下、ひろゆき）：（コメントを見て）「飲酒しながらプログラミングしているんですけど、ひろゆきさんもされていますか？」ということなんですけど、僕、酒を飲んでプログラムを書いたことはたぶんないですね。 司会者：へぇ、意外ですね。なんでですか？ ひろゆき：もともと、家であまり酒を飲まないのもあるんですけど、脳のバッファー量って超重要じゃないですか。 例えば、コードをバーッと書いている時に、話しかけられたり電話がかかってきたりすると、脳の
コード品質はやはりビジネスに影響を与える - mtx2s’s blog
私たちソフトウェアエンジニアは、コード品質についてしばしば論ずるけれども、ではコード品質の良し悪しがどれほどビジネスに影響するのかと問われると、回答に窮する。只々、「コード品質が悪いと変更により多くの時間がかかります」だとか、「欠陥の修正に追われて開発時間が奪われます」だとか、個人の経験やエンジニア的一般論に頼った定性的な説明に終始するしかない。ソフトウェアを繰り返し変更する頻度が高いほど、コード品質が開発時間に影響を与えるのは確かにそのとおりだと思えるが、はたしてそれは、どれほどのインパクトなのだろうか。 2022年の研究論文 "Code Red: The Business Impact of Code Quality – A Quantitative Study of 39 Proprietary Production Codebases" では、コード品質がビジネスに与えるインパクト
読みやすいコードを書くためのガイドライン
はじめに 長くシステム開発に携わっていると、最初は素早く開発することができたけども、今では新たな機能を付け加えるのに、多くの時間を費やすようになったという話をよく聞きます。 初めはシンプルだったソースコードも年月が過ぎていくなかで、機能追加やバグ修正、変更を行なっていくと、コードが非常に複雑化していき、開発者が修正するコストの増加やコード品質の低下につながります。設計の良くないコードや複雑化したコードは、同じ処理をするのにも余計にコードを書く必要がでてくるからです。 今回は、コードを複雑化して品質を低下させないために、普段意識しているソフトウェア設計や手法を紹介していきたいと思います。色々書いていますが、結果的にクリーンアーキテクチャー成分が多めになってしまいました。 「読みやすいコード」が持つメリット コードを読みやすくすることは開発全体に好影響を与え、特に以下の点において最大限効果を発
Reactの公式ドキュメントを読む
2023/3に正式リニューアルされたreactのドキュメントを改めて読む。 https://react.dev/learn のLEARN REACTの部分で気になったところをまとめていく。 Describing the UI Your First Component 特になし Importing and Exporting Components componentをdefault exportとnamed exportどっちにするかは、チームで統一する場合もあるが、特に公式でどちらかを推してるわけではない。 Writing Markup with JSX JSXの利点: ロジックにマークアップをsyncできる。マークアップ上のコンポーネントごとにロジックを分離できる HTMLをJSXに変換してくれる便利ツールがある。class -> classNameとかの属性名変換もやってくれる Jav
ドメインベースの開発体制への移行 - 10X Product Blog
CTOのishkawaです。 10Xの開発チームは、4月1日からドメインベースの開発体制に移行しました。 ここで言うドメインとは、注文やピックパックや配達などの業務領域を指す言葉です。ドメインベースの開発体制に移行するということは、開発チームの分割単位をドメインにして、各ドメインを担当する開発チームが決まっている状態にするということです。 組織移行の背景 これまでは、開発チームの分割単位をパートナー企業としてきました。各パートナー企業を担当する開発が決まっているため、パートナー企業の目線でプロダクトの未熟な面があっても迅速に対応できますし、それによって事業機会を掴めたケースもありました。 一方で、プロダクトを開発運用する中で以下の課題も出てきました。 認知コストの増大: Stailerは多様なドメインを抱えるプロダクトなので、すべてのドメインを理解するのは至難の業です。一方で、パートナー企
コードを書き続けるためにやってること
この記事は 6 年前に書いた記事を更新したものです プログラミングの生産性を上げるには - Cside::Private とても面白かったのでマネしてみた。人それぞれあると思うので自分のスタイルを。 といっても、かなり不真面目なので参考にはならないと思う。 1. README.rst を書く まず最初に何がしたいのか、どんなことをしたいのかを書く 概要、ゴール、実装方法、使用ライブラリ、TODO などを書いていく そして README.rst に擬似コードを書き始める コンパイルが通る必要は無い コメントもガンガン書いていく とにかく issues とか使わず全て README.rst に書いていく 一通り出来てきたら GitHub Issues にタスクを移す 2. 擬似コードでプロトを書く コードを書いてみないと分からない事が多いのでまずはコードを書く 自分が一番かける Erlang
自動E2Eテストを活用した デプロイフロー改善
MagicPodミートアップの発表スライドです。 https://trident-qa.connpass.com/event/278843/
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Design Doc の書き方 / How to Write a Design Doc (Ja ver.)
失敗から学ぶ 技術的負債との正しい歩き方 / learn from predecessors
新規開発を始めるときにやるべきこと
Value Points – Estimating the relative value of a User Story