アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか？～Software Processes are Software, Too（ソフトウェアプロセスもまたソフトウェアである）

「ソフトウェアシステムアーキテクチャ構築の原理 第2版」をアジャイルアーキテクトさんや他の方と輪読していたときの感想をメモ。

【1】「ソフトウェアシステムアーキテクチャ構築の原理 第2版」は既に絶版なのだが、内容は良い本だ。
アーキテクチャ設計のプロセスを現代風にうまく表現してくれている。
今のマイクロサービス設計にも当てはめることもできるだろう。

「ソフトウェアシステムアーキテクチャ構築の原理 第2版」に出てくる用語は、図4-3.コンテクストにおけるパースペクティブを見ればいい。

その時のビューは、図15-1.ビュー間の関係　の観点で整理される。

【2】「ソフトウェアシステムアーキテクチャ構築の原理 第2版」をアジャイルアーキテクトさんや他の方と輪読していたときに一つの疑問があった。

「ソフトウェアシステムアーキテクチャ構築の原理 第2版」では、アーキテクチャを定義し、設計し、実装し、評価する一連のプロセスが、図7-3.アーキテクチャ定義の詳細で定義されている。
そのプロセスの中に、「適切なアーキテクチャスタイルを識別する」プロセスでは、過去のアーキテクチャパターンを参照するという記述があり、腑に落ちていなかった。
アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか。
アーキテクチャ設計はもっと高尚なプロセスではないのか、という認識が強すぎた。

実際のシステム開発では、ユーザの要求を元に、業務やシステムの要件を定義し、スケジュールやコスト、品質の観点からアーキテクチャの候補を複数から選定して基盤を決定する。
そこから具体的な設計、実装に入っていく。
今なら、業務要件や機能要件を定義する中で、非機能要件を満たせるようなインフラ基盤やネットワーク基盤、開発フレームワークを選定するだろう。
サーバはクラウド、クライアントはPCやスマホなどを基盤に選定するだろう。

そういう設計を具体的に行うときに、過去のアーキテクチャパターンを参照するときもあるが、新しい技術を導入する時は過去の事例がないので、苦労するし、失敗しやすい。
その疑問を解決できていない気がしていた。

【3】この疑問について、先輩と議論して気づいたことがある。

アーキテクチャ設計について、アーキテクトの経験や会社の過去事例に既に実績があるならば、いきなりアーキテクチャ設計を実装するのではなく、要件を基に、過去に成功して実現性の高いアーキテクチャパターンを採用することで実装する方針を決めるのは自然な流れと理解した。
その時に、プロセスの実行（プロセスクラスをインスタンス化して実行）においても、同様に過去のプロジェクトで成功して実績のあるプロセス事例を参照して、プロセスを設計するのは自然な考え方ではないか、と気づいた。

一方、新しい技術を取り入れてアーキテクチャ設計する時、社外の専門家である外部ベンダーに参画してもらい、その知見を活かしてもらうわけだが、そのやり方も実現性の高いアーキテクチャパターンを知っている専門家を利用しているわけだ。

この辺りをモデル化してみた。

「当初の案」では、プロセスパターンクラスをアーキテクチャごとのタイプみたいなパターンクラスとみなし、プロセスクラスとしてプロセスのテンプレートを生成し、各プロジェクトではプロセスクラスのテンプレートををカスタマイズして実行するイメージだった。

しかし、要求とパターンの整合性を取る必要がある時に、要求そのものにパターンを抽出する基準が暗黙的に既に埋め込まれている。
実際、要求に沿ってシステムとして実現できるアーキテクチャはこれだ、と選定するときに、要求を制約事項とみなすアーキテクチャを過去のベストプラクティスを元に選定しているからだ。
つまり、アーキテクチャ設計としてアーキテクチャを選定するときに何らかの選定基準は暗黙的に埋め込まれている。

その暗黙的な基準こそが、パターンでありイディオムであるわけだ。
アーキテクトは、自身の脳みその中に、多数のパターンカタログ、イディオムカタログを暗黙的に保持していて、それを基準に当てはめている。

そこで、「田中さん案を元に再構成した案」で書き直してみると、プロセスパターンクラスをインスタンス化したものがプロセス記述書になる。
これはアナリシスパターンの抽象・具象パターンに相当するだろう。
そのプロセス記述書は、アーキテクチャ設計プロセスのテンプレートであり、どのプロジェクトでも使えるテンプレートになっている。
このプロセス、手順に従えば、アーキテクチャ設計ができますよ、という手順書になっている。
そのプロセス記述書は単なる手順書ではなく、過去のベストプラクティスが盛り込まれて、ソフトウェア開発が成功するような知見が盛り込まれているわけだ。

このプロセス記述書を各プロジェクトに当てはめて、必要であればカスタマイズして実装して、プロジェクトを実行していくことになる。

【4】そんなことを考えると、まだうまく表現できていないかもしれないが、ソフトウェア設計、ソフトウェア開発そのものも一つのソフトウェアのような気がしてくる。

そんな論文「Software Processes are Software, Too」は1980年代に既に提唱されているよ、と先輩から教えてもらった。

Software Processes are Software, Too

主張は「ソフトウェア開発プロセスは、プロセス記述書というクラスをインスタンス化したものである」と理解したがもう一つ重要な観点があると思う。
それは「ソフトウェアを再利用して効率化するやり方と同様に、ソフトウェア開発プロセスも再利用できるはずだし、それがパターンやイディオムになるはず」だという考え方だと思う。
つまり、「ソフトウェアシステムアーキテクチャ構築の原理 第2版」本で「適切なアーキテクチャスタイルを識別する」ときにパターンを参照することと同義だと理解している。

この辺りはもう少し整理してみたい。

パターンカタログよりもモンスターカタログの方が面白いね #jasstkansai

Jasst関西がオフライン開催だったので10年ぶりに参加してきた。
感想をラフなメモ。

【参考】
JaSSTソフトウェアテストシンポジウム-JaSST'23 Kansai

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

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

現場の経験知をパターン言語にするコツが分かった　#agileto2014: プログラマの思索

パターン言語の構造と事例集: プログラマの思索

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

【1】今回のテーマは「思考停止」。
正直難しいテーマだったかなと個人的印象を持った。
基調講演の山口鉄平さんの話を聞くと、説明に苦労されている印象があって、本来は「ソフトウェアテストをカイゼンする50のアイデア」本から色んな改善事例を出してもらえるともっと聞きたかったのにと思った。

今の日本の社会情勢であれば、「思考停止」というテーマはたくさんの事象が出てくるだろう。
たとえば、円安やインフレ、少子高齢化による社会保障制度の不安、コロナ補助金不正、マイナンバーカードの名寄せ問題、EV車やAIに対応できていない製造業やIT企業、を見れば「思考停止」の事例はいくらでもあるだろう。
つまり、そういう問題に対し、本来の課題（イシュー）は何なのか、その課題を解決する時に一番効果のある対策は何か、予防策は何か、まで突き止めて考えなければならないのに、前提条件や制約条件を無視した議論がすごく多い。

一般に、日本の組織論で有名な「失敗の本質」本を読めば、日本人の「思考停止」の例はすぐに2つは思いつく。
1つは、個人では意見を持っていても、同調圧力に流されて集団浅慮やリスキーシフトに陥ること。
もう一つは、一般兵士のような下級レベルの労働者や兵士は真面目で優秀だが、戦略の目的に合致しない行動を取っているために、いくら真面目に働いても生産性や投資効果が低いこと。
野中先生が指摘した日本人の弱点は、1945年当時から80年たった今でも変わらない。

akipiiさんはTwitterを使っています: 「日本人が思考停止に陥りやすい例が自分のイメージと違っている気がした。日本人は集団浅慮に流されて自分の意見を言わないとか、一生懸命働くけど生産性を意識せず働く場合が多いんじゃないかな？ #jasstkansai」 / Twitter

こういう思考停止の事例を分析するには、なぜなぜ分析が結局使われると思う。
なぜなぜ分析で自分の言動を問い詰めて、最終的にはその人の油断、プレッシャー、焦りなどの心理背景まで突き止められるのではないか、と思う。

OL参加者の意見として、フレームワーク思考を習慣的な思考と考えて、思考停止になっているのではというツイートもあって面白かった。

akipiiさんはTwitterを使っています: 「#jasstkansai なるほど、フレームワーク思考は習慣的な思考と捉えるのか。SECIモデルならどれに相当するのか？形式知を組み合わせる連結化？形式知を暗黙知にする内面化？」 / Twitter

【2】今日のJasst関西で最も印象に残ったのが、「思考停止からの脱出 ～ あなたの"問い”が自律へと導く ～」ワークセッション。
テーマは「思考停止を題材にして、問題事象をモンスターで書いてみよう」。

「思考停止」というテーマを各人の体験から問題事象を洗い出し、それらの問題事象にモンスターとして名前付けする。
そのモンスターには、名前とモンスターの絵があり、モンスターのプロフィールとして得意技・どんな時・他の特徴という説明文が付与される。
そのモンスターに対し、必殺技でやっつける、という流れ。

僕は「打合せ大好きマン」というモンスターを書いてみた。
伝わるかな？

これはアンチパターンと言えるだろう。
つまり、モンスターの名前はアンチパターン名。
得意技は問題事象。
どんな時は、問題事象が発生するタイミング。
他の特徴は、問題事象の影響事例。
必殺技は、解決策に相当するだろう。
フォースに相当する項目があればなおいいね。

僕もパターンは好きだし、パターンを自分で作れないか、パターンカタログのようなものを作れないか色々考えていた時期があった。
しかし、深く考えるほど難しいなと思う。
モンスターにアンチパターンを当てはめると、ロールプレイングゲームのように気楽な気持ちでパターンカタログを作り出すことができる。

この発想は他のワークショップでも使ってみたいなと思う。
プレインステーションなどのゲーム経験が深い人ほど馴染みやすいかもしれないから。
もっと気楽にパターンを考えてもいい。

【3】久しぶりにオフラインでコミュニティに参加して気づいたことはいくつかある。

1つ目は、参加者に若い人もいるけれど、年齢層が割りと高そうなこと。
アンケートでは、SE経験が10年以上の人が参加者の半分を占めていた。
本来は20～30代の人たちが半分以上を占めていて、経験が少なくてもノリが良くて活気があるのが普通だが、ちょっと落ち着いていた感じ。
久しぶりに会った方と話していたら、最近は若い人が少ないですよ、とのこと。
昨今の日本社会の情勢である少子高齢化が出ているのだろうか？

2つ目は、オンライン開催のチャネルが勉強会コミュニティで必要になってきたこと。
コロナ禍を経て、開催側もオンライン開催の手段がすごく簡単と分かったし、参加者も簡単に集めやすいと分かった。
参加者もオンライン開催であれば、スマホさえあれば作業しながらでも聞ける。
わざわざ交通費を払って時間を拘束させる必要もない。

今後の勉強会の運営は、Jasst関西のようにハイブリッド開催が当たり前になってくるだろうと思った。

XPエクストリームプログラミングは偉大だ～時代がその設計思想に追いついた

XPエクストリームプログラミング入門をオンラインで聞いた。
改めて、XPエクストリームプログラミングは偉大だ、時代がその設計思想に追いついた、と思った。
ディスカッションの内容から感じたことをラフなメモ。

【参考】
XPエクストリームプログラミング入門 - connpass

ITの地殻変動はどこで起きているのか？～チケット駆動開発はなぜ生まれたのか: プログラマの思索

僕は、「XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法 」の第1版の方が好きだ。
理由は、荒削りだが内容はとてもシンプルで、当初考えていた直感的な思いが直接的に表現されているからだ。

- eXtreme Programmingの魅力を探るにある「Embrace Change - 変化ヲ抱擁セヨ」のグラフが一番好きだ。

勉強会の内容は放談会みたいで面白かった。

XPはプラクティスありきではない。
プラクティスは具体的な実践方法。
プラクティスは価値を実現したものの一つ。
しかし、価値は抽象的すぎるので、プラクティスと価値の間に原則を置いて、プラクティスと価値を橋でつなぐ。
そういう絵がXPではよく出るが、その意味がようやく分かった。

XPのプラクティスは、そのテーマ単体だけで一冊の本になる。
たとえば、リファクタリングなら、リファクタリング(第2版)。
テスト駆動開発なら、テスト駆動開発、実践テスト駆動開発。
継続的インテグレーションなら、継続的インテグレーション入門、継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化。
見積もり手法や計画ゲームなら、アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~。
ふりかえりなら、アジャイルレトロスペクティブズ　強いチームを育てる「ふりかえり」の手引き。
シンプルな設計なら、エリック・エヴァンスのドメイン駆動設計。
つまり、それぞれのテーマはとても奥深いのだ。

たぶん、それらのテーマは重要である、とケント・ベックは直感的に感じていたのだろう。
それを言語化して形式知としてプラクティスで取り上げたのはすごいと改めて思う。

福井さんいわく。
最初はスクラムは好きではなかった。
XPは具体的なのに、スクラムではプロセスはしっかりしているが、実際に実践しようとすると中身が分からない。
でも、今はスクラムは好きですよ、と。
スクラムはスクラムマスターの存在が凄く大きい、と。

アジャイル開発は自動車の運転のようなもの。
到着先は分かっていて、その道順が分かっていても、不確定要素があり、ハンドル操作で変化を受け入れながら進める。
つまり、運転は変化が全くない動作ではないし、変化を受け入れる動作範囲に落ち着くようにする。

時代がアジャイルにやっと追いついた。
アジャイラーは当初は周囲と戦っていた。
いかに導入するか、いかに普及させるか、に注力していた。
しかし、今はお客様からも、アジャイル開発を導入したいと言われる。

WF型開発の権化だったPMBOKがアジャイル開発の考え方を取り入れて、PMBOKの最新版でごっそり変わったのも大きいね、と。
実際、PMBOKは従来の分厚い数多くのマネジメント技法の知識体系だったのに、アジャイル開発の考え方を具現化して、価値や原則が主体のマネジメント体系に変わろうとしている。

アジャイル開発を支える技術が揃ってきたのも重要だろう。
特にクラウドが普及したおかげで、すぐにサーバーを立ち上げて、実際に動かしてみて、動かしながら作っていくのができるようになった。
それもコストをあまり掛けずに、個人ですら開発できるようになった。
つまり、継続的インテグレーション、継続的デプロイ、リファクタリング、テスト駆動、短期リリースなどを支える技術が揃ってきたおかげで、アジャイル開発を実践しやすくなった、と。

一方で、SIがアジャイル開発に追いついていないように思える、と。
発注者は自社で内製開発がしたいので、アジャイル開発を自然に受け入れやすい。
しかし、SIは受託なので、既に自分たちの標準プロセスを持っているし、人月単価のビジネスモデルもあるから、いきなりアジャイル開発に変換するのは難しい。

僕がXPやアジャイル開発に惹かれる最大の理由は、IT業界のきつい仕事から脱出できるための救いとして捉えていた面があったからだと思う。
多重請負の人月単価のビジネスモデルの中で、大量のプログラマや技術者をまるで仕掛在庫みたいに扱って、変動するバッファみたいに扱う手法がどうしても慣れなかった。
アジャイル開発は人重視であり、技術者の専門性を活かしながらチームでアウトプットを出していく、という思想に引かれていたのだと思う。
IT技術者として専門性を高めていくと自然にアジャイル開発に収れんされていくはずだ、と思っていた。
今もその思いは変わらない。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SECIモデルの状態遷移図 from akipii Oga

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

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

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

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

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

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

MBA | 猫好きのブログ

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

パターン言語の構造と事例 from akipii Oga

SECIモデルの具体例(Scrum・チケット駆動開発など) from akipii Oga

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

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

SECIモデルの状態遷移図 from akipii Oga

SECIモデルの具体例(Scrum・チケット駆動開発など) from akipii Oga

パターン言語の構造と事例 from akipii Oga

【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モデルの状態遷移図で整理できるんだな、と改めて感じた。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

チケット駆動開発の解説～タスク管理からプロセス改善へ from akipii Oga

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

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

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

【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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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