FREITAGEEK

FREITAGが好きなエンジニア

FIDO認証を調べてみた

FIDO認証に興味があり、FIDO認証とはどういうものなのか、どういう仕組みで実現されているのか、を調べてみたので今回はそれについて書いていこうと思います。実装については触れていないのと、FIDO Allianceの仕様書をがっつり読み込んだわけではないので、ざっくりの概要レベルの説明になっているのでご容赦ください。

ゴール

  • FIDO認証の処理の流れがわかる

  • FIDO認証の仕様の分類がわかる

FIDOとは

FIDOとは、「Fast IDentity Online」の略で、FIDO Alliance - Open Authentication Standards More Secure than Passwordsによって仕様策定や普及推進が進められている、公開鍵認証に基づいた認証仕様です。

FIDOの用語

FIDOでは「Relying Party(RP)」という、ユーザの登録、認証を行うwebサイトや事業者を表すものと、「Authenticator (認証器)」という秘密鍵と公開鍵を生成, 保持するものが登場します。さらに認証器は、ローカルに実装されている内部認証器と、スマホなどのデバイスに実装されている外部認証器の2種類に分類されます。

FIDOの仕様

FIDOは以下の3種類の仕様が策定されています。

  • UAF

  • U2F

  • FIDO2

UAF

UAFは、「Universal Authentication Framework」の略で、パスワードレス型(所持+生体, etc)の認証仕様について策定されたものです。 UAFは、主にスマートフォンのアプリからの利用を想定したものになっています。

U2F

U2Fは、「Universal 2nd Factor」の略で、パスワード補完型(記憶+所持)の認証仕様について策定されたものです。 U2Fでは、パスワード認証の補完として生体認証やハードトークンの利用を想定したものになっています。

FIDO2

FIDO2は、外部認証器や内部認証器を用いた、パスワードレス型認証や多要素認証を実現するための仕様について策定されたものです。 FIDO2は、ブラウザ上でFIDO認証を実現するための標準APIであるWebAuthnと、認証器との通信プロトコルであるCTAPという仕様で構成されています。

WebAuthnは、正式には「W3C Web Authentication specification」と呼ばれるものでCTAPを用いてFIDO認証を行うための標準APIの仕様が記述されています。当初はFIDO Allianceによって仕様策定が進められていましたが、現在はW3Cで仕様策定が進められているようです。 またブラウザではChromeFirefoxなどがWebAuthnに対応しています。

CTAPは、Client-To-Authenticator-Protocolの略で認証器を用いてFIDO認証を行うための通信プロトコルの仕様が記述されています。 CTAPには、FIDO Security Keyを認証器として利用してFIDO認証をおこなうためのプロトコルであるCTAP1と、FIDO Security Keyに加えスマートフォンを認証器として利用してFIDO認証をおこなうためのプロトコルであるCTAP2の2種類があります。

FIDO認証の流れ(内部認証器を使った場合)

内部認証器を用いたFIDO認証の流れを「登録」と「ログイン」のフローに分けて書いてみます。

登録

  • ユーザがPCからRPにサービスを利用したい旨をリクエス

  • RPはチャレンジを生成してPCにチャレンジを返す

  • PC(Authenticator)は鍵ペアを生成して、チャレンジを秘密鍵で署名したものと公開鍵をRPに送信

  • RPはチャレンジや署名を検証して公開鍵を保存

ログイン

  • ユーザがPCからRPにログインしたい旨をリクエス

  • RPはチャレンジを生成してPCにチャレンジを返す

  • PCは送られてきたチャレンジを秘密鍵で署名してRPに送信

  • RPは署名を検証して認証をおこなう

最後に

FIDO認証(FIDO2)は、ブラウザなどのWebサイトでパスワードレスで認証をおこなう方法を実現するものとして期待されています。 現状、国内でもFIDO認証を導入した事例が出てきているので、今後さらにFIDOに注目していきたいと思います。(余力があればYubikeyなどを買ってFIDOの実装をしてみたい、、、)

参考資料

Hugoを使って生成した静的ページをGithub pagesにデプロイする

今回はHugoを使って生成した静的ページをGithub pagesにデプロイしてみようと思います。 公式サイトを参考にしているので、まずは公式サイトを読んで試してみてください。

やりたいこと

環境

環境は以下の通りです。git, hugoはすでにインストールしてある前提です。hugoが入っていないmacの人はbrew install hugoしましょう。

  • macOS 10.14.5

  • Git 2.19.1

  • hugo 0.55.6

手順

Githubに[username].github.ioを作成する

GitHubリポジトリを作成してcloneします。

$ git clone https://github.com/dais39/dais39.github.io.git

Githubに管理用のリポジトリを作成する(Hugoを導入するリポジトリ)

GitHubリポジトリを作成してcloneします。

$ git clone https://github.com/dais39/hugoadmin.git

$ cd hugoadmin

プロジェクトを作成

$ hugo new site myPage

$ cd myPage

$ ls 
archetypes  config.toml content     data    layouts     public      resources   static      themes

テーマを導入

https://themes.gohugo.io/ から自分の好きなテーマを探して、git submoduleでtheme/配下にテーマを紐づけます。 今回は以下のテンプレートを使います。

GitHub - jacobsun/edidor: A hugo theme that looks like an editor with a builtin style generator, INFINITE COLOR MODE from a market perspective. 😂

$ git submodule add https://github.com/jacobsun/edidor theme/editor

次にconfig.tomlの中身を修正して、テンプレートを有効にします。

$ echo 'theme = "editor"' >> config.toml

publicディレクトリを削除

ない場合はスキップでOK

$ rm -rf public

デプロイ先のリポジトリをpublicディレクトリと紐づける

$ git submodule add -b master git@github.com:dais39/dais39.github.io.git public

デプロイ用スクリプトの作成

以下の内容でdeploy.shをmyPage配下に作成します。 作成後ファイルの権限をchmod +x deploy.shで変更します。

#!/bin/bash

echo -e "\033[0;32mDeploying updates to GitHub...\033[0m"

# Build the project.
hugo # if using a theme, replace with `hugo -t <YOURTHEME>`

# Go To Public folder
cd public
# Add changes to git.
git add .

# Commit changes.
msg="rebuilding site `date`"
if [ $# -eq 1 ]
  then msg="$1"
fi
git commit -m "$msg"

# Push source and build repos.
git push origin master

# Come Back up to the Project Root
cd ..

デプロイ

./deploy.shを実行するとデプロイ先のリポジトリにpushされます。 https://[username].github.io にアクセスすると、ページが表示されていると思います。

参考資料

https://gohugo.io/hosting-and-deployment/hosting-on-github/

スクラムについて

今回は、Scrum Guideをはじめとした様々な書籍や資料を読んだり、業務でスクラムマスターとしてやっていく中で自分が腑に落ちた部分を書いていこうと思います。粗いところは少しずつ加筆して行こうと思っています。今まで読んできた主な書籍や資料は、参考資料として最後にまとめておきます。

そもそもアジャイルとは

スクラムとは

  • 問題を浮き彫りにするフレームワーク
  • Scrum Guideに則る
  • スクラムは経験的プロセスを基本としている
    • 経験したことから学ぶ
    • やってみないとわからない、というスタンス
    • 具体的に起きたこと、経験したことを元に業務を進めていく
    • 机上の空論にしてしまうと、結論がでない、メンバーの理解が得られない、背景の共通認識を得られない、といったことが起こりうる
  • 経験的プロセスは以下の3つの柱によって支えられている
    • 透明性
      • 何を作るか
      • 誰がやるか
      • いつやるか
      • なぜやるか
      • どうやってやるか
    • 検査
      • 成果物のレビュー
      • プロセスのレビュー
    • 適応
      • 問題に対して柔軟に対応する

スクラムの役割

  • プロダクトオーナー(PO)
    • プロダクトのあるべき姿に対して責任を持つ
    • ROIを常に考えて、最小の機能で最大の効果を得られるようプロダクトを導いていく
  • 開発チーム(Dev)
    • プロダクトの開発に責任を持つ
  • スクラムマスター(ScM)
    • スクラムチーム(PO, Dev, ScM)の成長を促したり、障害の除去に対して責任を持つ
    • 自走できるチームを作りあげることや、チームの問題を浮き彫りにしやすくする仕組みや支援を行う

スクラムイベント

  • スプリント
    • 目的
      • 決まったタイムボックスを設けることで、スクラムチームのベロシティ(生産性)を測定するため
    • 2~4週間のタイムボックス
    • プロダクトの方針と今やっていることに乖離が出た場合POがスプリントの中止をおこなうこともできる
  • スプリントプランニング
    • 目的
      • スクラムチームがスプリントで行うタスクの深い理解を得るためにおこなう
      • 開発チームが自律的に動く環境を作るため
    • プロダクトバックログの中から、スプリントで実現するアイテムを選ぶ
    • アイテムの数は、前スプリントまでの実績(ベロシティ)を参考にする
    • ベロシティを計測するために、アイテムを実現するための想定作業見積もりを相対的なポイントとして開発メンバーで決定する
    • プランニングポーカーがよく使われる
    • 開発メンバーのポイントが揃うまで議論する。議論することで認識のズレや仕様の理解を確認できる。
    • アイテムを実現するために必要な作業を開発メンバーで洗い出す
    • スプリントで達成する目標(Sprint Goal)を決める
    • リファインメントなどでDefinition of Doneをあらかじめ決めておく
  • デイリースクラム
    • 目的
      • 透明性を確保し、開発チームの状態を可視化するため
    • 同じ時間、同じ場所で毎日15分開催
    • スプリントゴールに対して、以下の観点を共有する
    • 昨日やったこと
    • 次の24時間で行うこと
    • 障害になっていること
    • デイリースクラムは開発メンバーのもの。雰囲気や発言に影響がでてしまうので、スクラムチーム以外の人間を入れるのは良くない
    • 開発メンバーがいないからといってスキップしてよいものではない
    • リモートでできないか、時間をずらしてできないか考える
    • どうしてもできない場合は、決まったフォーマットでSlackに流してもらう
  • プロダクトバックログリファインメント
    • 目的
      • プロダクトがどういう方向に進んでいくかをスクラムチーム全員で共有するため
    • プロダクトバックログアイテムの優先度の調整や、あいまいな要件を精査し、次のスプリントに容易に取り組める状態を作る
  • スプリントレトロスペクティブ
    • 目的
      • プロセスの検証と適応によって、スクラムチームの状態を改善するため
    • 2週間スプリントの場合、1.5時間
    • スプリントゴールに対してチームの良い点、悪い点、次へのアクションをスクラムチームで共有する
    • KPTなどのフレームワークをつかうことが多い
  • スプリントレビュー
    • 目的
      • スプリントの成果物がスプリントゴールを満たしているか検証しプロダクトの状態を把握するため
      • プロダクトバックログの状態についてスクラムチームで議論し、より深い理解を得るため
    • 2週間スプリントの場合、2時間
    • POやステークホルダーなどとスプリントのインクリメントをレビューし、プロダクトバックログの精査を行う
    • 最終的にdoneを判断するのはPOだが、DoDを定義しておくことでスクラムチーム全員が納得のいくdoneになる
    • POがレビュー時に気が付いてdoneを変更することは基本的になし

スクラムの成果物

  • プロダクトバックログ
    • プロダクトを実現するために必要な機能やユーザストーリーを優先度の高いもの順に並べたもの
    • 一つ一つの項目をプロダクトバックログアイテムと呼ぶ
    • それぞれのアイテムに対してDefinition of Doneを用意する
  • スプリントバックログ
  • スプリントで着手する予定のプロダクトバックログアイテムと、それを実現するための作業をまとめたもの

スクラムをなぜやるのか?

  • そもそもチームとしてどういう状態を目指しているのか?
    • 自己組織化されたチーム
    • 変化に対して柔軟に対応し、利益を生み出すチーム
  • 業界やメンバーなど、チームを取り巻く環境は常に変化する
    • 変化に柔軟に対応でき、変化によって発生した問題を解消できているならスクラムを導入する必要はない
    • 問題を浮き彫りにすることでチームに成長の機会を与えるフレームワーク

参考資料

アジャイルソフトウェア開発宣言

アジャイル宣言の背後にある原則

2017-Scrum-Guide-Japanese(PDF直リンクです)

アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技

SCRUM BOOT CAMP THE BOOK

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

ユーザーストーリーマッピング

Spring Frameworkの@Componentと@Controller,@Service,@Repositoryの違いを調べてみる

Springの@Component, @Controller, @Service, @Repositoryの違いについて気になったので調べてみます。

Stereotype Annotation

@Component, @Controller, @Service, @Repositoryなどは, Stereotypeアノテーションと呼ばれるものです。Stereotypeアノテーションとは、コンポーネントがアプリケーション内でどういう役割を担うかを表現するアノテーションです。 Springでは@Componentが付与されたクラスを、アプリケーション起動時にBeanとしてApplicationContextに登録します。@Controllerや@Service, @Repositoryなどはアノテーション内部で@Componentが付与されているため、@Componentと同じくクラスに付与することで、そのクラスはBeanとしてApplicationContextに登録されます。Stereotypeアノテーションは他にも@RestControllerや@Aspectなどがあります。

Spring Annotation Programming Model · spring-projects/spring-framework Wiki · GitHub

Spring Annotation Programming Model · spring-projects/spring-framework Wiki · GitHub

org.springframework.stereotype (Spring Framework 5.1.7.RELEASE API)

@Controller

@Controllerは、付与したクラスがMVCのコントローラの役割を持つことを表現します。機能面では@Componentと同じです。 @Controllerを使う場合は@RequestMappingや@ResponseBodyと一緒に使うことが多いと思います。ちなみに@ResponseBodyをコントローラクラスの描くメソッドに付与するのが面倒な場合は@RestControllerというstereotypeアノテーションを付与することで、デフォルトで@ResponseBodyアノテーションが各メソッドに付与されます。

Controller (Spring Framework 5.1.7.RELEASE API)

RestController (Spring Framework 5.1.7.RELEASE API)

@Service

@Serviceは、付与したクラスがDDD(ドメイン駆動設計)のサービスの役割、もしくはCoreJ2EEパターンの「ビジネスサービスファサード」の役割を持つことを表現します。裏側の複雑な処理を一つにまとめたシンプルなインターフェースを提供する役割と思ってもらえれば問題ないです。@Controllerと同じく機能面では@Componentと変わりません。Serviceという名前が汎用的なので、チームでどういう役割のときに付与するかは決めておいた方がよいです。

Service (Spring Framework 5.1.7.RELEASE API)

@Repository

@Repositoryは、付与したクラスがDDDのリポジトリの役割を持つことを表現します。また、PersistenceExceptionTranslationPostProcessorクラスをBean として登録することで、@Repositoryを付与したクラスで起きた例外をSpring独自のDataAccessExceptionという非チェック例外に自動で変換してくれます。

Repository (Spring Framework 5.1.7.RELEASE API)

PersistenceExceptionTranslationPostProcessor (Spring Framework 5.1.7.RELEASE API)

DataAccessException (Spring Framework 5.1.7.RELEASE API)

ロバストネス分析について

最近はドメインモデリングやコンテキストマッピングなどDDDの文脈で言う所の戦略的設計の具体的な取り組み方がよくわかっていないので、「ユースケース駆動開発実践ガイド」(以下リンク参照)を読んでいます。

ユースケース駆動開発実践ガイド (OOP Foundations)

ユースケース駆動開発実践ガイド (OOP Foundations)

今回はその中で紹介されている、ロバストネス分析について、どういうものか、なぜやるのか、どうやってやるのか、を自分の頭の整理も兼ねて書いていきたいと思います。

ロバストネス分析とは?

ロバストネス分析とは、システムのユースケースを記述した文章を基に、オブジェクトを用いた図(ロバストネス図)を作成する作業です。 ロバストネス分析を行うことによって、ユースケースを記述した文章からクラス図やシーケンス図といったUML静的モデルが作りやすくなります。

ロバストネス分析をなぜやるのか?

ロバストネス分析を行う目的は主に3つあります。

第一に、静的モデルを作りやすくすることです。書籍に詳しく解説されていますが、ロバストネス分析ICONIXプロセスというソフトウェア開発プロセスの中で使われています。ICONIXプロセスでは、ドメインモデリングユースケース作成 → ロバストネス分析UML静的モデリング→...という流れで開発をしていくので、ロバストネス分析が終わった段階でUML静的モデリングがしやすくなっていることが重要です。そのため、ロバストネス図にはユースケースが漏れなく表現されていることが要求されます。

第二に、ユースケースの記述から曖昧さをなくすことです。ロバストネス図を作成していると、うまくオブジェクトでユースケースで表現できないときや、作成したロバストネス図ユースケースを比較すると微妙に異なる表現をしているときが出てくるときがあります。こういうときは、ユースケースの記述を見直して、書き方に問題がないかをチェックします。こういったチェックをしてユースケースの記述から曖昧さをなくすことで、実際にシステムを実装した後の仕様の抜けや漏れを減らすことに繋がっていきます。

第三に、見逃していたドメインオブジェクトを発見することです。第二のユースケースの記述から曖昧さをなくすことと同様、ロバストネス図を作成していると、ユースケースの記述にはなかった語彙や概念が出てくることがあります。新しい語彙が出てきたときやより的確に表現する語彙が出てきたときは、その語彙をユビキタス言語としてドメインモデルに反映させます。こうすることで、ソフトウェアと実際の業務で使われている語彙のズレを無くしていき、メンバー同士、チーム同士の認識の齟齬が起きないようにしていきます。

ロバストネス図の作り方

ロバストネス図で登場するオブジェクト

ロバストネス図は以下の4種類のオブジェクトを使って、ユースケースを表現していきます。

  • アクター

  • バウンダリオブジェクト

  • エンティティオブジェクト

  • コントローラ

アクター

システムと対話をするオブジェクト(人間, 外部システム)です。例えば、「ユーザ」です。 アクターの名前は必ず名詞を使うようにします。 表記はUMLユースケース図と同じように棒人間で表現します。

f:id:dais39:20190519150822p:plain

バウンダリオブジェクト

システム外部との境界を表現するオブジェクトです。例えば、「ログインページ」や「申請ページ」です。 バウンダリオブジェクトの名前は必ず名詞を使うようにします。 バウンダリオブジェクトは以下のように表記します。

f:id:dais39:20190519150908p:plain

エンティティオブジェクト

ドメインモデルを表現するオブジェクトです。例えば、「アカウント情報」や「申請情報」です。 エンティティオブジェクトの名前は必ず名詞を使うようにします。 エンティティオブジェクトは以下のように表記します。

f:id:dais39:20190519151414p:plain

コントローラ

ソフトウェアの機能を表現するオブジェクトです。例えば「ID, パスワードをチェックする」「申請情報の入力チェックをする」です。 コントローラの名前は必ず動詞を使うようにします。 コントローラは以下のように表記します。

f:id:dais39:20190519151631p:plain

ロバストネス図を書いていく

書籍では他にもいくつかルールやTipsが紹介されていたのですが、まずは以下のルールや方針に則って書いていくことをおすすめします。

実際にユースケースロバストネス分析で簡単に表現したものが以下になります。

f:id:dais39:20190519154724p:plain

この例では、「Actorはログインページにアクセスする。Actorはログイン情報としてIDとパスワードを入力してログインボタンをクリックする。システムはIDとパスワードをチェックして、問題なければTOPページを表示する。ログインに失敗した場合はエラーメッセージとともにログインページを表示する。」というユースケースロバストネス図として表現してみました。

おわりに

今回はロバストネス分析について、どういうものか、なぜやるのか、どうやってやるのか、について書籍を読んで学んだことをまとめてみました。 実際にロバストネス図から静的モデルを作成するところは、まだよくわかっていないので、これからやっていきたいと思います。おわり。

「経産省と本気でアジャイル開発をやってみた!〜」 参加レポート

先日、「経産省と本気でアジャイル開発をやってみた!制度ナビPJで見えたGovTechのリアルと未来」というイベントに参加してきたので、イベントの様子や参加して感じたことを書き連ねていきたいと思います。

議事録のようなものではなく、あくまで登壇者の発表を聞いて感じたことを一個人が書いているエントリなのでそこは、ご理解ください。また聞き逃しや勘違いをしている箇所があるかもしれないので、その場合はコメントで指摘していただけると助かります。

イベントの雰囲気

  • 主催はCode for Japanさん
  • 会場は経産省の地下2F
  • 約250名参加
    • 会場のアンケートでは参加者の割合では開発者の方が多かった
    • 省庁関係者の方らしき人もたくさんいたように感じた

挨拶&Code for Japan紹介

  • Code for Japan代表理事 関 治之 さんによる発表
  • イベント全体で質問したいことはslido.jpを使って集約
  • 今回のイベントは、以下のテーマを発表
  • このイベントの目的
  • Code For Japanとは
  • なぜ行政にアジャイルが必要か?
    • 完璧な仕様は書けない
    • プロジェクトが失敗したときのリスクが大きい
    • 異動が前提
    • デジタル化についての経験値が浅い
  • なぜ行政でアジャイルが難しいか?
    • 年度単位の予算
    • 知識不足
    • 受発注者間の信頼関係構築の難しさ
    • 失敗を忌避する文化

スマート公共サービス官民協議会から見えてきたこと

  • Code for Japan理事、前総務省大臣補佐官 太田 直樹 さんによる発表
  • 太田さんのブログで発表
  • スマート公共サービス官民協議会
    • 未来投資会議の一つ
      • 6月の未来投資戦略のための会議
      • 未来投資戦略によって次年度の予算が決まるため未来投資会議は重要
  • スマート公共サービス

    • GovTech
    • 公民の連携
    • データのオープン化
    • API連携の整備
    • LGWAN問題
      • 10年前は省庁のインターネットが遮断されていたらしい
    • 会津若松, 益田市, 加古川市などの官民連携事例
      • 行政の外にDBがあって公民連携
      • 同意した利用者のデータを集めている(オプトイン)
      • このデータをベースにサービスを作っている
      • 官民連携すればよい行政サービスが作れるのではないか?
    • 自治体向けアプリマーケットの事例
      • アプリの開発者と利用者の密なコミュニケーションを実現するため自治体向けアプリマーケットというものを作った
      • 残念ながらオープンデータを作るのは自治体だけど、活用するのは民間にお任せという考えを持っている人もいる
  • 失敗を通して組織の垣根を超えて学んでいくことが重要

経産省DXの取り組み

  • 経済産業省情報プロジェクト室 室長補佐 吉田 泰己 さんによる発表
  • 行政サービスと民間サービスの質の差が見過ごせなくなってきた
  • デジタルトランスフォーメーションという取り組みを行なっている
  • 解決したい問題
    • 国民、事業者にとって不便なサービス
    • 職員の業務効率が非効率
  • ユーザ中心のサービス作り
  • 優れたUI/UXからデータが集まるという認識
  • ビズリーチを使いながら民間から人材を集めてデジタル化を進めている
  • アジャイル支援を行っているベンダーと一緒にものを作っている
  • tableauを使ってデータ分析をしている
  • 認証やデータの連携基盤を標準化し、サービス間で利用できるようにする
  • 目指すこと
    • UI/UXの整備
    • データ分析基盤の整備
    • 行政サービスを民間と同じ水準に

制度ナビPJ紹介&デモンストレーション

  • 経済産業省中小企業庁 松原 匠 さんによる発表
  • なぜ制度ナビを作ったか
    • 職員でも適切な情報を探せる気がしなかったから笑
    • 電話帳みたいなガイドブック
    • ミラサポという既存のwebサービス
      • 施策マップがユーザの要求を満たす機能ではなかった
      • ユーザ目線になっていない
  • 制度ナビ
    • メール通知ではなくプッシュ通知
    • 補助金の人気はある程度固まっている
    • 検索結果の表示(ページング)
  • 導入したアジャイルプロセス
  • 3つの制度の問題
    • 定義の違い
      • 制度や法律によって定期が異なる
      • 定義があいまい
      • 説明を読んでも補助金の対象化わからない
    • 補助金リテラシー問題
      • 補助金交付要項分厚過ぎる
      • ルールが複雑
      • 毎年変わる
    • アプリの実証に使えるデータがない
      • データのフォーマットがなく組織ごとに独自フォーマット
      • 委託していて役所がデータを持っていないケースも
  • どうやって改善してくか
    • 行政の担当者の意識改善
    • 利用者から不便を訴えていく
      • 行政はなるべく手間をかけずにサービスを作っている

民間から見た行政のサービス開発

  • ギルドワークス株式会社 代表取締役 市谷 聡啓 さんによる発表

    www.slideshare.net

  • 今回のプロジェクトでは以下の3つの役割で動いた

    • マネジメント, PO支援, スクラムマスター
    • ここからすでに怪しげな雰囲気が感じられる笑
  • 発表のテーマは「現実対越境」
    • 案件はミラサポのリニューアル
    • 行政側がアジャイル開発をしたいということで今回支援にはいった
    • アジャイル開発への暗黙的な期待が感じられた
      • スプリントの空振り
      • 最終スプリントで浮き上がるこれじゃない感
    • まずアジャイル開発をなぜするのか、目指す状態を理解
    • その上で本当に期待と現実があっているのか?を考えた 「提案してー」でもなく「やってきてー」でもなく「自分たちで(も)やる」
    • 大きな問題
      • プロダクトの「全体感欠如」
        • 今回のミラサポ案件はアプリが3つにわかれている
        • ユーザの体験が3つのアプリに分断されてしまう
        • ユーザの統一的なUX設計ができない状態
      • データの境界は「組織の境界」
        • データが組織ごとにバラバラで管理されていたり、そもそもデータがない場合があった
        • データを揃えるのはスケジュール的に到底不可能
    • 現状維持の文化, 流れに立ち向かうには関係者全員が探索的にならないといけない
    • 上であげた2つの大きな問題を解決するのは体制と時間的に困難
    • 自分たちだけでできないのであればユーザを巻き込む
    • 3アプリ合同でユーザテスト実施
  • アジャイルのやり方を学ぶのではなく、なぜやるのかを考えることが大事
  • 「正しいものを正しく作る」という本を出します

民間による行政サービスのアジャイル開発

  • 株式会社グラファー 代表取締役 石井 大地 さんによる発表
  • 民間企業が行政サービスを開発する話
  • Graffer
    • 面倒な行政手続きをシンプルなUI/UXで提供するサービスを提供する企業
      • 46000種類の行政の手続き
    • Grafferは紙, API, スクレイピングで行政と連携
    • サービスは3.5人(0.5は代表の石井さん分)で開発
    • コンセプトを深く議論して〜というサービス開発ではなく、まず作ってみる。作った上で改善を加えていく。というやり方を取っている。
  • 技術力ではなく組織の文化が重要
  • アジャイルプロセスを取り入れたからといってうまくいくわけではない

パネルトーク①「行政は使いやすいデジタルサービスを作れるのか?」

  • 関さん, 松原さん, 林 大輔さん(経済産業省デジタル化推進マネージャ), 市谷さん, 平本 健二さん(内閣官房政府CIO上席補佐官/経済産業省CIO補佐官) によるパネルトーク
  • sli.doの質問に答えるタイム
    • 行政でコラボレーションツールはつかっている?
      • 部署によるがSlackやBackLogを使っているところもある
    • 組織を動かす, 説得するコツは?
      • 利用者視点と対案を用意する
      • 関係者としてプロジェクトに巻き込む
      • 当事者意識を芽生えさせる
      • ワークショップを開く
      • 手を動かす、頭を動かす機会を作る
    • アジャイルの納品っていつ?
      • 納品する側とされる側で優先度をすり合わせて決める
      • トレードオフスライダーを使った
    • 請負契約ではなく準委任契約でやったのか?
      • 準委任契約でやった
      • 準委任契約だが、準委任契約をそのままやるとうまくいかないので請負契約的なことをやった?
    • チャレンジングな取り組みを他に行なっているのか?
  • 行政は使いやすいデジタルサービスを作れるのか?
    • アジャイル開発を取り入れて開発のプロセスは改善できた
    • UXの改善はまだあまりできていないので今後重要なテーマ
    • アナログなプロセスを改善するシステムを目指して、そこからデジタルなものづくりを目指す
    • ユーザの立ち位置に立ってものづくりを考える
    • 行政の中でPdMが不足していることは深刻な問題
      • 人を管理するProjectManagerはいるが、サービスを管理するProductManagerがいない
      • ユーザ視点に立ってものづくりを考える役割を増やしていく
  • トライアルでアジャイル開発をやってきたが今後どのようなプロセスでミラサポを作っていくか?
    • まずはデータの整備
    • PdMを引き継いで部署横断で進めていく
  • 今後行政としてどうやってサービスを作っていくか?
    • 今までは大手ベンダーと連携をとっていくことが多かった
    • 今回新しい取り組みをしている企業と連携を取って新しいことをした
    • これをさらに大人数でやっていきたい

パネルトーク②「民間事業者と考える行政サービスの未来」

  • 吉田さん, 平本さん, 石井さん, 木村 康宏さん(freee株式会社 執行役員)によるパネルトーク
  • こういうAPIがあるといいなというのはある?
    • WebブラウザでできることはAPIで全部できるようにしてほしい
    • 行政プロジェクトにアサインしてエンジニアから不満が出ないような環境を用意してほしい
  • APIをどうやって作っていいのかわからない
    • APIを作ってください、というの要求になってしまっているのが現状
    • APIを作るためのレビュー環境を整えることが重要
    • アメリカではGitHubで仕様書を管理
  • 既存の窓口はユーザインターフェースとしてもっと重要視していいと思うが、現場との距離感はどう取り組んでるか?
    • 現状使われているところでもっと簡単に使えるようにするということが大事
      • データフォーマットの整備
      • 豊富なAPIの提供
    • ただ、行政としても最低限の窓口は持つ必要がある
    • メモ: 国としてはプラットフォームとして民間にデータを提供することに注力していきたいということなんだろうか?
  • 行政の評価の仕組みはどうなっているのか?
    • 行政内外でどれだけコストを減らせたのか(KPI)
    • サービスの利用率(KPI)
    • 正しい失敗を許容して評価していかないといけない
    • そのためには国民も正しい失敗を許容することを理解しないといけない
    • KPIを達成すれば適切な報酬が与えられるためには、公務員も人事制度改革をしていかないといけない
  • アジャイル開発を行う場合の契約どうしたらいい?
    • アジャイル開発用の契約書の雛形みたいなものがあればよい
    • 別の省庁で雛形について議論する機会があった
    • 経産省の今回のプロジェクトが支援をしていく必要がある
  • 行政サービスの未来を考える上で行政側に期待することは?
    • 失敗談を赤裸々に外部に公開してほしい
    • 届きにくい部署に、失敗してもいい文化がある、ということを届かせることが大事
  • サービス利用の契約をしやすくしてほしい

「なぜ、あなたの仕事は終わらないのか」を読んだメモ

以下メモです。

  • 8:2を意識する

    • 10日間だったら最初の2日間で8割終わらせるつもりで取り組む

    • できなかったら締め切りを伸ばす

    • あと8日間は「流し」

    • 残りの完成度を高める

  • モックアップをまず作る

    • アプリの更新と同じ

    • 最初から100%は作れない

    • 修正を繰り返す

  • 1日の仕事は午前中にほぼ終わらせる

  • 長期の仕事は10-14日単位で分けて取り組む

  • マルチタスクはしない

  • 並行した仕事がある時は1日の中で時間を分配して取り組む

  • 人の仕事は遅れるもの

  • 仮眠を取る

  • 花屋のエピソード

    • 「花をパーティーのために用意する」事が仕事

    • 「花屋にパーティーのための花を予約する事」が仕事なのではない

  • 問題を分割して考える

  • 崖から飛び降りながら飛行機を組み立てるつもりで行動する

  • 寝る前にタスクリスト作る