« 2021年10月 | トップページ | 2021年12月 »

2021年11月

2021/11/28

第21回東京Redmine勉強会の感想 #redmineT ~Redmineは業務も組織も包み込む柔軟性がある

第21回東京Redmine勉強会の感想をラフなメモ書き。

【参考】
第21回勉強会 - redmine.tokyo

2021/11/27 第21回勉強会 - redmine.tokyo #redmineT - Togetter

【1】最初は、@g_maedaさんのRedMica、そしてRedmineの最新機能の紹介。

【1-1】複数キーワードによるAND検索の実装は嬉しい。
チケット一覧から、Google検索みたいに細かい条件で検索できる。
チケット検索機能の強化につながるので、Redmineをナレッジ資産として使う現場としては貴重な機能と思う。

【1-2】チケット一覧でカスタムクエリをデフォルトで表示できるようになった。
PJごとに、みんなが見たいビューはたいてい決まっている。
最初にカスタムクエリで絞り込んでおけば、今日はどの作業に注力すればいいのか、考える必要もないはず。

【1-3】CommonMarkdownの試験的なサポートも興味深い。
斎藤さんのLTでは、Confluenceがすごく便利と話されていた。
実際、Confluenceでは、Wordのような直感的なUIで表も挿入できるし、履歴管理もすごく楽。
Confluenceがあれば、Excelの設計書を廃止して、すべてConfluenceで設計書を書くことができる。

一方、RedmineのWikiでは、Markdownの原稿を逐一プレビュータブで開いては確認する手間がかかる。
また、表のセルの結合、細かな文字の装飾も直感的ではない。

本来は、WikiはWordやExcelの代替機能になるべきだ。
そうすれば、Redmine上で、日々のタスク管理や課題管理はチケット、技術情報や設計書はWikiに全て集約できる。
それ以外の足りない機能は、REST APIやGit連携などの機能によって、他の外部ツールと連携すればいい。
最終的には、Redmine一つでPJの情報をすべて一括管理できるし、Redmineはナレッジ基盤そのものになるはずだ。

【1-4】Mermaid.jsによる作図機能は面白い。
PlantUMLみたいに、UMLのクラス図、シーケンス図、フローチャートをテキストで表現できる。
ただし、redmica_ui_extensionプラグインの機能なので注意。

個人的にはPlantUMLは好き。
モデルそのものもテキストで管理できれば、Gitで履歴管理できるので、設計書をソースコードと同じように管理できるのはいい。

My Redmine インストール済みプラグイン | My Redmine

GitHub - redmica/redmica_ui_extension: This plugin adds useful UI improvements to RedMica.

plantuml - Plugins - Redmine

Redmineには2つのPlantUMLプラグインがある - taikii blog

【2】第21回 パネルディスカッション <Redmineとわたしたち>では、モデレータ、パネラーの女性5人によるフリーディスカッション。

【2-1】面白いのは、5人の女性のキャリアが全員違うことだ。
もちろん、5人全員がRedmine経験歴は10年なのでベテランばかり。

akipiiさんはTwitterを使っています 「Redmineを使う女性だけのパネルディスカッション。サーバ管理者、プロジェクトマネジャー、SEPG、PMO等の色々なキャリアを持つ。組込ソフトウェア会社、外資系、サービス系、メーカー系など色々な属性。面白そう。 #redmineT」 / Twitter

【2-2】僕の琴線に触れたのは、ともこさんとりょうこさんの発言だった。
りょうこさんは外資系SIのPMでPlanioを使っているので、プロマネ観点が多い。
だから、Redmineパトロールみたいにチケット保守や、多数の社外関係者のユーザの権限管理の観点が多くなる。

akipiiさんはTwitterを使っています 「PMの方の意見では、Redmineのパトロールが大事。Redmineの運用がずれてしまうので、定期的にチケットの運用をパトロールする。ゾンビチケットを駆除したりとか。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「Redmineの良さ。半年前のチケットを元にコピーして今回の作業チケットを作れるので、差分だけ見ればよく作業漏れがなくなる。関連チケットでチケットを相互関係付けられる。色んな会社の人が使うので権限管理が細かく決められるのがいい。 #redmineT」 / Twitter

一方、ともこさんは全社のソフトウェアの障害管理、全社PJのゲートレビューの管理、Redmineサーバーの管理をされているので、PMOの観点が多い。

akipiiさんはTwitterを使っています 「Redmineが使いにくい所では、UIが初心者のハードルが高い意見が多いが、UIよりもワークフロー設計の方に課題がある意見の方に興味を持った。トラッカーとステータスで障害管理、定常業務の作業管理のワークフローをどう設計するか?の方が重要だし腕の見せ所と思う。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「Redmineに限らずチケット駆動の弱点の一つは、チケットの説明欄が自由すぎること。起票者の能力によってバラついて作業連携やコミュニケーションにロスが出る。そこでテンプレートを用意したり、事前にテンプレートチケットのリンクをWikiに用意して誘導する。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「Redmineを通じて対面だけでなく非同期のコミュニケーションもやっている。1年前の障害チケット、既に去った人が書いたチケットを読んで意図を理解する。チケットの説明欄に、障害内容や関連するチケットがこれです、と書けば伝えられる。書いて伝える能力が要求される。 #redmineT」 / Twitter

【2-3】女性ならではの観点では、お母さんみたいな役割もあるらしい。
この辺りは中年男性の僕には分からない笑。

akipiiさんはTwitterを使っています 「管理者がオレオレ運用ルールを押し付けると、メンバーは何でやねん!と反発してしまう。そこで相談しやすい雰囲気を作って、お母さんみたいな役割を持って、悩みを聞きまくる。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「Redmineをパトロール中に、この表現はダメだよね、と気づいたら、チケットもコメントもコッソリ直したり指導する。IT技術者の説明はぶっきらぼうで、これが仕様です、と書いてもノンITの人には伝わらない。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「心理的安全性を高めて雰囲気を良くして、チケットに書いたら、お互いに時間を有効に使えるよ、と伝えたい。 #redmineT」 / Twitter

【2-4】5人のディスカッションでは、「柔軟性」というキーワードが多かった。
「Redmineはユーザとツールの観点で柔軟である」と。

ツールの観点では、Redmineはプラグインやパッチのおかげ機能追加がすごく柔軟な特徴を持つ。
一方、ユーザの観点では、Redmineは現場の人たちのニーズに応じて、運用ルールを柔軟に変更してFitさせることができる。

僕は、「柔軟性を英語でいうと、Elasticと思う。AWS用語でよく出ると思う。 #redmineT」と思っていたが、どうやらFlexibilityの方がイメージが合っていると思う。

akipiiさんはTwitterを使っています 「柔軟性には、ツールの柔軟性と人としての柔軟性の2つの観点がある。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「100人上のユーザの中で女性PMが一番Redmineが詳しいが、若い人の意見に時々はっと気づく時がある。自分が決めた運用ルールが絶対ではないのでこう変えてもいいかもと思う時もある。人の柔軟性を実現してくれる柔軟なツールがRedmine。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「Redmineは、各人が貯めている経験や知識を吐き出すのに向いている。他人の言葉にハッとする時はむしろTwitterや対面の方が多いのではないか。 #redmineT」 / Twitter

【3】田畑さんの森林管理でRedmineを利用している事例はとても面白かった。
岡山の山奥の村に、林業でDXをやっているらしい。

【3-1】Redmineを使う場面は、補助金の申請業務や日々の作業管理。

akipiiさんはTwitterを使っています 「林業だけでは収入が少ないので、補助金の書類が大事。書類が多い。そこでRedmine。人によって情報格差が大きい。知っている人は作業できるが、知らない人は作業できない。ストレスが溜まる。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「ステータスは、下請けさんの作業街が多いので追加。監督者対応中も追加して65歳の監督者を想定。補助金の申請業務は他者対応待ちを追加。実際の業務で必要だから。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「プロジェクト=現場。バージョン=作業監督。チケット=作業で数時間。トラッカー=設計、実施、監査など。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「トラッカー=設計、監督、実施後で作ったが、WFが同じなので分ける必要はなかったかもしれない。 #redmineT」 / Twitter

【3-2】Redmineで工夫している点は、ワークフロー設計と、GTTプラグインを入れて、チケットに地図情報を記載している点だ。
実は、第20回勉強会 - redmine.tokyoで「 第20回 LT: Redmineで地理空間情報を扱う、Redmine GTT (Geo-Task-Tracker) plugin の紹介」で知って、取り入れたらしい。

Redmineと地図情報を組み合わせるアイデアは面白いと思う。
営業活動や配送管理などにRedmineを適用できるのではないか。

akipiiさんはTwitterを使っています 「森林管理は口承伝承。作業手順を文字化して標準化したい。作業手順記録はWiki、作業状況確認はRedmine+GTTプラグイン。前回勉強会LTのGeoTaskTrackerプラグインを使う。 #redmineT」 / Twitter

GitHub - gtt-project/redmine_gtt: Plugin that adds spatial capabilities to Redmine

akipiiさんはTwitterを使っています 「チケットにGTTプラグインの地図情報が表示される。チケット説明は簡単に書く。詳細はWikiに書く。チケットの説明に詳しく書くと流用しにくい。 #redmineT」 / Twitter

【4】僕も久しぶりに「Redmine屋から見たMS Planner #redmineT」を講演した。
Teamsに付属しているPlannerを使っているのだが、とにかく使いづらくて仕方ない。
Plannerは所詮ToDo管理に過ぎず、もっと細かなタスク管理や課題管理をやるのには向いていない。
当たり前なんだけどね。

MS PlannerはRedmineと違って使いにくいのは複雑なワークフロー管理ができないから: プログラマの思索

懇親会で聞いてみたら、ブレークアウトルームの大半の人はTeamsを使っている。
Slackを使う人はごく少数。
Office365を使う企業は多いので、Teams利用者が圧倒的に多い。
すると、フリーのPlannerも付属してくるので皆知っている。

しかし、Plannerは使えませんという声が圧倒的だった。
興味深い意見は、Plannerのタスクには更新履歴が残らないので、ナレッジにならない。
使い捨てのカードみたい。
PostItの感覚でしか使えない。
本来は、Redmineのように、完了したチケットでも後から参照したいのに、と。

【5】今回の勉強会は参加者が100人にも到達しなかった。
同日開催の裏番組のOL勉強会が多かったせいだろう、という意見が多かった。

また、@naitohさんのRedmine.tokyo21 questionnaireの通り、初めての参加者が少なく、4回以上の参加者が圧倒的に多くなっている。
この傾向に危険を感じる人も多い。

でも僕はあまり気にしていない。
我々の勉強会が楽しくて盛り上がっていれば自然に人は集まる。
誰でも参加できるような雰囲気さえあればいい。
他人の都合に合わせる必要はないし、こちらの雰囲気が良くて気になるなら、こちらの都合を合わせてくれればいい。

コミュニティはボランティアなので、過大なコミット感まで持たなくていい。
むしろ、緩く長く続けることのほうが大事と思う。
年2回開催という絶妙のバランスのおかげで、スタッフの作業負荷も大きくない。
5月、11月に定期的に開催できるリズムがあるから、参加者もスタッフも講演者も予定を入れやすい。

この勉強会ももう10年以上も続いているのは一つの奇跡だと思う。
他のアジャイルコミュニティも浮き沈みがあって、スタッフの入れ替え時期には開催できなかったりしていた。

三浦かずひとさんの通り、純粋に楽しめればいいと思う。

みうら かずひとさんはTwitterを使っています 「#redmineT 最近RedMineに対する思いもないし、特段興味を持って参加ではなかったのだけど…「利用者視点かつファンでない視点で見つめる」と、「お、工場?」「お、林業?」とか、凄く純粋に楽しめました。」 / Twitter

【6】2021年もAdventCalendarをやっているので、興味のある方はぜひ応募してみてください。
書いてみると、1年後には記念になるのがいいです。

Redmine Advent Calendar 2021 - Adventar

| | コメント (0)

2021/11/23

質的データの分析方法は統計処理が全盛の今でも使える

情報生産者になる (ちくま新書) | 上野千鶴子」を読んだらとても良かった。
卒論や修論を書く人にとっては論文の書き方を学ぶことができる。
それ以外に、プログラミング言語を使ったデータマイニングという量的データ分析ではなく、KJ法による質的データ分析の解説も非常に興味深かった。
気づきをメモ。

【1】社会科学の論文を書くには、アンケートや経済データなどで、大量データを統計処理する分析手法が流行りだ。
今なら、色んなプログラミング言語で統計処理ライブラリを使えば、いろんな観点で分析できる。
ビジネスの副産物として発生する大量データをクラウドのML基盤に乗せて、機械学習や深層学習をさせればいい。

しかし、「情報生産者になる (ちくま新書) | 上野千鶴子」では、そういう量的データ分析ではなく質的データ分析を好む、という一節があり、興味深かった。曰く。

第1に、質的データ分析は、相対的に少ないデータ量で数多くの発見が得られるから。
第2に、質的データ分析による帰納的データ分析の結果は、仮説を裏切る発見に至る確率が高いから、と。

量的データ分析では、平均の範囲に含まれないデータは外れ値として除外されてしまう。
しかし、質的データ分析では、外れ値や逸脱した現象は、他の大多数の類型を説明できる重要な対照サンプルになる。
この対照サンプルは、平均値である大多数の類型の特殊性を照らし出す意義がある。

この意見は面白かった。
サンプル数が少なくても、質的データ分析では意味ある仮説、主張を生み出せるわけだ。

【2】質的データ分析には、KJ法を使う。
僕は、「情報生産者になる (ちくま新書) | 上野千鶴子」を読んで、初めてKJ法の凄さを理解できた気がした。

質的データ分析の対象データでは、インタビュー記録、フィールドノートに書かれた観察データ、などの主観が入った文章だ。
まず、この文章データを、言説、つまり意味ある文体にばらす。
これを情報ユニット(単位)と呼んでいる。
情報ユニットはKJカードに1枚ずつ書き込む。
例えば、1時間のインタビュー記録で、情報ユニットのKJカードが100枚ぐらい作られるイメージ。

インタビュー記録に沿って作られたKJカード群は、その時系列に従って並べて写真かコピーを撮っておく。
後で比較するためだ。

次に、情報ユニットを脱文脈化するために、KJカードをばらばらにして、カテゴリ化する。
どうやらカテゴリはメタ情報であり、何らかの価値観に従って分類する。
このカテゴリが、たとえばユングの心理的類型みたいなものと思う。
このカテゴリ、メタ情報の名前付けが重要。

次に、集めたメタ情報(カテゴリ)を似ている、近い、遠いなどでKJカードで配置する。
マッピングと呼ぶらしい。

マッピングが終われば、チャートにする。
要因連関図というらしい。
メタ情報でグルーピングされた一次情報、メタ情報のKJカード同士で、因果関係、対立関係、相関関係で関係付ける。
このチャートを作ることで、メタ情報のストーリーを認識できる。

ここで、他と繋がりのない単独のメタ情報が生まれる時がある。
これを離れ小島、離れザルと呼ぶらしい。
KJ法は京都学派の霊長類学者がよく使っていたので、こういう概念が生まれたらしい。

ここまでで、1次情報の情報ユニット、2次情報のメタ情報が整理できた。
このチャートをもとに、ストーリーを組み立てる。
つまり物語化。
チャートの中に論理関係が含まれているので、それらの情報を元にした物語を作り、その物語が論文の本論部分になる。

【3】このやり方ですごいと思ったのは、質的データ分析にKJ法を使った論文では、論文の本論部分に1次情報である情報ユニットを下線部で引くと、ほとんどが引用された状況になっている点だ。
つまり、本論で示された事実や主張は、1次データから引用されているので、信憑性が高いことになる。

量的データ分析とは異なるが、こうやってKJ法を使って論文を書くのだ、という点は参考になった。

【4】「情報生産者になる (ちくま新書) | 上野千鶴子」ではKJ法の結果をさらに使い倒す。
基本はマトリクス分析だ。

たとえば、インタビューで何度も使われる同じ質問と、メタ情報のマトリクスを作る。
縦軸が、質問つまりケース。
横軸がメタ情報つまりコード。
ケースとコードのマトリクスを作る。

ケースとコードのマトリクスで表すと、特定の事例には出てくるが、他の一般事例には出てこないコードが出てくる。
この解釈には3つあると言う。

第1は、1次情報が不完全だった。
これは、もう一度1次情報を採集すればいい。

第2は、論理的にありえない。
第3は、論理的にはあり得るが経験的に登場しない。

ここで重要なのは第3のケースだ。
フーコーは、ある言説空間の中で、特定の言語は生産されるが、そうでない言説は原理的にありうるが登場しない可能性を示唆した。
つまり、あるテーマの現象に対し、その言説空間の歪みや傾向は、今までにない新しい仮説を生み出す可能性が高い。

他に、ケース分析、コード分析も行い、最後に報告会で分析結果を報告した時に、メンバーからコメントをもらう。
そのコメントという1次情報をKJカードで分類し、同じように分析する。
これはメタメタ情報と呼ぶらしい。
この内容が結論や主張に出てくる内容になりやすい。

【4-1】「第3は、論理的にはあり得るが経験的に登場しない」ケースは何か?
これが統計データの平均範囲に収まらない外れ値に相当する。
この外れ値という例外ケースを深く突き詰めると、新たな知見が得られる。

情報生産者になる (ちくま新書) | 上野千鶴子」ではこんな例があった。
医療現場の看護婦である研究者が、生体肝移植の成功可否とドナーの満足度について研究した考察がある。

医者は生体肝移植の手術しか興味はないし、患者以上に長く生きるドナーのその後の観察はない。
しかし、長期に渡る患者とドナーの関わりをたどると、自分の生きた臓器を提供したドナーの側に実は様々な問題が残っている、ということが分かったらしい。

マトリクス分析すると、生体肝移植が成功してドナーも肯定的なケース、生体肝移植が失敗してドナーも否定的なケースは想像可能な当たり前のケースだ。
一方、生体肝移植が失敗したけれど、ドナーは肯定的に捉えたケースがあったという。
さらに、生体肝移植が成功したけれども、ドナーは否定的というレアケースもあったという。
これらのケースがまさに「第3は、論理的にはあり得るが経験的に登場しない」ケースに相当する。

著書にはこれ以上書かれてないけど、想像すると、生体肝移植が失敗したけれどドナーは肯定的に捉えたケースは、自分はよくやった、尽くしたかった、というドナーがいたのだろう。
一方、生体肝移植が成功したけれども、ドナーは否定的というレアケースでは、ドナーの方が体調を崩し、自分の寿命を縮めてしまって否定的に捉えた、とか、患者とドナーの関係が著しく損なわれた、ということが推察される。

そういうケースがなぜ発生したのか、インタビューを元にKJ法を洗い出してくれるわけだ。

【5】ここまで来たら、後はこの分析結果を元に、きみは何を言いたいのか?をまとめる。
ここが研究の醍醐味だろう。

研究者は、データに語らせる、としばしば呼ぶが、本来は、データに代弁させるように使わなければならない。

【6】以上が質的データ分析のやり方だが、質的データの分析方法は統計処理が全盛の今でも使えると思う。
特に、インタビューや観察データが1次情報の場合に有効だろうと思う。
この使い方についてもいろいろ考えてみたいと思う。

| | コメント (0)

信頼と心理的安全性は概念が違う

恐れのない組織――「心理的安全性」が学習・イノベーション・成長をもたらす」を読んで、「信頼と心理的安全性は概念が違う」ことに気づいた。
ラフなメモ。

心理的安全性はPM理論のメンテナンスの発展形ではないか: プログラマの思索

管理職に求められる能力はPM理論そのものではなかったのか: プログラマの思索

【1】「恐れのない組織――「心理的安全性」が学習・イノベーション・成長をもたらす」の解説では、日本人の先生が率直に、心理的安全性を知った時、その価値がすぐに理解できなかった、と吐露している。
理由は、信頼と心理的安全性の違いが分からなかったからだ。
なぜ、あえて、心理的安全性の概念を打ち出す必要があったのか?
この違いを理解することは、実践上、とても重要だ、と。

そう、僕もそうだった。
信頼関係のある人間関係であれば、他人に率直に意見を述べることはできる。
いわゆる本音だ。
信頼関係が大事だとみんなが気づけば、心理的安全性という概念をわざわざ言う必要性はないはずだ。

【2】「恐れのない組織――「心理的安全性」が学習・イノベーション・成長をもたらす」の解説では曰く。
日本の組織でも、イノベーションや創造性が重要だと経営陣は社員に対して言う。
それを実現できないのは、個人の問題なのか?
実際は、経営者は、失敗するな、というメッセージも発している。
つまり、アンビバレントな両方のメッセージを社員に送っているわけだ。
すると、社員は現実上、個人に責任が発しないように、イノベーションのリスクを取らない行動を取る。

この問題の本質は、個人の問題ではなく、チームや組織の問題だ。
チームワークの研究では当たり前の、職場の雰囲気が個人の行動に多大な影響を及ぼす前提を頭では分かっていても、実際のビジネスの現場を通じて、個人の問題に帰属しない、チームや組織の問題があることを理解した、と。

【3】では、信頼と心理的安全性の違いは何なのか?
信頼は、個人が特定の対象者に抱く認知的・感情的態度。
一方、心理的安全性は、集団の大多数が共有すると生まれる職場に対する態度だ。
つまり、心理的安全性は組織文化に由来しているのであって、個人の性格に依存しているものではない。

集団で共有される心理的安全性は、集団全体の行動に影響を与える。
職場に異なる意見を受け入れる雰囲気があれば、メンバーは率直な提案をあげ、周囲はそれに耳を傾け、チーム全体で建設的な議論を交わす。
他メンバーもそういうやり取りを見ることで、違う意見や率直な考えが許される、と感じ取り、その結果、集団全体の活発な議論へ発展する。

一方、個人間に存在する信頼の影響は、あくまでも、信頼できる他者とのやり取りだけに限られる。
個人間の信頼のままでは、会議中は各自が自身の思いを秘めているだけで、チーム全体の活発な議論につながらない。
これでは、組織のポテンシャルを最大限引き出し、独創的なアイデアを実現するのは難しいことは明確だ。

つまり、個人間の信頼のレベルに留めるのではなく、それを集団で最大限に共有することが重要であると認識することが重要なわけだ。

チームワークの研究者は、チームは単なる個人の寄せ集めではなく、分解せずにチーム自体として現象を捉えるべき、と言っているらしいが、それは、バーナードの組織の3要素を思い出す。
人が集まれば組織を形成するわけではない。
共通目的があって、各人が貢献意欲を持ち、他者と対話を取ることができて初めて組織を形成する。
その基盤に、心理的安全性の概念がある。

個人間の心理的現象と集団で起こる心理的現象を明確に区別することが重要だ、という指摘は心に残った。
つまり、心理的安全性は、集団に起こる特殊な心理的現象なのだ。

【4】心理的安全性が重要であるもう一つの理由は、イノベーションを生み出す組織の特徴の一つにメンバーの多様性があるが、多様性だけではイノベーションにつながらず、心理的安全性と多様性が組み合わさって初めてイノベーションにつながる、という指摘だ。

メンバーの多様性が高ければ、常にイノベーションが生まれるわけではない。
多様性の高いチームは、メンバー間の価値観が大きく異なる為、意見の衝突が起きやすく、相手を説得するのも難しい。
つまり、多様性だけでは、メンバーが持つ専門知識を組み合わせてチームとして成果を出すのは難しい。

よって、多様な意見や価値観が存在する時、意見の違いや衝突が起きたとしても、思い切って意見を共有できる雰囲気、つまり心理的安全性が必要不可欠なわけだ。

この指摘は、考えてみれば当たり前なのだが、僕自身が忘れていた説明変数だった。
チームがイノベーションを生み出すには、メンバーの多様性だけでなく、率直な意見を言い合えるような心理的安全性もクリティカルな要素になっている。

【5】心理的安全性が難しい原因は、それが集団に共有された雰囲気であることだろう。
信頼のような個人間の心理的現象と比べて、集団に存在する現象は、個人一人が頑張っても変化を起こすのは難しい。
各メンバーが協力しあって、チームとしての意識的行動が起きて、初めて、心理的安全性が高まる。

しかし、心理的安全性はとても脆い心理状態だ。
たった1人のメンバーの振る舞いで簡単に壊れてしまう。

【6】では、多様性や心理的安全性を持つようなチームを構成するには何が必要なのか?
それは、リーダーシップの重要性だ。
リーダーが組織文化に大きな影響を及ぼすために、リーダーが心理的安全性を維持し続けるように振る舞う必要がある。
また、昨今であれば、各メンバーがリーダーシップを発揮して、協力しあって心理的安全性を生み出す必要がある。

しかし、日本では縦割り社会であり、年功序列制度や脅し、いじめなどが文化として根付いてしまっているために、心理的安全性は非常に作りにくい面があると思う。
特に、チームの中で社会的地位が低いメンバーほど、集団圧力に順応しやすく、周囲に合わせて行動しやすい。

一方、リーダーは力を持っているので、規範から生じる集団圧力にも抵抗しやすく、逸脱した行動も取りやすい。
だから、本来は、チームのメンバーはリーダーになれるぐらいの能力を持っている専門家が望ましいのではないか。

また、リーダーは、心理的安全性は個人の問題ではなく、チームや組織の問題であると捉えて、対処する必要があるのだろう。

| | コメント (0)

2021/11/20

心理的安全性はPM理論のメンテナンスの発展形ではないか

恐れのない組織――「心理的安全性」が学習・イノベーション・成長をもたらす」を読んでると、心理的安全性に関する色んな発想が出てきた。
感じたことをメモ。

『恐れのない組織』の書評とサクッと要約|勝つためにプレーする組織のつくりかた - サクっと読書(サクどく)

【要約】『恐れのない組織』と心理的安全性|【国内MBA/体験記】白山鳩|note

『恐れのない組織』の「解説」を公開します。|英治出版オンライン

【人事の読書記録】「恐れのない組織」エイミー・C・エドモンドソン | 人事担当者の頭の中

【1】「恐れのない組織――「心理的安全性」が学習・イノベーション・成長をもたらす」を読むまで、心理的安全性を誤解していた。
何でもフラットに言い合える関係、雰囲気を指すだけと思っていた。

心理的安全性の背景には、個人が標準化された作業に従事するブルーカラーから、専門性を持つ複数人が共同作業でチームを形成して成果を出すホワイトカラー集団に変わったことがある。

不安があると人間は能力を発揮できない。
強迫や不安の思い込みがあると、人は意思を削られる。
時間に追い立てられても、速く考えることはできない。

心理的安全性とは、対人関係のリスクを取っても安全と信じられる職場環境であること。
他人に自分の意見を主張しても、人格を攻撃していると思われず、率直な意見同士で対立しても後に残らないこと。

【2】たぶん、日本の組織ではとても難しい。
日本人は、学校に入った後、ずっとその一生では、縦割り集団の意向に沿うようにしつけられる。
ビジネスの世界ならもっとあからさまであり、正規社員と派遣労働者、発注者の大企業と受託の中小企業などでは、脅しが頻繁に見られる。
それはいけないと建前はあっても、所詮ビジネスは請負契約が基本なので、その契約を背景に強者は弱者に押し付けることができる。
ウォルフレンの著作に、日本人には脅しが有効だ、という言葉があって、その言葉に心情的に反発したが、実際の日本の職場ではその言葉は真実だ。
中国人SEなど海外出身の人の方が脅される弱い立場でも堂々と張り合うのに、日本人はいつも黙って従順でいる。

【3】心理的安全性という概念を導き出すきっかけの研究も面白かった。
病院において、チームワークが医療の誤り率に関係するテーマを研究されていた。
チームには専門家が多数いて、医師は人的ミスを判断できる。
こうした専門家は実質的に、従属変数となるもの、チームレベルでの誤り率のデータを集めてくれる。
そして、研究者自身が医療に明るくなかった点も、逆に実験者バイアスという認知バイアスに関わらない利点をもたらした。

実際にデータを統計分析すると、誤り率とチームの有能さの間に有意な相関関係があると分かったのだが、意外なことに、負の相関関係があったのだ。
つまり、優秀なチームほどそうでないチームよりもミスを多くしているようなのだ。
そんな話があるだろうか??
チームワークが優れていればミスが増えるのは道理に適っていない。

この事実から、有能なチームには率直に話す風土があって気軽にミスを報告したり話し合ったりできる、という仮説が導かれた。
これが心理的安全性という概念の発端だった。

そして、いろんな業界のデータを集めるうちに、心理的安全性はグループレベルで存在する、という興味深くシンプルな事実が共通項として生まれた。

さらに、率直に意見を簡単に言い合えるチームもあれば、率直に発言するのは最後の手段というチームもある。
つまり、心理的安全性はまさにグループごとのリーダーによって作られる。

実は心理的安全性の概念は新しいものではない。
エドガーシャインの組織変革の研究でも、組織や個人は学習の不安にぶつかるが、それを克服するには心理的安全性が必要だ、と著書で書かれているらしい。

不安によって能力のある個人の意欲や能力をうまく引き出せない理由は、専門性の高い仕事や多様なメンバーによるチームで共同作業を行う仕事では、心理的安全性が欠けているからだ。

【4】「恐れのない組織――「心理的安全性」が学習・イノベーション・成長をもたらす」のP.44にある心理的安全性と業績基準の関係のマトリクスがとても分かりやすい。
心理的安全性の高低x業績基準の高低のマトリクスがある。

心理的安全性が低く、業績基準が低い →無気力ゾーン
心理的安全性が低く、業績基準が高い →不安ゾーン
心理的安全性が高く、業績基準が低い →快適ゾーン
心理的安全性が高く、業績基準が高い →学習能力が高くパフォーマンスも高いゾーン

XY理論、マイクロマネジメント主体の管理手法は、作業派を不安ゾーンに陥れて働かせる。
確かに成果は出るが、心理的に安全ではない。
このやり方がつい最近まで主流の管理手法だったので、そのやり方でソフトウェア開発などのナレッジ労働者に適用してもアウトプットが出ない。

と言っても、心理的安全性が高くても業績基準が低ければ、人は快適ゾーンで暮らすことになる。
こういう職場は昨今のグローバル化により、存在し得なくなった。
どこの職場もいつも競争にさらされているからだ。

心理的安全性と業績基準の関係のマトリクスは、PM理論を連想させる。

管理職に求められる能力はPM理論そのものではなかったのか: プログラマの思索

PM理論におけるパフォーマンスとメンテナンス、つまり、仕事の成果と人間関係の2つの軸は、パフォーマンスは業績基準、メンテナンスは心理的安全性に対応付けられるのではないか。
それを言い換えただけかもしれないが、現代ではこちらの概念のほうがFitするのかもしれない。

【5】「恐れのない組織――「心理的安全性」が学習・イノベーション・成長をもたらす」では、会社や組織が不正を起こした事例を数多く載せている。
フォルクスワーゲン、ファルコ、そして日本の原発事故。
いずれも、組織が成果を従業員に強制し、心理的安全性をないがしろにすると、従業員は不正を働き、その成果をあげようとする行動を誘発する。
成果が悪事よりも重要だ、という雰囲気を生み出してしまうのだ。

こういう集団心理は、インセンティブによる動機づけを連想させる。
昨今の経済学、心理学の傾向では、人や組織を動かすにはインセンティブを故意に作り出し、インセンティブによる行動を誘発して物事を変化させようとする手法に変化している。
マーケット主導という概念も、結局は他人に新たな欲望や感情を働きかけて、市場にその行動を反映させようとするものだと思う。

すると、心理的安全性もインセンティブによる行動の誘発の一手法とみなせるのではないか。
自由に率直に意見を言い合えることで、新たな独創的なアイデアを生み出し、チームの成果を生み出すという好循環な仕組みを、心理的安全性というインセンティブがもたらすわけだから。


| | コメント (0)

2021/11/14

「入門xyzzy」は唯一のテキストエディタxyzzyの解説本だった

テキストエディタxyzzyを愛用しているのだが、入門xyzzyなる本を見つけて読んでる。
自分のためのリンクのメモ。

xyzzy - カスタマイズ可能で軽快な Windows 用テキストエディタ

「xyzzy」「Emacs」風の老舗テキストエディター - 窓の杜

強力な拡張機能を備えたテキスト・エディタ | 日経クロステック(xTECH)

入門xyzzy | Ohmsha

(引用開始)
無料で使える高機能なテキストエディタ「xyzzy」の解説書
xyzzyは、高機能なWindows用のテキストエディタである。Lispインタプリタを内蔵しており、Windows用の一般的なエディタとEmacsの両方の特徴を持ち、根強い人気がある。本書は、xyzzyについて、これから使い始める入門者から思い通りに使いこなしたい中級者までを対象に、インストール手順や操作方法、便利な設定や追加機能などを平易に解説。この一冊で、xyzzyを使いこなせるような構成となっている。
このような方におすすめ
xyzzyをこれから使ってみたいと考えているWindows(2000/XP)ユーザ
既に使っているがさらに使いこなしたいと考えているユーザ
(HTMLを手書きするような人およびプログラマも含む)
(引用終了)

Manual of xyzzy

xyzzyはEmacsやMeadowのWindows版もどきのMDIエディタ。
割とカスタマイズもできる。
Emacsライクなキーバインドは、WordやExcelと異なるので、Windows風に変更する。
英単語を英語辞書で辞書引きできる。ポップアップ表示もできる。
インクリメンタルサーチもできる。

気に入っている機能は、各プログラミング言語のコードハイライト、強力なGrep機能と検索置換、アウトラインエディタ。
基本は、markdownで書いてアウトラインエディタにしている。
EclipseやVSCode、Wordが重たいと感じる時があるので、サクサク使えるエディタが一番いい。

xyzzy 関連 outline-tree2

CommonLispで作られているので、Lispがそのまま使えるのもいい。
xyzzyでCommonLispでプログラミングする解説本「入門Common Lisp―関数型4つの特徴とλ(ラムダ)計算」も見つけた。
Lisp初心者向けの本だがこれくらいで丁度いい。
もっと早く知っていれば、Lispと仲良くなれたかなと思う。

xyzzyっはもう人気がなくなったのか、色んなプラグインのサイトが閉じられていて、肝心の本家のGithubの更新も滞っている。
GitHub - xyzzy-022/xyzzy: xyzzy 0.2.2 系列。有志により開発が継続中です。
けれど、今後も長続きして欲しいと思うソフトウェアの一つ。


| | コメント (0)

PlantUMLはJSONやYAMLのデータを視覚化できる

PlantUMLはJSONやYAMLのデータを視覚化できる記事を見つけたのでメモ。

PlantUML で JSON データを簡単視覚化

JSONやYAMLはDockerとかAPI連携でよく使うが、文字列の羅列なのでイメージしにくい。
しかし
PlantUMLを使えば、データをER図やクラス図みたいにモデルで図示できるので、全体像を把握しやすい。
こういう使い方もあるんだな、と気づいたので、今後試してみる。

| | コメント (0)

2021/11/11

法律用語「及び」「ならびに」は全く違うらしい

法律用語「及び」「ならびに」は全く違うらしいというツイートを見かけたのでメモ。

【参考】
スドー??さんはTwitterを使っています 「前にも言った気がするけど、法律文書で「部屋、ワイシャツ及び私」と「部屋及びワイシャツならびに私」と「部屋ならびにワイシャツ及び私」とではそれぞれ意味が違う」 / Twitter

とるくす????加油さんはTwitterを使っています 「@stdaux 小汚い印象を受ける部屋、ワイシャツ及び私 →小汚いのは3つすべて。 小汚い印象を受ける部屋及びワイシャツならびに私 →小汚いのは部屋及びワイシャツ。 小汚い印象を受ける部屋ならびにワイシャツ及び私 →小汚いのは部屋のみ。」 / Twitter

Ladygaya2014さんはTwitterを使っています 「@stdaux 最近甲乙丙で契約文訳したらGoogle翻訳が訳し分けるので戦慄しています…でもまだ日英、英日を逆転させると変わってしまうので混乱の極み…」 / Twitter

きくちゃんさんはTwitterを使っています 「@stdaux プログラマにもよくわかるようにS式でお願いします!」 / Twitter

山田 太三郎さんはTwitterを使っています 「@kikuchan98 @stdaux 「部屋、ワイシャツ及び私」= 部屋+ワイシャツ+私 「部屋及びワイシャツならびに私」=(部屋+ワイシャツ)+私 「部屋ならびにワイシャツ及び私」= 部屋+ (ワイシャツ+私)」 / Twitter

きくちゃんさんはTwitterを使っています 「@tasaburoyamada @stdaux なるほど、ありがとうございます! 「ならびに」は両端をグループ化した上で、さらに結合の優先順位は「、」「及び」より低いのですねー」 / Twitter

まっとさんはTwitterを使っています 「@stdaux @883R_kuma3 いっそ括弧で括ってほしい」 / Twitter

K.TerataniさんはTwitterを使っています 「@stdaux 混乱されてる方、こちらをどうぞ。 >出席者に法律関係者が集まる結婚披露宴で、司会者が「新郎並びに新婦の入場です。」と言ったところ、「並びにじゃないぞ、及びだぞ!」とヤジが飛んだという。実話なのか作り話なのかは知らないが(以下略) https://t.co/crIEZOLbj9」 / Twitter

コラム:法令を読む前に~法令用語を少しだけ/労働政策研究・研修機構(JILPT)

(引用開始)
出席者に法律関係者が集まる結婚披露宴で、司会者が「新郎並びに新婦の入場です。」と言ったところ、「並びにじゃないぞ、及びだぞ!」とヤジが飛んだという。実話なのか作り話なのかは知らないが、二十数年前に読んだ法令用語に関する書籍(さすがに題名等は失念)の中で紹介されていた話である。
(引用終了)

S式で書いたら、
「部屋、ワイシャツ及び私」= 部屋+ワイシャツ+私
「部屋及びワイシャツならびに私」=(部屋+ワイシャツ)+私
「部屋ならびにワイシャツ及び私」= 部屋+ (ワイシャツ+私)」
になるらしい。
日本語にすると全くわからない。
英語の方が分かりやすいのかな。
Rubyの&&とOR、ANDなどの優先度の違いみたいな感じかな。

しかも最近の自動翻訳では契約の文章をきちんと英訳するらしい。すごいな。
確かに契約の文章は型通りで誰もが同じように解釈しなければいけないから、翻訳向きと思う。

個人的には、こういう法律用語はことごとくプログラム化してほしい。
法律は性悪説から成立していて、このパターンならこう処理する、という羅列に過ぎないのだから。

| | コメント (0)

2021/11/09

なぜソフトウエア後進国の日本でRubyは成功したのか?~ソフトウェアの成功の秘訣はコミュニティ、そしてコンウェイの法則にある

なぜソフトウエア後進国の日本で、Rubyは成功したのか? 生みの親・まつもとゆきひろが語った五つのポイントの記事がとても心に残った。
ラフなメモ。

【参考】
なぜソフトウエア後進国の日本で、Rubyは成功したのか? 生みの親・まつもとゆきひろが語った五つのポイント - エンジニアtype | 転職type

この記事で僕の心に響いたのは下記の文章だった。

(引用開始)
ソフトウエアの成功にとっては、コミュニティーやポリシーなど、意外とテクノロジーではない部分が重要だというのが、私の経験から言えることです。
(引用終了)

ソフトウェアは、プログラマが書いて生まれる。
しかし、永続的に存続していくには、ソフトウェアを囲むエコロジーが必要だ。
それは、開発者コミュニティやユーザコミュニティだ。

熱心なユーザや開発者がいるからこそ、ソフトウェアのバグがあってもユーザが見つけてくれて、開発者がパッチを即座に当ててくれる。
高品質なソフトウェア、永続するソフトウェアは、熱心なユーザや開発者がバグ修正したり、新たなアイデアに基づく機能改善によって成長していく。

オープンソースのコミュニティの存在意義と知的財産権: プログラマの思索

柔軟なソフトウェア設計はOSSコミュニティを活発化させる~OSSソフトウェアとOSSコミュニティの密接な関係: プログラマの思索

次の文章もすごく心に残った。

(引用開始)
最初に申し上げた通り、日本の大企業的なやり方はソフトウエアづくりの面ではうまくいきません。21世紀のソフトウエアビジネスをしようと思ったら、コミュニティーの存在が不可欠なのではないかと思います。
(引用終了)

日本の大企業的なやり方とは、製造業に基づく大量生産かつ高品質な生産プロセスとのことだ。
製造業の高品質な生産方式は、規模の経済を活かしやすい特徴がある。
しかし、ソフトウェアは規模の経済が効きにくいのが最大の特徴だ。
大人数で開発するほどソフトウェアの品質は悪くなるのはよく知られている。

ソフトウェアもムーアの法則で巨大化する: プログラマの思索

少人数のチームの方がソフトウェアの品質は高いという経験則: プログラマの思索

ソフトウェア開発のチームは人数が増えるとプロジェクトは失敗する経験則がある: プログラマの思索

その理由は、人月の法則、リーマンの法則によるものだ。
コミュニケーションロスが、ソフトウェア開発の生産性を大きく落とす。

ソフトウェアの複雑性は本質的な性質であって偶有的なものではない: プログラマの思索

リーマンの法則~ソフトウェアもエントロピー増大の法則を避けられない: プログラマの思索

その背後には、Conwayの法則がある。
1つのコンパイラを4チームが作ったら、4つのインターフェイスに分割されて、無駄に複雑なアーキテクチャになってしまった、という逸話を思い出す。
つまり、「アーキテクチャは組織構造に従う」。
だからこそ、逆に、組織をアーキテクチャに合わせるように、組織をフラットに少人数なチームへ編成し直す戦略が必要になる。
これが、逆コンウェイ戦略。

今、「DXとは組織論である」という風潮が流れているが、その背景には、ソフトウェアに基づくビジネスモデルを構築したいならば、従来の重厚長大な階層型組織ではなく、ソフトウェア開発に向いたフラットで少人数のチームへ編成し直すべき、というメッセージが込められているのだろうと思う。

Conwayの法則~アーキテクチャは組織にしたがう: プログラマの思索

逆コンウェイ戦略のメモ~望ましいアーキテクチャを促進するためにチームと組織構造を進化させる: プログラマの思索

ツールで定義したプロセスが組織文化を作り出すのではないか、という仮説: プログラマの思索

DXとは組織論である: プログラマの思索

| | コメント (0)

2021/11/07

東大の講義内容が「AWSではじめるクラウド開発入門」本で出版されたらしい

東大の講義内容が「AWSではじめる クラウド開発入門 (Compass Data Science)」本で出版されたらしく、評判がよいのでメモ。

コードで学ぶAWS入門

AWSではじめる クラウド開発入門 | マイナビブックス

tomomano/learn-aws-by-coding: コードで学ぶAWS入門

Keisuke NishitaniさんはTwitterを使っています 「クラウド開発って何かと思ったら東大の講義内容らしい。今って大学でAWS習ったりするのか AWSではじめる クラウド開発入門 (Compass Data Science) https://t.co/HlJLizJ5QV」 / Twitter

是村 @ 多言語学習 & カスタマーサクセスさんはTwitterを使っています 「@Keisuke69 元はこれだと思うんですが、これの2020年度版を見てこんなの大学で教える時代なんだなーと思ってました。 https://t.co/HeZ4eQW1Hm」 / Twitter

Keisuke NishitaniさんはTwitterを使っています 「@JKoremura あーこれ!ちょっと前に話題になってたやつですよね。こういうの大学で教わるのはすごい時代ですよねー」 / Twitter

是村 @ 多言語学習 & カスタマーサクセスさんはTwitterを使っています 「@Keisuke69 いやー、ほんとそうです。そのうち何処かのタイミングでは、中途よりも新卒取る方が実践向きみたいな時期が来るかもですね。」 / Twitter

Shotaro SuzukiさんはTwitterを使っています 「@Keisuke69 これ先週読了しました。とっかかりとして良い内容ですね。」 / Twitter

最近、AWSに触っているがまだまだ本質を分かってない。
何となくEC2を立てて、色んなサービスを組み合わせれば動くのだが、何か分かった気がしない。
たぶん、もっと実際のアプリを作らないと、経験して初めて分かった気にならないのだと思う。

ツイートを読むと、東京大学2021年度S1/S2ターム システム情報学特論 "AWSを使ったクラウドコンピューティング入門" 講義資料が書籍として出版されたらしく、割と評判が良さげ。
ハンズオンでチャットボットを作るみたいだが、サーバーレスや機械学習、ディープラーニングまで触れられるのは、AWS初心者にとっては良さげ。

こういう講義ノートを読んでいると、下記ツイートのように、メインフレームのCobol開発者やオンプレミスの業務系WebシステムのJava開発者は、自分のスキルを棚卸しして、もう一度新しい技術を勉強し直す気概が必要だろうと思う。
過去の経験だけで仕事できる時代は終わった。
中年や年寄りにはそんなに甘くない。

Masanori Kusunoki / 楠 正憲さんはTwitterを使っています 「ざっと眺めたところクラウド開発といいつつEC2、Docker、サーバーレスといった足回りの話だけでなく、深層学習やらチャットボットの作成やら諸々ウォークスルーでハンズオンも充実してて、今時は前期課程でここまでやっちゃうのか高速道路スゲーぞってなったので、取っかかりの入門書としては良さげ」 / Twitter

Masanori Kusunoki / 楠 正憲さんはTwitterを使っています 「東大だけに自作CPUみたいにクラウドをつくる話を期待したらAWS上での開発か。学生時代くらいはラズパイ並べて自作クラウドをつくるとか贅沢な時間を使って欲しいけど、今時の若手はUTPケーブルの圧着もサーバーのラッキングもやったことなくサーバーはクリックすると生えてくる感覚という印象(老害)」 / Twitter

easter2501さんはTwitterを使っています 「若手が仮想化やクラウドに特化してくるならロートルはさらに泥臭い領域に縄張りを求めた方が生存率は上がるだろうな。 当然クラウドの勉強もしなきゃならんが。」 / Twitter

| | コメント (0)

2021/11/03

DockerとVirtualBoxの違い

DockerとVirtualBoxの違いをメモ。
インフラ初心者の自分のためのメモ。

【参考】
Dockerとは何か?初心者にもわかりやすく仕組みやメリットを解説

「Docker」を全く知らない人のために「Docker」の魅力を伝えるための「Docker」入門 - Qiita

VirtualBox - DockerとVirtualBoxの違いについて|teratail

DockerとVirtualBoxの違い - Qiita

「Vagrant」と「Virtual Box」の違い - Qiita

初心者のための Vagrant, Chef, VirtualBox の関係 - Qiita

vagrantのネットワークについて - Qiita

サーバー仮想化には、ハイパーバイザー型とコンテナ型がある。
ハイパーバイザー型はVirtualbox。
アプリケーションを実行するためにはまずゲストOSを起動する。
CPUやメモリ、ディスクなどのリソースも多く消費する。

コンテナ型はDocker。
コンテナはホストOSから見ると単一のプロセスとして扱われる。
カーネル部分をホストOSと共有するため、リソース使用量が非常に少ない。

以前どこかのZoomで、サーバ仮想化の技術がどんどん進化しているけど、コンテナ型のDockerは結局、Unixのプロセスと同じだよね、という発言を聞いた時があった。
その時は、そんなものかと特に感動しなかったが、ようやくその意味に気づいた。

コンテナが流行るのは、Infrastructure as codeの流れからして、開発環境やサーバー環境の構築を全てテキストで管理できること。
WindowsでもMacでもAWSでもどこでも同じテキストで構築できる。
そうすれば、作った環境を使い捨てしながらどんどん開発できる。

クラウド時代になって、オンプレミスで物理的なハードディスク装置の冗長化構成などを考える必要がなくなった。
それは単に、物理環境から仮想化環境に変わったことを意味しているわけではない。

一度作った環境は使い捨てにできる。
いつでも同じ環境を復元できるから。
すると、冗長化構成した時も、複数のノードを管理するアプリが重要であって、管理される側のノードはどんどん使い捨てていいというネットワーク設計にすればよい。
かつては、メモリやハードディスク、サーバーは貴重なリソースとして扱う必要があった為に、大切に扱うような設計手法ばかりだったが、今は使い捨てを前提とした設計手法に変わった、ということだろう。

そんな事を考えながら、改めて「ネットワークの根本問題は何だろうか?」を考えている。
ネットワークのQCDをバランス良く実現するためには、現状の技術の制約ではどんな課題があって、どんな設計手法が必要になるのか?
現代のように次から次へと新しい技術が生まれたとしても、その背景にある根本的な問題は変わらないのではないか?と推測している。

たとえば、ネットワークスペシャリスト試験の難易度|ネットワークスペシャリスト.comにこんな一節があった。

(引用開始)
なぜ難易度が高いのか?
これは「午後問題が難しい」ことに尽きます。
また出題範囲が広く、何がどういった形で出題されるかが読めないため対策が立てにくいことも合格を難しくしている要因の1つです。午前試験に関しては過去問の流用が多いので過去問の反復練習で容易に突破できますが、午後問題についてはそうはいきません。
午後試験をいい表した言葉の中で私が印象に残っているのは、「午後試験は、受験者のうち10%未満しか経験したことのない技術についての説明を読み、基礎知識を応用して解く試験である」というものです。
実際に近年だけを見ても、VPFやSDN、VoIP、IPv6、VXLAN、WAN高速化装置、UDP/QUIC、IPsecの詳細など新技術の出題を挙げればきりがありません。
このような問題に対処するためには確かな知識・技能に加え、その応用力が求められます。
(引用終了)

つまり、新しい技術が生まれたとしても、基本的な技術であるOSI7層モデル、ルーティング、スイッチング、TCP、信頼性・効率性・セキュリティなどを理解していれば、問題の本質を見抜けるはずだ。

たとえば、最近のニュースでは、楽天モバイルの普及に苦労している記事を見かける時があるが、基地局まで仮想化してしまおうとする楽天の仮想化技術にはとても興味はある。

楽天が通信網の「完全仮想化」技術をドイツに輸出、目指すはAWSで稼ぐアマゾン | 日経クロステック(xTECH)

楽天モバイルの「世界初、完全仮想化」ネットワーク、分かりやすく説明するとどうなる?:OpenStack Daysでカーン氏が解説 - @IT

CCNAの感想: プログラマの思索

ネットワークの根本問題は何か~昨今のIT技術と時代の変化についての考察: プログラマの思索

Dockerは仮想スイッチと仮想イメージの両方を持つ: プログラマの思索

SDNアーキテクチャの本質は巨大な仮想L3スイッチを実現したことではないか: プログラマの思索

他にも色々考えていく。

| | コメント (0)

« 2021年10月 | トップページ | 2021年12月 »