CCNAなどネットワーク学習者必携のチートシートを見つけたのでメモ。
【1】Cisco機器やネットワークの基礎知識が一通りそろったチートシート。
個人的には、Spanning Tree Protocolの絵が分かりやすかった。
CCNAなどネットワーク学習者必携のチートシート | 社内ITゲリラがWebで世界をめざす
やっぱり、ネットワークを制覇するにはCisco機器を使いこなすのが一番。
最終的には、Cisco機器のうち、L2のスイッチ、L3のルータを使いこなすこと。
【2】OSIの7階層モデルのチートシートも良かった。
OSI Model Summary Cheat Sheet - Part1 - Network Walks Academy
アプリケーション層に、DHCPやDNSがあるのは知っていたが、プレゼンテーション層は気にしていなかったが、JPGやGif、SSL/TLSが含まれているのか。
今一度眺めてみると割と参考になる。
「SAFe 4.5のエッセンス」「大規模スクラム Large-Scale Scrum(LeSS)」を読み比べていると、色々気づきがある。
2冊共に完読していないけど、アイデアをラフなメモ。
【1】SAFeの本質はアジャイルリリーストレインにあるのではないか？
複数のスクラムチームのアウトプットを同期させるために、アジャイルリリーストレインで統制をかける。
さらに、アジャイルリリーストレインを複数チームだけでなく、複数PJの集まりであるプログラム、複数の組織、果ては予算まで同期させようとする。
つまり、アジャイルリリーストレインによって、ソフトウェアという成果物、リリース計画、予算まで同期させようとする目論見を企てている。
ただし、SAFeは既存組織の組織構造は変えずに、アジャイルPMOという立場も認めている所は現実的かもしれない。
たぶん、日本のように組織構造も組織文化も変化させにくい所では、SAFeが導入しやすいのかもしれない。
【2】LeSSは忠実に、スクラムをスケールアップしようとしている。
だから、いくらPJが大規模になってもPOは1人だし、スクラムマスターがPJや組織の中心にいる。
SAFeではスクラムマスターの役割は大規模PJの中に埋もれてしまっているが、LeSSでは、大規模PJであっても、スクラムマスターは積極的に活動し、スクラムプロセスを推進する原動力になっている。
LeSSは最終的には、PJのスクラム運用だけでなく、既存の組織そのものをスクラム化しようと企んでいる。
スクラムマスターは、チェンジマネジメントの変革者として、既存組織の文化を変えてしまう役割も担っているように思える。
実際、LeSSでは、従来のプロジェクトマネージャや中間管理職には否定的で、彼らの存在はなくなってもいい、と思っているから。
「BABOK入門」を読んでいたら、ERP導入の難易度と組織文化をマトリクスで整理していたのが非常に分かりやすかった。
そのマトリクスの考え方の背後には、キャズム理論がある。
なるほど、そういう考えなのか。
適当なラフなメモ。
間違っていたら後で直す。
「BABOK入門」を読むと、キャズム理論は、ERP導入だけでなく、PMOが新しい標準プロセスを導入する時に、どういう対処をすれば運用を拡大して推進できるか、という示唆が得られると思う。
まず、キャズム理論は、ERP導入や開発プロセス導入対象の組織文化のレベル分けに使える。
ビジョナリーは、イノベータなので、最新のERP、最新の開発プロセスに興味を持ち、導入してくれる。
アーリーアダプターは、実利重視なので、自分たちの目的に叶うならば、リスクを背負って導入してくれる。
アーリーマジョリティは、保守的なので、他社が多数導入して、デファクトスタンダードになってから導入し始める。
ラガードは、自分たちの組織文化に誇りを持ち、他の価値観を受け入れないので、そもそも導入しないか、導入しようとしても自分たちの組織文化に合うように、ERPをカスタマイズしまくったり、プロセスをカスタマイズしまくる。
他に、キャズム理論は、ERP導入やプロセス導入の問題解決に使える。
キャズム理論では、アーリーアダプターとアーリーマジョリティの間にあるキャズムを乗り越えるのが重要、と知られている。
だから、ERPであれ、新しいプロセスであれ、キャズムを乗り越える対策が必要。
キャズム理論が教える所では、ホールプロダクト理論が知られている。
ボウリング・ピンのように、主要ターゲットを狙って成功させて、その後は次々にターゲットを定めて落としていく。
同様に、ERP導入でも、プロセス導入でも、主要ターゲットを定めて確実に成功させて、周囲のボウリングピンを一つずつ落として、シェアを高めて、デファクトスタンダードに近づけていく。
アジャイル開発の導入でも、Redmineの導入促進でも、同じような苦労があったことを思い出した。
今、PMOが導入しようとしているフェーズは今どこなのか、自分の足元を確認しながら、進めていくべきなんだな、と改めて気づいた。
Ciscoネットワーク機器のシミュレータPacketTracerのリンクをメモ。
ロジカルでないラフなメモ書き。
【1】オンプレのネットワーク構築、会社内でルータやスイッチを使って社内LANを構築するのはお手伝いくらいしか経験がないので、詳しい内容が分かってない。
有線LAN構築は割と面倒で、設計図通りに配置したし、IPアドレスも付与したのに、なぜネットワークがつながらない？みたいなこともあった。
インフラエンジニアの仕事は、サーバー機器のトラブル対応、深夜の障害対応、開発案件の本番リリースで夜間対応、とか、割とタフな仕事が多かったように思う。
今でも、客先や委託ベンダーの開発現場に行った時に、部屋の床下がミシミシ鳴っていると、床下にLANケーブルをタコ足みたいに引いているんだろうな、と想像したりする。
今は、AWSやAzureなどのクラウドで環境構築するのが普通だから、Cisco機器に精通する必要はないかもしれない。
しかし、AWS経験者から、CCNA資格を持っていると、AWSは理解しやすい、という話は聞いた。
確かに、CCNAでネットワークの基本知識は一通り身に付くから、AWS上でも、SPTとかOSPFとかルーティング構成とか、色々理解しやすくなるのだろう。
【2】下記の通りに作れば、PacketTracer上で、PCとルータだけのネットワークがが作れて、Ping通信を確認できる。
まずは使ってみよう（基本的な使い方）～その1 Packet Tracer
まずは使ってみよう（基本的な使い方）～その2 Packet Tracer
CISCOパケットトレーサーの使い方①?CCNA対策? ? ネットワークエンジニアチュートリアル
CISCOパケットトレーサーの使い方②?CCNA対策? ? ネットワークエンジニアチュートリアル
PacketTracerの操作は、下記のYoutubeが分かりやすかった。
パケットトレーサーの使い方シリーズ③ 簡単な使い方 デバイスを置いてみよう ? ネットワークエンジニアチュートリアル
パケットトレーサーの使い方シリーズ④ 簡単な使い方 ルーターやスイッチをちゃんと置いてみよう ? ネットワークエンジニアチュートリアル
【3】Cisco機器のコマンドは独特なので、調べながら叩いて、動作確認するしか無い。
「大規模スクラム Large-Scale Scrum」を読んでいたら、「文化は（組織）構造に従う」という文章があった。
なるほど、と思ったのでメモ。
以下、結論のないラフなメモ。
【1】「大規模スクラム Large-Scale Scrum」P.63では、「文化は（組織）構造に従う」をラーマンの組織行動の法則として紹介している。
組織は、中間管理職やマネージャの権力構造を維持するために、暗黙的に最適化されている。
その結果、組織を変えようとする試みは、職種の名称を変更するくらいで現状維持になる。
その結果、組織を変えようとする試みは、マネージャや現状維持しようとする人々から、理想主義者として非難される。
その結果、文化は構造に従う。
つまり、組織の文化を変えようとするのは愚かな試みで常に失敗する、と。
人々の行動（文化）はシステムの産物なので、システム（組織構造・組織階層）を変更すると、人々の行動が変化する、と。
【2】チームの文化、メンバーの行動、組織の文化は、所属する組織の構造の影響下にある。
逆ではない。
構造は文化に従うよりも、文化は組織構造に従う力の方が大きい。
人々の行動はシステムの産物。
システムを変更すると、人々の行動は変化する。
組織の構成要素を変更すると、人々の行動は変化する。
たとえば、ポリシー、役割、組織階層など。
【3】「文化は（組織）構造に従う」考え方は、システム思考と同じ考えだ。
システム思考では、発生する問題、人々の行動を即座に変更できないのは、悪循環を生むシステムが存在していて、その因果関係によって発生しているとみなす。
つまり、原因となる悪循環のシステムを変更するか、壊さない限り、問題は変化しないし、人々の行動は変わらない。
また、「文化は（組織）構造に従う」考え方は、行動経済学と同じ考えだ。
行動経済学では、人はインセンティブの奴隷、とみなす。
人々にインセンティブを付与することで、人々の行動を特定の方向に誘導しようとする。
たとえば、政府の財政政策や給付金、競争を取り締まる政策によって、企業や消費者、市場を特定の方向に誘導し、政策の効果を引き出そうとする。
【4】「大規模スクラム Large-Scale Scrum」はまだ読みかけなのだが、組織論の話が多い点に気づいた。
いかにマネージャを排し、フラットなチームを残してスケールさせるか？
現場で生き生きと活動しているスクラムから、いかに大規模な組織のスクラムにスケールアップするか？
そのためには、既存の組織構造に手を入れて、スクラムというチームの活動（文化）に悪影響を与えないようにする。
つまり、組織構造にスクラムの原理を反映させて、組織そのものをフラットにしてしまう。
この考えや意見は理想主義的なように思えるが、「大規模スクラム Large-Scale Scrum」を読んでいくと、あながちそうでもない気もする。
コロナ時代では、企業も人もいきなり変化する環境に放り出されて、物理的な接触を禁じられて、リモートワークを余儀なくされた。
すると、物理的にもマイクロマネジメントなプロジェクト管理は実施できなくなり、事実上、組織人ではなく、自由な一個人として労働するようになっているし、そうならざるを得ない。
コロナがなくなっても、労働環境も組織も変化してしまったのだから、もう昔のやり方に戻ることはできない。
そういう時代だからこそ、スクラムをチームベースではなく、大規模な組織ベースにスケールさせることには意義がある。
そのために、組織構造に手を加えて、人々の行動を変容させることも必要になってくるのだろう、と思う。
「ストーリーマッピングをはじめよう」本を読んで良かったのでラフなメモ。
【参考】
なぜユーザーストーリーによる要件定義にピンとこなかったのか: プログラマの思索
あなたが開発しているプロダクトにストーリーはあるか。クリフハンガーに陥らないための作戦がここにある。 - The Dragon Scroll
小説分析ツールyWriterの機能を元にストーリーの構造や考え方を解説するpart1: プログラマの思索
小説分析ツールyWriterの機能を元にストーリーの構造や考え方を解説するpart2: プログラマの思索
yWriterは映画の脚本を作るためのアプリだったのではないか: プログラマの思索
【0】「ストーリーマッピングをはじめよう」本の感想は3つある。
1つ目は、ユーザーストーリーで物語を可視化できる。
システム要件を物語として構造化できる。
物語は三幕構成というロジカルな構成を持つ。
アリストテレスが古代ギリシャ悲劇を理論化して、何千年もの歴史がある。
世界中の誰もが馴染みやすい。
そもそも、人間の認知のメカニズムは、ストーリーになる。
人間は、事象を、物語を介して理解している。
たとえば、旅行、映画、体験談。
たとえば、内視鏡検査が痛かった体験談すら、ストーリーで家族に語る。
2つ目は、ストーリーはSaaSと相性が抜群に良い。
ストーリーに合わせて顧客を呼び込んで、顧客行動をWebの画面遷移のWebログで計測できる。
導線のクリフハンガーを特定できる。
ストーリーの効果をKPIで評価できる。
SaaSのKPIなら、AARRRを思い出す。
AARRRとは?サービスを成長させるための基本戦略【テンプレート付】｜ferret
つまり、購入率、CVR、成約率というKPIでストーリーの効果を評価できる。
3つ目は、課題解決に適用できる。
現状→問題→葛藤→目的達成→解決、という課題解決の流れは、古典的なストーリーの構造である、状況設定→複雑化→問題→解決と全く同じ。
課題解決には3種類のストーリーで使い分ける。
コンセプトストーリーで、新製品・新規機能をアピールする。
次に、潜在顧客に、オリジンストーリーでメッセージを伝える。
さらに、具体的な利用シーンをユセージストーリーで説明して、末永く利用してもらう。
つまり、新製品のコンセプトを打ち出してユーザを惹きつけ、顧客接点となるWebログイン画面から、物語のようなWebの導線を張ってユーザ誘導して、おとぎ話に落とし込む。
それぞれの機能は、利用シーンに合わせたストーリーで一貫した目的があり、ユーザはそれに一喜一憂して、ハラハラ・ドキドキさせられる。
そういうSaaSを目指すわけだ。
【1】ストーリーマッピングの特徴は3つある。
1つ目は、ユーザー体験を物語の各場面にプロットポイントとしてマッピングすることで、ストーリー化してしまうこと。
物語はナラティブアークと言われる。
ナレーションみたいなものだろうか。
「ストーリーマッピングをはじめよう」に出てくるストーリーには、7つのプロットポイントがあり、時系列のグラフとしてマッピングされる。
プロットポイントは、状況説明→事件や問題の発生→盛り上げ→危機→クライマックス→オチ（落とし込み）→エンディング、という流れ。
三幕構成では、状況説明→事件や問題の発生が、始まり。
→盛り上げ→危機→クライマックスが中盤。
落とし込み→エンディングが終わり、に相当する。
ストーリーの構造は、「考える技術・書く技術」に出てくるプレゼンテーションのイントロの技術「状況→複雑化→疑問→答え」と全く同じ。
一方、ストーリーはこの7つのプロットポイントを明確に意識し、観客の感情を上下させるように場面設定を論理的に組み立てなければ、興ざめしてしまう。
各プロットポイントにも特徴がある。
事件発生では、Call To Action、つまり、行動を求める声となるイベントを置く。
ユーザが後戻りできないような事件を引き起こす。
物語では、クライマックスが大事。
クリフハンガーとは、上昇途中やクライマックスで唐突に終わるストーリー。
これは避けなければならない。
halfalogueとは、盛り上がるだけで、オチのないストーリー。
クライマックスやエンディングが半分だけなのでイライラする。
これは避けなければならない。
エンディングでは、続き物をわざと残す。
別の物語につなげるために。
【2】2つ目は「ストーリーマッピングをはじめよう」では、ストーリーは3種類ある。
「コンセプト・ストーリー」「オリジン・ストーリー」「ユセージ・ストーリー」の３つ。
【2-1】コンセプト・ストーリーとは、製品概念の物語。
Concept＝構造、全体像。
顧客が製品に感じる印象を元に、課題解決する。
新製品や新機能の開発に取り組む時に利用される。
例は、ジョブズがiPhoneを始めて紹介したプレゼン。
Slackというコミュニケーションツールを最初に紹介したプレゼン。
注意点は、平坦な展開は避ける。
物語を支える要件を見極める。
【2-2】オリジン・ストーリーとは、潜在顧客が初めて購入する物語。
Origin＝発端、起点。
製品概念を知った後で、製品を実際に使ってもらう。
よって、顧客のチャネルや顧客接点が重要になる。
目的は、新規客を獲得し、リピート客にConvertする。
顧客接点を起点にあの手この手で販促する。
物語はプロモーションかな。
マーケティング部、営業部、広報部が、オリジン・ストーリーを主体的に作る場合が多い。
つまり、技術部がメインではなく、潜在顧客をマーケティング部などがイメージして、ストーリーを作り出す。
注意点は、物語をどう終わらせるか？が大事。
物語をストーリーにマッピングできないと、クリフハンガーが発生し、せっかくの見込客が離れてしまう。
Webシステム上のユーザの導線を計測して、クリフハンガーを特定し、対策を取る。
どんなアフォーダンスをユーザに示すか？が大事。
つまり、Web画面上の手がかりをユーザに認知させること。
ストーリーの概念としては、Call To Actionが大事で、たとえば、ボタンという機能を作り込むのが大事。
【2-3】ユセージ・ストーリーとは、顧客がステップごとに製品を使っていく物語。
Usage＝利用、使い方。
プロットポイントごとにユーザの実行動がマッピングされる。
カスタマージャーニーを構造化したもの。
ユセージ・ストーリーには、長い旅もあれば短い旅もある。
大冒険型ストーリーなのか、連続ドラマ型ストーリーなのか。
物語のスケールを決めるのが大事。
Core Task（＝Item）が中心になる。
クリフハンガーを解決するストーリーがテーマになる。
物語を視覚化すると、クリフハンガーがはっきりする。
たとえば、初期のTwitterはユーザ同士がつながるだけで、その利用シーンをユーザはイメージできず、クリフハンガーが発生していた。
そこで、ツイートしてメリットが出るユセージ・ストーリーを作り、それをTwitterの導線で実現することで、現在の爆発的な利用につながった。
【2-4】3パターンのストーリーのいずれもターゲットである顧客行動をKPIで計測する。
具体的には、SaaSであれば、Webログからユーザのアクセス履歴は全て追跡できる。
目的は、ストーリーの効果を測定すること。
クリフハンガーを特定し、ストーリーとWebシステムのギャップを探し出し、Webシステムを改良していく。
これにより、購入率やCVR、成約率を向上できるし、顧客満足度を高めることもできる。
【3】3つ目は、ストーリーマッピングの技法は、経営戦略の分析・策定や行動方針にも適用できること。
「ストーリーマッピングをはじめよう」にはいくつか例がある。
ギャップ分析では、ストーリーを使って、クリフハンガーや平坦な物語と、ユーザや企業が目標にたどり着ける物語の差（ギャップ）をクリフハンガーとして視覚化する。
Webシステムや製品に対し、ユーザの行動分析にストーリーを使って、ユーザがどのように利用しているのか、クラスタリングみたいに複数のユーザの特徴を洗い出す。
それにより、製品の改良に役立てる。
要件評価では、バックエンドのシステム要件、フロントエンドのシステム要件をストーリーマッピングで視覚化し、ストーリーを評価する。
SWOT分析では、カスタマージャーニーや製品のSWOT分析をストーリーで語らせる。
ストーリーマッピングにより、物語の全体像が視覚化できる以外に、足りない所、機能していない所、可能性が眠っている所を明確にできる。
【4】「ストーリーマッピングをはじめよう」を読んで改めて思い浮かぶことは、なぜ、ストーリーが要件定義や企画フェーズで重要な役割を果たすのか？ という問題だ。
ストーリーは実はロジカルに構成できるから。
実際、ストーリーという物語形式は、アリストテレスの悲劇論の歴史から始める三幕構成というロジカルな形式で表現される。
普通の日本人が思うような起承転結みたいな浅はかな構成ではない、と思う。
ストーリーは課題解決に適用できるから。
課題解決の構造は物語の構造と一致している。
現状とあるべきゴールに対し、ギャップが問題として発生し、その問題を解決する。
状況設定の後、主人公が達成すべき目的となるインサイト・イベントが発生し、苦難の旅を経て、目的を解決する。
ストーリーは顧客から要件を引き出せる。
ITに詳しくない発注側のユーザ、情報システム部門から、要件を引き出したり、要件を議論するには、ストーリーで語ると共通理解が捗る。
ストーリーはKPIで測定できる。
WebシステムのKPIはAARRRの他にもたくさんある。
要件定義されたストーリーは、プロダクトバックログ（PBL）に蓄積される。
PBLから実際のリリース計画にマッピングする時には、ユーザーストーリーマッピングの技法を使えば、時系列と優先順位の表にユーザーストーリーをマッピングできる。
よって、ユーザ体験を重視したストーリーを実現するために必要な機能要件は、ユーザーストーリーマッピングの表から、MVPとなる対象機能を抽出でき、開発チームは、スプリントの襦袢に実装していけばいい。
こういう流れを理解すると、ストーリーによる要件定義はSaaSととても相性が良い。
そして、SaaSはアジャイル開発にピッタリのシステムであり、ビジネスモデルでもある。
昨今、DXが日本企業でも流行しているが、僕は、DXとは、ソフトウェア開発のビジネスモデルを持たないレガシー企業が、既存事業をSaaSとして展開するための仕組みづくり、と理解している。
従来のようなレガシーな基幹システムの開発スタイル、要件定義の手法とは、全く違うやり方ではないか、と考える。
このストーリーによる要件定義手法については、今後も色々考えてみる。
みんなのPython勉強会#65に初参加してみて、内容がとても良かった。
自分もPythonが理解できるようになったので、その意義がすごく理解できる。
社会変革の鍵はIT技術者にあるのかもしれない、と思った。
結論のないラフなメモ書き。
【参考】
みんなのPython勉強会#65 - connpass
セミナー参加ログ》みんなのPython勉強会#65 2021/1/13(水) 19:00?21:00（オンライン開催） - acokikoy's notes
【1】Pythonのビジネス、データサイエンティストの話、LT、そしてシビテックまで、幅広いテーマでとても興味深かった。
その中で、シビテックの話がとても興味を引いた。
シビテックは、プログラマが市民の立場で、政府や公共機関に出てくる問題をITで解決すること、と理解している。
関さんは、Coder fo japanというOSSコミュニティで活動されている。
東京のコロナ感染のWebサイト構築で一躍有名になった。
都内の最新感染動向 | 東京都 新型コロナウイルス感染症対策サイト
また、台湾のIT大臣のオードリーさんがGithubにプルリクを送ったことでも注目された。
ソフトウェアの政治的影響力とは何だろうか: プログラマの思索
関さんの話によると、日本では、2011年の東日本大震災の時にシビテックに関わるプログラマが増えて注目を浴びたらしい。
さらに、昨今のコロナ感染状況の期間で、関さんのいるSlackメンバーは、約4倍以上の人数に増えた、とのこと。
つまり、社会の危機的状況が、プログラマをシビテックに関与しようというモチベーションを与えているわけだ。
では、なぜそんな状況でプログラマは、シビテックに関わろうとするのか？
理由は色々あるだろう。
たぶん、人間としての生存本能が現れるのではないだろうか。
こういうOSSコミュニティは、IT技術者にとって、とてもメリットがある場だ。
理由は、自分とは違うバックグラウンドを持つ技術者と関係ができて、技術力もアップするし、視野も広がる。
講演では、東京のコロナ感染のWebサイトでは、色盲の人に優しいアクセシビリティを考えるべき、というプルリクもあって、非常に勉強になった、とのこと。
【2】講演後の質疑応答で気になったのは、シビテックが欧米と日本でどのような特徴の違いがあるのか、という話。
関さんによると、欧米人は自分の意見を持って自己主張する。
政府はこういう政策を取るべき、こういう行動を取るべき、とか。
一方、日本人は、自己主張しない代わりに、応援するタイプが多い。
良い政策があれば、それを後押しするように活動する。
言い換えれば、日本人はリーダーシップがなく、受け身の人が多いのだろう。
また、米国では行政府の人はリボルビングドア（回転ドア）なので、OSSコミュニティの人の中に、行政府に所属して働いた経験を持つ人が多い。
すると、行政の事情に詳しいので、行政のニーズをよく知っていたり、行政の人間関係や法律上の壁などの事情をよく知っている。
ゆえに、シビテックではそういう人たちと組むことで、より効果の出せるIT技術による解決策を提示できる。
一方、日本では、OSSコミュニティに行政に関係する人が少ないので、行政と連携しにくい。
プログラマもそういう行政の裏事情を知らないので、連携しづらい面がある。
しかし、東京の副都知事にヤフー経験者の人が入ったおかげで、東京ではシビテックが盛んになってきた、と。
また、行政はITに詳しくないので、ITに詳しい技術者やOSSコミュニティと関わりたいニーズはある。
特に最近は、デジタル庁を設立する話も出たし、農林水産省や経済産業省もIT技術者を募集する広告を見かけるようになってきた。
こういう危機的な状況だからこそ、IT技術者が求められているのだろう。
社会変革の鍵の一つに、IT技術者も含まれている。
【3】そういう講演を聞きながら、今のコロナ感染対策が難しい理由も素人ながら何となく想像できるようになってきた。
その理由は、コロナ感染という問題が影響する範囲が広すぎて、数多くの分野の専門家を集結させて、一貫した方針を打ち出す必要があるのに、どれが正解か分からないので対策を取るのが難しいからだろう。
たとえば、コロナ感染の新規感染者を予測し、政策に合わせてその精度を次々に手早く変更していくには、西浦先生のような疫学の専門家が必要だし、感染などの医療に詳しい医学者が必要。
しかし、彼らだけで問題を解決できるわけではない。
たとえば、ロックダウンにより経済的に困っている人たちへ給付する政策を実行して、人々にどういうインセンティブを持たせれば効果が上がるか、という行動経済学とか、財政出動とその効果を測定するには、マクロ経済学とか、そういう経済学の専門家も必要。
そして、そういう経済政策や医療政策を実行するための正統性を確保するために、新しい法律を整備する法律家も必要。
たとえば、コロナ感染者が増加している状況で、コロナ感染者をスマホで追跡・隔離したり、検査した情報をクラウドの基盤に蓄積したり、刻一刻と変わる情報をWebサイトで収集・公開したり、各人に適切な給付金を配布するための一連の仕組みをWebシステムで構築したりするには、専門のIT技術者が多数必要になる。
つまり、それぞれの分野で一流の人を集めて、彼らを的確にアサインし、振ってくる問題をさばいていくことが求められる。
そういうことを実施する時、トップが全ての分野に精通して理解できるのは難しいだろう。
トップは全ての分野に精通した専門家ではないのだから。
では、そういうチームを編成して、問題を一つずつ解決していくことを成し遂げるには、何が必要なのだろう？？
専門家でもないリーダーには、どんなスキルが求められるのだろうか？
どんなリーダーシップを発揮したら、問題となる状況を解決できるのだろうか？
何故ファシリテーションが流行しているのか？: プログラマの思索
管理職に求められる能力の記事を読んでいたら、三隅二不二のPM理論そのものではないか、と感じた。
ラフなメモ書き。
浅い考えなので後で直す。
【参考】
管理職に求められるものとは─新世代リーダーへの条件─（前編）【ONE JAPAN CONFERENCE 2020レポート：PEOPLE④】｜ONE JAPAN｜note
【1】（引用開始）
基本的に管理職に求められることは今も昔も変わらず、パフォーマンスとメンテナンスです。パフォーマンスとは、部門の業績を管理することで、メンテナンスはそのために多様なメンバーをマネジメントすることです。
しかし、管理職は組織の中間点にいるので、この2つに加えてダイバーシティや働き方改革、DX（デジタル・トランスフォーメーション）などあらゆる組織の問題が、すべて管理職にしわ寄せが来てしまっています。
さらに経営層からは、新規事業や新しい価値を作ってくれとオーダーされたり、現有の戦力の中で、多様な部下の強みを引き出して、なるべく早く革新的な成果を、しかもリモートで出してくれと命じられています。
（引用終了）
「基本的に管理職に求められることは今も昔も変わらず、パフォーマンスとメンテナンス」ということは、まさにPM理論そのままだなと思う。
成果を求めるパフォーマンス（P）と、チームビルディングなどのメンテナンス（M）の２つ。
PM理論by三隅二不二 | EARTHSHIP CONSULTING
PM理論とは ～理論から理解するリーダーシップとその変遷～｜人材育成・社員研修｜ラーニングエージェンシー
【2】そう言えば、PM理論は別名、パパママ理論とも呼ばれるらしい。
「業績：目標達成機能」（Performance)はパパ、「維持：集団維持機能」（Maintenance)はママに相当するように覚えると理解しやすかった。
（引用開始）
当時はまだまだ男が稼いで奥さんが家を守るという雰囲気の世の中だったので、このPM理論はパパ・ママ理論とも呼ばれ、厳しく子どもを育てるお父さんと、子どもの気持ちに寄り添うお母さんのイメージをあてて、このPM理論を説明していた。
（引用終了）
【研究ノート１】リーダーシップ理論（その１）「PM理論」｜鈴木康宏｜note
【3】「管理職に求められる能力はPM理論そのもの」という意見から気づいたことは3つある。
1つ目は、リーダーシップには成果（P）を求められること。
「採用基準」本に「リーダーシップとは成果を求めること」というフレーズがあったが、たぶんそのことを指しているのだろう。
問題解決のためには、リーダーシップを発揮して、周囲を巻き込みながら、あるべきゴールへ到達するルートをとにかく進んでたどり着く。
まずはそういうスキルがなければ、話にならない。
2つ目は、ファシリテーション能力が10年以上前から重視されている理由は、メンテナンス機能の特徴の一つであること、そして、リーダーシップを補完する機能であるためだろう。
管理職に成り立てのマネージャは、部下に仕事を回すよりも自分でやった方が速いので、どうしてもマイクロマネジメントになりがち。
そういう時に、プロジェクトファシリテーションのようなスキルがあると、結果を出すチームを形成できるようになる。
スクラムマスターという役割も、メンテナンス機能を重視しているのではないか、と思う。
3つ目は、上記の記事では、管理職には新規事業を提案することまで求められてはいない、と記載されていたが、優秀な中間管理職ほど、新しい事業アイデアを実現したくてウズウズしている。
誰だって、上から言われた仕事をそのままやるのがモチベーションではない。
自分で実現したいアイデアや夢があって、それが会社の方向性と一致していれば、やる気も上がるし、そうなるように仕向けたいと思うからこそ、職務や権限を利用して動く。
特に、日本の組織では、名君と言われる経営トップは必ず、優秀な中間管理職をブレーンとして持ち、自由に采配が振れるように配慮してくれるものだろう。
たとえば、幕末から明治維新の頃は、薩長の下級武士がそういうトップに引き立てられて、彼らが原動力となって時代を変えていったように。
たぶん、日本は、経営トップが独裁的に振る舞うような欧米・中国のやり方ではなく、中間層のリーダーがリーダーシップを発揮するような、そういう組織文化なのだろう、と思う。
Pythonデータ分析試験、Python基礎エンジニア試験に無事に合格できた。
感想をラフなメモ。
【参考】
Pythonデータ分析試験 | 一般社団法人Pythonエンジニア育成推進協会
Python基礎試験 | 一般社団法人Pythonエンジニア育成推進協会
【1】Python基礎エンジニア試験は簡単だったが、Pythonデータ分析試験は難しかった。
Python基礎エンジニア試験は、RubyやJavaを知っていれば、それら言語のライブラリを比較しながら理解すれば良かった。
Pythonは確かに書きやすい。
Rubyのように異音同義語のようなAPIはないし、文法も簡素だし、Tabのインデントだけでプログラミングできるので、手に馴染む。
しかし、Pythonデータ分析試験では、Numpy・Pandas・MatplotLib・sklearnの割とたくさんのAPIを覚える必要があるし、統計学や線形代数の数学の知識、分類・回帰・次元削減・クラスタリングなどの機械学習の知識も必要になるので、Python以外の知識習得に手間取った。
統計検定2級、G検定も取得していたので、それらの知識に慣れているから1ヶ月で十分だろう、と思ったが、実際は2ヶ月以上習得にかかった。
まだまだ、Pythonのセンスが足りないので勉強すべきと分かった。
なお、Python基礎エンジニア試験の教科書「Pythonチュートリアル 第3版」、Pythonデータ分析試験の教科書「Pythonによるあたらしいデータ分析の教科書」は持っておいた方がいい。
このAPIはどうだったけ？と振り返る時に、辞書代わりになる。
【2】Python基礎エンジニア試験、Pythonデータ分析試験で良かったのは、Web上の模擬問題が充実していること。
PRIME STUDY（プライム・スタディ） ? Python試験とPHP試験の無料模擬試験サイト
G検定、Python、Rubyの模擬テスト | DIVE INTO EXAM
上記のWeb問題を5～10回転ぐらいやって100％得点できてから受験したので、そんなに緊張感はなかった。
特に、PRIME STUDYの問題の方が確かに難しかったけれど、出題内容は「Pythonによるあたらしいデータ分析の教科書」と全く同じなので、理解に役立った。
【3】Pythonデータ分析試験、Python基礎エンジニア試験を良かったことは、3つある。
【3-1】プログラミングはブロックを組み立てる感覚が大切、と改めて感じたこと。
Python 初心者だから、Numpy、Pandas、Matplotlib、sklearnのAPIでつまづいてるけど、機械学習は面白い。
教師ありデータなら、train_test_splitして、機械学習のモデルにfitで学習させて、scoreで評価し、最後にpredictで予測する。
実際は、そういうデータの前処理に大量のロジックを組み込むわけだが。
すると、1行でもロジックというブロックが崩れると、プログラムは意図通りに動かなくなる。
ちょうど、積み木の途中で1個のブロックが崩れると、全てが崩れてしまうみたいな感じ。
プログラミングはとても繊細な作業。
プログラミングが書けるかどうかは、そういうセンスに依存する所も大きいと思う。
「60%の人間はプログラミングの素質がない」記事のリンク: プログラマの思索
【3-2】プログラミングは書くだけでなく、開発環境も大事、と改めて感じたこと。
Pythonが良いのは、Anacondaで一通りのライブラリが揃い、ライブラリのバージョンごとに依存した開発環境を別々に保持できること。
一方、RubyならGemのバージョン依存にすごく手間取るし、Ruby初心者はRailsの環境構築ですぐにつまずいてしまう悲しさがあると思う。
また、PyCharmという開発環境がとても良い。
コード補完できて、デバッグもできるので、プログラミングにストレスがない。
一方、コンソール画面で対話形式でPythonをプログラミングできるよ、ブラウザ上でJupyter Notebookでグラフも書けるよ、と言われても、やっぱりコード補完できないのは辛い。
僕は、IntelliJの有償ライセンスを購入したので、Jupyter Notebook上でもコード補完もデバッグもできて、ああ、こういう風に動いてるのか、とか、初心者レベルからの気づきがあった。
プログラミング初心者はこういうつまらないレベルでつまずいて、先に行けなくなるから。
DockerやAnsibleの考え方もそこに通じているのではないか、と思う。
【3-3】Pythonを通じて、最先端の技術に簡単にたどり着けること。
線形代数や微積分、統計学の数学の知識は、それがなくても、Pythonを書きながら慣れていけばいい。
Numpyのブロードキャストやユニバーサルファンクションに慣れれば、自然に線形代数は理解できるはず。
統計量の計算、データの前処理となる分散正規化、ヒストグラムで表示する前処理となる層化抽出法、などは、PandasやMatplotLib、sklearnに慣れれば、理解できるはず。
sklearnのSGDライブラリを使いこなせれば、微積分の考え方も分かるはず。
もちろん、「ゼロから始めるディープラーニング」のサンプルプログラムを動かしながら慣れていけば、ディープラーニングだけでなく、微分における極小値や最小値の違い、鞍点のイメージも理解できるはず。
つまり、Pythonの機械学習ライブラリを使いこなせるようになれば、自然に、統計学・線形代数・微積分の知識も身につくはずだ。
紙と鉛筆で計算することも大事だが、プログラミングでは、要は動かしてナンボの世界だから。
そして、今のIT技術の最先端に一度到達できれば、他の分野でも、初心者レベルから今の自分のレベルまでに到達するにはどれくらいの道のりが必要なのか、そこから先にはどんな課題が控えているのか、を想像できるようになる。
そうすれば、すごく楽しくなる。
おかげで、Pythonの機械学習や深層学習の本が読めるようになってきたので、乱読できるのがすごく楽しい。
まずは「Pythonではじめる機械学習 ―scikit-learnで学ぶ特徴量エンジニアリングと機械学習の基礎」から読み始めていて、今頃になって、そういう意味だったのか、とか色々気づきがあった。
【4】Pythonの機械学習や深層学習ライブラリを覚えた後で、やりたいことは、目の前の問題事象に対し、原因とその予測を見つける因果推論ではないか。
100件以上のデータがあれば、分類モデルや回帰モデルで簡単にモデルを試せて、やりたい問題が解けるのに感激した。
最終的にやりたいのは、目の前の問題やイベントに対して、誰も見つけなかった因果関係の発掘だよな、と思う。
Python でプログラムを書ければ、誰でも新しい因果関係を発見して、経験則と言う法則を作り出せる。
たとえば、行動経済学や公共経済学であれば、こういう政策を政府が提示した場合、国民の消費活動や企業の生産活動はどう予測されるか、などの問題も、スマホやWebで収集した大量データをクラウド上に集めて、機械学習や深層学習のエンジンでモデルを学習させれば、その結果を予測することもできる。
つまり、回帰分析のように、予測したい目的変数に対し、有意な説明変数を見つけることで、単に相関関係を見つけるだけででなく、AならばBとなる、といった因果推論まで提示できるはず。
経済学は信頼性革命や構造推定により大きく変貌している: プログラマの思索
IT企業が経済学者を雇い始めた理由が面白い: プログラマの思索
社会現象や人間の心理に対し、こういう因果推論を経験則、法則として数多く見出すことができれば、それらは一つの規範を示す。
つまり、哲学の言う、ザイン（である・存在）ではなく、ゾルレン（かくあるべし・規範）を学問として提示できるはず。
最終的には、全ての文系学問の出てくる諸問題は、統計確率論を基盤としたPythonの機械学習や深層学習で実装されたモデルから導かれる規範を樹形図のように整理するだけで、自然科学の中の一つの学問分野に収斂されるのではないだろうか。
こういう技術が直近10年で当たり前になったのもすごいし、こういう技術を知らずに、今までの知識や技術に固執するのも一つのリスクだな、と思う。
小説分析ツールyWriterに似たようなソフトとして、ストーリー作成ソフト『StorYBook』があるらしく、その記事を読んでいたら、こういうストーリー分析ツールは映画の脚本を作るためのアプリだったのではないか、と気づいた。
【参考】
ストーリー作成ソフト『StorYBook』を使ってみた: はまログ
小説分析ツールyWriterの機能を元にストーリーの構造や考え方を解説するpart1: プログラマの思索
小説分析ツールyWriterの機能を元にストーリーの構造や考え方を解説するpart2: プログラマの思索
なぜユーザーストーリーによる要件定義にピンとこなかったのか: プログラマの思索
【1】実際に、yWriterは映画の脚本を作るのに最適だ。
理由は2つある。
【2】一つは、場面ごとに、人物・場所・アイテムという貴重なリソースを割り当てることが明確になるからだ。
映画では、一つの場面ごとに、高額な俳優に来てもらい、海辺やビルなどの場所を確保して、衣装や車などの道具（アイテム）を準備して望む。
1つの場面がたとえ5分であっても、人物・場所・アイテムという貴重なリソースをたった一つの場面に割り当てる必要がある。
一方、ある俳優の撮影期間が限定される場合、彼が出演する場面をすべて抜き出して、あらかじめ撮影すれば良い。
そのために、映画を数百本の場面にバラしておき、特定の俳優がアサインされる場面だけを抽出して、全体ストーリーとは無関係に個別にシーンを撮影するように、人物ごとの撮影スケジュールを作ればいい。
つまり、場面の観点ではなく、人物の観点で場面を抜粋しているわけだ。
あるいは、夕焼けの海辺のシーンのように、この一瞬しか場面を撮影できないとなれば、場所の観点で撮影スケジュールを作ればいい。
つまり、人物一覧・場所一覧・アイテム一覧のビューで、場面数が集計表示されるのは、そういう意味があったわけだ。
【3】もう一つは、ストーリーボードで時系列に場面を簡単に入れ替えたり、追加・変更・削除できることにより、映画のストーリーを柔軟に変更しやすくなることだ。
映画は2時間という制約があるので、場面数には上限がある。
よって、脚本家が数多くの場面を細切れに作った後で、まるでブロックを組み立てるように、場面を時系列に並べると映画が完成する。
名作と言われるレベルまで練り上げるために、場面を入れ替えたり、削ったり、場面を書き直したり、何度も推敲すればいい。
そういう推敲作業をツールが支援してくれるわけだ。
yWriterにはストーリーボードなど数多くのビューがあるけれど、その他の米国製のストーリー作成アプリを調べてみると、登場人物の家系図や関係図を表示したり、場面・人物ごとのカレンダーを表示したり、場所を集めた地図を表示するような機能もあるらしい。
確かに、歴史小説や推理小説であれば、人物の家系図や時代表はあると理解しやすい。
【4】こういう小説分析ツール・ストーリー作成ソフト・映画の脚本作成ツールは、なぜか日本製のツールがなくて、ほとんどが米国製だったりする。
たぶん、ハリウッド映画のように大量に映画を作成するには、こういう脚本作成ツールでロジカルかつ大量な場面を管理するツールが必要なのだろう。
また、欧州では小説を論理的に場面を意味あるもので組み合わせて構成するようなので、場面を管理して分析できるツールは必要なのだろう。
一方、日本ではこういうツールがない事実があるので、小説や映画、テレビ番組の脚本は、小説家や脚本家の個人的能力だけに依存しているか、アナログの京大式カードなどで場面を管理するとか、そういうレベルに過ぎないのかもしれない。
あくまでも推測に過ぎないが。
【5】yWriterをモデリングの観点で分析してみることで、アジャイル開発に出てくるストーリーのニュアンスや役割が何となくイメージできた気もする。
たぶん、欧米人がシステム要件をユーザーストーリーと呼んで扱っている場合、日本人の想像を遥かに上回って、もっとロジカルなレベルで考えているのだろうと思う。
つまり、ユーザーストーリーには、目的・対立・結論の構造と、人物・場所・アイテムの構成要素を持ち、英雄伝説の構造に沿って、世界中の人が誰でも親しみのある物語形式のロジックに組み込むように、彼らは作り込んでいるのだろう。
この考え方を使って、ユーザストーリーマッピング、カスタマー・ジャーニー・マップ、ナレーティブ・ジャーニー・マップなどの要件定義手法を考えてみたいと思う。
インフラの勉強がしたくて、Youtubeを探していたら、下記のCCNA講座が秀逸だったのでリンクしておく。
【参考】
【CCNA動画支持率No.1】未経験からのインフラエンジニア勉強講座【ネットワーク基礎入門 #1】 - YouTube
【CCNA講座】「OSI参照モデル」が30分で絶対分かる！【インフラエンジニア基礎入門 #2】 - YouTube
【高評価97.2%】CCNA「物理層」を完璧理解できる講座【インフラエンジニア基礎入門 #3】 - YouTube
【CCNA合格講座】「イーサネットとは？」を徹底解説！【インフラエンジニア基礎入門 #4】 - YouTube
【CCNA合格講座】TCP/IPとは？「仕組み」完全解説！【インフラエンジニア基礎入門 #5】 - YouTube
【CCNA講座】「TCP」「UDP」を日本一易しく解説！【インフラエンジニア基礎入門 #6】 - YouTube
なお、すべての講義はUdemyで見た方が早い。
新CCNA（200-301）完全未経験からの合格講座（上）【YouTube高評価率98.2%のパワーアップ完全版】 | Udemy
【1】上記のCCNA講座の対象は、SIに入社した新人社員、5年目までの若手までのレベル。
インフラ専門で仕事している技術者は当たり前の話だろう。
しかし、アプリ開発しかやっていない人、AWSをかじっているけどインフラ基盤の知識が薄い人には、とても参考になると思う。
たとえば、ハブ、スイッチ、ブリッジ、ルータの違いが分からない、というレベルであれば、とても参考になる。
AWSサービスを組み合わせてインフラ基盤を構築する時にも役立つはず。
そういう知識は、IT業界にいたら、既に知っている知識のはずだろう。
しかし、別の業界の人にとっては、未知の知識なので、そういう初歩レベルからつまずく。
そういう人たちがいきなりAWSをやるぞ、と言っても、たぶん訳がわからないのではないだろうか。
同様に、IT業界のベテランであっても、法律系や財務系の知識はほとんど知らず、経理や法務の部署の人から見れば、その部署の新人レベルに過ぎない、という人も多い。
僕は理系人間なので、会計システム構築の経験を踏まえて、財務や会計は面白いし、知識も習得できた。
一方、法律だけはどうしても理解できなかった。
ああいう変な日本語の文章で書かれて、判例があるたびに例外の処理が増えて、しかもGitで構成管理されていないから、変更履歴が入り混じった変な因果関係で書かれた文章は、性に合わない。
結局、IT技術者であっても、別の業界に移れば、新人ないし5年目までの若手レベルに過ぎない。
【2】最近、こういう動画配信の講義がすごく増えてきて、書籍を買うよりも分かりやすい、という評判をよく聞くようになった。
自分も色々試してみて、動画と書籍による学習方法やその効果の違いもだいたい分かってきた気がする。
Udemyのような動画のメリットは、映像化されているので、その分野では自分は素人または初心者の時は有効。
Python機械学習、AWSのクラウドネットワーク講座、ビジネス法務検定みたいない法律系、とかは、いきなり書籍を読んでも分からないので、こういう初心者向けの動画を見ながら、PCでメモを取って、基本単語に慣れることから始める。
動画のデメリットは、長時間で目が疲れること。
初心者レベルから解説しているので、どうしても3～20時間ぐらい見ないといけないのは割と辛い。
最初は2倍速で聞き流して、何回も繰り返して見る。
一方、書籍のメリットは辞書代わりになること。
ある程度、基本概念に慣れたら、中級向けの本が読めるようになる。
図書館で数冊の本を借りて乱読すれば、どんどん理解が進むので楽しくなる。
書籍のデメリットは、初心者向けの本ですら最初は読みにくいこと。
基本的な用語すら分かってないので、写経みたいな感じで結局読了すらできない。
だから、Udemyみたいな動画から取り組んだ方が早道。
Udemyクラスの先生は、その道のプロなので、初心者がハマりやすい箇所を知っていて、比喩の使い方がすごく上手。
最近は、こういう勉強ツールがすごく揃ってきた状況を考えると、自分が高校生だったり新人社会人なら、もっと効率的に学習できただろうに、と思ったりもする。
つまり、現代では、高速道路を使って一気に最低限の基本知識を習得する基盤が揃ってきたわけだ。
そういうツール、学習方法を知っているか否かで、その後のキャリアも変わってくるのだろう。
いつまでも学習を続ける、みたいな感じなのかな。
以前、ITILの研修を受けた時、講師から「変更管理プロセスが弱いとトラブルが多い 」という話を聞いて、非常に心に残った。
【1】ITシステムは変更に起因するインシデントによって、必ず変更が起き、それが遠因となってトラブルが起きやすい。
例えば、OSやソフトのバージョンアップ、システム移行、マイグレーションなど。
つまり、今まで「あるべき姿」で稼動していたのに、ある時点で「おかしくなった現在の姿」へ方向が変わり、時間が経つにつれて、ギャップが生じる。
このギャップがトラブルだ、と。
だからと言って、ITシステムの変更を生じるインシデントを全て拒否することはできない。
むしろ、ITはバージョンアップすることで、使いやすくしていくのが最大の特徴だから。
そこに矛盾がある、と。
【2】ITシステムは変化があって当然だし、その変化を受け入れて、その変化をコントロールする技術を持つことが重要だ。
その技術が、変更管理プロセスであり、構成管理プロセスであったりすると考える。
つまり、プログラミングやモデリングそのものに問題があるわけではない。
それら技術の進化が激しく、5年も経てば老朽化が当たり前で、5年おきにリプレースしてシステム移行だけでなく業務移行も伴う。
そういう変化をコントロールする術をあなたは持っていますか？と問われている気がする。
ITILはそういう変更管理プロセスに着目した考え方だと思う。
僕は、そういう変化をコントロールできる開発基盤として、Redmine＋Gitが必要ではないか、と考えている。
そのアイデアも膨らましてみる。
開発プロセスを管理することでしか、ソフトウェアの品質は管理できない: プログラマの思索
「カンバン仕事術」を読んで、気づいたことをメモ。
【1】カンバンの運用では、ステータスはどんな観点で作るべきなのか？
カンバンはチケット管理と相性が良い。
なぜなら、カンバンのステータスはチケットのステータスと同じだから。
チケット一覧をタスクボードでビジュアライズすれば、障害修正プロセスのどの工程でボトルネックが発生しているのか、一目で分かる。
では、カンバンのステータスはどんな観点で作るべきなのだろうか？
一般に、Redmineのワークフローでは、新規→進行中→解決→完了 がデフォルトだが、現場で運用する場合は必ず変更した方がいい。
チケットのステータスと同じ、と言っても、それぞれの現場でワークフローはかなり違う、という経験をしてきた。
たとえば、デフォルトステータスのまま運用すると、実は、ステータスに対応する担当者がいない時もあれば、複数人もいる時がある。
たいていの場合、SIの開発プロセスはインフラ基盤・デザイナー・アプリ開発・DB基盤・設計レビュー担当のように部門ごと、役割ごとに縦割り組織になっているので、割と複雑だ。
よって、ステータスが組織と対応付けられていないと混乱しやすい。
では、カンバンのステータスはどんな観点で作るべきなのか？
【2】カンバンのステータスは、役割やチームごとに割り当てる
「カンバン仕事術」のイントロでは、Jiraを例として、カンバンのステータスを決める場面がある。
最終的には、ToDo→分析→開発→テスト→受入→運用待ち→本番 に決まる。
決め方は、各ステータスに役割ごとの担当者がアサインされる。
最後に「完了」ステータスがない理由は、チケットのタスクを実装して運用待ちになっても、リリース作業は別のベンダーが担当するので、自分たちで本番リリースしてバグがなかったことを見届けられないからだ。
本番リリースしたとしても、バグが出れば、また戻ってくるので、完了という呼び名が合わない、とチームで決めたからだ。
この場面を読んでいると、カンバンのステータスは、作業の役割ごとに決められる点だ。
開発プロセス、組織構造の部門ごとに、作業の役割は細分化されるので、その単位ごとにステータスが対応付けられる。
Redmineのデフォルトステータス「新規→進行中→解決→完了」ではステータスが少なすぎる場面が現実では多い。
経験上、メーカーのように生産工程が、生産計画部・製造部・品質保証部などのように縦割りになっている場合、ステータスの個数が増える傾向が多い。
メーカーの生産工程を模倣したWF型開発や、ソフトウェア工場のプロセスでは、通常のソフトウェア開発よりもさらにステータスが多くなりがち。
たとえば、開発者がバグ修正してコミットしても、テストサーバーにアップするには、構成管理担当者に連絡してアップしてもらい、別のテスターに検証してもらう、といった手間がかかる場合は、「構成管理担当者によるリリース待ち」「リリース終了・テスト検証前」のようなステータスがないと、誰がボールを持っているのか、混乱しやすい。
とは言え、現状を表したステータスをつけて、ワークフローを作るべき。
別の話では、リーン開発の考え方により、バリュ・ストリーム・マッピングの手法を使って、複雑になりすぎたワークフローをリファクタリングしてプロセス改善しましょう、というやり方もある。
【3】ボトルネックになるステータスの前に、キューを置け
役割ごとにステータスをアサインして実際に運用すると、ボトルネックとなる作業者の前に仕掛作業が滞留し、ボトルネックとなる場合が多い。
その原因を探ると、単純に、WIPが少ないからだけではない。
たとえば、受入ステータスのWIPが4になっているが、常に受入可能なチケットが埋まっているわけではない。
基本は、受入可能なチケットがあれば、担当者はすぐに検査・テストして、リリース可能と判断できれば、運用待ちステータスへ流す。
しかし、WIPが4より小さいと、テスターは常に張り付いて作業しないといけないが、出張や会議などで不在の時は対応できない。
一方、WIPが4より大きいと、テスターがフィードバックを戻す前に、開発者は別の作業に仕掛中になってしまって、すぐに対応してくれなくなる。
よって、受入フェーズでは、バッファとなる「準備完了」と、実際の「作業中」でステータスを分ける。
つまり、何らかの理由で制約がある工程の前にキュー（バッファ）を置くことで、ワークフローの一連の流れが停滞しないようにする。
キューの役割は、作業の流れを平準化することだ。
すなわち、フローの中で、流量（つまりタスク）のばらつきを抑える役割を果たす。
一般にキューは、ボトルネックとなる作業の前後で置かれる場合が多い。
たとえば、ToDo、開発準備完了、開発完了、テスト待ち、リリース待ち、レビュー待ち、受入待ち、などの呼び名がある。
キューの有無を判断するには、ステータスの入出条件、退出条件から考えればいい。
【4】カンバンは奥が深い
キューは、アルゴリズムの基本の一つ。
FIFO。
ワークフローを作る際に、流れが悪い場面で使う事が多いと思う。
ふりかえりでプロセス改善する時に、思いつきやすいと思う。
カンバンが面白いのは、2つある。
一つは、ワークフローの改善に役立つこと。
もう一つは、メトリクスやKPIを採取しやすいので、プロセス改善の材料に簡単に昇華できることだ。
なぜなら、カンバンはフロー管理に特化しているので、流量を速度にたとえれば、チケットの枚数で計測化しやすい。
完了ステータスとなったチケットはアウトプットなので、生産性にたとえられる。
「カンバン仕事術」では、下記のKPIを紹介している。
リードタイム：1枚のチケットが最初のステータスから最後のステータスに入るまでにかかった時間
スループット：一定期間（例：1週間）ごとに完了したチケット数
こういうKPIはグラフ化すると分かりやすい。
たとえば、チケット完了日ｘチケットのリードタイム で散布図をプロットすれば、問題解決について、色々議論しやすい。
なぜ、このチケットはこんなに時間がかかり過ぎたのか？
そこからどんな原因が分析できるか？
たとえば、リリース週ｘスループットを折れ線グラフにすれば、納期遵守の工夫が見つかるかもしれない。
つまり、これらのKPIを開発プロセスにフィードバックすることで、各ステータスのWIPを減らしたり多くしたり、ステータスを統合・分割する解決法が見つかり、プロセスを改善する行動につなげられる。
元々、Redmineはカンバンと相性が良いので、どのKPIがプロセス改善に役立つのか、そういうノウハウも蓄積できるはずだ。
いろいろ考えてみる。
RedmineをPJ管理ツールと呼ぶのは嫌い。
「Redmineはチケット管理ツール」と呼びたい。
【1】PJ管理ツールと呼びたい場面では、プロジェクトマネージャーやPMO、経理部門、経営層が各PJの進捗・課題・コスト・品質管理を常に監視したい欲求がある。
彼らは、ソフトウェア開発の案件は常に赤字のリスクにさらされているのを身を持って知っているので、プロジェクトリーダーの定性的なPJ報告を信用していない。
プロジェクトリーダーは、PJ途中まで、進捗も問題ありません、と言いながら、リリース間近になって、品質が悪くて進捗が大幅に遅延しました、というPJ報告が多すぎるから。
プロジェクトリーダーも、90％症候群に慣れている。
よって、PJ管理ツールを全社に導入して、各PJのQCDを可視化し、常時監視できる状態にしたい。
すると、PJメンバーは毎日、PJ管理ツール上で、詳細化されたWBSに進捗率と実績工数を入力するように躾けられる。
一般に、高価な有償パッケージ製品のPJ管理ツールを導入して、社員だけでなく、内製開発にいる準委任契約の協力会社メンバー（BP）にもその運用を強制させる。
それにより、毎週・毎日のPJ報告では、進捗や原価は自動計算できるから、理論上は、毎日、PJ報告を提出させることで、PJのEVM、原価と粗利、営業利益を出力させることはできる。
でも、実際にそんな運用をしたら、メンバーの進捗・工数入力の作業負荷が大きくなり、肝心のPJ作業時間が削られるので、そこまではやらないのが普通。
【2】しかし、PJ管理ツールの真の問題点は、PJメンバーのやる気を下げる点だ。
PJ管理ツールの目的は、PJのQCDの可視化であり、経営層や経理部門、間接部門にメリットがあるだけ。
大多数のPJメンバーの気持ちは全く考慮していない。
大多数のPJメンバーは、PJ管理ツールにデータを入力するだけの役割であって、PJ管理ツールやその運用を改善しようというインセンティブは働かない。
一般に、PJ管理ツールではユーザの権限制御が厳しく、一般のPJメンバーには、PJの採算情報はもちろん、メンバーの月額単価のようなマスタ情報にアクセスできないようにしているので、彼らが触るメニュー画面は、制限された機能が少しだけ載せられているだけであり、非常に貧弱な機能に過ぎない。
つまり、PJメンバーから見れば、PJ管理ツールは単なるデータ入力基盤に過ぎず、面倒なシステム以上のものではない。
ゆえに、PJメンバーにとって、PJ管理ツールを使いこなす動機やインセンティブがない。
【3】一方、Redmineのような自由なチケット管理ツールであれば、PJ管理ツールのデータを自分たちで分析しよう、そこからプロセス改善していこう、という仕組みを作れる。
「チケット駆動開発は、メンバー全員でチケットを消化していくゲーム」という雰囲気を醸し出せるからだ。
PJの外側にいる利害関係者たちのRedmineではなく、PJに実際に関わっている開発者のためのRedmineであれば、自分たちのPJをより良くしていくための仕組みとしてRedmineの豊富な機能を有効活用できる。
【4】僕もRedmineやプロセス改善に長年関わってきて、Redmineの優れた機能やUIを、PJのQCDを把握できるPJ管理ツールに発展させていく方向性を考えてきたし、Redmineの最終形は案件のQCDを管理するためのERPへ発展していくだろう、と考えていたこともあった。
しかし、ERPのような機能を盛り込んでしまうと、Redmineの良さがどんどん失われて、せっかく自分たちで作り上げた開発プロセスが、他人が押し付ける開発プロセスに変化してしまい、PJメンバーのモチベーションが落ちていく現象も何度も見てきた。
だから、RedmineをPJ管理ツールと扱うのは嫌いだ。
Redmineはチケット管理ツールとして扱うべきだ。
【5】そういう経験を振り返ると、Redmineは、外部のステークホルダーの為のPJ管理ツールというERPの側面と、PJ関係者の為のチケット管理ツールの側面の2つがあり、それらを同時に実現するのは難しいと考える。
現実としては、それぞれの役割を3層構造のシステム・オブ・システムにシステム分割する方向性ではないか、と考える。
たとえば、
View＝チケット管理で進捗・課題・障害管理（QD）＝Redmine、
Model第1層＝コスト管理（C）＝原価管理システム、
Model第2層＝社内の会計システム
みたいな3層構造にする。
理由は、PJ関係者、PMOやSEPGや品質保証部門、経理部門や経営層の3つの役割ごとに、PJ管理ツールを使う目的が異なるからだ。
チケット管理に特化したUI層と、PJのQCDを見たい層、PJの原価や採算を管理したい層、の3つに分けて、Redmineで入力されたデータが裏では自動連携される仕組みになるべきだ。
そうすれば、PJメンバーのモチベーションやインセンティブが損なわれず、活発にプロセスを改善していく雰囲気を維持できるだろう。
そんなことを考えると、PJ管理ツールは最終的には、SAPのような会計システムと連動すべきERPの機能の一部と見なせる一方、RedmineはそういうERPに統合させるべきではない、とも考えている。
最近のコメント