KindleをDeepLで翻訳しながら読む
はじめに
Kindleで洋書を読むときにiOS版やiPadOS版Kindleでは文章を選択すると翻訳してくれます。
ただ、Mac版のKindleには同じ機能が無いため、Mac版でなるべく楽に翻訳できる方法について私が試した方法になります。
翻訳の方法
翻訳は下記の手順で行います。
- Kindleで翻訳したい文章を選択
- 本文検索を実行
- 検索ボックスの文章をコピー
- 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を動かす
現在Apple siliconに対応したSQL Serverは現状ありませんが、Docker Desktop Version がRosettaをサポートしたことで、SQL Server Linuxを動作させることができるようになりました。
SQL Server Linuxを動かしてみたので、その際の手順になります。
Dockerを使ったSQL Server Linuxについては、Microsoftのページにも記載があるため、こちらを参考にしました。
learn.microsoft.com
今回はコンテナ起動時のパラメータを毎回入力しないようにするために、docker-composeを使用しました。
手順
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の方にはされていませんでした。
Mac側のスタックの設定をWindowsと同じにしたところ、無事アプリの画面が表示されました。
また、再度MacのVisual Studio for MacでAzureへ公開しようとしたところ、最初に公開したApp Serviceが選べませんでした。 もしかすると、Visual Studio for MacはAzureへの公開機能は完全に対応していないのかもしれません。
PostgreSQLへASP.NET CoreとEntity Frameworkでアクセスしてみる
asp.net MVCを使えるようになりたいと思い少し触ってみました。
asp.netは仕事でWebFormを使ったことがあるだけです。
自宅にはmacしかないので、.net coreを選択したのですが、かなりハマりました。
このエントリーを見つけたおかげで、
なんとか動かすところまではできたのでそのメモです。
前提
- .Net Coreがインストール済み
- Visual Studio Codeがインストール済み
- PostgreSQLがインストール済み
- node、npm、yeome、generator-aspnetインストール済み
動かすまでにやったこと
テンプレートの作成(ターミナルで実行)
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
- 無事起動すれば準備完了
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" }
ModelクラスとDbContextの作成
- Modelsフォルダを作成
- Articleクラス(Article.cs)
- Authorクラス(Author.cs)
- ArticleContextクラス(ArticleContext.cs)
ソースはリンク先のとおりなので省略。
変更した点は、各クラスを別ファイルにしたのと、
namespaceをnamespace sample1
にしたこと。appsettings.jsonへDB接続情報を記載
{ "DbContextSettings" :{ "ConnectionString" : "User ID=postgresのユーザ;Password=パスワード;Host=localhost;Port=5432;Database=DemoArticlesApp;Pooling=true;" } }
Startup.csへDbContextを追加
ConfigureServicesに下記を追加
もともとservices.AddMvc();
の記載があるのでその下に追記var connectionString = Configuration["DbContextSettings:ConnectionString"]; services.AddDbContext<ArticleContext>( opts => opts.UseNpgsql(connectionString) );
migrationの実行
sample1フォルダをターミナルで開いて、下記コマンドを実行
dotnet ef migrations add InitialMigration dotnet ef database update
migrationが成功しているか確認
ターミナルで下記コマンドを実行
psql DemoArticlesApp -c "SELECT table_name FROM Information_Schema.tables where table_schema='public'"
3テーブルが作成されていればOK
table_name ----------------------- __EFMigrationsHistory Authors Articles (3 rows)
Controllerを作成
Controllerは
yo asp:MvcController
コマンドで作成yo aspnet:MvcController AuthorsController
AuthorsControllerのソースはリンク先そのままなので省略。(namespaceだけ
namespace sample1
に変更)
アプリケーション実行
最後に
かなりざっくりだけれど、これでapi叩いて追加、参照はできるようになりました。
asp.net MVCもEntity Frameworkもわからない状態で始めたので、
試行錯誤を繰り返して動かすまでかなり大変でした。
ようやく動かせるようになったので、内容はこれから理解していきます。
Elixirで単純なパターンマッチにハマりました。
前々からElixirに興味があったので、プログラミングElixirを購入しました。
- 作者: Dave Thomas,笹田耕一,鳥井雪
- 出版社/メーカー: オーム社
- 発売日: 2016/08/19
- メディア: 単行本(ソフトカバー)
- この商品を含むブログを見る
第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章以降も読み進めていこう。
アジャイル開発の研修メモ
会社でアジャイル開発の研修を受けさせてもらったのでそのメモ。
メモっただけで理解できていないことなどが多いので、後々調べて理解していく。
研修が終わって一番重要だと感じたのは、アジャイルな開発手法を導入することよりも、
「アジャイルソフトウェア開発宣言」と「アジャイル宣言の背後にある原則 )」が、チームや経営陣に理解されないと成功しないだろうと感じた。
そこも含めてアジャイルの導入なんだろうけれど。
以下からは研修のメモ書き。
プロジェクト失敗の要因
- ユーザのインプット不足
- 不完全な要求事項と仕様
- 要求事項と仕様の変更
- 経営者の支援不足
ウォーターフォール型開発の前提
- 顧客の要求は予め明確になっている
- 顧客の要求は開発者側に正確に伝わる
- 顧客の要求は大きく変更されない
- プロジェクト計画に従えば予定どおり進む
- 前工程には間違いがない
アジャイル開発とは
- 反復
- 漸進的
- 適応
- 自律的
- 多能工
- 強調
アジャイルソフトウェア開発宣言
アジャイル開発の価値観の共有
共通の概念や考え方を広く社会に知らせる
- プロセスやツールよりも⇨個人と対話を
- 尊敬の気持ち
- お互いの信頼感
- 自由にやり取りする雰囲気
- 良いコミュニケーション
- 透明性
- 目標に対する貢献
- 包括的なドキュメントよりも⇨動くソフトウェアを
- 顧客が要求する実行可能な状態のソフトウェア
- 正しく機能するソフトウェアを一定の間隔で提供
- 契約交渉よりも⇨顧客との協調を
- 顧客のプロジェクトチームへの参加
- 顧客との緊密なコラボレーションの方法や仕組みの導入
- 計画に従うことよりも⇨変化への対応を
- 顧客の要求は始めから全てを明確に定義できない
- 変更があるのは当たり前であるという前提で柔軟に対応
アジャイルマニフェスト 12の原則
アジャイル開発の特徴
- 反復・漸進型開発
- 設計・開発・テストを繰り返し開発
- ドキュメントより動くソフトウェア
- 顧客の要求は事前に明確に定義できない
- 必要なドキュメントは最小限に
- 顧客との対話を重視しながら要求を明確に
- 動くソフトウェアのもとで品質管理
- 顧客との協調
- プロジェクトの開発時点では、その後の全てを見通すことはできない
- 反復開始毎に優先的に開発すべき要求を顧客と一緒に決めて実行
- 顧客のプロジェクトへの参加は必須
- 変更に柔軟に対応
- 開発中もビジネス環境が変化して要求自体も変わってくる
- 変更があるのは当たり前
- ビジネス価値を上げる要求は歓迎
- 全ての要求が自由ではない
- 個人間の相互作用「自己組織的チーム」
- チーム自身が責任をもって、自律的にプロジェクトを運営
- 問題意識や目的を共有
- それぞれの相互作用による知恵の出し合い
- ひとつの組織としての意思決定
- ペア・プログラミング
- 技術の共有
- 質の高いプログラミング
- コード全体の問題点とメンバー特性の共通認識
- ドライバーとナビゲーター
- テスト駆動開発
- 最初にテスト項目を決め、動作する必要最低限の実装をまず行う
- 次にコードを洗練させる
- XPで多く用いられる
ウォーターフォール型開発との比較
ウォーターフォール | アジャイル | |
---|---|---|
成功の指標 | 計画に合致 | 変化に対応、正常に動くコード |
要求と設計 | 前もって、大きく | 継続的、その都度適切な内容を定義 |
コーディングとテスト | すべての機能を順番にコーディングし、後でテスト | コーディングと単体テスト、連続的にリリース |
テストと品質保証 | 計画主体、最後にテスト | 並行的、継続的、早期にテスト |
管理の文化 | 命令と管理 | リーダーシップ、コラボレーション |
アジャイル適用の効果(顧客視点)
- 早期に導入効果を実現
- すべての要求が決まらなくても着手可能
- リスクを早期に軽減
- 高い投資効果(80:20の法則)
- Time to Market向上
- 変化への対応が容易
アジャイル適用の効果(受託企業視点)
- リスクの早期発見
- 動くソフトウェアの早期リリース
- 頻繁な反復による品質向上
- モチベーション向上と高い生産性
- 顧客の役に立ったという達成感
- 自らの責任で計画を立てて実行するためやらされ感がない
- 開発者の能力向上
- 残業からの解放
- 自分たちの開発能力から見て達成可能な計画を自主的に立てる
- ムダの削減
- 手戻りがなくなる
- face to faceのコミュニケーション重視のため、「不要」なドキュメントは作らない
- 振り返りによる継続的改善
アジャイルのプロセス
スクラムの原点
- 新製品開発ゲーム
- リーン生産方式
- スクラム
- 反復的な開発アプローチ 動くソフトウェアを順次作り、発展させながら開発を進める
- タイムボックス:すべての作業や会議は規定された時間内に完了。
- 目標の共有:目標を共有し、自ら方向性を定め、日々の時間管理をし、改善する
- 固定したチーム:メンバーは専任。交代せず固定化した体制で臨む。
- 確約(Commitment):約束したことを確実に実現すること
- 専念(Focus):確約したことの実現に専念すること
- 格差ない(Open):たとえ自分に不利なことでも包み隠さないこと
- 尊敬(Respect):自分と異なる人に敬意を払うこと
- 勇気(Courage)確約し、隠さず、敬意を払うことに勇気を持つこと
- スクラムチーム
- プロダクトオーナー
- プロダクトの要求事項の定義
- プロダクトのリリース計画と内容の決定
- プロダクトの収益性、投資回収性の責任
- 要求事項の優先順位付け(ビジネス価値・リスク)
- 作業結果の評価・判断
- 開発チーム
- プロダクトの要求事項を反復ごとに納品
- プロダクトオーナーに品質と納期をコミット
- 組織横断的チーム活動
- 自己組織的チーム活動
- 継続的プロセス改善
- スクラムマスター
- 開発チームを自己組織的チームに育成
- 開発チームの反復活動を支援
- 開発チームの機能向上、品質向上、生産性向上を支援
- 開発チームのコラボレーション促進
- 進捗の阻害要因を除去
- 開発チームに対して指示・管理は行わない
- プロダクトオーナー
- スクラム開発の流れ
- リリース計画
- プロジェクトビジョン
- 戦略性:ビジネスの価値、差別化要素
- 目的:システムで実現したいこと
- プロジェクトスコープ:プロジェクトの全体像
- 機能・性能:システムにして欲しいこと
- 要求機能の表現方法
- ユーザーストーリー
- プロジェクトビジョン
- プロダクトバックログ
- 開発要求リスト
- 優先順位
- 常時開示
- スプリント計画ミーティング
- スプリントゴール どの要求を構築するか
- スプリントバックログ 選択した項目をタスクに分解
- スプリントバックログ
- プロダクトバックログを実装するために必要な作業のリスト
- 担当するタスクはメンバー自らが選択
- デイリースクラム
- 日時の15分程度のミーティング
- 昨日は何をしたか、今日の予定、今抱えている課題
- スプリント
- 最大30日
- 各スプリントの長さは同一
- 作業に専念できる環境にすること
- チーム以外の人は、スプリント中にチームが行っている作業の範囲を変更することはできない
- チーム以外の人は、スプリントに昨日や技術を追加してはならない
- チーム以外の人は、チームにスプリントでどう行えばいいか等を教えてはいけない
- チーム以外の人は、チームにスプリントでどう行えばいいか等を教えてはいけない
- バーンダウンチャート 源氏あの状況をモニターし、どれだけの作業が残っているかを視覚的に分かりやすく表示
- スプリントレビューミーティング
- スプリントレトロスペクティブミーティング
- 振り返り
- 続けたいことと改善したいことをチーム全員で共有
- 話題の対象は開発に関わる全てのこと
- 開発チームが自主運営
- 自由闊達になんでも話し合える
エンタープライズアジャイル
エンタープライズアジャイルとは
- アメリカを中心に海外ではビジネス、ITの分野で広く普及している
- 2001年のアジャイル宣言
- 変化するビジネスニーズへ、より迅速、的確に対応
- ITを通じてお客様のビジネス価値向上
普及への仮題
ハイブリッド開発
- ハイブリッド開発の例
- アジャイル開発に向くプロジェクト
- 要求が事前に定めにくいプロジェクト
- 革新的、実験的、経験がない分野のプロジェクト
- 顧客が積極的に参加出来るプロジェクト
- これできないならアジャイルの意味ないのでは?
- スキルが高く、高いモチベーションと専門性を持ったチームが編成できるプロジェクト
- 日々チーム内及び顧客との緊密なコラボレーションができるプロジェクト
- ウォーターフォール型開発に向くITプロジェクト
- 事前に要求がほぼ確定できるプロジェクト
- 基幹系業務、感情系業務
- 厳格な変更管理が要求されるプロジェクト
- 広範囲のドキュメントが要求されるプロジェクト
- 法律や規則へのコンプライアンスが要求されるプロジェクト
- 主要な役割に未経験者を割り当てしないといけないプロジェクト
- 人材不足なプロジェクトってこと?
- 顧客やエンドユーザのプロジェクト参画が制限されるプロエクト
- 分散開発環境のプロジェクト
- 複数のベンダーが関わるとか?
- 事前に要求がほぼ確定できるプロジェクト
アジャイル開発のメリット
- 顧客側
- 頻繁な反復レビューにより、プロジェクトの進捗状況がわかるため安心感がある
- 顧客がシステム開発に理解があれば良いけれど、そうじゃない場合は発注したんだからあとはちゃんと作ってになりそう
- 反復レビューとフィードバックによって価値のあるシステムとなり、満足度が向上する
- 開発の終盤まで要求仕様が検討できる
- 頻繁な反復レビューにより、プロジェクトの進捗状況がわかるため安心感がある
- 開発側のメリット
チーム発展
- チームとは
- 共通の目的、達成すべき目標、そのためのアプローチを共有し、連帯責任を果たせる補完的なスキルを備えた人の集合体。
- チーム発展段階モデル
- 成長期
- 動乱期
- 安定期
- 遂行期 自己組織的チームになる
- 自己組織的チーム
アジャイルとリーダーシップ
- アジャイルを成功に導くリーダーシップ
- 感情の知性(EQ Emotional Intelligence Quotient)
- コミュニケーション
- 個人との対話を
- 顧客との協議を
- 動くソフトウェアを
- 共同作業とチームワーク
- チームワークの善し悪しが開発業務の成否を左右する
- ビジョン
- プロジェクトが進むゴールを明確に示す
- ゴールの共有
- ファシリテーション
- 他者の成長
- コンフリクトマネジメント
- 効果的なコンフリクトは必要、コンフリクトを有効活用する
- 柔軟性
- 変化へ柔軟に対応
- 指示管理型リーダーシップとコラボレーション型リーダーシップ
- モチベーション
- 指示管理型:大きな権力を持ちたい
- コラボレーション型:他者の役に立ちたい
- マインドセット
- 指示管理型:競争を勝ち抜き自分が賞賛される
- コラボレーション型:強調とWIN/WINを重視
- 影響力
- 指示管理型:自分の権力を行使して畏怖させて動かす
- コラボレーション型:信頼関係を気づき、自律性を重視、説得して動かす
- コミュニケーションスタイル
- 指示管理型:他者に対して命令、指示することを重視
- コラボレーション型:他者の話を傾聴することを重視。
- 業務遂行能力
- 指示管理型:自分自身の能力向上で得られた自信をベースに他者に指示する
- コラボレーション型:他者の育成、ともに学習することにより能力向上
- 成長についての考え方
- 指示管理型:しゃない制度等を利用することで自分の地位を上げ、成長していく
- コラボレーション型:他者のやる気を大切に考え、個人と組織の成長の協調を考える
- 責任についての考え方
- 指示管理型:責任とは、失敗した時にその人を罰するためにある
- コラボレーション型:責任を明確にすることで、失敗からも学ぶ
- モチベーション
- サーバント・リーダーシップとは
- リーダーシップのスタイル
- 5つの柱、11の特徴
- 奉仕の精神
- 奉仕
- 使命感:使命感を持って下から支える
- 導き:共通のゴールに向かい導き、組織と人を動かす
- 奉仕
- 対人関係力
- 傾聴
- 最後まで話を聴く
- 相手の方を向いて聴く
- 相槌を打つ
- 黙ってもせかさない
- 体全体で聴く(顔の表情、しぐさまで含めて)
- 相手の発するシグナルをきちんと受け止める
- 相手の言葉の奥底に潜む本筋と感情を理解する
- 相手から自分の話を聴いてもらえるという姿勢
- 的確な質問で、相手の意図を引き出す
- 共感
- 他人の感情、軽々ん、問題を理解する。あるいは共有する能力
- 期待値を理解する
- イメージ力を強化する
- 共鳴しあえる共通の価値観の見い出し
- 相手が欲している、困っていることを理解するため相手との架け橋を作る
- 感じたことを相手に伝える優しさを持つ
- 相手は共感してほしい、共感したいと思っている。自分の感情も相手に伝えてみる。
- 気づき
- 自分自身、組織、スタッフすべてに気を配る
- メンバーに対する気づき
- プロジェクトに関する気づき
- 自分自身に対する気づき
- 何が問題で何をすべきか
- 刻々と変化する女うっ今日にたえず敏感になる
- 自分自身の能力や限界を理解し、他人の意見に耳を傾け自己開発に努める
- 癒し
- 相手にかけているもの、木津ついていることを見つけ出し助言を与える
- かけている部分を見つけたら、すぐに誘いの手を差し伸べる
- ねぎらいと感謝の気持ちで接する
- かけていることを悪と捉えない
- 傾聴
- ビジョン
- 概念化
- 目指すゴールの絵を描く
- 達成可能な大きな目標を立て、具体的な手順を列挙する
- メンバーには結果責任を負わせながらも、目標達成ん向け自ら模範を示し、導く
- 先見力・予見力
- 目的地までどうやって行くかを示す力
- 通常ルートと何かが起こった時のルートを予見する
- リーダーは、行き方を常に見直しながら、何が起きるか察知して適切な判断を適宜下す
- 洞察力を付ける
- 直感的に判断する力
- 概念化
- モチベーション
- スチュワードシップ
- 大切なものを任せても信頼できると思われるような行動
- 権力・理屈などに依存せず黙々と自分の役割の遂行に浸る
- その人の背中を見て人々が自然と付いてくるような行動・姿勢
- 組織の大きなゴールに応えるためには自己犠牲も厭わない
- 説得
- あることを相手に説明し、納得してもらい、相手に行動を自発的に起こしてもらう
- 権限に依存することなく、服従を強要しない
- 納得してもらい、共通のコンセンサスを確立する
- 説き伏せるのではなく、自発的にゴール・ミッションを納得してもらう
- 相手の言うことに耳を傾けながら、自分自身の意見も主張し相手にわかってもらうの力が必要
- スチュワードシップ
- 成長
- 人々の成長へのコミット
- メンバー一人一人に目をかけ、人間的にもキャリア的にも成長することをコミット
- 定期的な面談、現場研修への積極的な参加、グループディスカッションを実施
- メンバーの成長意欲を満たし、サポートする
- 自分勝手な選り好みはしない
- リーダーの役割はメンバーがゴールを達成するのを助けること
- メンバーのパーソナルスキル、プロフェッショナルスキルの開発
- 効果的なフィードバックを行い、さらなる成長のためのニーズを見つけ出す
- 開発チームの一人一人の少しづつの成長がチームの成長になり大きなパワーになっていく
- メンバー一人一人に目をかけ、人間的にもキャリア的にも成長することをコミット
- コミュニティづくり
- 情報、計画、資源を共有しながら共同作業をする
- 友好的、協力的雰囲気を作り出す
- 自らが尊敬、助け合い、強調の模範となる
- 積極的、情熱的なコミットメントを喚起し、チームを一体感ある集団にする
- 顕密な人間関係を作り上げることに時間をかける
- まずは、開発チームというコミュニティを念頭に置く
- 人々の成長へのコミット
- 奉仕の精神