サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
パリ五輪
note.com/yfuka86
割と初期(茶〜水くらいのころ)この記事の150問・典型90問(最後の1問のFPSパート以外)を埋めました。特に典型は2周しました。 その後鉄則も復習的な感じで全部、EducationalDPも全部、PASTを8回分くらい埋めました。 https://atcoder.jp/contests/typical90 https://atcoder.jp/contests/tessoku-book https://atcoder.jp/contests/dp hamamuさん、社会人になってから始めた勢の先輩でもありますし、ライブラリや問題を解く部分以外での向き合い方など色変記事の中でもとりわけ参考にさせていただきました。 意識していることなどコンテストに出られるだけ出る発熱や遅刻以外のタイミングでは基本ratedで、参加できるコンテストは全部出ていました。解けなかった問題+1問くらいも(難易度によ
自己紹介AppBrewで代表(兼新規事業リード)を務めている深澤です。https://appbrew.io https://initial.inc/companies/A-17314 clubhouseが流行った時にクローンサービスを作っていました。 https://note.com/yfuka86/n/n28bae17d6dcd 解決したい課題=リモートコミュニケーションの悩みコロナで急速にリモート化がすすみ、弊社AppBrewも50人ほどのフルタイムスタッフのほとんどがリモート勤務になりました。 僕自身含め、多くのスタッフが既存ツールを使いながら変化に適応する中で、形としては体裁を保ちつつも、やはり解決しきれていない問題があると感じるようになりました。それは、コミュニケーションハードルが高くなることです。 多くの会社はSlack/Zoom(あるいはその代替ツール)の構成で、それぞれ非同
ひさびさに衝撃を受けたサービスなので、感じたことをメモとして残しておかねばなるまいと思い、なぐり書きをした。 ほとんど直観的な分析で裏取り不十分な部分もあると思うので、指摘など歓迎したい。 teleful(自社でクローンとして作ってリリースしたが伸びなかったサービス)から得た知見も含む。 ーーーーーーーーーーーーーーーーーー 追記:2021/6/8 ピークが過ぎてしばらく経って思ったことの追記。 ・想定ほど短期では伸びなかった(ごめんなさい)。初期の加熱感は消え、KOLも相性のいい一部の人しかおらず、ユーザー側としてもコンテンツを求めにくるには中身が薄すぎる。一方、個人的に使い続けているのはこのプロダクト特有のソーシャルグラフを得られたからで、ゆるく(気分次第で)集まれる価値というのは未だに強く感じている。 ・獲得と定着は完全に別物で、定着を指数関数的に伸ばすにはより「自然」なバイラルが必
これはなにAppBrewでは、「給与の公開制度」と「360度評価制度」を導入しています。 人件費を聖域化せず、オープンに各自の能力・価値やそれに見合う報酬について議論できるようにという意図を込めて運用しています。 360度評価制度は、専用のシステムを作って(代表自身がコーディングとメンテをしています)業務フィードバックを中心に周囲の人全員から評価がなされ、内容は公開されます。 他社と比較しても、シビアな制度になっていると思います。ハイパフォーマーにとってはやりやすい環境である一方で、全ての人が高い評価を貰えるわけではなく、どうしても厳しく映ってしまう一面はあります。 そういった背景があり、評価制度は厳しく運用する一方で、キャリア価値を高めていく成長のチャンスは全員に均しくあることを伝えたいと考え、社内向けに公開した資料なのですが、反響が大きかったので一般公開すべく編集しました。 ほぼそのま
本日発表したリリースの通り、 ミッション/CIの制定と、11億円の資金調達を実施した。 ミッションについて「個性を解放するものづくりを」 個人としても会社としてもかなり悩んだが、 思いの外奇を衒うこともなく、ストンと落ち着くところに落ち着いた。 非常に抽象的だが、言いたいことはシンプルで、 間違いなく人類史の転換点であろうこの21世紀の時代に、 徹底的に「個=エンドユーザー」や「ニーズ=時代の要請」と向き合い、 ヒューマニズムに寄り添いながら、 頑固なまでにこだわってものづくりをし続けたい。ということである。 これは個人的なエゴでもあるが、 そういう意志があったと言語化して改めて気づいた。 CIについてCIに関しても、ミッションが非常に抽象的な中、かなり多くの案を出していただいて、紆余曲折ありこの形に落ち着いた。 公式の説明ではなく、作成いただく時にそういう指示をしたわけでもないのだが、個
筆者には専門的なバックグラウンドはないが、会社を経営している中であらためてデータを日常的に意思決定に活用することの重要性を痛感し学習してきて、社内への普及活動もしている。 かなり煽り的なタイトルになってしまったが、もとは、弊社でデータに関わるツールを普及しようとしていて、 「そもそもなんでデータ・ツール(SQL等)を学ぶ必要があるのか?」 「そこはエンジニアがやった方が効率がいいのでは」 「ツールの学習は手段であって、データを活用した業務が目的なのに、SQLの学習に時間をかけるのは手段の目的化ではないか?」 などの声があり、あらためて考え直す契機になったので、書くことにした。 データと意思決定の欠かせない両輪経営は、「企業体として(個人であっても同様)目標に向かい、継続的・計画的に、現在ある資源を最大限に活用する意思決定を行っていくこと」からなる。言い換えれば、打てる手数(限られた時間あた
今から3年以上前、2016年2月に個人開発者から法人を設立、シード資金を投資していただき、共同創業者の松井と高橋(当時)と3人で、様々な事業にトライし潰しを繰り返しました。1年ほど経った2017年の1月に現在の主要事業であるLIPSのリリースに至りました。 早いもので、それからもう2年が経ちました。 LIPSはTVCMなども実施させていただき、多くのユーザーさんを抱えるプラットフォームになり、伸び続けています。 その間、30人以上の方に入社いただきました。大学の同期や後輩のエンジニアがそのまま入ってくれたり、自分より二回り以上経験豊富なビジネスメンバーが来てくれたり、当時では考えられないくらいの精鋭のチームが出来てきました。 一方で、一般に言われるような組織の壁を感じるタイミングも出てきました。30人を超えると、誰か1人が全員とコミュニケーションを取ってどうこうという訳にもいかなくなってき
ユーザー数の変動をいかにして記述すべきかの簡易シミュレーションです。 LIPSの数値などは使っていませんが(当然)、特にインターネットのコンシューマー向けプロダクトに関してはほぼほぼこんな感じで抽象化できるはずで、こういった感覚わからずに運営するのは危険だと思います。ただし、短期で実践的に役立つかというとかなり微妙です。 また抽象論は、具体を経験した人がそれを体系的に蓄える手段と思っているので、プロダクトリリース経験・グロース経験がある方は特におすすめです。 筆者は初等数学しかわかりませんので、間違いはご容赦・ご指摘ください。 基本はロジスティック方程式の離散的な記述をベースにしています。 class SimulationParams: def __init__(self, epoch, market_size, initial_n, acquisition, increase_rate,
このページを最初にブックマークしてみませんか?
『Yuta Fukazawa|note』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く