たくろぐ！

はじめに

アジャイル（スクラム）開発向けのプロジェクト管理ツール。

現場で無料で使えるっぽいので4人のチームで利用中。

直感的に操作できるのでUI最高。

今までプロジェクト管理ツールはRedmineをつかっていて、スクラム始めたチームとかにいいと思う。

用語

しょっぱないろんな設定をみていて、つまづきそうな用語のみをピックアップした。

単にスクラム初心者マンなだけかもしれない。

ラベル

community.atlassian.com

ラベルを一括編集するUI画面はなさそう。

日本語で調べると、Confluenceのラベルが出てきたのでこれと連動しているのかなと思ったが特に関連はなさそう。

JQLでバルク処理は可能とのことだが、今の所使い所はなさそう。

Epic

課題タイプの一つ。

課題タイプは簡単に言えば課題のタグ（階層構造を持たない）のことだと思う。

階層構造を持つカテゴリはないんだね。

関連する一連のバグ、ストーリー、タスクのこと。

ロードマップ（ガントチャートみたいなやつかな）を作る際の単位にもなっている。

課題タイプにはほかに以下がある。

ストーリー
タスク
バグ
サブタスク

ロードマップ使わなそうだし、なくてもいいかも。

ストーリー（たぶんユーザーストーリーのこと）と何が違うのかがよくわからない。

Epic name

It is intended to be used to label any issues that that belong to the Epic.

Epicに属する課題にラベルをつけるために使われる。

課題タイプ画面スキーム

今のプロジェクトは以下の名称になっている。

初期設定の際に選んだ内容が反映されているはず。

プロジェクト名: Kanban Issue Type Screen Scheme

いわば課題タイプと画面スキームの組み合わせの総称で、以下のようにそれぞれが対応関係にある。

課題タイプは「規定」、「バグ」
画面スキームは「PJ名: Kanban Default Screen Scheme」、「PJ名: Kanban Bug Screen Scheme」

画面構成

プロジェクトのアーキテクチャや設定、編集画面等の重要な画面のみをピックアップした。

全体

まずはJiraのみでなく、Atlassian製品全体の設定項目。

管理画面

以下のようなメニューがある。

会社概要
ディレクトリ
- 管理対象アカウント
- ユーザーのプロビジョニング
- ドメイン
セキュリティ
- SAML シングルサインオン
- パスワードの管理
- Session duration
- 2 段階認証
- 監査ログ
- Insights
設定
サイト
- ユーザー管理
  - ユーザー（デフォルト）
  - グループ
  - アクセスリクエスト
- サイト設定
  - サイトへのアクセス
  - 製品アクセス
  - G Suite
  - 絵文字
  - 接続済みのアプリ
  - ストレージ
- サブスクリプションと請求
  - 請求
  - サブスクリプションを管理
  - アプリケーションを検索
- アプリケーション設定
  - Jira
  - Confluence（静的サイトジェネレーターとか、設計書等を書くためのもの。普通にメモ帳代わりにも使える。）
- 新しい管理者機能
  - フィードバックを送る

Jira Software画面

次にAtlassian製品の個別設定画面をみていく。

Jiraはプロジェクト（タスク）管理ツール。

まずはここから始める人も多そう。

プロジェクト設定

プロジェクト設定
- 詳細
- ユーザー
- 概要
- プロジェクトの削除

課題タイプ(編集はここ)
課題レイアウト

ワークフロー
画面
フィールド

バージョン
コンポーネント

権限
課題セキュリティ
通知

課題コレクター

課題編集画面

課題タイプ
- 課題タイプ
- 課題タイプスキーム
- サブタスク
ワークフロー
- ワークフロー
- ワークフロースキーム
画面
- 画面
- 画面スキーム
- 課題タイプ画面スキーム
フィールド
- カスタムフィールド
- フィールドの構成
- フィールドの構成スキーム
課題機能
- 時間管理（1日の作業時間等の設定が可能）
- 課題のリンク（ブロッカー、クローン、複製、関連を管理するリンクを編集できる）
課題の属性
- ステータス
- 解決状況
- 優先度
- 課題セキュリティスキーム
- 通知スキーム
- 権限スキーム

疑問

無料なの？

わからないが特にクレジットカード等の登録なく利用できている。

おわりに

いったん主要な用語や設定画面についてまとめてみた。

更新するかはわからないです。

備忘録のためにまとめているので悪しからず。

注釈

この記事は音声認識ソフトを利用しております。

読みづらい部分がありますが、ご了承ください。

OAuth徹底入門

これから認証や認可に関しての本の紹介をしたいと思います。

OAuth徹底入門という本です。

この本は大きく4部16章に分かれています。

まず第一部としてそもそもOAuthって何ということを話します。

次に第二部では環境構築します。

認可を取得するにあたっていろいろなですね付与方式というものがありましてその説明もこの中でします。

この環境構築でOAuthの大まかなワークフローが理解できます。

例えば認可サーバというものや、保護対象リソース、アクセストークンやクライアントという考え方が理解できます。

次の第三部ではOAuthを実装するにあたっての注意点としていろいろな脆弱性を紹介します。

そして最後の第4部これが11章から16章までなんですがこのOAuthの応用的な使い方について紹介します。

この中でOAuthを使ったユーザー認証を紹介します。

OAuth自体は認可システムですが、これを応用してOpenID connectという認証も備えたシステムを構築することができます。

OAuthとは

では早速始めていこうと思います。

最初にOAuthとは何かについて話そうと思います。

このOAuthというのは、簡単に言えば権限委譲するためのプロトコルです。

説明するにあたり、構成要素を考えてみたいと思います。

1つはリソース所有者です。

このリソース所有者とはAPIのアクセス権をもちそのAPIではアクセス権を以上できる所有者のことです。

次に保護対象リソースです。

この保護対象リソースとはリソース所有者がアクセス権を持っているリソースのことです。

多くの場合、なんらかのWeb APIになります。

次にクライアントです。

一般的なクライアントとは違って、ここでの文脈のクライアントというのは、リソース所有者の代わりに保護対象リソースにアクセスするソフトウェアのこと指します。

これらを踏まえてOAuthについて簡単に説明すると、

まずリソース所有者はブラウザでクライアントにアクセスします。

そこでリソース所有者はそのクライアントから操作させたい保護対象リソースのクレデンシャルをわたします。

そうすることでそのクライアントは保護対象リソースにアクセスしその権限でいろいろな操作をすることができるようになります。

ただしこの場合だとクライアントと保護対象リソースが同じドメインの場合は問題ありませんが、クライアントと保護対象リソースが別ドメインだった場合セキュリティー上のリスクが伴います。

そこでもう一つ保護対象リソースにアクセスするための権限を与える認可サーバというものができました。

この認可サーバーは保護対象リソースに信頼されているサーバーで特別な目的を持ったセキュリティクレデンシャルをクライアントに発行するものです。

ここでいうセキュリティクレデンシャルというのはアクセストークンのことです。

このアクセストークンというのは文字通り、保護対象リソースにアクセスするための通行券みたいなものです。