プロダクト
自社で開発・運営しているサービス・ツールをご紹介します。家族と暮らしに関わる領域には、自らも取り組んでいます。
提供中のプロダクト
GitHub Projects Ops Kit
GitHub Projects 運用の半自動化キット
GitHub Projectsの初期構築から運用分析までをGitHub Actionsで半自動化する、オープンソースの運用キットです。ForkしてWorkflowを実行するだけで、Projectの作成・Issue/PRの紐付け・レポート生成までを一気通貫で行えます。
Project作成とField・Status・Viewの一括セットアップ
Label・初期ファイル・Rulesetなどリポジトリ初期設定の一括作成
Issue/PRの一括紐付けと、滞留検知・工数・ベロシティのレポート生成
JSON定義による構成管理と、GitHub Actions・GitHub CLIのみで完結する運用
開発中のプロダクト
Omamori Notebook
終活アプリ（家族・暮らし領域の取り組み）
Ehonica
絵本アプリ
公開時期などの詳細は、お問い合わせいただければ個別にご案内します。
社内ツール
これらは社内で開発・運用している仕組みであり、外部への提供・販売は行っていません。開発のご相談はお問い合わせからお願いします。
クリエイティブ制作基盤
ポスター・チラシ・PDF などの販促物を、企画から校正まで一貫した工程で制作する仕組み
販促物の制作を、思いつきではなく決まった工程として回すための仕組みです。目的の整理、訴求の設計、コピー、ビジュアルの方針、レイアウト、印刷観点のチェック、校正を独立した役割に分け、順に通していきます。
属人的なセンスではなく、工程として再現できる形にしている
制作意図を知らない目で見る初見レビューを必ず挟む
誇大表現・コンプライアンスの確認を制作フローの内側に置いている
解決している課題
販促物の出来が担当者の力量に左右され、良し悪しの判断も作った本人しかできない状態になりがちです。
設計上の考え方
制作を一続きの作業ではなく、役割ごとに区切った工程として扱っています。訴求の方針、ブランドとの適合、公開してよいかの最終判断は必ず人が行います。
自社での使い方
当サイトの各プロダクト紹介ページに掲載しているポスターは、この仕組みで制作したものです。
リポジトリ最新化キット
既存システムの老朽化を、定期的に点検・更新し続けるための仕組み
作ったあとのシステムは、放っておくと必ず古くなります。点検と更新の手順を一箇所にまとめ、複数のシステムへ同じ基準で差し向けられるようにしたものです。
「動いているから触らない」の先にある作り直しのコストを避ける
点検の基準を仕組みとして持つため、担当者が変わっても品質が揺れない
更新は安全側に倒す設計。壊さないことを前提に組んでいる
解決している課題
手を入れないまま年数が経ったシステムは、小さな変更にも大きな検証が必要になり、やがて作り直しでしか動かせなくなります。
設計上の考え方
使っている部品が古くなる流れと、当時は最適だった作り方が今の標準から外れていく流れは性質が違うため、別々に扱っています。一度きりの大掛かりな作り直しではなく、健全な状態を保ち続けることを目的にしています。
API 仕様の集約基盤
社内外で利用する API の仕様を一箇所に集約し、仕様書と接続部分を自動生成する仕組み
利用している API の仕様を一箇所に集め、そこから仕様書と、実際に通信するための実装を自動で生成しています。手で書き写す工程がないため、仕様と実装がずれません。
仕様書と実装のずれという、規模が大きくなるほど効く問題を構造で潰している
外部サービスとの連携が多い案件ほど効果が出る
既知の問題と新しい問題を混ぜない設計になっている
解決している課題
仕様書と実装を別々に手で保つ運用では、必ずどこかがずれます。ずれは連携先が増えるほど見つけにくくなります。
設計上の考え方
生成に失敗した場合でも既存の資料はそのまま残す設計です。未解決のまま許容している箇所は明示的に登録して切り分け、今回新しく壊れたのか、前から分かっている問題なのかが判別できるようにしています。
共通開発基盤
複数プロダクトで共通して使う部品・テスト環境・自動化を、ひとつにまとめた基盤
自社プロダクトで繰り返し必要になる部分——画面の共通部品、テストの土台、部品カタログ、リリースの自動化——をひとつの基盤にまとめています。新しいプロダクトは、この基盤の上から始められます。
立ち上げの速さが、道具立ての差として説明できる
品質の下限が、個人の技量ではなく基盤の側で担保される
自社のサイト・プロダクトが実際にこの上で動いており、机上のものではない
解決している課題
プロダクトごとに同じものを作り直していると、立ち上げに時間がかかるうえ、出来上がりの質が担当者ごとに変わります。
設計上の考え方
十数個の部品群として整理し、社内の各プロダクトから共通して利用しています。共通で持つべきものと、プロダクト側で決めるべきものを切り分けることを基準にしています。
自社での使い方
このコーポレートサイト自体も、この基盤の上に構築されています。
Web アプリ開発テンプレート
新しい Web アプリを、整った状態から作り始めるための出発点
新規の Web アプリを立ち上げるときの雛形です。多言語対応、コード品質の確認、自動テスト、部品カタログ、リリース管理——開始時に必ず必要になるものを、あらかじめ組み込んだ状態から始められます。
立ち上げの手戻りが少なく、着手から動くものが出るまでが短い
テストと品質確認の仕組みが最初から入っている（後付けにしない）
決め打ちしない部分を明確にしており、案件ごとの事情を潰さない
解決している課題
準備が整わないまま着手すると、あとから品質確認やテストを足すことになり、その分だけ手戻りが発生します。
設計上の考え方
意図的に含めていないものもあります。案件ごとに選ぶべきものは雛形の段階で決め打ちしません。「最初から入れておくべきもの」と「案件ごとに決めるべきもの」を切り分けることが設計の中心です。