パターン言語

2022/06/05

「大人の学びパターン・ランゲージ」の感想~知識と経験を行ったり来たりするタイミングを大切にする

「大人の学びパターン・ランゲージ」はリスキリングの参考になると思った。
IPAの同じWebページにある「学び続けている実践者の方からお話を伺いました。」というインタビュー記事もとても良い。
読んでみて、自分の中で色々考えるものがあった。
ラフなメモ。
間違っていたら後で直す。

【参考】
大人の学びパターン・ランゲージ(略称まなパタ):IPA 独立行政法人 情報処理推進機構

変革への道:IPA 独立行政法人 情報処理推進機構

知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る: プログラマの思索

実践した後に勉強するのがエンジニアの本来の道: プログラマの思索

【1】社会人になって「学ぶ」とはどんな意義や問題点があるのだろうか?

日本人なら大学へ入る18歳までは受験勉強という公式な体制の元で勉強させられる。
学びとは何なのか?という基本的な問いを考える作業は、この期間は無意味だ。
むしろ、希望大学に入学することが自己目的化している人ほど、受験競争の勝者になる。

一方、社会人になると、急激に能力を伸ばす人と、停滞する人の2種類に差別化される。
案件に揉まれて技術やマネジメントの経験を身に着けて、どんどん昇格して、社会的地位が上る人もいれば、職を転々としながらも何も変わらない人もいるし、同じ企業の中でずっと何も変わらずに仕事している人もいる。
人はそれぞれの目的を持って生きているように仕向けられる。

そういう状況の中で、現代という時代では、20代で身につけた知識や技術がすぐに陳腐化するリスクに常につきまとまれている。
特に、IT技術を身に着けても、それは10年後には当たり前になり、差別化できる要因ではなくなる。

すると、30代、40代、50代と年齢を経るごとに、自分が活躍できるステージをどんどん変えていく必要性が出てくる。
単純な専門的知識で差別化するよりも、チームや組織、企業を回すようなマネジメント、経営への領域へ移す人達も多い。
人との関わりという部分で差別化しようとする。

しかし、20年経てば1世代変わるので、人も社会も価値観が変わり、人間関係をコントロールするマネジメントスタイルも急激に変わる。
昨今では、米国でのマネジメントの最新知識、たとえば、心理的安全性、ファシリテーション、ティール組織、などいろいろな手法を身に着けなければ、今の社会で自分の存在意義を見つけるのは難しいのではないか。

【2】ビジネスで結果を出そうとする時、知識と経験の2つの両輪が必要になる。

自分の数少ない経験では、知識を経験に変わるタイミング、経験が知識に変わるタイミングを自分なりにつかんでおくことが重要と思う。
なぜならば、知識だけ脳みそにたくさんあっても使いこなせなければ現場では無意味だからだ。
経験をいくら積んでも、その経験を自分なりに解釈して抽象化した知識に変換して、他人に説明できなければ、現場では無意味だからだ。

知識を実際の現場で使おうとする時、他人から教わった知識、本から得た知識は、自分の現場の問題が発生する環境とギャップがある。
環境がもたらす制約条件を考慮しながら、問題を解決する方向へ知識を利用する。
その知識が問題をうまく解決するときに使えたタイミングで、その知識の有効性とその知識が使える範囲を自分なりに理解できる。
この時が知識が経験に落とし込めたタイミングだ。
このタイミングはすごく重要で、そのタイミングを意識しなければ、何事もなく通過してしまって、自分の腹に落とし込めたものにならない。
その知識には、自分にとって再現性がなくなるからだ。

一方、色んな経験をして来た後で、本を読んで気づいたり、コミュニティや大学で色んな人と議論して気づいたりするタイミングがある。
たとえば、初めての案件で初めての役職で仕事して試行錯誤したり、デスマーチ案件で日々苦しめられたり、ルーチンワークに追われて何も考えないまま過ごしたりした後で、なぜこんな状況を自分で解決できないのか、という疑問や問題意識を強烈に持つ。
自分の能力の限界を知り、自分で環境を変える要因をつかみたいと思う。
そんなときに、本や動画、ネット、他人との会話という数多くのチャネルを通して、知識やフレーズに触れたときに、ぴーんと来る時がある。
この時の知識が、経験から知識を抽出して、自分なりに理解できたタイミングだ。
このタイミングは重要で、自分でそのタイミングを意識しなければ、経験は単なる時間的浪費にすぎない。
いくら年齢を取ったとしても、同じ時間という量は質が大きく異なる。

知識と経験を行ったり来たりするタイミングを自分なりに意識して習得することが必要であると最近感じている。

【3】知識と経験を行ったり来たりするタイミングやその活動は、たぶんSECIモデルで表現されるだろうと思う。

知識を経験に変えるタイミングは、形式知から暗黙知に変換する活動に一致し、それは「内面化」に相当すると思う。
経験を知識に変えるタイミングは、暗黙知から形式知へ変換する活動に一致し、それは「表出化」に相当すると思う

つまり、内面化や表出化のタイミングを自分なりにいつも意識して、その瞬間を忘れないようにすること。
そうすれば、以前の自分からなにか一つ殻を破れた、という感覚が得られると思う。

そのためには、表面的な知識を色々自分なりに考えて、どういう問題ならうまく適用できるのか、どんな制約条件を考慮すべきか、実はあまり効果がないのでは、と試行錯誤して考える必要がある。
その作業は、形式知同士を組み合わせて新たな形式知を得る「連結化」という作業が必要になるのではないか。

また、案件でたくさんの経験を得たとしても、その経験から何が問題だったのか、何が足りなかったのか、どんな環境要因があったのか、試行錯誤して考える必要がある。
その作業は、暗黙知の内容を整理して暗黙知のレベルを高める「共同化」という作業が必要になるのではないか。

【4】知識と経験を行ったり来たりする作業は意識的にやる必要があると思う。
特にビジネスマンになれば、いろんな場面で初めての問題に遭遇し、常に問題解決や再発防止を迫られる。
そんな状況で何らかの成果を出すには、常に知識と経験を行ったり来たりする技術を持つ必要があると思う。

以前「実践した後に勉強するのがエンジニアの本来の道」というツイートを読んで、ソフトウェア開発はまず実践して経験した後で知識を習得するのが一番の近道、という内容を思い出した。
実践した後に勉強するのがエンジニアの本来の道: プログラマの思索

また、ビジネス経験を積んだ後でMBAを取得する話をよく聞くが、たぶん、一度経験した内容を知識として再構築する必要性を感じているのだろうと思う。
「あるMBAコースの人(元銀行員で支店次長)が僕にこう言っていた。MBAっていうのは、サラリーマンが20年間で覚えることを圧縮して教えるものだと。マネジメントのエッセンスを短期的に学ぶことで管理職、役員レベルの視点を持つことを目的にするということなのかもしれない。」という内容は心に残った。

企業経営アドバイザー - hmiyau ページ!

MBA | 猫好きのブログ

まなパタにはそのヒントが隠れているような気がする。

| | コメント (0)

2022/04/26

知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る

SECIモデルの状態遷移図を描いて、ようやくSECIモデルを理解できた気がする。
ラフなメモ。

【1】2014年頃に、SECIモデルでパターン言語を理解しようと考えていた。
確かにパターン言語と相性は良いが、SECIモデルのイメージがまだピンときていない気がしていた。

SECIモデルは、PDCAみたいなマトリクスよりも、知識・経験の状態遷移図で描く方が理解しやすいと考えた。
形式知=知識、暗黙知=身体による経験。

【2】知識を使って身体に落とし込むのが内面化。
スポーツ、楽器、お絵描きなどの訓練が相当するだろう。

一方、身体で経験した内容を知識でまとめるのが表出化。
一流のスポーツマン、学者、音楽家、宗教家、哲学者たちは、自分たちの体験を何とか知識として言語化し、みんなに広めようとする。
走る哲学者と言われる為末大さんみたいな感じかな。

他方、形式知を組み合わせて新たな知識を創造するのが連結化。
感覚的に情報を受け取って暗黙知を高めるのが共同化。

【3】知識は経験よりも大切なのか?
経験は知識よりも勝るのか?

僕は両方を経験している。

IT技術者であれば、たくさんのプロジェクトで新技術や業務システム開発を経験した後で専門書を読み直すと、ああ、そういうことだったのか、と気づく時が多い。
中島聡さんは、プログラミングとは、座学で勉強するものではなく、実際にアプリ開発して体験した後で専門書で答え合わせするものだ、と言われていた。
そんな内容と似ている。

実践した後に勉強するのがエンジニアの本来の道: プログラマの思索

僕がRedmineにハマったきっかけも、XPやアジャイル開発の本はたくさん読んだが、何か腑に落ちることがなくて、Redmineでいろいろ試して初めて分かったという事があった。
知識がいくらあっても、やはり体験しなければ、本当に理解できた、という感覚がない。
肌感覚では分かった気にならなかった。

一方、IT企業やプロジェクトという組織形態では、いつもイライラするものがあって、その原因がなにか分からない時があった。
組織文化はトップが作るのか、ボトムアップで作られるのか、いつも疑問に思っていて、アジャイル開発の影響から、組織文化は現場からボトムアップで生まれるのだろうと思っていたが、診断士の先生に聞いたところ「組織文化を生み出す責任は社長にある。もっと社長が汗をかけ!」と言われて、ハッと気づいた時があった。

制度的リーダーシップの考え方が何となくしっくりきた: プログラマの思索

組織文化はトップが作るのか、ボトムアップで作られるのか: プログラマの思索

同様に、組織論、経営戦略論、経済学などを勉強してみて、メンバーに応じた教育方法ならSL状況理論やPM理論を使ってみたらいい、とか、プロマネとPMOの微妙な対立関係はエージェンシー問題に似ているな、とか、知識を使って、自分なりに理解が進んだ気がした。

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

ITの地殻変動はどこで起きているのか?~今後の課題はソフトウェア事業におけるエージェンシー問題を解決すること: プログラマの思索

また、RedmineでRubyのソースコードは適当に触っていたがRubyはちゃんと理解できてなかった。
RubySilverやRubyGoldを勉強してみて、Rubyはオブジェクト指向言語を徹底しているんだな、と改めて理解し直した。

Ruby技術者認定試験の感想: プログラマの思索

そんなことを考えると、知識と経験の相互作用として、SECIモデルの内面化、表出化を行ったり来たりしながら自然に実践している。
そして僕はたぶん、実際に色々体験して、失敗を繰り返さないと腑に落ちないみたいだ。
そういう感覚はSECIモデルの状態遷移図で整理できるんだな、と改めて感じた。

| | コメント (0)

2022/01/23

「ハリウッドリライティングバイブル」のマインドマップ

脚本術の本の一つ「ハリウッドリライティングバイブル」を読んだ。
映画や小説はどんな構造(ストラクチャー)とストーリー(感情を揺さぶる物語)を持つべきなのか、とても理解ができた気がした。
その時のマインドマップを後で自分が読むためにアップしておく。

物語を構成する要素はプロットである: プログラマの思索

なぜユーザーストーリーによる要件定義にピンとこなかったのか: プログラマの思索

小説分析ツールyWriterの機能を元にストーリーの構造や考え方を解説するpart1: プログラマの思索

小説分析ツールyWriterの機能を元にストーリーの構造や考え方を解説するpart2: プログラマの思索

「ストーリーマッピングをはじめよう」本の感想~ストーリーによる企画や要件定義はSaaSと相性がいい: プログラマの思索

【1】どうやら、直近5年間に脚本術の有名な本がどんどん翻訳されているらしい。
理由は知らないがニーズはあるのかな?

ゲームシナリオにハリウッド脚本術は使えるのか?おすすめ本の紹介とともに|卍凸凹|note

(引用開始)
ここ数年、ハリウッドの脚本術の本が色々と出版されています。
ハリウッドで定評のある本は、どれも非常に論理的にわかりやすく説明しており、シナリオを書く人にとっては何かしらの発見がある読み物かと思います。
(引用終了)

僕も、下記の本を読み上げた。
2000年代以前の映画をたくさん見た人にとっては、脚本術の本に載っている映画のストーリーやシーンが分かるから、より一層楽しめると思う。
映画は視覚の芸術だからこそ、小説とは違って、より緻密に構造化されていて、そのおかげで量産化できるようになってビジネスになり、大金をもたらす。
小説家や脚本家になりたい人だけでなく、ロールプレイングゲームを作りたい人にとっても、役立つ本だと思う。

SAVE THE CATの法則 本当に売れる脚本術 | ブレイク・スナイダー, 菊池淳子

映画を書くためにあなたがしなくてはならないこと シド・フィールドの脚本術 | シド・フィールド, 安藤 紘平, 加藤 正人

素晴らしい映画を書くためにあなたに必要なワークブック シド・フィールドの脚本術2 | シド・フィールド, 安藤紘平, 加藤正人, 小林美也子, 菊池淳子

最高の映画を書くためにあなたが解決しなくてはならないこと シド・フィールドの脚本術3 | シド・フィールド, 安藤紘平, 小林美也子, 加藤正人

ストーリー ロバート・マッキーが教える物語の基本と原則 | ロバート・マッキー, 堺三保, 越前敏弥

【2】脚本術の本に興味を持っている理由は、アジャイル開発におけるストーリーによる要件定義手法を理解したいためだ。

ユーザーストーリー、ユーザーストーリーマッピング、ストーリーマッピングなど、似たような言葉が沢山出てくる。
また、カスタマージャーニーやデザイン思考の背後にも、ストーリーという概念が背後にあるように思える。

たぶん、欧米人が語る「ストーリー」という言葉は日本人が持つ言葉のイメージと違うと直感している。
単に物語という意味ではない。
起承転結という仕組みよりも、アリストテレスによる悲劇の分析で三幕構成が提唱されてからずっと、たぶん彼らは舞台劇や小説を理論化してきていると思う。

実際、「ハリウッドリライティングバイブル」「映画を書くためにあなたがしなくてはならないこと シド・フィールドの脚本術」「素晴らしい映画を書くためにあなたに必要なワークブック シド・フィールドの脚本術2」を読んでみると、映画のワンシーンという一つのプロットに小さなストーリーを埋め込み、全体の構成の配置、構造化に数多くの原則を彼らは見出している。
欧米人は、脚本術のおかげでプレゼン能力がすごく高いのではないか。

実際、単純な因果関係で説明されても人の心には響かない。
でも、感情を揺さぶる物語形式がバックボーンに埋め込まれていると、堅苦しいプレゼンを聞いているはずなのに、感情を揺さぶられて聞き入ってしまう、そういう感じがする。

アジャイル開発でも、システムの要件定義というIT技術の言葉が氾濫して難しい現場において、システムの詳細を知らないユーザが理解できるように、脚本術でストーリーを持ち込んで、一連のストーリーとして理解できるようにしたように思える。

今後の僕のテーマの一つは、欧米人が理論化した脚本術を、astahを使って、概念モデルやプロセスの構造に落とし込んで理解したいことだ。


| | コメント (0)

2022/01/14

【資料公開】チケット駆動開発の解説~タスク管理からプロセス改善へ #redmine

プロジェクト&プログラム・アナリシス研究部会で講演した資料「チケット駆動開発の解説~タスク管理からプロセス改善へ」を公開します。

【参考】
お知らせ2点:P&PA研究部会「チケット駆動開発」(1/11)、BOMに関する1日集中セミナー(1/27) : タイム・コンサルタントの日誌から

プロジェクト・マネジメント・システムは存在しうるか : タイム・コンサルタントの日誌から

【1】資料のテーマは、下記の通り。
基本的な前提として、Redmineの経験者を対象としている。

チケット駆動開発は、ソフトウェア開発で使われる障害管理ツールをタスク管理に利用する開発手法を指す。
チケット駆動開発はアジャイル開発と親和性が高いので、アジャイル開発のプラクティスを利用しやすく、チーム運営に役立つ。
チケット駆動開発を支えるチケット管理ツールは、汎用性が高く、とても有用な為、色々な業界の現場のプロセス改善に使われている。
チケット駆動開発の発端、仕組み、事例、プロセス改善に使われる理由を解説する。

チケット駆動開発、チケット管理ツール、Redmineというものを知らなければ、たぶん理解しにくかったかもしれない。

僕は、そういう内容を前提の上で、現時点で、チケット駆動開発とチケット管理ツールがどういう課題を乗り越えて、ここまで進化してきたのか、そして、今後はどんな未知の分野や課題があるのか、を整理して示したかった。
よって、70ページものボリュームになってしまった。

分かってくれる人に理解してもらえれば本望かなと思って公開してみる。

| | コメント (0)

2021/12/28

チケット駆動開発のプロセスとチケット管理システムの全体像 #Redmine

チケット駆動開発のプロセスとチケット管理システムの全体像はこんなイメージではないだろうか?

【1】チケット駆動開発とは、チケットを起点として、業務の活動をすべてチケットで追跡する仕組みでありプロセスだ。

具体的には、リリース計画を作成して、チケットを一括登録したり、チケットを随時登録する。
登録されたチケットは担当者によって日々更新されたり完了されて、その進捗状況は、ガントチャートやロードマップなどのチケット集計機能によってリアルタイムにモニタリングできる。
管理者はこの情報を使って日々の意思決定やリスク管理に適用する。

リリースバージョンでグルーピングされたチケットが全て完了になったら、そのバージョンはCloseされて、成果物がリリースされる。
ソフトウェア開発ならば、バージョンつまりスプリントやイテレーションがCloseされると同時に、そのバージョンのモジュールがビルドされてデプロイされてリリースされる。

リリースされたモジュールや成果物は開発者が検証したり、ユーザが実際に使ってみて、開発者が見つけた障害修正やユーザの改善要望が管理者へフィードバックされる。
管理者はそのフィードバック情報を元に、次のリリース計画をブラッシュアップして、次のスプリントを開始する。

すなわち、チケット駆動開発とはアジャイル開発を実装したプロセスの一つとみなせる。

【2】一方、チケット駆動開発はチケット管理ツールという具体的なソフトウェア製品よって支えられている。
このソフトウェア製品という特性と実際の運用をまとめたものをチケット管理システムと呼ぶことにしよう。

【2-1】チケット管理システムの具体的な中身は何か?
基本はPMBOKが言うPMIS、つまりプロジェクト管理情報システムだ。
すなわち、チケットというインプット情報をPMISへ食わせた後、PMISがいろんな観点で加工して、PJ管理に必要な各種レポートをアウトプットして吐き出す仕組みだ。

第三者の観点から見れば、チケット管理システムはすごく単純だ。
なぜなら、インプット+プロセス+アウトプットという逐次実行の仕組みに過ぎないからだ。

【3】しかし、チケット管理システムというPMISの機能を解剖すると、単純な機械でありながら強力な機能を持っていることが分かる。
PMISの主な機能は、フロー管理とストック機能の2つだ。

【3-1】まず、フロー管理は、チケットを流通媒体とみなし、タスクをサクサク流すことに力点を置く。
MS Plannerのタスクカード、Agile開発やカンバン駆動開発のストーリーカードやタスクカード、申請承認ワークフローの申請書に相当する。
フロー管理では、作業のリズムを重視する。

【3-2】次に、ストック機能は、チケットを記憶媒体とみなし、日々の作業結果を記録していくことに力点を置く。
障害管理票や課題管理票、WBSなどの記録媒体。
過去の作業履歴、得られた経験や知識はチケットに記録されているので、チケットが蓄積されるほどナレッジ資産になる。
ストック管理では、ナレッジ基盤を目指す。

【3-3】実際は、チケットがフローとストックの2つの意味を二重に持っていることから、PMISはフロー管理とストック管理の機能を自然に持つようになる。
この特徴により、数多くのチケットを集計した結果から有用なメトリクスが得られる。
例えば、ガントチャート、EVM、リソース管理、タスクボードなど。
また、この特徴により、蓄積されたチケットの履歴やチケット間の関係、成果物とチケットの相互関係から、トレーサビリティの機能が生まれる。

【3-4】チケット駆動開発では、ビルドしたモジュールはバージョンというタグがあり、バージョンでグルーピングされたチケットがあり、そのチケットには作業履歴が残っていて、チケットには構成管理ツールの配下に置かれたソースコードや設計書などの変更履歴が紐づくように、運用される。
このトレーサビリティという機能があるからこそ、開発者は自信を持って開発できるし、管理者もリリースしたモジュールの品質を自分でコントロールできるようになる。

【4】チケット管理システムには、その運用を支える数多くのロールがある。
チケット管理をスムーズに運用するために必要なアクターがあることは、Redmineコミュニティで数多く研究されてきた。

【4-1】チケットを起票する現場の人は、PMISを業務のナレッジ基盤とみなす。
自分が入力した作業結果だけでなく、他人の作業結果も参考にして、ナレッジを利用することで自分の作業手順を効率化することに役立つ。

【4-2】管理者は、PMISをメトリクス集計のプロセス黄ばんと看做す。
彼らは、ガントチャート、EVM、リソース管理、タスクボード、信頼度成長曲線など各種の有用なメトリクスを用いて、業務活動の進捗管理、品質管理、要員管理をモニタリングし、日々の意思決定に活かす。

【4-3】お巡りさん(Redmine警察)は、チケット管理の守護神だ。
彼は、現場の人や管理者がチケット管理に困っていたら支援して、チケット管理をスムーズに運用させる。
チケットは生鮮食料品みたいなもので、日々更新されなければ、ただのゴミに過ぎない。
だから、お巡りさんは定期的にチケット管理システムを通じてチケット管理が運用されているか見て、チケット駆動開発を守る人になる。

【4-4】エバンジェリストはチケット管理の伝道師だ。
チケット管理がいかに素晴らしいか、チケット管理を通じて組織をどのように発展させていくべきか、現場の人や管理者を啓蒙する人だ。
エバンジェリストは熱い気持ちを持ち、チケット管理に関わる人の心に息吹や熱気を注入する人だ。

【4-5】PMISは、現場の人達や現場のプロセスに合うようにカスタマイズしたくなるので、マイスターという開発者がPMISをその現場特有のPMISへカスタマイズし、現場のプロセスに局所最適化する。
マイスターはまさにPMISの職人だ。
マイスターから見れば、PMISはPJ管理の開発基盤という側面も持つ。
つまり、チケット管理システムというPMISはプロジェクト管理を実現するソフトウェアフレームワークという開発基盤とみなせる。
すなわち、チケット管理システムはカスタマイズしやすい特徴を持つので、いろんな現場に適用できるように局所最適化しやすい。
だからこそ、改善が大好きな日本人にはチケット管理システムが合うのだろう。

【4-6】活動家は、PMISのログ(Redmineの活動タブ)を見て、現場の人達の活動、さらには組織の活動をモニタリングし、PMISを組織のプロセス改善の基盤として使う。
活動家は、1個のPJや1個の部署だけでなく、複数のPJや部署を横断して、人間の血液診断や健康診断のように、PMISを通じて組織の活動診断を行う人になる。

【5】こういうポンチ絵を描いてみると、チケットで作業も課題も障害も管理する、という単純なアイデアから生まれたチケット駆動開発は、いろんな側面に支えられて、豊富な応用結果を持つことが分かる。
こういうことを考えるのが楽しい。

脱Excel! Redmineでアジャイル開発を楽々管理:エンジニアがお薦めする 現場で使えるツール10選(3)(1/5 ページ) - @IT

ストック型チケットは記憶媒体、フロー型チケットは流通媒体: プログラマの思索

Redmine警察・マイスター・活動家は導入の立役者 | マドびっ! Madosan's View

Redmineの普及促進にはRedmine警察やRedmineマイスターという役割の人達が必要: プログラマの思索

打ち捨てられていたRedmineが復活するまでの軌跡 - Qiita

| | コメント (0)

2021/08/01

OODAループの時代は、大事なのは使命であり、目標は使命達成のための手段に過ぎない

あるブログ記事で、OODAループの時代は、大事なのは使命であり、目標は使命達成のための手段に過ぎない、というメッセージが非常に心に残ったのでメモ。

【参考】
成績未達のものは、きつく叱責すべきか - ウィリアムのいたずらの開発?日記

PDCAサイクルは、1年毎の年間計画でよく使う。
しかし、超短期のサイクルでは使いづらい。
また、コロナ禍のような時代では、当初立てた計画が無意味となってしまった場合、PDCAを最初から作り直さないといけなくなる。

「PDCAサイクル全盛の時代は、目標を数値化してたてて、それを達成したらちょっと伸びた目標を立て続けていく」そんなやり方だった。
しかし、OODAループの時代では、「会社で大事なのは使命であり、目標は使命達成のための手段に過ぎない。」
つまり、「目標が達成しようがしまいが、目標と現実との差を常に感じ、使命達成のために行動する。そのためには目標の変更もあり得る。」

OODAループの考え方は、More Effective Agile ~“ソフトウェアリーダー"になるための28の道標で知っていたけど、腹落ちできていなかったと思う。
飛行操縦士が敵機を撃ち落とすための意思決定構造を形式化しただけ、というイメージで、ソフトウェア開発や経営に活用するイメージがなかった。

OODAループでは、目標よりも、価値や使命が最重要であり、目標や計画は達成するための手段に過ぎない。
目標や計画よりも、価値や使命が最優先であるという行動を誘発させること。

そんなことを考えると、OODAループはスクラムと相性が良いように思える。

| | コメント (0)

INSPIRED 熱狂させる製品を生み出すプロダクトマネジメントの感想~日本に足りないのはプロダクトマネジャーだ

INSPIRED 熱狂させる製品を生み出すプロダクトマネジメントを読んで、日本に足りないのはプロダクトマネジャーだと改めて思った。
ラフなメモ。

【参考
ソフトウェア・ファーストの感想: プログラマの思索
プロダクトマネジメントの感想~プロダクトオーナーはもっとチームの外のユーザに寄り添うべき: プログラマの思索

「クライアント-ベンダーアンチパターン」という根本問題: プログラマの思索

プロダクトマネージャに必要なスキルは何か?~「世界で闘うプロダクトマネジャーになるための本 ~トップIT企業のPMとして就職する方法」の感想: プログラマの思索

(2) 伊藤 大地 / Daichi ITOさんはTwitterを使っています 「NHKのデジタル人材採用の募集要項に並ぶ言葉がもはや「メディア」ではなくて、「テック」企業のそれ。全てはソフトウェアの構築とその応用…というデジタルの性質が募集要項にそのままアウトプットされている。 https://t.co/yIZHbpQG5y https://t.co/Yu4YGX97Wu」 / Twitter

一括請負案件では、どうしてもプロダクトマネージャーという役割は持ちにくい。
プロジェクトマネージャが案件の中心にいて、顧客とプロジェクトマネージャが対峙するというクライアント・ベンダー・アンチパターンにはまりやすい。

では、日本では、どんなソフトウェア開発でプロダクトマネージャーという役割が必要になるのか?
INSPIRED 熱狂させる製品を生み出すプロダクトマネジメントのあとがきでは、日本でプロダクトマネージャーが必要とされる場面は、スマホアプリの開発だという。

なぜなら、スマホアプリの開発では、利用ユーザの観点で、利用ユーザの導線を極力簡素化すべきであり、そのために機能はできるだけ削ぎ落とし、シンプルでワクワクするUIをいかに作り出すか、が大事になるからだ。
実際、一括請負案件でも、スマホアプリの開発が混じってくると、従来のウォーターフォール型開発で要件をガチガチに固めた後に機能やUIを開発したとしても、最後のユーザ受け入れテストで数多くの不満が出て収拾がつかなくなる場合も多い。
スマホアプリを実際に触ってみて、初めて操作感だけでなく、本来のユーザ導線を考えるという手戻りも発生しやすい。
僕もそういう現場を見てきた。

つまり、スマホアプリの開発はとりわけアジャイル開発に適していて、利用ユーザのユーザエクスペリエンスを重視するには、プロダクトマネージャーという役割の人が統括する方がうまくいきやすいと思う。


| | コメント (0)

2021/07/18

プログラマが「何をやっているか分からない」「何が分からないか分からない」状態から脱出する記事がとても良い

プログラマが「何をやっているか分からない」「何が分からないか分からない」状態から脱出する記事がとても良いのでメモ。

【参考】
(1) 出来るプログラマーやエンジニアの方でも「何をやっているか分からない」「何が分からないか分からない」状態に陥りますか?その時は、どの様にして対処・解決しますか?に対するYuki Sonodaさんの回答 - Quora

RubyコミッタのYuki Yugui Sonodaさん (@yugui)もこんな問題意識を持たれていたらしい。

(引用開始)
私は出来るエンジニアじゃないせいか、何かちょっと経験の浅い分野のことをやると「何をやっているか分からない」「何が分からないか分からない」状態に陥ります。
それで、Stack Overflowで調べたコード片をコピペして動かすことがあります。
最近はGradleのビルドスクリプトの書き方が本当に何も分からなくてStack Overflowに世話になりました。
(引用終了)

Yuki Yugui Sonodaさん (@yugui)の回答なので、本当によく考えられている。
こんな手順を踏む。

チュートリアルやGetting Startedのような案内文書があれば、写経して動かしてみる
→先ほど体験したつまずきや未知の用語を手がかりとしながら概念を理解する
→良い実例を読むとともに利用できる資源を網羅する
→実際にやってみて経験を積む

僕も、Pythonのデータ分析、機械学習&深層学習、ソフトウェア統計分析、Ciscoネットワークなどを初めて勉強した時、同じような手順を踏んでいたのを思い出した。

上記の手順をもう少し深堀りして考えてみると、野中郁次郎先生のSECIモデルを連想させる。
あるいは、コルブの経験学習理論を連想させる。
この辺りも考えてみたい。

SECIモデルは知識の再利用モデル、または、実践知を生み出すモデルだ: プログラマの思索

「経験学習」とは?学習プロセスや促進させるためのポイントなどご紹介 | BizHint(ビズヒント)- クラウド活用と生産性向上の専門サイト

【公開】XP祭り関西2014講演資料「KPTによるプロセス改善~あなたはPDCAを回したことがありますか?」 #xpjugkansai: プログラマの思索

| | コメント (0)

2021/05/14

日本人の弱点は忖度しすぎること、理論化できないことではないか

4月末と今夜、平鍋さんがアジャイル開発について語る勉強会を聞いた。
日本人の弱点は忖度しすぎること、理論化できないことではないか、という気づきをラフなメモ書き。

【参考】
今こそ必要な実践知リーダーシップとスクラム - connpass

BPStudy#164?アジャイル開発とスクラムの今を語ろう - connpass

【1】野中先生の肉声を初めて聞いた。
86歳らしいので、平成上皇と同い年らしい。
すごくハキハキした口調で、英語の論文にも慣れているのだろうか、知的バトル、とか、割と英単語が出た。

スクラムを生んだジェフがすごいのは、ベトナム戦争で偵察機の経験があったこと。
その経験をベースに、スクラムを生んだ。
ソフトウェア開発の手法は幾多数多あるが、それを理論化できたのはジェフがフィロソフィーを持っていたから。

野中先生の論文でも、スクラムでも、共感ありきで始まる。
欧米の哲学は、デカルト以来、コギト、我思う故に我あり、から始まるが、そうではなく、共感をベースにした。
だから、上手くいく。

一方、日本人は、元々共感力があるので、スクラムをやるのにもっと共感を重視しようとすると、忖度しすぎてしまう。
忖度するのではなく、もっと知的バトルをすべきだ、と。

僕らの頃は、ジャパン・アズ・ナンバーワンと言われていたが、DXの流れに乗れず、今はその面影もない。
だから、またジャパン・アズ・ナンバーワンを目指してほしい、と。

【2】日本人の弱点は忖度しすぎること、理論化できないことではないか、という考えを思い巡らすと、今まで読んできた本のいろんなフレーズを思い出してくる。

【3】「採用基準」「生産性」はマッキンゼーの元コンサルが、日本人や日本の組織に足りない要素2つを書いている。
それは、日本人には問題解決リーダーシップの能力が足りないこと、問題解決の生産性の意識が低いこと、の2つ。

リーダーシップ経験のない日本人が多すぎるから、評論家ばかりで、実際の問題を泥臭く解決していこうとする能力も意識も低い。
リーダーシップとは、自分の意見を持ち、周囲を巻き込んで、リスクを取って、問題を解決していく。
しかし、リーダーシップを発揮する日本人は、出る杭は叩かれる、ばかりに思われるので、たぶん自然に忖度してしまう。

また、生産性をコストダウンの事ばかり考えすぎる。
日本人が得意なプロセス改善の手法は、コスト低減による付加価値を上げる手法の一つに過ぎない。
生産性=付加価値/コストで考えるならば、コスト低減よりも、付加価値を圧倒的に増やす方がはるかに生産性は上がるはず。
しかし、日本人サラリーマンは斜陽産業でコスト低減ばかり経験しているので、ホワイトカラーが付加価値を上げるために、今までの手法を捨てて、全く新たなアイデアや手法を採用して、リスクを取っていく、という発想も能力もない。

【4】「経済数学の直観的方法 マクロ経済学編」では、世界の経済戦争の重心が、製造業の競争力強化から、世界全体の資金の流れを上手く誘導して流す方向に変わってしまった。
しかし、日本は、製造業があまりにも成功したので、マクロ経済学における動的均衡理論を取り入れる機会を逸してしまった。
そして、世界中の中央銀行がインフレターゲット政策を運用し始めた頃、慌てて、動的均衡理論を学習しようとしたが、従来のケインズ経済学とは異なり、解析力学をベースとした高度な数学理論を使うので、とても学習しづらい。

ちょうど、欧米では、これを学んだ人たちが政治経済の中枢に占めているのに、日本では学習し損なった世代がブランクになり、そのギャップを埋めることが難しい状況らしい。

かつて、日本では、ケインズ理論に従って、政府の公共政策による景気浮揚策は良いことだ、という理解が、割と世間の人たちも認識が共有されていた。
ちょうど、その頃は、日本の製造業が無敵の時代だった。
しかし、コンピュータやITが直近の四半世紀でまたたく間に普及して、ITなしでは生活もビジネスも経済も成り立たなくなった。
経済学の主導権もケインズ理論から動的均衡理論に代わったが、日本は追いつけていない。
さらに、世界中の資金を自国に誘導するように、情報や経済理論を整備して発信していく、というやり方に日本は乗り遅れてしまった。
「ミクロでマクロを制する」という発想は、日本人は弱いらしい。

【追記】
平鍋さんが「先生へお礼のメッセージを送ろう」とtwitter 上で平鍋がよびかけ、集まったコメントが公開された。

野中郁次郎先生へのみなさんからの手紙

自分のコメントも掲載されていて恥ずかしい。
今一度読み直すと、日本人には共感力よりも、知的バトル、知的コンバットが必要なのだろう。
つまり、対立することを恐れず、もっと知的論争をすべきであり、お互いにもっと衝突して、その後で握手する事が大事なのだろう。
知的論争に忖度は無駄。


| | コメント (0)

2021/05/08

『オブジェクト指向でなぜつくるのか』第3版が出版された

『オブジェクト指向でなぜつくるのか』第3版が出版されたのでメモ。

【参考】
『オブジェクト指向でなぜつくるのか』第3版

オブジェクト指向でなぜつくるのか 第3版|日経の本 日経BP

「オブジェクト指向でなぜつくるのか」は良い本だ: プログラマの思索

「オブジェクト指向でなぜつくるのか」は良い本だ: プログラマの思索では、第2版を改めて読み直してみた。
オブジェクト指向プログラミングがヒープ領域を使っていることから、UMLによる汎用の整理術、XPに至るまでのアジャイル開発、そしてパターン言語まで幅広い。
こういう一大ストーリーでまとめているのはすごいと思う。

僕が思うに、オブジェクト指向の考え方をアジャイル開発、特にスクラムに適用している所が一番興味はある。
たとえば、「More Effective Agile “ソフトウェアリーダー”になるための28の道標」では、「スクラムチームはブラックボックスとして扱うべきだ」という主張が何度も使われている。
つまり、スクラムチームはInputとOutputだけ管理すればよく、プロジェクトマネージャはマイクロマネジメントする必要はないし、マイクロマネジメントすべきでない、という主張が一貫して流れている。
これもオブジェクト指向のカプセル化がわかっていれば、とても腑に落ちる。

More Effective Agileは良い本だ: プログラマの思索

「オブジェクト指向でなぜつくるのか」本はずっと読まれ続けてほしいと思う。

| | コメント (0)

より以前の記事一覧