サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
大谷翔平
www.blockchainengineer.tokyo
YOUTRUST社長の岩崎さんが無用な論点の話を上げていました。とても良かったので引用して記事を書かせていただきます。 「無用な論点を作らない」というのを日頃意識しています。 コンサルの方はクライアント先に行く際、タクシーはオフィスの少し手前につけるそうです。更に、往訪時はブランド物を身に着けない、という暗黙の?ルールもあるそうです。 何故ならば、発注元社員からすると「贅沢にしてるな」と思われて、仕事と直接関係のないところで感情を逆撫でしてしまい、成果を出すためにいらぬ向かい風を作ってしまう可能性があるからだそうです。 これはコンサルでなくとも学ぶべき事例だと思っていて、仕事をするうえで必要のない「無用な論点を作らない」というのは非常に重要だと思います。 服装やタクシーのみならず、表情だったり話し方だったり、挨拶一つとっても論点になることがあります。 そんなときに「無用な論点を作らない」と
事業開発は、企業が長期的な成功を収めるために必要です。事業開発においては、PL(損益計算書)型とBS(貸借対照表)型の二つの異なる考え方があると考えています。PL型は売上や利益の追求に焦点を当て、BS型は将来のPLを見越して資産を積み上げることに重点を置いています。この記事では、私の経験から、これら二つのアプローチの特徴、利点、そして潜在的な落とし穴について詳しく記します。 売上や利益を追求するPL型の事業開発 PL型事業開発の落とし穴 短期的な成長を追ってしまう 製品・組織が発展しない場合がある BS型の事業開発 BS型の事業開発とは BS型の事業開発は長期的に有益になる まとめ 売上や利益を追求するPL型の事業開発 PL型の事業開発は、短期的な成果に注目し、売上や利益の最大化を目指します。このアプローチは市場での迅速な対応や競争上の優位性を確保する上で有効です。一方で、短期的な目標に集
9月にプロダクトマネージャーをやめ、エンタープライズ部の部長になってから3ヶ月が経ちました。エンタープライズ部は従業員1000人以上の企業向けにサービス提供する部として発足しました。戦略、業務、組織を整備してきましたが、本日は組織について記しておこうと思います。 組織設計の考え方 組織は基本的に分割された単位で1つの目標を追えるようにすることがシンプルになります。システムアーキテクチャ設計では「単一責任の原則」という言葉があり、1つのコンポーネントに1つの役割を持たせるべきという考え方です。組織作りもこれに似ていて、一つの責務だけを負うことを意識しました。 着任時には私以外にアカウントマネージャー5人、プリセールス1人が専任、カスタマーサクセス、マーケティングとインサイドセールスがそれぞれ兼務で1人ずついる状態でした。 9人は少し1つのチームとしては多いですし役割も入り乱れています。一方で
9月から異動でバクラクのプロダクトマネージャーの職種をおりることとなりました。異動先は大企業向けビジネスを推進するエンタープライズ部を立ち上げてそこの部長になります。エンタープライズ向けの機能開発マネジメントはしていたものの、ビジネス全般の管掌となり立ち位置が大きく変わりました。 もともとエンジニアからプロダクトマネージャーになり、エンジニアリングマネージャーも務め、と開発畑のキャリアを歩んできていたので晴天の霹靂だったのですが、意外とビジネス職になっても役立つ経験が多いので書いてみます。 着任1ヶ月で行った現状把握 メンバー理解を深める(組織) 常に発見を議論する機会を作る(業務) 事業をプロダクトとして捉えて構造化する(戦略) 羅針盤(アウトカムとロードマップ)を作る おわりに 着任1ヶ月で行った現状把握 まず開発職からビジネス職への異動ということで状況理解から始めました。理解する構造
受取請求書処理SaaSのプロダクトマネージャーとして、この1年以上プロダクトのインボイス制度対応を行ってきました。 請求書の受け取り、仕訳処理、支払処理などを行うB2BSaaSだったのですが、インボイス制度自体が非常に複雑で対応方法に非常に頭を悩まされてきました。 法制度自体が過度に複雑なため、業務もプロダクトの設計もユーザー体験も複雑にならざるを得ない点を感じました。 インボイス制度は増税観点で批判されることも多いのですが、業務自体の生産性やエンジニアの開発生産性にも影響を及ぼすと感じ、今回は法制度の複雑性に焦点を当てていきます。政治的な内容はあまり書くつもりはないのですが、昨今あまりに業務をおざなりにして法制度が作られることが気になるので課題意識を書いてみたいと思います。 インボイス制度とは インボイス制度によって業務負担が増える 適格請求書を逐一確認する業務負担が増える 適格請求書か
今年の4月にITストラテジストという試験を受けて合格しました。合格率15%のそこそこ難関試験という区分でしたが学習戦略がよかったのだと思います。今後受ける人や資格受験者のために体験記を記しておきます。 受験のきっかけと試験の選定 学習戦略 学習に用いた教材 学習内容 午前2(合格率90%) 学習時間 1~2時間 午前1(合格率73%) 学習時間 4~6時間 午後1(合格率66.4%) 学習時間 20時間ほど 午後2(合格率31%) 学習時間 40時間以上 当日 感想 受験のきっかけと試験の選定 ふと新年何か目標を立てようと思い受験に至りました。体系的に学習する機会があまり最近持ててないので資格でも取ってみようと安易に思いました。 試験の選定基準として 数ヶ月で受験のきっかけが来るもの(大体新年に立てる目標は半年も経つと忘れているので) 直近の業務に関わるもの 知識を詰める学習時間が少なくて
昨日、ITストラテジストという試験を受けて、ChatGPTを用いて勉強していました。 受けたITストラテジストという試験 ChatGPTに解答を添削してもらう勉強方法 ChatGPTで対応できることと対応できないこと まとめ 受けたITストラテジストという試験 私が受けたのはITストラテジストという、IPAが行う情報処理技術者試験のうち、高度試験と呼ばれる分類になります。IT戦略の立案という試験で、鬼門と呼ばれる午後Ⅱ試験では、2時間でおおよそ2000文字程度の論述を行う必要があります。 論述の問題を具体的に示すと、IPAによる2021年の過去問題ではこのように、「あなたの経験に基づいて、DXを実現する新サービス企画を書け」という内容になっています。 で、公式の解答例はというと実は出題要旨と採点講評くらいしかなく、解答例がわかりません。これはなかなか対策しづらいです。 ChatGPTに解答
「開発優先度はどのようにつけますか?」という質問を受けることが増えました。おそらく多くのプロダクトマネージャーがよく悩んでいる質問なのだと思います。 プロダクトマネージャーは、カスタマーニーズを満たすために製品を改善する必要がありますが、同時にビジネス目標を達成する必要があります。どちらを優先するかについて常に判断を迫られています。 あるべき姿、理想の姿を目指すために施策を使いたいが、売上が上がるところを目指したいので「今」やる必要がある、というシーンにいつもいつも挟まれています。この記事では、その優先度判断の一助として私が行っている方法を記してみます。 基本軸はプロダクトビジョンとビジネスインパクト 水撒きホース製品の例で優先度を考えてみる ロマンとそろばん さいごに 基本軸はプロダクトビジョンとビジネスインパクト 過去の記事で、開発の優先順位付を行うためのフレームワークを紹介しました。
私はかれこれ6年、高級キーボードのHHKB(Happy Hacking Keyboard)ユーザーです。分離型キーボードを使ったこともありますが、持ち運びの便利さと打鍵の心地よさからHHKBをメインに利用しています。 PFU キーボード HHKB Professional HYBRID Type-S 日本語配列/墨 HHKBAmazon 2年前、蓋の閉まりが緩いままジュースのペットボトルをカバンに入れてしまいました。その中にはHHKBが。昨今の精密機械では、防水が施されていることは多いですが、糖分は内部基盤の腐食を進めてしまい、大体の場合壊れます。 乾かし、電池も入れ替えて試したところ、キーを1度押すと複数回入力されます。「HHKB」と押すと「HHHHKKBB」と表示。これは使うのが非常に辛い。糖分が粘着の問題なのか、基盤の腐食の問題なのか。粘着の問題ならクリーニングでなんとかなりますが腐
タイトルは、ポール・グレアム氏(Yコンビネーター)の「メイカー(作り手)のスケジュールとマネージャーのスケジュール」(Maker's Schedule, Manager's Schedule) からの引用です。 マネージャーは多くのミーティングをこなすなど、1時間単位でタスクにあたりますが、エンジニア(プログラマ)は最低でもまとまった半日単位の時間を作業に必要とする、と書かれています。 paulgraham.com 日本語訳 note.com エンジニア上がりのプロダクトマネージャーとして開発もプロダクトマネジメントも並行してこなしてきたのですが、意思決定のためのミーティングスケジュール、自身が開発を行うためのスケジュールをやりくりするバランスに腐心していました。 自身のタイムマネジメントで特に感じた点として、ミーティングとミーティングの間に1時間が3コマある時の開発生産性と、3時間まとま
SaaSはPMFを繰り返していくことで成長すると過去書きました。 www.blockchainengineer.tokyo スタートアップのSaaSはT2D3の成長が必要だと言われており、5年間で72倍の成長を求められます。そのために、レバレッジがかかるように戦略が重要とされます。 スタートアップの T2D3 (Triple, Triple, Double, Double, Double) | by Taka Umada | Medium B2BSaaSの戦略として、プロダクト戦略、Go To Market戦略の2つがあります。今回、この2つについてどのような役割があり、どのように関連するのかを書いていきます。 プロダクト戦略とは プロダクト戦略の作り方 Go To Market戦略とは 最後に プロダクト戦略とは プロダクト戦略は簡単にいうと「誰に」、「何の価値を」提供するかを定めること
プロダクトロードマップに関する書籍を探していたら、「Product Roadmaps Relaunched」に辿り着きました。未邦訳なので英語で読んでいったのですが、非常に良い本です。 Product Roadmaps Relaunched: How to Set Direction while Embracing Uncertainty (English Edition) 作者:Lombardo, C. Todd,McCarthy, Bruce,Ryan, Evan,Connors, MichaelO'Reilly MediaAmazon アウトカムベースのロードマップ(Outcome Based Roadmap) プロダクトマネジメントでは「アウトプット」と「アウトカム」がよく比較されます。アウトプットは出てきた機能に対して、アウトカムは提供価値であり、プロダクトマネージャーはアウトカ
「成長するためにはハードワークは不可欠」。こういう言説は常に世に出ています。そして、それを信じた真面目な若者が「成長」するためにハードワークをこなすという流れ。知っているだけでも10年以上同じサイクルがあるように思います。 思いつくだけでも、サイバーエージェント創業者の藤田晋氏が著書「渋谷ではたらく社長の告白」で月に440時間働いていたという話や、テスラ創業者のイーロンマスク氏が世界を変えるためには最低でも週80時間は働くべきだと主張があったり、成功者がハードワークを乗り越えた話があります。 一方で自分自身の経験を振り返ると、必ずしも労働時間の長さが個人の成長につながったとは思えません。この認知の違いはどこからくるのか。自分自身の経験を振り返ってみたいと思います。 自分自身の労働時間経験 ハードワークだが成長しなかった経験 ワークライフバランスを保ち、成長した経験 成長の定義を「今できない
プロダクトマネジメント関連の相談をいただくことが徐々に増えました。 特に新しい職種であるため、業務範囲がどこからどこまでなのか、という話の相談を受けます。 プロダクトマネージャーの仕事は会社によって差異があり、かつ組織体によって差異があって良いものだと思いますが、私が思うプロダクトマネージャーの仕事を整理してみます。 プロダクトマネージャーの3つの仕事 プロダクトビジョンの策定 ロードマップの策定 製品仕様(Product Requirements Document)の策定 まとめ プロダクトマネージャーの3つの仕事 結論からいうと、プロダクトマネージャーの仕事は プロダクトビジョンの策定 ロードマップの策定 製品仕様(Product Requirements Document)の策定 の3点です。プロダクトが目指すべき姿、実現する内容を決めるのがプロダクトビジョン。目指し方を策定するのが
プロダクトマネジメントを最近は生業としていますが、プロジェクトマネジメントについても必要となることが多くあります。 最近、周囲でもプロジェクトマネジメントが必要な機会を見聞きすることがあり、需要はあるのではないかと思い、私が学んできた知識や経験を書き記してみます。 仕事の終わらせ方は2つしかない プロダクトマネジメントとの違い プロジェクトマネジメントの3種の神器 プロジェクトマネージャーの仕事は不確実性を潰していくこと チームマネジメントについて 「運用でカバー」は最終手段 まとめ 仕事の終わらせ方は2つしかない 新人研修で、仕事の終わらせ方は2つしかないという話を教えてもらいました。その2つは「成果で終わらせるか」、「期限で終わらせるか」です。 (こちらの企業の研修だったと思います http://www.onevision.jp) 言い換えると、あらかじめ定めた成果物が完成した時、ある
2021年はB2B SaaS開発にどっぷり浸かりました。バクラク請求書という経理業務の支払処理に該当するサービスを開発していたのですが、当然のことながら専門業務向けのSaaSになります。 プロダクトマネージャーとしても動いていたのですが、具体的な経理知識が必要になり、経理の方から常にヒアリングを重ねていました。しかし、個社によって事情は異なります。例えば、仕訳の切り方1つにしても教科書的に正しいものと、現場での作業では簡略化して入力するものなどがあり、それらを考えた上での仕訳機能を策定する必要があります。 また、法令改正などの影響によって仕様が影響を受け、ここも理解して開発を進める必要があります。あるべき仕様やペインが何なのか、また法令によってどのような影響を受けるのかを判断できる、経理業務に精通した人間が内部にいる必要を痛感しました。 この内部領域専門家は「ドメインエキスパート」と呼ばれ
タイトル通りですが、NFTを発行して欲しいと問い合わせがたくさん来ており、直近忙しくしているので方法だけまとめておきます。 OpenZeppelin + Solidity0.8 + Hardhat + ethers.jsが良さそう Hardhatでプロジェクトを作る NFTコントラクトを、OpenZeppelinで作る コントラクト デプロイスクリプト ローカルで仮想ノードを動かす 仮想ノードにデプロイ hadhat flattenでコントラクトをフラットな形で見る testを書く OpenZeppelinの関数を変えたい場合、オーバーライドする サンプルコードを公開しました OpenZeppelin + Solidity0.8 + Hardhat + ethers.jsが良さそう Solidityが0.4.21でワイワイしていたのはいつのことか。2021年はもうv0.8台になりました。O
この記事はLayerXアドベントカレンダーの企画の一部です。 ここ1年ほどは所属しているLayerXにて、LayerXインボイスという、請求書処理プロダクトの立ち上げ開発を行ってました。特に最近はプロダクトマネージャー(PdM)業務を行っており、事業部内で上半期MVPをもらいました。 正式なプロダクトマネージャーの仕事は試行錯誤しながらでしたが、得た知見や気をつけていることを記しておきます。 1/ 本業のLayerXでは1年強ほどブロックチェーンはお休みしてB2BSaaSの開発とプロダクトマネージャー(PdM)をして、DX事業部(SaaS事業)内で上半期MVPをもらいました。 まだ全然成果を上げられていないと思うものの、この機会にPdMとして意識していること、意識したいと思っていることを言語化してみます— 花村 直親 Nao Hanamura (@naomasabit) October 3
プロダクト作りにおいて、開発したプロダクトがユーザーにとって価値提供が成り立つのかを検証する作業のことをプロダクトマーケットフィット(PMF)と呼びます。これもふわりふわりとした概念で、元々はBenchmark Capitalの創業者であるアンディー・ラフレフ氏が以下のように定義しました。 「PMFとは強力な価値仮説を見つけることである。価値仮説とは、なぜユーザーや顧客があなたのプロダクトを使うのかを説明しうる重要な仮説のことである」 プロダクトを作る新規事業において、まず目指すのはPMFになります。最小限のプロトタイプ(MVP)をユーザーのフィードバックを受けながら改良し、「使いたい」と思わせること、そしてそれが多くのユーザーに適用可能な「強力」であることになります。 過去を振り返り、B2BのPMFプロセスを考えてみる 僕のいくつかの経験を思い返してPMFまでの流れを言語化してみます。
前回の記事が思ったより反響があったので、今回もDXという文脈で感じたこと、学んだことを書いていきます。僕は過去にSI案件の業務システムの開発に携わってきた他、複数のB2B SaaSの新規事業、開発に携わってきて、主にB2Bのソフトウェア開発を主戦場としてきました。昨年からB2Cサービスを主にやってきたWEBエンジニアと一緒に働くことが多くなり、そこでこれまで前提としてきた視点の違い、B2Cで培われる能力、2Bで特に求められる視点について振り返る契機になりました。 DXという言葉の流行とともに、これからB2Cサービスに携わったエンジニアがB2Bサービスに携わることが増えてくるでしょう。B2C,B2Bなど様々なバックグラウンドのエンジニアチームが生まれると思いますが、視点の整理の一助になれば幸いです。 この記事では WEBエンジニアがB2Bソフトウェアへの選択肢が増える流れ B2BとB2C開発
DX(デジタルトランスフォーメーション)という言葉が流行し、猫も杓子もデジタル化という言葉を使い始めました。さて、デジタル化とは何なのか、そして流行しはじめたのはなぜなのか。 端を発するのは経産省の「2025年の崖」のレポートだと言われていますが、レポート読んではみたものの本題はSAP ERPの保守期限を意識した基幹システムの刷新化と技術的負債の返済であるにもかかわらず、日本企業のスピード感の話だったり、なぜかマイクロサービスとAI、アジャイルサービスなど流行のワードがたくさん出ており、論点がぼやけている印象を受けてしまいました。 基幹システム刷新化においてマイクロサービスなどは一部で使えるかもしれませんが、銀の弾丸とは思いませんし、現状整理によってはきちんとしたデータベース設計とウォーターフォールを主としたロジック移行が最適解であることも十分にありえるといち技術者としては思います。 僕自
Dappsの運用方法を考える Cosmos-SDKとは スマートコントラクトについて Cosmos-SDKチュートリアルアプリの実装概要 app(baseapp) Keeper Msg Handler Querier codec Cosmos-SDKチュートリアルアプリの実行 testchainのセットアップ jackとaliceの初期アカウントを作成する jackが独自ID(jack.id)というドメイン名を購入 jackがかったドメインの所有権を確認する aliceがjackからドメインjack.idを購入する 感想 Dappsの運用方法を考える レイヤー2ソリューションやinteroperabilityが重要視されており、実ビジネスでの利用が徐々に考えられています。 まだ整理中なので誤っているかもしれないのですが、Dappsの運用方法を整理してみました。 運用方法 Public以外で
EthereumのYellowPaperを元に、Ethereum独自のRLPエンコーディングについて実験してみました。 RLPエンコーディングとは 5つのエンコードパターン バイト配列の場合 バイト配列でない場合 実験に用いたコード バイト配列をRLPエンコーディングする場合 1. バイト配列が単純な1バイトで、128より小さい時、そのままアウトプットする 2. バイト配列が56バイトより小さい場合、バイト配列の長さ+128に等しいバイトを加えた配列に等しくなる 3. 他の場合、ビッグエンディアン整数として解釈した時に最小となる入力バイト配列の長さを、接頭辞として入力に付与する。加えて、その長さに183を足した長さを接頭辞に付与する バイト配列以外をRLPエンコーディングする場合 4. 56バイト未満の場合 5. 56バイト以上の場合 まとめ RLPエンコーディングとは RLP(Recur
セキュリティトークンが盛り上がっていますが、今月「ERC-1400: Security Token Standard」としての提案がEthereum Improvement Proposal上で行われました。なお、この提案はFinalizeされていないため、ERCではなくEIP1400になります。 また、EIP1400は議論中のため、内容が変わることがあります。2018年9月30日時点で議論されている内容を大まかにまとめました。 github.com セキュリティトークンとは EIP1400で定義されているセキュリティトークンの要件 前提知識 - トランシェとは セキュリティトークンにメタデータが必要な理由-EIP1400のAbstractより function定義 Partially-Fungible Tokenに関するfunction定義 オペレーターに関係するfunction定義 セ
Bitcoinはサイファーパンクの活動の歴史と深い関係があります。 サイファーパンク (cypherpunk)とは、社会や政治を変化させる手段として強力な暗号技術の広範囲な利用を推進する活動家である。 サイファーパンク - wikipediaより サイファーパンクの思想を理解するにあたって重要な文書として、1992年にティモシー・C・メイが発表した“クリプトアナーキスト宣言” (「The Crypto Anarchist Manifesto」)が挙げられます。本記事では、こちらの宣言を読んで思想を理解したいと思います。 『The Crypto Anarchist Manifesto』(1992, Timothy C. May ) https://www.activism.net/cypherpunk/crypto-anarchy.html サイファーパンクは1980年代の終わりから活動をし
Blockchain EXE様とConsenSys様が共催のuPortを使うハッカソンにでるという事で、EthereumのKYCツールであるuPortを利用してみます。 uPortの仕組みはこちらのブログが詳しいです。 zoom-blc.com ざっくりいうと、ETHアドレスに名前や電話番号などの付帯情報をつける事で、ログイン処理の一元化、分散管理化を行います。1つの企業が個人情報のほとんどを持つのではなく、暗号化して分散化されたある種のワールドデータベースに保存し、個人で管理するという事だと理解しています。 きっちりとしたKYCというよりは、ETHアドレスに個人の属性を追加する事でログイン管理、ユーザー利用体験の向上に紐づけるという様に感じました。現状ETHアドレス同士の通貨交換では16進数の数字しか表示されないところを、uPortを用いて相手の名前やメールアドレスなども確認する事で、誤
3月29日、「Ethereum Community Fund」創設発表イベントが東京で行われました。 Ethereum Community Fundとは、Ethereumのインフラ整備やDappsの普及のためのファンドとのことです。 イーサリアムを支援する6つのプロジェクト——Cosmos、OmiseGO、Golem、Maker、Global Brain Blockchain Labs(GBBL)、Raiden——は先ごろ共同で、イーサリアムのインフラの整備や非中央集権型アプリ(dApp)の普及を意図したファンド「Ethereum Community Fund(ECF)」の創設を発表している。 thebridge.jp たまたま参加させていただけて、イベント内容についてソーシャルシェアがOKということなので、少し記載します。 当日はVitalik Buterinのスピーチ、Ethereum
前の記事を書いた10月の時と比べて、「ブロックチェーンエンジニア」という職種が徐々にメジャーになってきたように感じます。 仮想通貨が2017年11月頃から急騰し、取引所ビジネスの利益率が高いということも広まりました。それに伴って、金融庁の仮想通貨交換業登録も100社以上申請待ちという概況になってきたように思います。私自身も「ブロックチェーンエンジニア」としてイベントなどに呼ばれる機会や、ブログ経由で問い合わせをいただくようになってきました。 前回は 変化が早い業界なので、半年後にはまた変わっているかもしれません。。 と締めました。ちょうど半年経った今において、募集要項がどう変化して採用トレンドがどのようになっているか、またどのようなブロックチェーンエンジニアが求められていきそうかをまとめてみたいと思います。 ※この記事はあくまで業界全体に対する一意見です。 前回の記事 取引所求人に引き続き
最近、ブロックチェーンエンジニアを目指すためにどのようなスキルセットを身につければ良いかや、初心者向けの技術書執筆の話などを頂くことが増えてきました。 ブロックチェーン業界で働くという事に興味をもつエンジニアの方が増えてきたように感じます。 そこで、初めてブロックチェーンに触れる方の指針になればと思い、本記事を書きました。 猛者の方には物足りない点は多々あると思いますが、あくまで初学者向けというところで勘弁していただければと思います。 前置き 前提として、応用先によって身につける技術は異なる どんな職場(チーム)でも、初めのハードルは「共通言語」 最良なのは公式ドキュメントだが、英語と技術用語のハードルも 共通言語を会得するための本 基本知識は「Mastering Bitcoin」(ビットコインとブロックチェーン)から アプリへの応用知識を得られる「ブロックチェーンアプリケーション開発の教
次のページ
このページを最初にブックマークしてみませんか?
『SaaSベンチャーで働くエンタープライズ部長のブログ』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く