- 生年月日
- 1975/5/1
- 所属会社
- キャディ株式会社
- 現年収
- 850万円
- 希望する職種
- プロジェクトマネージャー、バックエンドエンジニア
- 希望勤務地
- 東京都
- editor
- emacs
***その他 URL ***
- GitHub
- CADDi Tech Blog - Clean Architecture
- UZABASE Tech Blog - RDB
- UZABASE Tech Blog - TDD, Smalltalk
うまい仕組みを考えて、世の中の役に立つ
私はコンピューターサイエンスのバックグラウンドが無く、この仕事に着いたのも偶然です。
ただ、業務に取り組む中で触れる技術や、技術を用いて価値を提供する仕組みに興味を持ち、次第にこの仕事が好きになり、
ソフトウェア開発の本質を掴みたいと考えるようになりました。
特に、技術面ではスプレッドシートから RDB 、UNIX 、LISP 、OOP などが仕組み的に私に「うまい！」と感じさせてくれました。
これらは共通して、少ない原則に基づき多様な部分を統一的に扱うことが出来、
全体として整合性を保った上で多様な表現を実現できる仕組みが備わっていると考えています。
また、プロジェクトマネジメントの観点では、アジャイル（ 中でも XP ）の、価値 / 原則 / プラクティスを分けて捉えて関係性を定義し、
書籍で扱われているケースをそのまま適用できないような実際の開発現場で遭遇する様々な場面においても、
価値 / 原則に立ち返ってプラクティスをそれぞれが打ち立てることが出来る仕組みを提供しており、
やはり深い洞察が、多様で有効なプラクティスを可能にしています。
そのようなパワフルな仕組み全体、それができなくても既存の仕組みの中で美しい部分をつくっていく、
というようなものづくり、仕組みづくりを実践しつつ価値をつくっていきたいです。
- キャディ株式会社
- 2021年7月〜現在
- 株式会社ユーザベース
- 2015年8月〜2021年5月
- 株式会社ISIDアドバンストアウトソーシング
- 2011年4月〜2015年6月
- フリーランス
- 2005年4月〜2011年4月
- レッドフォックス株式会社
- 2002年4月〜2005年4月
- プロジェクトタイプ
- 自社プロダクト
- 経験した職種・役割
- プロジェクトマネージャー、スクラムマスター、バックエンドエンジニア
- 担当工程
- 開発に関わること全て
- 実際に使っていた技術
- Rust, gRPC, TypeScript, GraphQL, React, Docker, Kubernetes
- 既存受発注プロダクト（社内ユース）のリプレース
- 期間は 1 年弱、エンジニア 15 - 20 名、3 チーム制（ LeSS ）のプロジェクト
- Rust で Clean Architecture を体現した、マイクロサービスバックエンド API が複数協調するプロダクト
事業の成長による商流の変化への追随と上場に向けた会計処理の健全化を実現する。
上記の課題に対し、既存プロダクトの受発注モジュールが密結合していること、永続化されたデータを用いての会計処理が困難であることなどの問題が顕在化しました。
大量製品を扱うようになったために、受注を前提としない発注、つまり在庫を作るための発注機能が必要でしたが、受発注機能の分離が難しいつくりとなっていました。
また、製品マスターが正しく管理されていなかったため、会計処理上必要な受発注時点の製品情報のトレースが不可能になっていました。
また、エンジニアリング上の問題として手動シナリオテストのみ存在し、テストに守られていないためリファクタリングによる設計の進化が困難な状況でした。
これらの問題を鑑みリプレースを行う判断となりました。
ユーザーは社内の受発注管理者です。
受発注システムを構成するプロダクトは 3 つ想定されました。
受発注自体を管理するもの、被発注者が使用するポータル機能、新たにつくる在庫管理システムです。
これらを 3 つのチームがそれぞれ担当するのですが、システムに依存関係があるためプロジェクトは協調して進める必要がありましたので
LeSS を採用しました。（ LeSS の導入経緯と振り返りはイベントで行いました。）
商流が変わるためユーザーのオペレーションから再設計する必要がありましたので、
紙芝居( スプシ、Figma )を含んだプロトタイピングをユーザーに早めにレビューしてもらうという進め方を行いました。
このような不確実性が高いプロジェクトでしたので、スクラムベースで MVP を常に見直しながら進めることに特に配慮しました。
基本的にスクラムではチケットにユーザーストーリーを表現し、チームで優先順位を合意して、手が空いたメンバーが優先順位の高い順からチケットに着手します。
ユーザーストーリーはユーザー提供価値を現していますので、その中にはバックエンド、フロントエンドなどの複数種のタスクが含まれることが多いです。
一方、エンジニアは得意分野とそうでない分野を持っていますので、 discord に常駐していつでも声を掛け合えることをベースに、必要に応じてペアプログラミングを行うこと推奨してコンテキストの属人化を排し、スキルトランスファーを促進しました。
また、チケットに詳細な実装方針などは記載せず、背景と完了条件のみを記述するルールとし、不明な点がある場合は情報を取りに行くように促すことで、チケットに対するオーナーシップを個々のメンバーが強く持ってもらうようにしていました。
上記ビジネス課題を解決し、運用されている状態となりビジネス価値に貢献できました。
また、汎用 API として外部システムとの連携も可能な状態となり、その構想が進んでいる状態となりました。
- プロジェクトタイプ
- 自社プロダクト
- 経験した職種・役割
- -
- 担当工程
- 開発に関わること全て
- 実際に使っていた技術
- Clojure, Docker, Kubernetes
- 1ヶ月限定のミニプロジェクト
- Clojure で Clean Architecture を体現した、マイクロサービスバックエンドAPI
- XBRL 内の非定形データから企業情報を抽出
企業の有価証券報告書提出からそのコンテンツをプロダクトに反映するまでの期間の短縮とその工数、外注費用の削減
データ生成チーム経由で PDF から企業情報を抽出する作業を外注しており、
さらにその成果物をプロダクトに反映するまでに半年を要していました。
データの鮮度はプロダクトの価値に直結します。
データ生成チームが上記のようなペインをいくつか開発チームに共有しており、
その中から選択しました。
チーム開発が基本ですが、「ひとりプロジェクト」と呼ばれる取り組みがあり、これに自ら手を挙げて行いました。
ユーザーはデータ生成チームです。
まずはスパイクとして、ひとつの企業の XBRL を tsv に変換するコマンドをつくり、
数十社をサンプルとしてユーザーに示し、運用をイメージしてもらいながら、仕様とそれらの優先順位をざっくりと決めました。
上記コマンドにそのフィードバックを反映した後、数百社をサンプルとしてユーザーに渡し、外注も含めたデータ品質チェック作業を依頼しました。
それを行ってもらってる間、コマンドを REST API 化しました。
コマンドは書捨てのつもりでモノリシック、テストも必要性を都度判断して書きましたが、
REST API は Clean Architecture、 TDD かつアウトサイドインで実装を行い、可変性、可読性を意識しました。
取得したいコンテンツが含まれるエリアまでは XBRL で定義されたタグでたどり着けるのですが、そのコンテンツは一般的な HTML タグで表現されています。
その構成は個社毎に異なるものです。
なので、Instaparse のようなパーサコンビネータ−を用いてかっちりやることは出来ないと判断し、以下のように「泥臭いが徐々に正解に近づいていける」やり方にしました。
まず、 tr を全て企業レコード候補とみなします。
それらを、ドメイン層で spec を用いて定義した企業属性群の値のプールへの適合具合を見て判定するようにしました。
spec とそれを構成する述語を調整することで、徐々に精度を高めてゆきました。
また、上記のサンプル企業データを e2e の expected としていたので、積極的に調整することができました。
フルリモートの為、Discord の特定の部屋に常駐し、気軽に話しかけてもらえるようにしていました。
ミニプロジェクトなので、カンバンは作らず、
Trello を用いて画面共有しながらユーザーとストーリーの優先順位づけ、スコープの決定を行いました。
また、特に Clojure の知見を持っているエンジニア中心に、
ライブラリの選定やアーキテクチャの妥当性についてフィードバックを得て反映していきました。
上記品質チェックは OK となり、外注の成果物と遜色無いものになり、ユーザーに感謝されました。
まとめて書きます。
前職では、金融系、事業会社の経営企画をターゲットユーザーとした B2B SaaS の開発を行っていました。( 5 年 )
当初はバッチ処理、後にマイクロサービス化が進んできた後では、名寄せ API はじめ各種バックエンド API、フロント（Web, BFF）などを開発していました。
チームは 4-5 人で、常にペア・プログラミングを行っていました。
前々職では、SIer で航空会社のデータ解析基盤などをつくっていました。( 3年 )
AWS Redshift、S3 などをデータストア、Tableau BI をフロントとした基盤で導入からサポートを行いました。
現職では、プロジェクトマネージャー兼スクラムマスター兼バックエンドエンジニアとして、採用からチームの組成、スクラムの運営の導入と改善などを行っていました。
前職では、リーダーを置かないという方針と、エンジニアがビジネスをリードするという開発チームの目標があったこともあり、
ビジネスサイドのメンバーやデザイナーを含めたインセプションデッキを作成し、デザインスケッチを描くための合宿を主導することから、
アーキテクチャ選定、CI/CD パイプラインの構築、開発、運用、トラブルシュートまで、開発に関わるあらゆることを行いました。
前々職では、常駐先のリーダーをしていました。
どちらにちても、エンジニアの採用を行っていました。
使っていた頻度降順で書きます。
- Kotlin( Spring Boot )
- Rust
- Clojure
- TypeScript
- Python
- Dart
- Java
- 直近で一番やりたいこと
- サービスをつくりたい
- 好きなスタイル
- 一人で黙々、みんなでワイワイのどちらも
- 自信を持って人より秀でていると言える点
- 複雑なドメインロジックを写したデータを正しく扱うこと
- スキルのタイプ
- ゼネラリスト
- 得意なフェーズ
- やや 0 → 1 寄り
- 会社を選ぶ一番の基準
- 社会的意義、自分のスキルが活きるかどうか
- 好む文化
- アジャイル開発
- 手を動かして設計してコードを書きたい
- やりたい
- 価値あるプロダクトを作り成長させたい
- 絶対やりたい
- 学び続けて技術力でプロダクトに貢献したい
- やりたい
- 意義があることや社会に貢献できる仕事がしたい
- 絶対やりたい
- 人や計画の調整・マネジメントをしたい
- 絶対やりたい
- レガシーなシステムの保守・運用・改善をしたい
- 別に普通
- 企画や仕様を考えるところから関わりたい
- やりたい
- 業務効率を改善して一緒に働く人のためになりたい
- 別に普通
- 全社横断的な共通基盤作りや強化をしたい
- 別に普通
- 組織や文化を作る・成長させる仕事をしたい
- やりたい
フロントエンドは、フリーランスの時にいくつかの案件をこなしたくらいで、
現職でも既存画面に対する改修ばかりでアーキテクチャを組むスキルは無いです。
フリーランス当時は jQuery でごりごり書いてたりしたのでフロントエンドの技術に対してネガティブなイメージを引きずっていましたが、
その後成熟し再利用のための仕組みなども整ってきているようなので、
一通り学んでなにかつくりたいと思っています。
現職で場数を踏んでアジャイル開発の手法に慣れ親しみ、とくにファシリテーションなどは周囲からも評価されるようになりました。
ただ、現職ではチーム全体でアジャイル開発が浸透しているのであまり問題にならないのですが、
新たにジョインした方や、アジャイル開発に慣れていないビジネスサイドのメンバーに対してもプラクティスの本質をもっとしっかり伝えられるようになりたいと考えています。
以下のような書籍をさらに読み込み、意図を持ってプラクティスに取り組み実践からフィードバックを得てチームのアジリティ向上を牽引する存在になりたいと考えています。
- 証明の読み方・考え方
論理的に考えるための思考の順序や、基本的な道具立てを学べました。 - 論理学をつくる
上記と同じです。
直接的にはテストケース作成などに役立っています。真理表のつくり方もこの本で身につけました。 - データベース実践講義
リレーショナルモデルをつくったひとの結構熱い思いに感動しました。
あと、正規化の本質を学べました。
学んだことはブログに書きました。 - テスト駆動開発
プログラマがやろうとしていることやその意図を徹底して言語化することを学びました。 ペアプロ時に活きていると思います。
また、プログラミングの規律とそれに基づいた自由の楽しさを知りました。
学んだことはブログに書きました。
責任と、それに見合った裁量権を与えられる環境です。
複雑なドメインへの理解力、それに基づいたリカバリ力、運用を着実に実行できる、運用フローを改善できるなどです。
チームの雰囲気を良くする、ファシリテーションが楽しいとも言われます。
TOEIC スコア 720
英語は読み書きが出来る程度です。
ベトナムに駐在していた時、現地の方と英語で会話していましたが、
ネイティブの方とのビジネス会話は難しいです。
学校名