問い合わせ率が3年間で半分になったカンムは現在、Visaプリペイドカードの「バンドルカード」と手元の資産形成に活用できるクレカの「Pool」の2つの事業をやっています。今回はバンドルカードのお話です。 2022年末に過去の問い合わせ率を集計したところ、一番多かった時期と比べると問い合わせ率が半分になってました。（問い合わせ率 = 問い合わせ数 / 稼働会員数） 良きタイミングなので頑張ってきたことを振り返ってみます。
仕事力と技術力と不安に関する雑文
先日「育児など家庭の色々があって自分の時間が確保できなくなった。技術力を高めるための勉強ができなくて不安。」みたいな話を聞いた この悩みの直接的な解決方法としては先人の様々な体験談および対策みたいなものが世に出回っているからご家庭の状況に応じて参照すればいい思う 子育てと開発を両立するコツは「無理をしないこと」。パパ／ママエンジニアの働き方とは 子育てを支える技術 ─ フルスタックお父さんとエンジニアとしての成長を両立させるには ITエンジニアと子育てと勉強と それよりも「技術力を高めるための勉強ができなくて不安」という点が個人的には気になった 技術力とは何か？技術力が高くないとなぜ不安なのか？みたいな話 技術力は特に明確な定義があるわけではない 例えば著名なOSSにコミットしているとか低レイヤーのプロトコルやインフラをバリバリ実装してるとか競プロで上位勢だとか、挙げ始めたらキリがなく、そ
【資料公開】マネージャーのしごと
みなさんこんにちは。@ryuzeeです。 2022年12月9日に行われたイベント「Developers CAREER Boost」の登壇資料を公開します。 今回は、「マネージャー」と名のつく職種を分類して、それぞれの職務や定義を確認した上で、有効なマネージャーであるにはどうしたらよいかを整理してみました。 資料を作るにあたって、過去の日記を読み返したり記憶を思い起こしたりして、当時の活動や出来事、悩みを整理してみたのですが、自分はやっぱりマネージャーに向いていないし志向していないことを再確認できました（笑）。 全員がマネージャーにならなければいけないなんてことはなく、自分が日々楽しく過ごせるキャリアを選択すればいいと思いますが、資料が少しでも役に立てばうれしい限りです。 本セッションで紹介した書籍は以下のとおりです。 エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーに
自己肯定感の話 ①
もうずいぶん昔のことです。 当時、すでに八十歳を超えていた母方の祖母とふたりきりで、ロンドンを旅したことがあります。 何故そんなことになったかというと、ある年のお正月、皆で祖母宅に集まったとき、私がイギリスで過ごした日々の思い出話を親戚たちに求められたのです。 それで問われるままにあれこれ語っていたら、祖母が「一生に一度でいいからイギリスに行きたい。お姫様のような旅がしたい」と言い始め、それを聞いた伯父たちが、それなら資金を出すから私が連れていってはどうか、と言い出したのだったと思います。 高齢者というのはたいてい何かしら気難しいところがあるものですが、祖母も典型的な「プライドが高すぎるめんどくさい年寄り」であり、既にまあまあ認知症も進んでおり、扱いの大変さを知っている母や叔母は強く反対しました。 祖母が海外で体調を崩したりしたら大変、というのが反対の理由でしたが、今思えばむしろ、ひとりで
わかりやすいシステム構成図の書き方 - Qiita
わかりにくいシステム構成図とは こんなシステム構成図を書いてないでしょうか？ このシステム構成図のわかりにくい点が３つあります。それは 製品名は書いてあるが「役割」が書いていない データと処理が区別できない データの流れと制御の流れが区別できない の３つです。 わかりやすいシステム構成図 これら３つのわかりにくい点を改善したわかりやすいシステム構成図が↓です ポイントを解説していきます ポイント1. 製品名称ではなく「役割」を書く システム構成図には製品名称ではなくシステムコンポーネントの「役割」を書きます。 役割とは、例えば〇〇データや〇〇処理といったことであり、それを読むだけでシステムの動きを理解できる文字列です。役割をかかずに製品名称のみを書いてしまうと、その製品を知らない人が見たときに理解できません。例えば「Cloud Pub/Sub」という製品はGCPというパブリッククラウドの分
10年エンジニアリングマネージャーをやって気づいた4つの大事なポイント 【EMはもっと自由でいい】 - MonotaRO Tech Blog
はじめに ※この記事はEngineering Manager Advent Calendar の22日目の記事になります。前日はmtx2sさんの技術的負債に対するマネジメントの記事でした。個人的には「負債上限」「負債ベースライン」の考え方良かったです。 こんにちは。モノタロウでエンジニア組織のマネージャーをしております普川(@taipuka0)です。 自分は前職から通算10年以上してエンジニアリングマネージャーを続けた後、現在モノタロウでは8人のEMのみなさんと日々ソフトウェア・エンジニアリングの現場でマネージャーとして課題解決に向き合っています。これまで色々な壁にあたり、試行錯誤を繰り返して来ました。EMの難しさを痛感したことも多々ありました。 なぜEMが難しいのか？その一つとして、エンジニアからEMにジョブチェンジした際のギャップというのがあると思います。同じチーム、現場にいたとしても
MVP（Minimum Viable Product）の意味を理解する。そして、なぜ私はEarliest Testable / Usable / Lovableを好むのか。 | ANKR DESIGN | デザインリサーチ・プロトタイピング・サービスデザイン
数年前、私はこんな絵を書いて、アジャイル開発やリーン開発のついての様々なプレゼンで用いた。 そこから、この絵は急速に広まっていった！記事、プレゼン、さらには本（Jeff Pattonの”User Story Mapping”という素晴らしい読み物なのだが）にまで至る所で姿を見せた。多くの人がこの絵は反復型開発、リーンスタートアップ、MVP(minimum viable product)の本質をよく捉えていると伝えてくれた。しかし、元の文脈から切り離して物事を捉える際にはごく自然なことであるのだが、この絵を誤解している人がいる。簡素化しすぎだと非難する人もいる。（正しい指摘である） この絵はあくまで比喩である。実際の車の開発の話ではなく、車を比喩とした一般的なプロダクトの開発の話なのである。 とにかく、これらのバズからこの考えの背景を話す時だと判断したのだ。 １つ目の例：not like
仕様書の参考例と、こんな内容を仕様書に最低書くといいというお話｜田辺めぐみ
よく、仕様書を書いていなくて、書いてみたいけど、具体的な仕様書がネット上に落ちてなくってこまってるって相談を受けるので 「仕様書の記載内容のイメージ」を作りました！ ※前提として「現在仕様書を書いていない、自社開発のMVP検証前後のフェーズのスタートアップ向け」に書いています。PMが仕様書、エンジニアがDesign Docを書く分担です。 ついでに、システム開発の基礎である「システム開発のV字モデルをベースにした設計書の紹介」も含めてまとめてみましたー！ 大規模開発に使われたり、古くからあるフレームワークなので、スタートアップの方だと、システム開発のV字モデルの概念やそれにあわせた成果物を知らない人が多いけど、「要件定義書」と「設計書」を全てドキュメント化するとどうなるかを理解した上で、「仕様書」として情報を削る方が、考慮漏れ防止やエンジニアがやっている設計内容の理解につながるので、全体を
未知の世界に飛び込め
大阪市立南高校という高校が今年度でなくなる。他の二つの市立高と統合されて別の高校になるのである。独特の教育をしていた高校... 世界は変わっているぞ、日本ヤバイぞ、君たちの肩に掛かっているぞ、頑張れ、という話。言っている事に異論はないが、これを高校生に言って刺さるのかな、と思った。日本の未来なんて大きすぎて若者には遠すぎやしないか。そういうのが自分の肩に乗っていると錯覚できるようになるのは中年になってからじゃないのかな、と思った。 先日、大学生になった友人のご子息の相談に乗って話をする機会があった。インド系アメリカ人で、地元の進学校として割と名前の通った高校に行き、遠くの大学に進んだ。父である僕の友人の影響もあってか、Minecraftのモッド作りに精を出して子供向けプログラミング活動の運営に関わっていた事もあるし、Kubernetesを触った事もあるらしいし、高校生の時はRobotics
【2021年ベストバイ】ユナイテッドアローズ 栗野宏文が今年買って良かったモノ
FASHIONSNAP（以下、F）：「ウィリー・スミス（WILLI SMITH）」は1980年代のデザイナーですよね。10年近くファッション業界にいますが、正直名前を聞いたことがある程度です。どんな人なのでしょうか？ 栗野宏文（以下、栗野）：1980年代にニューヨークに登場した最初のアフリカ系アメリカ人デザイナーです。当時はジェフリー・バンクス（Jeffrey Banks）など他にも黒人デザイナーはいましたが、彼らはトラッドだった。その点ウィリー・スミスのようにポップですごくクリエイティブなものを作る黒人デザイナーは他にいなかったんです。 F：これは女性も似合いそうなロング丈シャツですね。 栗野：パジャマみたいな雰囲気もありますが、裾はシャツテール、袖はガウンのようなディテールになっています。僕がまだビームス（BEAMS）にいたときにワンシーズンだけ仕入れたことがあったんです。ところがいき
リモートワークのための質問力向上研修を実施しました - Classi開発者ブログ
この記事は Classi developers Advent Calendar 2021 の 7日目の記事です。 こんにちは。顧客サポート基盤チーム兼、技術戦略室にてエンジニアをしています、中島です。 みなさんは、日々仕事をする上で必須である「誰かに質問をする」という行為について、自信を持って適切に行うことはできているでしょうか？ 先月弊社では外部講師である、株式会社フィッシャーデータのあんちべさん をお招きし、質問力向上のための研修を実施しました。今回はこの研修を実施するに至った背景、研修内容を少しお見せするのと、社内の反響をお伝えします。 質問力を向上しよう！と至った背景 弊社は2020年2月頃よりリモートワークへの移行を行い、1年半以上が経過しました。リモートワークのお困りごととして一般的にもよく聞かれる、コミュニケーションについての課題を見聞きするようになってきました。 （ちなみに
なぜ、ソフトウェアプロジェクトは人数を増やしても上手くいかないのか - Qiita
はじめに ソフトウェアプロジェクトには不思議な性質があります。現状のスケジュールに課題を感じて、短くするために人員を投下しても、なかなか思い通りに短くならない。それどころか悪化してしまうことがあります。場合によってはプロジェクト自体が破綻して失敗してしまうことすらあります。 今回は、このようなソフトウェアプロジェクトに潜む直感に反する性質を数理的なモデルを介して理解していく試みです。ある種の思考実験としてお楽しみください。 宣伝 Qiitaさんとコラボ企画でアドベントカレンダーをつくりました。 DXをめちゃくちゃ改善した話を募集しています。 https://qiita.com/advent-calendar/2021/dx-improvement 10人の妊婦がいても1ヶ月で一人の子供は生まれない これは誰かの技術力やプロジェクトマネジメント力に欠陥があるのではなく、「人月の神話」で有名な
20 Things I've Learned in my 20 Years as a Software Engineer
Hard disagree with most of the 20 items. 1. Writing software is difficult, tedious and needs real work. No silver bullet libraries, no methodology, no framework, no IOT, no amount of unit tests will get the work done faster. 2. Developers collect tools, libraries and pet technologies and make projects go over their time and budget by doing it. 3. Code should encapsulate algorithms and not be struc
イーロン・マスクが特許をオープンソース化した理由がブっ飛んでてステキだった
数年前、イーロン・マスク率いるテスラ社がかかえていた電気自動車関連の特許を公開してオープンソース化した。ライバル他社に「この特許技術を使いたければ、どうぞご自由に」と公開してしまったのだ。ジャーナリストや専門家が信じられなくて、いろいろと分析していた。 「あのイーロン・マスクのやることだし信じたらダメだ。絶対テスラに利点があるに違いない。」 「特許がゴミ同然だから公開したのでは？」 「ライバルを出し抜くためにやってるに決まってる」 という感じだった。その後、年数が経ってそうしたテスラだけの利点とか技術的欠陥を見つけた人はいない。結局は「全人類のイノベーションを加速すること」これだけが理由だった。 ちょっとブッ飛んだ発想で理解するには数々のインタビューでイーロン・マスクが語る内容を連続して観ていく必要があった。なのでこの件に関するそれぞれのインタビュー発言を抜粋して意訳した。 インタビューワ
「これぐらいのことはできていて」は勝手な期待 観察・考察・選択のサイクルで相手の力を引き出す「誰も嫌な思いをしない変化」
「Scrum Fest Osaka」はスクラムの初心者からエキスパート、ユーザー企業から開発企業、立場の異なる様々な人々が集まる学びの場です。KEYNOTEで登壇したのは、楽天グループ株式会社の椎葉氏。「誰も嫌な思いをしない変化」をタイトルに、自身が開発グループのサポートをしたときの取り組みについて話しました。全3回。2回目は、誰も嫌な思いをしない変化のために実践したことについて。前回はこちらから。 誰も嫌な思いをしない変化のために「相手に期待しない」 椎葉光行氏：その頃の自分と、今の自分でいろいろと変わったとは思うんですけど、大きくこの2つかなと思います。 「相手に期待をしなくなった」それから「相手の気持ちを考えなくなった」です。 言葉にすると、人としてどうなのという感じがしますけど（笑）、でもこの2つが自分の中でけっこう大きな軸になっています。 何年か前に、娘が「2桁のかけ算教えて」っ
国政選挙で勝つということ - やしお
自民党総裁選と衆院選を控えて、最大野党の立憲民主党も政策アピールに入っていて、その政策が刺さらない、粒度が変、センスがない、安保も経済もない、と左右両サイドからネットで叩かれる光景をよく見かけて、ちょっと思ったことのメモ。 選挙戦 「選挙で勝つ」には「票をたくさん集める」が必要で、その票には大きく分けて、投票時点での世の中の空気感や、党や候補者のイメージに左右されて入る浮動票と、特定の党や個人に固定的に投票される組織票とがある。投票率が高ければ浮動票の比率も高まり「風が吹く」と言われるような大勝／大敗が起こり得るし、低ければ組織票の比重が大きくなる。 浮動票と組織票には、それぞれ党自体の方針で確保されるものと、候補者・国会議員や地方組織・地方議員の働きによるものとがある。 この4つのエリアそれぞれで対応が必要になる。（ただ各エリアで確保できても調和が取れていない／方針がちぐはぐだと政権交代
高頻度は問題を容易にする - Martin Fowler's Bliki (ja)
https://martinfowler.com/bliki/FrequencyReducesDifficulty.html 私が気に入っている引用の一つに「もしそれが痛みを伴うのであれば、さらに頻繁にそれを行え」という引用がある。 この言葉は、表面的には馬鹿げたことに見えるという幸せな性質も持っているが、深く探れば価値のあることがわかる。 このことを説明するための例示できる文脈は、統合だ。 ほとんどのプログラマーは、自分の仕事を他の人と統合することは苛立たしくてつらい経験であることを早い段階で学ぶ。 そのため、自然な人間の反応として、できるだけ統合を先延ばしにしようとする。 上記グラフのように、その行動を起こすまでにかかる時間と、その行動に伴う痛みに指数関数的な関係がある場合、その行動をより頻繁に行うと、痛みを大幅に軽減できる。 そして、これが継続的インテグレーションで起こることだ。毎日
アジャイルな見積もりを理解する「コース定数」という概念 - だいくしー(@daiksy)のはてなブログ
アジャイル開発をはじめて体験すると、いろいろな考え方を身につけるために苦労をすることがあります。 特に、相対見積もりや、ベロシティによる経験主義的な見通しの取り方について、実際に経験せずに理解するのは難しいようです。 そこで今日は、日常生活の中で馴染みの深い考え方を使って、説明を試みてみたいと思います。 「コース定数」でアジャイルな見積もりを考えてみる 国民的な娯楽である登山をやられる人なら誰もが知っている「コース定数」という考え方があります。みなさんもご存知かと思いますが、簡単に解説します。 山は、事前の計画がとても重要でありつつも、実際に登ってみないとコースの状態や、自分の体力がその山に適しているのかがわかりづらい遊びです。そういう意味では、経験主義的なアプローチが必要なソフトウェア開発に似ているとも言えます。 交通機関やレスキューの体制が整備されている街中と違い、山は自分の体がすべて
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Jason Warnerとマイクロサービス - 西尾泰和のScrapbox
The three great virtues are important
