KindleをDeepLで翻訳しながら読む

はじめに

Kindleで洋書を読むときにiOS版やiPadOS版Kindleでは文章を選択すると翻訳してくれます。
ただ、Mac版のKindleには同じ機能が無いため、Mac版でなるべく楽に翻訳できる方法について私が試した方法になります。

翻訳の方法

翻訳は下記の手順で行います。

  1. Kindleで翻訳したい文章を選択
  2. 本文検索を実行
  3. 検索ボックスの文章をコピー
  4. DeepLアプリにコピーした文章を貼り付け

上記手順を翻訳のたびに手動で行うのは手間なので、Automatorとショートカットを使用しショートカットキーで実行できるようにします。

設定方法

ここからは、Automatorとショートカットの設定方法です。

Automatorの設定

1. Automatorを起動し「ワークフロー」を選択します。

2. Kindleアプリを画面の一番手前に表示するためのAppleScriptを登録します。

「ユーティリティ」の「AppleScriptを実行」を選択します。

スクリプトに下記を記載することで、Kindleを最前面に表示します。

tell Application "Kindle"
    Activate
end tell

3. 本文検索の操作を記録します。
この操作が実際に動くのは、Kindleで文章を選択後になるので、その状態に合わせるためにまずはKindleアプリで文章を選択した状態にしておきます。

文章を選択すると上画面のようなメニューが表示されるので、この状態でAutomatorの上部にある「記録」ボタンを押します。
ボタンを押した後の操作が記録されるので、Kindleアプリに切り替えメニューの「本文検索」をクリックし、クリック後記録を停止します。
Automatorに戻ると、Kindleへ切り替える操作と本文検索ボタンをクリックした操作が記録されています。

実際にKindleへ切り替える操作は2. のスクリプトで行うため、本文検索ボタンをクリックする操作以外は削除しておきます。

4. 本文検索をしたときに検索ボックスにフォーカスが当たっている状態のため、この検索ボックスの値をコピーします。

操作の記録の方法は3.と同じです。
⌘Aで検索ボックスの値を全選択、⌘Cで選択した値をコピーしています。

5. DeepLアプリを画面の一番手前に表示にします。
4.でコピーした文章をDeepLアプリへ貼り付けるために、DeepLアプリを画面の一番手前に表示します。
方法はKindleと同じように、スクリプトで行います。
tell Applicationに指定する名前は"DeepL"です。

tell Application "DeepL"
    Activate
end tell

6. DeepLアプリに4. でコピーした文章を貼り付けます。
DeepLアプリの原文の箇所に直前に翻訳した文章が残っているため、⌘Aで全選択し⌘Vで上書きコピーします。

選択した文章が貼り付けられ、翻訳されました。

ここまで終わったら、作成したワークフローを保存しておきます。

ショートカットへの登録

ここまででKindleで選択した文章をDeepLで翻訳するためのワークフローができました。
このままでは翻訳するたびにAutomaterを開き実行する必要があるため、ショートカットに登録し簡単に実行できるようにします。

1. Spotlightに「ショートカット」と入力しショートカットアプリを起動します。

2. 作成したワークフローのファイルをショートカットアプリへドラッグ&ドロップし登録します。

3. 登録したショートカットを右クリックし「編集」を選択します。
右上の「ショートカットの詳細」を選択し、「詳細」タブの「次で実行」に割り当てたいショートカットを登録すします。

これで登録したショートカットキーで翻訳ができるようになりました。
あとはKindleで調べたい文章を選択し、登録したショートカットキーを押せば翻訳が行われます。

初回の実行時はプライバシーの許可を求めるウインドウが表示されるので、許可してください。

改善したいこと

ここまでの内容でやりたかったことは出来ているのですが、ショートカットキーを押してからワークフローが動き始めるまで(「本文検索」をクリックするまで)に2秒程度時間がかかります。
どこに問題があって時間がかかっているのかは分かりませんが、もっと短い時間にする方法にしたいと思っています。

Apple silicon搭載のMacでSQL Serverを動かす

SQL Server Docker

現在Apple siliconに対応したSQL Serverは現状ありませんが、Docker Desktop Version がRosettaをサポートしたことで、SQL Server Linuxを動作させることができるようになりました。
SQL Server Linuxを動かしてみたので、その際の手順になります。
Dockerを使ったSQL Server Linuxについては、Microsoftのページにも記載があるため、こちらを参考にしました。
learn.microsoft.com

今回はコンテナ起動時のパラメータを毎回入力しないようにするために、docker-composeを使用しました。

環境

  • Apple M1 Pro macOS Ventura
  • Docker Desktop Version 4.16.2

手順

1. Docker DesktopでRosettaを有効にする

Docker DesktopのSettingで「Use Rosetta for x86/amd64 emulation on Apple Silicon」にチェックを付け有効にします。

2. docker-compose.ymlを作成

docker-compose.ymlを下記内容で作成します。

version: '3'

services:
  db:
    image: mcr.microsoft.com/mssql/server:2022-latest
    platform: 'linux/x86_64'
    ports:
      - '1433:1433'
    volumes:
      - './data:/var/opt/mssql/data'
      - './log:/var/opt/mssql/log'
      - './secrets:/var/opt/mssql/secrets'
    environment:
      - 'ACCEPT_EULA=Y'
      - 'MSSQL_SA_PASSWORD=${MSSQL_SA_PASSWORD}'
  • 公開されているDockerイメージはx86_x64なため、platformを指定しています。
  • コンテナを削除時にデータが消えないよう、volumesで保存先にホストのフォルダを指定しています。
  • ${MSSQL_SA_PASSWORD}はSQL Server の既定のパスワード ポリシーに従ったパスワードに置き換えてください。
3. コンテナを起動

docker-composeコマンドで起動します。

$ docker-compose up -d


コンテナが起動しているかどうか確認します。

$ docker-compose ps -a


出力結果のSTATUSがUpとなっていれば起動しています。

NAME                IMAGE                                        COMMAND                  SERVICE             CREATED             STATUS              PORTS
mssql-db-1          mcr.microsoft.com/mssql/server:2022-latest   "/opt/mssql/bin/perm…"   db                  11 seconds ago      Up 9 seconds        0.0.0.0:1433->1433/tcp
4. 動作確認

コンテナへ接続後のデータベースの作成からデータの登録まではMicrosoftのサイトに記載の「データの作成とクエリ」のとおりのため、記載を省略します。

コンテナへ接続

$ docker-compose exec db bash


sqlcmdでSQL Serverへ接続

$ /opt/mssql-tools/bin/sqlcmd -S localhost -U SA -P <パスワード>


データベースの作成からデータの登録までは、下記ページのとおりに実行します。
learn.microsoft.com

コンテナ外からの接続は、VS Codeの「SQL Server (mssql)
」を使用しました。
marketplace.visualstudio.com

コンテナ上で登録したデータが参照できました。

まとめ

まだプレビュー版ですが、Docker DesktopのRosettaを使用することでSQL Serverを使用することができました。
Apple siliconのMac上で開発する際に、SQL Serverも含めてローカル内で開発を完結させられるようになったのは良いのではと思います。

App ServiceへASP.NET CoreのWebアプリケーションを初めてVisual StudioでデプロイするときのWindowsとMacの違い

2023/1/29 追記

最初はVisual Studioからのデプロイが楽なように思えたけれど、AzureではGitHub Actions等の継続的デプロイが簡単に設定できるので、積極的に利用した方がいいと思います。

私はこれまでGitHub Actionsを利用したことがありませんでしたが、App Serviceのデプロイ センターを利用すると画面の指示どおりに選択、入力するだけで連携できとても楽に設定できました。

↑2023/1/29 追記ここまで
　

ASP.NET CoreのWebアプリケーションを作成しAzure App Serviceへ公開する時に、Windowsの場合、Visual Studioだけで完結できましたが、Macの場合は、Visual Studio for Macだけでは完結できませんでした。

発行後ブラウザでアプリへアクセスすると「Forbidden」画面が表示されました。

動作させるにはAzureポータルからApp Serviceの構成の「スタックの構成」を設定する必要がありました。

環境

Windows

Visual Studio Community 2022(Version 17.4.4)

Mac

Visual Studio for Mac(Version 17.4.3)

Webアプリの作成からApp Serviceへの発行までの手順

前提としてApp Service プランまではAzureポータルから作成済みです。

Windowsの場合もMacの場合も、テンプレートからASP.NET Core Webアプリを作成しAzureへ発行しているだけで、この時点での違いはありません。

Windows
  • Webアプリの作成

「新しいプロジェクトの作成」画面から「ASP.NET Core We アプリ」を選択し、フレームワークは「.NET 6.0」を選択。

それ以外はデフォルトで作成。

  • App Serviceへの発行

作成したプロジェクトを右クリックし「発行」を選択。

次に、発行先は事前に作成ずみのApp Service プランを選択し発行します。

デプロイが完了するとアプリの画面が表示されます。

Mac
  • Webアプリの作成

「新しいプロジェクト用のテンプレートを選択する」画面から「Web アプリケーション」を選択し、フレームワークは「.NET 6.0」を選択。

それ以外はデフォルトで作成。

  • App Serviceへの発行

作成したプロジェクトを右クリックし「公開」から「Azureに公開する」を選択。

次に、「Azure App Service に公開する」画面で「新規」を選択し、事前に作成ずみのApp Service プランを選択し発行します。

デプロイが完了するとアプリの画面が表示され……ませんでした。

Macで発行したApp Serviceの構成を変更

WindowsとMacで作成、発行したApp Serviceの構成を確認したところ、WindowsのApp Serviceにはスタックの設定がされていましたが、Macの方にはされていませんでした。

Windowsで発行したApp Serviceの構成

Macで発行したApp Serviceの構成

Mac側のスタックの設定をWindowsと同じにしたところ、無事アプリの画面が表示されました。

また、再度MacのVisual Studio for MacでAzureへ公開しようとしたところ、最初に公開したApp Serviceが選べませんでした。 もしかすると、Visual Studio for MacはAzureへの公開機能は完全に対応していないのかもしれません。

2016年振り返り

今年一年の振り返り

全然更新できていないのだけれど、やりたいことは沢山あったし、やりたいことが全然できていない一年。

フロントエンド

一番やりたかったのはangular(angular2)。チュートリアルやったぐらい。これだけ書ければフロントはいけそうだし、angular1に比べてコード見やすいし。

サーバサイド

nodeやりたかったけれど、仕事で.net使ってるのもあって、asp.net coreへ方向転換。ただそのあとすぐに忙しくなって止まってる。

ニュースとかブログは読んでるけれど、アウトプットが無さすぎて自分の中に残ってない感が多い。
まず来年は時間を作るところから。

PostgreSQLへASP.NET CoreとEntity Frameworkでアクセスしてみる

ASP.NET Core PostgreSQL Entity Framework

asp.net MVCを使えるようになりたいと思い少し触ってみました。
asp.netは仕事でWebFormを使ったことがあるだけです。

自宅にはmacしかないので、.net coreを選択したのですが、かなりハマりました。
このエントリーを見つけたおかげで、
なんとか動かすところまではできたのでそのメモです。

前提

  • .Net Coreがインストール済み
  • Visual Studio Codeがインストール済み
  • PostgreSQLがインストール済み
  • node、npm、yeome、generator-aspnetインストール済み

動かすまでにやったこと

  1. テンプレートの作成(ターミナルで実行)

    • yo aspnetコマンドを実行
    • Web Application Basic [without Membership and Authorization]を選択
    • プロジェクトの名前を入力。(今回はsample1を入力)

    • プロジェクトが作成されたら、下記コマンドを入力するように出るので、その通りにコマンドを実行

        cd "sample1"
  dotnet restore
  dotnet build
  dotnet run

    • dotnet runが成功するとURLが表示されるので、ブラウザでそのURLへアクセス

      • http://localhost:5000
    • 無事起動すれば準備完了

  2. project.jsonへEntityFrameworkを追加

    • dependenciesへ下記を追加

      "Npgsql.EntityFrameworkCore.PostgreSQL": "1.0.0"
"Microsoft.EntityFrameworkCore.Design": "1.0.0-preview2-final"

    • toolsへ下記を追加

      "Microsoft.EntityFrameworkCore.Tools": {
    "version": "1.0.0-preview2-final",
    "imports": "portable-net45+win8+dnxcore50"
}

  3. ModelクラスとDbContextの作成

    • Modelsフォルダを作成
    • Articleクラス(Article.cs)
    • Authorクラス(Author.cs)
    • ArticleContextクラス(ArticleContext.cs)

    ソースはリンク先のとおりなので省略。
    変更した点は、各クラスを別ファイルにしたのと、
    namespaceをnamespace sample1にしたこと。

  4. appsettings.jsonへDB接続情報を記載

     {
     "DbContextSettings" :{
         "ConnectionString" : "User ID=postgresのユーザ;Password=パスワード;Host=localhost;Port=5432;Database=DemoArticlesApp;Pooling=true;"
     }
 }

  5. Startup.csへDbContextを追加

    • ConfigureServicesに下記を追加
      もともとservices.AddMvc();の記載があるのでその下に追記

        var connectionString = Configuration["DbContextSettings:ConnectionString"];
  services.AddDbContext<ArticleContext>(
      opts => opts.UseNpgsql(connectionString)
  );

  6. migrationの実行

    • sample1フォルダをターミナルで開いて、下記コマンドを実行

        dotnet ef migrations add InitialMigration
  dotnet ef database update

  7. migrationが成功しているか確認

    • ターミナルで下記コマンドを実行

        psql DemoArticlesApp -c "SELECT table_name FROM Information_Schema.tables where table_schema='public'"

    • 3テーブルが作成されていればOK

        table_name
  -----------------------
   __EFMigrationsHistory
  Authors
  Articles
  (3 rows)

  8. Controllerを作成

    • Controllerはyo asp:MvcControllerコマンドで作成

        yo aspnet:MvcController AuthorsController

    • AuthorsControllerのソースはリンク先そのままなので省略。(namespaceだけnamespace sample1に変更)

  9. アプリケーション実行

    • ターミナルからdotnet run

    • Chromeの拡張機能のPostmanを使って動作確認

      • POSTするときにデータフォーマットはrawにして、JSON(application/json)にする

    • ブラウザのアドレスバーにhttp://localhost:5000/api/authors/1を入れて、POSTで登録したデータが取得できるか確認。

最後に

かなりざっくりだけれど、これでapi叩いて追加、参照はできるようになりました。
asp.net MVCもEntity Frameworkもわからない状態で始めたので、
試行錯誤を繰り返して動かすまでかなり大変でした。

ようやく動かせるようになったので、内容はこれから理解していきます。

Elixirで単純なパターンマッチにハマりました。

Elixir

前々からElixirに興味があったので、プログラミングElixirを購入しました。

プログラミングElixir

プログラミングElixir


第2章のパターンマッチでまで読んだのだけれど、理解できないところが。
(この記事を書いていたら解決したけれど、せっかく書いたので残しておきます。)

分からなかったのは2章の「練習問題PatternMatching-1」で、 結果がどうなるのかというもの。

a = [ [1, 2, 3]]
[a] = [ [1, 2, 3]]
[ [a] ] = [ [1, 2, 3] ]


一つ目はすぐに分かったのだけれど、二つ目、三つ目が分からなかった。

一つ目は、aは[ [1, 2, 3]]に束縛される。
これは見たままなので簡単。

二つ目は、aは[1, 2, 3]に束縛される。
三つ目は、MatchErrorになる。

ぱっと見何これ？と思ったのだけれど、一段ずつリストを取り出して考えれば簡単に分かりました。
三つ目の場合でいうと、

[ [a] ] = [ [1, 2, 3] ]
↓
[a] = [1, 2, 3]
↓
a = 1, 2, 3

左辺は値(a)が一つだけれど、右辺は1, 2, 3の3つ。
左辺と右辺で値の個数が違うためエラー。
二つ目も同じように考えれば、[1, 2, 3]になるのは納得。

上記みたいに考えれば簡単だけれど、最初式だけ見たときは全然理解できなくて、何これ？と思ってしまいました。

理解できたので引き続き3章以降も読み進めていこう。

アジャイル開発の研修メモ

agile

会社でアジャイル開発の研修を受けさせてもらったのでそのメモ。
メモっただけで理解できていないことなどが多いので、後々調べて理解していく。

研修が終わって一番重要だと感じたのは、アジャイルな開発手法を導入することよりも、
「アジャイルソフトウェア開発宣言」と「アジャイル宣言の背後にある原則 )」が、チームや経営陣に理解されないと成功しないだろうと感じた。

そこも含めてアジャイルの導入なんだろうけれど。

以下からは研修のメモ書き。

プロジェクト失敗の要因

  • ユーザのインプット不足
  • 不完全な要求事項と仕様
  • 要求事項と仕様の変更
  • 経営者の支援不足

ウォーターフォール型開発の前提

  • 顧客の要求は予め明確になっている
  • 顧客の要求は開発者側に正確に伝わる
  • 顧客の要求は大きく変更されない
  • プロジェクト計画に従えば予定どおり進む
  • 前工程には間違いがない

アジャイル開発とは

  • 反復
  • 漸進的
  • 適応
  • 自律的
  • 多能工
  • 強調

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

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

アジャイル開発の価値観の共有
共通の概念や考え方を広く社会に知らせる

  • プロセスやツールよりも⇨個人と対話を
    • 尊敬の気持ち
    • お互いの信頼感
    • 自由にやり取りする雰囲気
    • 良いコミュニケーション
    • 透明性
    • 目標に対する貢献
  • 包括的なドキュメントよりも⇨動くソフトウェアを
    • 顧客が要求する実行可能な状態のソフトウェア
    • 正しく機能するソフトウェアを一定の間隔で提供
  • 契約交渉よりも⇨顧客との協調を
    • 顧客のプロジェクトチームへの参加
    • 顧客との緊密なコラボレーションの方法や仕組みの導入
  • 計画に従うことよりも⇨変化への対応を
    • 顧客の要求は始めから全てを明確に定義できない
    • 変更があるのは当たり前であるという前提で柔軟に対応

アジャイルマニフェスト 12の原則

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

アジャイル開発の特徴

  • 反復・漸進型開発
    • 設計・開発・テストを繰り返し開発
  • ドキュメントより動くソフトウェア
    • 顧客の要求は事前に明確に定義できない
    • 必要なドキュメントは最小限に
    • 顧客との対話を重視しながら要求を明確に
    • 動くソフトウェアのもとで品質管理
  • 顧客との協調
    • プロジェクトの開発時点では、その後の全てを見通すことはできない
    • 反復開始毎に優先的に開発すべき要求を顧客と一緒に決めて実行
    • 顧客のプロジェクトへの参加は必須
  • 変更に柔軟に対応
    • 開発中もビジネス環境が変化して要求自体も変わってくる
    • 変更があるのは当たり前
    • ビジネス価値を上げる要求は歓迎
    • 全ての要求が自由ではない
  • 個人間の相互作用「自己組織的チーム」
    • チーム自身が責任をもって、自律的にプロジェクトを運営
    • 問題意識や目的を共有
    • それぞれの相互作用による知恵の出し合い
    • ひとつの組織としての意思決定
  • ペア・プログラミング
    • 技術の共有
    • 質の高いプログラミング
    • コード全体の問題点とメンバー特性の共通認識
    • ドライバーとナビゲーター
  • テスト駆動開発
    • 最初にテスト項目を決め、動作する必要最低限の実装をまず行う
    • 次にコードを洗練させる
    • XPで多く用いられる

ウォーターフォール型開発との比較

ウォーターフォール アジャイル
成功の指標 計画に合致 変化に対応、正常に動くコード
要求と設計 前もって、大きく 継続的、その都度適切な内容を定義
コーディングとテスト すべての機能を順番にコーディングし、後でテスト コーディングと単体テスト、連続的にリリース
テストと品質保証 計画主体、最後にテスト 並行的、継続的、早期にテスト
管理の文化 命令と管理 リーダーシップ、コラボレーション

アジャイル適用の効果(顧客視点)

  • 早期に導入効果を実現
  • すべての要求が決まらなくても着手可能
  • リスクを早期に軽減
  • 高い投資効果(80:20の法則)
  • Time to Market向上
  • 変化への対応が容易

アジャイル適用の効果(受託企業視点)

  • リスクの早期発見
  • 動くソフトウェアの早期リリース
  • 頻繁な反復による品質向上
  • モチベーション向上と高い生産性
    • 顧客の役に立ったという達成感
    • 自らの責任で計画を立てて実行するためやらされ感がない
  • 開発者の能力向上
  • 残業からの解放
    • 自分たちの開発能力から見て達成可能な計画を自主的に立てる
  • ムダの削減
    • 手戻りがなくなる
    • face to faceのコミュニケーション重視のため、「不要」なドキュメントは作らない
  • 振り返りによる継続的改善

アジャイルのプロセス

スクラムの原点

  • 新製品開発ゲーム
    • 高いパフォーマンス⇨少人数の組織横断的なチーム
    • ラグビーのスクラムのような自己組織チーム⇨組織の障害要因が取り除かれれば、より高品質なソフトウェアを提供可
  • リーン生産方式
    • リーン：痩せた、贅肉のないの意味
    • 必要な時に必要なものを必要なだけ作り、在庫を寝かせずフル回転させるジャストインタイムのカンバン方式
    • 自ら仕事の結果をチェックし、異常はその場で解決し、次工程に持ち越さない
    • 多能工、目で見て管理、目標を掲げ改善を継続

      スクラムの精神

  • スクラム
    • 反復的な開発アプローチ 動くソフトウェアを順次作り、発展させながら開発を進める
    • タイムボックス：すべての作業や会議は規定された時間内に完了。
    • 目標の共有：目標を共有し、自ら方向性を定め、日々の時間管理をし、改善する
    • 固定したチーム：メンバーは専任。交代せず固定化した体制で臨む。
  • 確約(Commitment)：約束したことを確実に実現すること
  • 専念(Focus)：確約したことの実現に専念すること
  • 格差ない(Open)：たとえ自分に不利なことでも包み隠さないこと
  • 尊敬(Respect)：自分と異なる人に敬意を払うこと
  • 勇気(Courage)確約し、隠さず、敬意を払うことに勇気を持つこと
  • スクラムチーム
    • プロダクトオーナー
      • プロダクトの要求事項の定義
      • プロダクトのリリース計画と内容の決定
      • プロダクトの収益性、投資回収性の責任
      • 要求事項の優先順位付け(ビジネス価値・リスク)
      • 作業結果の評価・判断
    • 開発チーム
      • プロダクトの要求事項を反復ごとに納品
      • プロダクトオーナーに品質と納期をコミット
      • 組織横断的チーム活動
      • 自己組織的チーム活動
      • 継続的プロセス改善
    • スクラムマスター
      • 開発チームを自己組織的チームに育成
      • 開発チームの反復活動を支援
      • 開発チームの機能向上、品質向上、生産性向上を支援
      • 開発チームのコラボレーション促進
      • 進捗の阻害要因を除去
      • 開発チームに対して指示・管理は行わない
  • スクラム開発の流れ
    1. リリース計画
    2. プロダクトバックログ (開発対象の動くソフトウェアに関するすべての要求機能が一覧になったもの)
    3. スプリント計画ミーティング
    4. スプリントバックログ (プロダクトバックログを動作するソフトウェアとして実装するために必要な作業のリスト)
    5. デイリースクラム (毎日のミーティング)
    6. スプリント
    7. スプリントレビューミーティング
    8. スプリントレトロスペクティブミーティング
  • リリース計画
    • プロジェクトビジョン
      • 戦略性：ビジネスの価値、差別化要素
      • 目的：システムで実現したいこと
      • プロジェクトスコープ：プロジェクトの全体像
      • 機能・性能：システムにして欲しいこと
    • 要求機能の表現方法
      • ユーザーストーリー
  • プロダクトバックログ
    • 開発要求リスト
    • 優先順位
    • 常時開示
  • スプリント計画ミーティング
    • スプリントゴール どの要求を構築するか
    • スプリントバックログ　選択した項目をタスクに分解
  • スプリントバックログ
    • プロダクトバックログを実装するために必要な作業のリスト
    • 担当するタスクはメンバー自らが選択
  • デイリースクラム
    • 日時の15分程度のミーティング
    • 昨日は何をしたか、今日の予定、今抱えている課題
  • スプリント
    • 最大30日
    • 各スプリントの長さは同一
    • 作業に専念できる環境にすること
      • チーム以外の人は、スプリント中にチームが行っている作業の範囲を変更することはできない
      • チーム以外の人は、スプリントに昨日や技術を追加してはならない
      • チーム以外の人は、チームにスプリントでどう行えばいいか等を教えてはいけない
      • チーム以外の人は、チームにスプリントでどう行えばいいか等を教えてはいけない
    • バーンダウンチャート　源氏あの状況をモニターし、どれだけの作業が残っているかを視覚的に分かりやすく表示
  • スプリントレビューミーティング
    • 動くソフトウェアが完了基準を満たしているか
    • プロダクト・オーナーからのフィードバックと受け入れの判断をしてもらう
    • 結果をプロダクトバックログに反映、ソフトウェア全体の完了日を予測
    • プロダクトバックログの内容と優先度の見直し
  • スプリントレトロスペクティブミーティング
    • 振り返り
    • 続けたいことと改善したいことをチーム全員で共有
    • 話題の対象は開発に関わる全てのこと
    • 開発チームが自主運営
    • 自由闊達になんでも話し合える

エンタープライズアジャイル

エンタープライズアジャイルとは

  • アメリカを中心に海外ではビジネス、ITの分野で広く普及している
  • 2001年のアジャイル宣言
  • 変化するビジネスニーズへ、より迅速、的確に対応
  • ITを通じてお客様のビジネス価値向上

普及への仮題

ハイブリッド開発

  • ハイブリッド開発の例
  • アジャイル開発に向くプロジェクト
    • 要求が事前に定めにくいプロジェクト
    • 革新的、実験的、経験がない分野のプロジェクト
    • 顧客が積極的に参加出来るプロジェクト
    • スキルが高く、高いモチベーションと専門性を持ったチームが編成できるプロジェクト
    • 日々チーム内及び顧客との緊密なコラボレーションができるプロジェクト
  • ウォーターフォール型開発に向くITプロジェクト
    • 事前に要求がほぼ確定できるプロジェクト
      • 基幹系業務、感情系業務
    • 厳格な変更管理が要求されるプロジェクト
    • 広範囲のドキュメントが要求されるプロジェクト
    • 法律や規則へのコンプライアンスが要求されるプロジェクト
    • 主要な役割に未経験者を割り当てしないといけないプロジェクト
      • 人材不足なプロジェクトってこと？
    • 顧客やエンドユーザのプロジェクト参画が制限されるプロエクト
    • 分散開発環境のプロジェクト
      • 複数のベンダーが関わるとか？

アジャイル開発のメリット

  • 顧客側
    • 頻繁な反復レビューにより、プロジェクトの進捗状況がわかるため安心感がある
      • 顧客がシステム開発に理解があれば良いけれど、そうじゃない場合は発注したんだからあとはちゃんと作ってになりそう
    • 反復レビューとフィードバックによって価値のあるシステムとなり、満足度が向上する
    • 開発の終盤まで要求仕様が検討できる
  • 開発側のメリット
    • 頻繁な反復レビューによって、リスクを早期に検知できる
    • 頻繁な反復テストによって、品質が向上する
    • 仕様追加があっても柔軟に予算と納期に対応出来る
      • 予算増えるの？納期変えられるの？どうやって？
    • 開発に投入するマンパワーの平坦化

チーム発展

  • チームとは
    • 共通の目的、達成すべき目標、そのためのアプローチを共有し、連帯責任を果たせる補完的なスキルを備えた人の集合体。
  • チーム発展段階モデル
    1. 成長期
    2. 動乱期
    3. 安定期
    4. 遂行期 自己組織的チームになる
  • 自己組織的チーム
    • お互いの信頼
    • 共通の目標を一緒に協力して達成する
    • 自由裁量権あるいは権限移譲されたチーム
    • チーム自ら意思決定する
    • チームは計画実行をコミットする
    • 情報はオープンで共有かされている
    • 建設的な反対意見は歓迎される
    • メンバーの役割は明確である
    • メンバーは高いモチベーションを持っている
    • マネージャーはチームをコントロールするのでなく支援する
    • プロセスは継続的に改善がなされる
    • 対話を重視する
    • お互いが助け合う
    • お互いが学び合う

アジャイルとリーダーシップ

  • アジャイルを成功に導くリーダーシップ
    • 感情の知性(EQ Emotional Intelligence Quotient)
      • 感情の状況を理解し、それをうまくコントロールする能力
      • 人の言動や行動は、その時々の感情の状態に大きく影響される
      • 良い人間関係
      • EQは適切な訓練によって高められる
      • 自分の今の感情の状態を認識し、それをコントロール
      • 相手の今の感情の状態を認識する
    • コミュニケーション
      • 個人との対話を
      • 顧客との協議を
      • 動くソフトウェアを
    • 共同作業とチームワーク
      • チームワークの善し悪しが開発業務の成否を左右する
    • ビジョン
      • プロジェクトが進むゴールを明確に示す
      • ゴールの共有
    • ファシリテーション
    • 他者の成長
    • コンフリクトマネジメント
      • 効果的なコンフリクトは必要、コンフリクトを有効活用する
    • 柔軟性
      • 変化へ柔軟に対応
  • 指示管理型リーダーシップとコラボレーション型リーダーシップ
    • モチベーション
      • 指示管理型：大きな権力を持ちたい
      • コラボレーション型：他者の役に立ちたい
    • マインドセット
      • 指示管理型：競争を勝ち抜き自分が賞賛される
      • コラボレーション型：強調とWIN/WINを重視
    • 影響力
      • 指示管理型：自分の権力を行使して畏怖させて動かす
      • コラボレーション型：信頼関係を気づき、自律性を重視、説得して動かす
    • コミュニケーションスタイル
      • 指示管理型：他者に対して命令、指示することを重視
      • コラボレーション型：他者の話を傾聴することを重視。
    • 業務遂行能力
      • 指示管理型：自分自身の能力向上で得られた自信をベースに他者に指示する
      • コラボレーション型：他者の育成、ともに学習することにより能力向上
    • 成長についての考え方
      • 指示管理型：しゃない制度等を利用することで自分の地位を上げ、成長していく
      • コラボレーション型：他者のやる気を大切に考え、個人と組織の成長の協調を考える
    • 責任についての考え方
      • 指示管理型：責任とは、失敗した時にその人を罰するためにある
      • コラボレーション型：責任を明確にすることで、失敗からも学ぶ
  • サーバント・リーダーシップとは
    • リーダーシップのスタイル
    • 5つの柱、11の特徴
      1. 奉仕の精神
        • 奉仕
          • 使命感：使命感を持って下から支える
          • 導き：共通のゴールに向かい導き、組織と人を動かす
      2. 対人関係力
        • 傾聴
          • 最後まで話を聴く
          • 相手の方を向いて聴く
          • 相槌を打つ
          • 黙ってもせかさない
          • 体全体で聴く(顔の表情、しぐさまで含めて)
          • 相手の発するシグナルをきちんと受け止める
          • 相手の言葉の奥底に潜む本筋と感情を理解する
          • 相手から自分の話を聴いてもらえるという姿勢
          • 的確な質問で、相手の意図を引き出す
        • 共感
          • 他人の感情、軽々ん、問題を理解する。あるいは共有する能力
          • 期待値を理解する
          • イメージ力を強化する
          • 共鳴しあえる共通の価値観の見い出し
          • 相手が欲している、困っていることを理解するため相手との架け橋を作る
          • 感じたことを相手に伝える優しさを持つ
          • 相手は共感してほしい、共感したいと思っている。自分の感情も相手に伝えてみる。
        • 気づき
          • 自分自身、組織、スタッフすべてに気を配る
          • メンバーに対する気づき
          • プロジェクトに関する気づき
          • 自分自身に対する気づき
          • 何が問題で何をすべきか
          • 刻々と変化する女うっ今日にたえず敏感になる
          • 自分自身の能力や限界を理解し、他人の意見に耳を傾け自己開発に努める
        • 癒し
          • 相手にかけているもの、木津ついていることを見つけ出し助言を与える
          • かけている部分を見つけたら、すぐに誘いの手を差し伸べる
          • ねぎらいと感謝の気持ちで接する
          • かけていることを悪と捉えない
      3. ビジョン
        • 概念化
          • 目指すゴールの絵を描く
          • 達成可能な大きな目標を立て、具体的な手順を列挙する
          • メンバーには結果責任を負わせながらも、目標達成ん向け自ら模範を示し、導く
        • 先見力・予見力
          • 目的地までどうやって行くかを示す力
          • 通常ルートと何かが起こった時のルートを予見する
          • リーダーは、行き方を常に見直しながら、何が起きるか察知して適切な判断を適宜下す
          • 洞察力を付ける
            • 直感的に判断する力
      4. モチベーション
        • スチュワードシップ
          • 大切なものを任せても信頼できると思われるような行動
          • 権力・理屈などに依存せず黙々と自分の役割の遂行に浸る
          • その人の背中を見て人々が自然と付いてくるような行動・姿勢
          • 組織の大きなゴールに応えるためには自己犠牲も厭わない
        • 説得
          • あることを相手に説明し、納得してもらい、相手に行動を自発的に起こしてもらう
          • 権限に依存することなく、服従を強要しない
          • 納得してもらい、共通のコンセンサスを確立する
          • 説き伏せるのではなく、自発的にゴール・ミッションを納得してもらう
          • 相手の言うことに耳を傾けながら、自分自身の意見も主張し相手にわかってもらうの力が必要
      5. 成長
        • 人々の成長へのコミット
          • メンバー一人一人に目をかけ、人間的にもキャリア的にも成長することをコミット
            • 定期的な面談、現場研修への積極的な参加、グループディスカッションを実施
            • メンバーの成長意欲を満たし、サポートする
          • 自分勝手な選り好みはしない
          • リーダーの役割はメンバーがゴールを達成するのを助けること
          • メンバーのパーソナルスキル、プロフェッショナルスキルの開発
          • 効果的なフィードバックを行い、さらなる成長のためのニーズを見つけ出す
          • 開発チームの一人一人の少しづつの成長がチームの成長になり大きなパワーになっていく
        • コミュニティづくり
          • 情報、計画、資源を共有しながら共同作業をする
          • 友好的、協力的雰囲気を作り出す
          • 自らが尊敬、助け合い、強調の模範となる
          • 積極的、情熱的なコミットメントを喚起し、チームを一体感ある集団にする
          • 顕密な人間関係を作り上げることに時間をかける
          • まずは、開発チームというコミュニティを念頭に置く