茹でガエルなエンジニアの記録

やったことや考えたことなどを不定期に書き残していきます

リーンスタートアップとかアジャイル開発

リーンスタートアップシリコンバレーで盛り上がり、日本にも上陸してかなり浸透していると思う。 一方、最近になってとくに大企業では新規事業でイノベーションだ!みたいな話がよくあるが、リーンスタートアップ自体を知らないままに「仮説検証」とか「MVP」とかのワードだけを何となく使っている組織をよく見かける。

リーンスタートアップの出自

リーンスタートアップアジャイル開発が似ている、と言う人がいるが、それはそのとおりである。 なぜなら、リーンスタートアップの生みの親であるエリック・リースが、師匠(と呼ぶのかは微妙だが)であるスティーブン・ブランクの提唱する顧客開発モデルという手法に、ソフトウェア開発のアジャイル開発を掛け合わせて創り上げたのがリーンスタートアップだからである。

アジャイル開発との違い

アジャイル開発との違いは、アジャイル開発がソフトウェア開発(ハードウェア開発の場合もある)にフォーカスしているのに対し、リーンスタートアップは、事業アイデアの種を世に出し、事業としてスケールするまでの広い範囲をスコープとしている。

ただし、具体的なアイデア出しの方法や、ソフトウェア開発手法については扱っていない。 スタートアップのやりかたとして、あらゆることを仮説として捉え、それを検証しながら進めていくというやりかたである。

違い、と書いたが、実際には違いではなく包含関係にあるといえる。高速に仮説検証を回して学びを得ながらプロダクト開発をする。そのために開発手法はアジャイル開発を採用する、という理解が良いように思う。

なお、高速なアジャイル開発は、いざやろうとすると高度な技術レベルと幅広いスキルがチームに求められる。 どこかの誰かに委託してそう簡単に実現できるモノではないが、そこが分かっていない組織が古めの起業にはとてと多い。

リーンスタートアップにとって大事なこと

リーンスタートアップが目指しているのは、資金の少ないスタートアップが一撃死するような大きな失敗を避けることである。逆に、小さく失敗することについては許容することが重要である。早めに気づいて方向転換しましょう、ということ。 失敗というより、仮説を検証した結果、間違っていたことを学んだ、という姿勢を持つことがポイントになるが、これが実際の起業や社内新規事業においては難しい。 都合の良い結果解釈をしがちである。

このあたりは、どうすればうまく仮説検証結果から次の動きを見いだせるか、まだ自分も試行錯誤している。

AWSで手軽に使えるアクセス制限

はじめに

不特定多数に公開するWebアプリではない場合、セキュリティの観点からするとできればサインイン画面まで到達する前にアクセス制限をかけ、そもそもWebアプリまで到達できないようにしたい。 サインイン認証をMFAなどで強固にすることで不正アクセスの対策にはなるが、そもそもアクセスされてサインイン試行されまくるとそれだけでサーバーに負荷がかかる。

そこで今回はAWSマネージなサービスだけでアクセス制限を実現する方法を整理したいと思います。

アクセス制限する方法

クライアントからのアクセスを制限する方法はいくつか考えられる。

  • 接続元のIPアドレスによる制限
  • クライアント証明書による認証
  • 外部IdPによる認証

AWSサービスによってこれらの利用可否が異なるので、整理します。

AWSサービスごとの利用可能なアクセス制限方法

ざっくりまとめると次の表のとおり。

IPによる制限 クライアント証明書 外部認証 その他
API Gateway △Cognitoのみ Lambdaオーソライザで作り込みが可能
ALB × 〇 OIDC対応
WAF × × SQLインジェクションなどアプリレイヤーでのセキュリティ強化

API Gateway

  • 接続元のIPアドレスによる制限が可能。リソースポリシーを使用することで実現可能。
  • mTLSによるクライアント証明書の認証が可能
  • APIキーによる制限
    • APIキーを知っていれば結局どこの誰からでもアクセスできるため強度としては不十分。
  • Cognitoユーザープールによる認証。アクセスしてくるユーザーをCognitoで管理することが前提となる。

ALB(Application Load Balancer)

  • 接続元IPアドレスによる制限が可能。
    • WAFでも制限できる。WAFを使うほうがより高度な設定/制限が可能なため便利。
  • OpenID Connect(OIDC)やCognitoによるユーザー認証が使える。ALBアクセス時にユーザー認証を要求する。 認証済みのリクエストのみをALBのターゲット(Webアプリ)に送信する。
  • クライアント証明書による認証はできない。

WAF

  • 接続元のIPのアドレスによる制限が可能
  • クライアント証明書認証は不可
  • 外部IdPによる認証は不可

なお、WAFを適用できるAWSサービスは以下のとおり

まとめ

いろんなサービスで少しずつ取れる手段が異なるので注意が必要。 うまく自身の構成で使うことができれば簡単かつ管理不要でセキュリティ強度を高めることができるので積極的に使っていきたいところ。 AWS IoTで使われているような、クライアント証明書の発行とアクセス認証をセットで簡単に使えるといいなぁと期待しています。

ALBの設定でAuth0でOIDCでクライアント認証をやってみたのでメモ

はじめに

AWSのALB(Application Load Balancer)にOIDCによる認証を設定しました。

認証を追加することで、ALB(の後ろにいるWebアプリ)へのリクエストがあった際、不特定多数のリクエストをWebアプリ側に到達させることなく、ALB側で拒否することができます。 特定の人にしか使わせない想定のアプリの場合、IPで制限するなどの手段もありますが、IP以外の方法でフィルタすることができますので、より使いやすいです。 アクセス制限には以下のようないくつかのやり方があると思います。

  1. 接続元IPアドレスを制限する方法
  2. クライアント証明書による認証をする
  3. OIDCなどによるクライアント認証

今回は一番最後のアプローチを採用しました。ALBでは1か3のやり方ができますが、IPによる制限はリモートワーク環境では使いづらいためです。

また、OIDCのIdPとしてAuth0を使ったのですが、ALB側の設定項目がAuth0の場合は何を設定すれば良いのか少し分かりづらかったのでメモを残しておきます。

設定内容

ALBのリスナー設定画面

f:id:jiig999:20210805184856p:plain
リスナーの認証設定

発行者

https:// + Auth0のDomainの値をつなげて、https://xxxxx.jp.auth0.com/形式にする

最後に/をつけるのを忘れないこと。私はこれをつけ忘れて一日ハマりました。。。

認証エンドポイント(認可エンドポイント)

https://<YOUR_AUTH0_DOMAIN>/authorize

トークンエンドポイント

https://<YOUR_AUTH0_DOMAIN>/oauth/token

ユーザー情報エンドポイント

https://<YOUR_AUTH0_DOMAIN>/userinfo

クライアントID

 ・Auth0でApplicationを作成すると生成されるClient IDの値

クライアントのシークレット

 ・Auth0でApplicationを作成すると生成されるClient Secretの値

これでOKです。

感想

いい感じです。 Webアプリのセキュリティを確保する上で、そもそもWebアプリまで到達できるユーザーは絞っておきたいです。
ログイン認証を強固にすることももちろん大切ですが、それだけではセルフマネージなサーバーに対してログイン試行はできてしまうので、アクセス負荷がかかります。 できるだけ、AWSマネージな仕組みでアクセスをフィルタリングできたほうが楽ですよね。

AirTagを使ってみた

Appleから発売されたAirTagを購入したので少し使ってみて分かったことなどを書こうと思います。 AirTag - Apple(日本)

期待していたこと

広い公園やショッピングモールなどで、子どもと離れたときに見つけ出したいという課題の解決。子ども二人連れていると、どうしても離れてしまうことがあり心配だったので。

先に結論

ダメでした。期待していた、公園などで子どもを探し出すという使い方にはマッチしなかった。 もともと、"モノ"を探すことをコンセプトにしており、他の用途には向いていないことが、実際に使ってみて分かった。

使ってみて

AirTagsは、BLEだけでなくUWBという通信を使うことで、高精度の測位機能を実現しているらしい。 このことを知って以来、公園や屋内で、子どもとはぐれたときの活用を想定していた。

しかし、実際に子どもに持たせて、屋内遊戯施設で使ってみたところ、AirTagsを頼りに子どもを見つけ出すことは難しいと感じた。 なぜなら、期待していたUWBによる測位機能は、対象物が静止していることを前提に最適化されているようで、動いている子どもの位置はほぼ検出できなかった。 移動しているから、位置が特定できないというメッセージが表示される。

f:id:jiig999:20210723184838j:plain

誤解して欲しくないですが、これはAirTagsが使い物にならないというわけではない。 本来の使い方と違う使い方をしてみた結果なだけである。

あと、Find Myによる世界中のiPhoneメッシュを利用した位置検出を試してみたくて、車の中にひとつ置きっぱなしにしてみた。

やってみたところ、妻が運転しているときなど、クルマがだいたいどのあたりにいるかを知ることが出来る。 リアルタイム制は期待できないが、わりと使えそう。ただし、相手のスマホに『近くにあなたのモノではないAirTagsがありますよ』的なメッセージが表示されるので注意。これはストーキングなど悪意あるユーザーが他人の荷物にAirTagsしのばせて位置トラッキングすることを防止するための配慮だと思われます。

使ってみて、自分はあまり忘れ物や落とし物を しないので活用シーンが無いことに気づかされました。 紛失したときの保険としてはいいのだろうが、紛失しない間は価値がゼロというのが地味にコレ系のスマートタグ共通の弱点かも知れない。

新事業アイデアの考え方

新事業や新しいサービス・プロダクトのアイデアの考え方を考えてみた。

文脈は企業内の新規事業企画。 企業内で新事業やサービスなんかのアイデアを考えるときって、売れるならどんなアイデアでもいいよ、という事は稀で、 実際には様々な制約があり、それにマッチするアイデアである必要があることがほとんど。
であれば、まずは発散!とか、デザイン思考でしょ!みたいに同じアプローチで挑んでも、狙った制約範囲に着地できる確率は低く、非効率である。
そうなりたくないので、制約ごとにいくつかのやり方パターンに分けられるのではないかと思い、整理してみた。

1. モノをベースにするやり方

1-a. モノを外したくないケース

例)冷蔵庫を使って何かやりたい。冷蔵庫に新しい機能や関連サービスを追加したいというケース。

冷蔵庫とは何か、を徹底的に考え、既存の枠(フレーム)を作る。そしてその枠を壊すやり方。
「冷蔵庫×〇〇」とか、「もし冷蔵庫が〇〇だったら」とかで発散して光るものを探す。

1-b. モノを外しても良いケース

例)冷蔵庫の周辺で新しいアイデア無いか?冷蔵庫自体は必須ではない

冷蔵庫を使うとき、その周辺を含めてユーザー体験を描く。 観察(エスノグラフィー)から入ってもよいし、自分で想像できるなら、ペルソナ設定してカスタマージャーニーマップを描くところから入っても良い。 いずれにせよ、冷蔵庫にまつわる体験において、PainとGainを洗い出して考えていくアプローチをとる。

2. 課題から入るやり方

2-a. 解決したい課題が決まっているとき(狭い)

ある意味ベーシックなスタートアップのやり方が適用できる。課題の存在確認とソリューションを提供可能(パートナー協業含め)かは気をつける必要がある。 最初に課題フォーカスしている分、それが外しているかも?というときに冷静になってピボットする割り切りを持てるかどうかがキモになる気がする。

2-b. 対象領域だけが決まっているとき(広い)

定性インタビューや観察から、課題仮説を立てるところから始める。立てた仮説はちゃんと検証してC/P fitしているか確認を忘れない。あとは2-aと大差ないかも。せまい課題に固執していない分、ピボットに対する受容度も高いはずなので、いかに早く安く仮説検証を回すか、その能力者(体制)を組めるか、がポイントになりそう。

なんかいずれにせよ、抽象度の上げ下げを意識的に行い、本質課題に迫ること(およびその手段は柔軟に考える)、あくまで仮説であり、検証を小さく早く回すことが大事ということ、が重要ということに尽きる気がしている。

会計に関する用語の整理

会計に関する用語を何回も調べているので、ここらでメモ代わりに整理しておくことにします。

限界利益

売上高から変動費をひいた部分。 限界利益 = 売上高 - 変動費

「限界」ということばは、「ギリギリ」という意味ではなく、「一単位増えるごとに」という意味合いなので注意。 「貢献利益」ということもある。

粗利(売上総利益

売上高から売上原価をひいた部分。
限界利益と似ているが、限界利益変動費のみをひいたもの。粗利は、変動費と固定費を一部含めた売上原価をひいたもの。 具体的には、製造に関わる人件費などがひかれる。

営業利益

限界利益から固定費をひいたもの。本業の利益ともいう。

営業利益 = 売上高 - (売上原価 + 販管費) 営業利益 = 限界利益 - 固定費

限界利益が無い状態では、いくら効率化をはかっても儲からないと言える。

(新規事業では、限界利益が出るところまで事業のあらゆる側面でチューニングする必要があるということ)

限界費用

生産量が一単位増えたときに増加する費用。ひとつあたりの変動費と捉えるとよい。 ソフトウェアのライセンスビジネスの場合、限界費用がほぼゼロになる。

P/Lを5つの箱で見る

https://news.yahoo.co.jp/byline/kandatoshiaki/20201130-00210279/ こちらのサイト。

P/LはProfit and Loss statementの略で、損益計算書のこと。 B/SはBalance Sheetで貸借対照表のこと

P/Lはある一定期間の間に得られた売上から、かかった費用をひいた差をもとに、損益を計算する表。 期間の概念を持っている。(2020年度のP/Lなど)

BSは、ある時点で持っている財産の状態を、資産・負債およびその差額である純資産に分けて表した表。 期間の概念はなく、ある特定時点でのスナップショットである。

参考) - PLとBSの関係を図でイメージする

経常利益

営業利益が本業の利益を表すのに対し、本業以外の収益・損失を含めたものが経常利益。

経常利益 = 営業利益 + 営業外収益 - 営業外費用

ROE

自己資本比率。自己資産を使ってどれだけ利益を生んでいるか。 ROE(%)=当期純利益÷純資産(総資産-負債)×100

ROA

総資産利益率。総資産を使って利益を生む効率を表す。経営の効率の良さを表す。 5%を超えると優良企業といわれている。 ROA(%)=当期純利益÷総資産×100

売上高利益率×資産回転率と分解することも出来る。

ソフト開発を内製化した方が良いか考察

はじめに

ソフトウェアを本気でビジネスで活用しようと思うなら、ソフトウェア開発を内製化したほうが良いという仮説について考えてみた。
とくにアジャイル開発が主流になってくるであろうDX文脈において、開発を外部発注することの構造上の歪みを感じていたので、自分の思考を整理するために、まとまってはいないが書き連ねてみることにする。

アジャイル開発と内製化

日本ではソフト開発専門の会社に発注する(ようはアウトソース)ケースが多く、受託開発自体を本業とするSIerやSEという業種・職種が多く誕生してきた。欧米では違うらしいが。

自分たちが必要とするものが何か完全に見通せていれば、それで仕様化して発注してあとは待つだけ、というやり方でできるのだが、そんなことは滅多にない、ということが分かってきた。 使ってみて、フィードバックを得て、それをまた取り込んで、というやり方のほうが、本当に価値あるものを作り上げて手に入れることができる。これがアジャイル開発を導入する目的でもある。

では、ソフト開発会社に委託しつつも、アジャイルでやってもらえばいい、という考えもある。 それも一理あるし、実際にそのスキームでITシステム開発を行っている事業会社も日本には多い。

ここで、事業側(委託側)と開発会社(受託側)それぞれビジネスモデルについて考えてみる。

  • 事業側は、開発したシステムを使って何らかの売上をあげる。売上-開発費用=利益となる(超ざっくりですが)。同じモノなら、安く作れば作るほど利益を増大することができる。

  • 開発会社は、開発費用をもらって開発する。開発にかかる費用を差っ引いた残りが利益となる。

事業側も開発会社側も、それぞれ自社のビジネスをやっているわけなので、売上拡大や利益増加が重要な経営指標となっているはずである。 開発会社はたくさん仕事を受注し、それを少ない工数で完了させればさせるほど、利益率が大きくなる。 したがって、請負開発において同じ金額の開発を比較した場合、技術力向上やツール導入によって効率化をはかり生産性を向上させることで、自社の利益を大きくすることが出来る。つまり、生産性向上が利益に直結するわけである。(=生産性向上に対するインセンティブが働く

一方、アジャイル開発では、準委任契約となることが多い。 準委任契約のとき多くの企業では、アジャイルチームの人数×人月単価で契約をすることになる。そうすると、技術力やツール導入で効率化をしようがしまいが、利益率は一定である。 つまり、実績工数ベースの準委任契約では生産性向上が開発会社にとって自社の利益に直接は結びつかなくなるのである。(=生産性向上に対するインセンティブが働かない

長期的な目線で、事業側の予算内で多くの成果を上げ続けることで、事業の存続確率(継続性)とソフト発注にかけることのできる予算が確保できるという考え方もできるが、そこまで考えて活動できる受託開発会社は少ないのではないか。
目先の売上と利益確保が最優先で、細くとも長く継続することでLTVを最大化するといった、サブスクにあるような継続率を追いかける考え方は難しい。

また、受託開発で売上を伸ばし利益額を増大していこうとすると、エンジニアの頭数がボトルネックになってくるため、プロパー社員だけではスケールに限界がある。 したがって、協力会社への再委託や派遣社員といった形でプロパー社員ひとりあたりの抱える人数を増やすことでしか売上をスケールさせることができない。 結果として、実装に関与せずに比率としてメンバーの管理業務が多めの社員が増えていく。

継続的に開発し、ノウハウが蓄積されるようなソフトウェアの開発は、内製化したほうが良い。正しく内製化してこそ、ノウハウ獲得や自動化による生産性向上を自社の利益に還元できる。 (すでに業界や技術が枯れていて、どこがやっても生産性はある程度突き詰められているようなものは外部に発注してもよい)

新技術やツールの導入が、業績につながるような事業構造になっていないと、新しい技術の獲得がむくわれない。
もしくは上層部の理解が得られず、こっそりやるしかない。手を打つのが遅れる(そういう発注が来るまでやらないから)

わかりやすい例が、テスト自動化である。 受託開発会社にとっては、テスト自動化が自分たちのビジネスの利益につながらない。(競合についていくため/競合差別化という点では意味があるが)
力をかけてやる意味が薄い(毎回テスト工数をもらう方が売上稼げる)し、持ち出しで技術的負債を解消する意義はない。発注があれば対応する、という動き方になる。

事業会社とアジャイルチームを組んで人を完全に組み込んだ形の入り方は、開発会社からすると、メリットが薄い。高レートで長期的に体勢確保してもらえるならいいが、スケールはしない。 ソフト開発とソフトファーストや事業を切り離すことに無理がある。

つまり、目指しているゴールがそもそも違う2社でやっていく限りしょうがないということになる。

  • 事業会社は、事業による売上と利益を追求する
  • ソフト開発会社は、ソフトウェア開発それ自体で儲ける

そこで、内製化もしくは子会社戦略が必要になる。このとき、何も考えずに子会社を売上と利益をあげることを目標にして経営すると、外部の開発会社を使っているのと同じ事が起こるので注意が必要。 そうではなく、親会社のゴール達成の一部を切り出したミッションを開発子会社に与えるべきである。そうすると、ソフト開発の売上や利益よりも重要な指標があるはずである。 外部の会社にそんなことをお願いするのは無理だが、子会社に対してなら経営目標や方針にまで関与できるはず。アジャイル開発の時代に開発子会社をつくる意義はそこにあるのではないだろうか。

自由競争させるか、開発効率化するメリットが開発会社サイドにないと、新しいことに先行的に取り組んでいくモチベーションがうまれにくい。

結論

  • アジャイル開発が適しているようなものは、内製化がベスト
  • 内製化がリソース的に難しいなどであれば、開発子会社(OR関係会社)という手もあり。ただし、子会社は売上追求型ではなく提供価値重視型の経営となるように工夫が必要。
  • 丸投げしても本当にOKといえる部分は、外部に発注すればよい(なんでもかんでも丸投げはダメ)