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

2022年1月

2022/01/23

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


| | コメント (0)

2022/01/22

プロジェクトマネージャの意思決定プロセスや判断プロセス

プロジェクトマネージャの意思決定プロセスや判断プロセスはどんな仕組みなのか?

問題解決トレーニング アタマがよくなるビジネス50題」「1分間でマスター 問題解決トレーニング」の内容をまとめてみた。

たぶん、すごく新しい考え方ではない。
限られた時間で、どのプロセスを選択するか、その時の条件に従って、処理プロセスを条件分岐させるだけ。
事実や情報が集まって意思決定できるか、情報が少なすぎて意思決定がすぐにできないか。

こんなストーリーかな。

原因が分かって問題解決の手法も明確なら、改善プロセスを選択する。
正攻法なので時間はかかるが、確実に効果を上げる。
30%ぐらいまでの投資対効果を目指す。

時間があれば、仮説を立ててゆっくり考えることはできる。
改革プロセスはそんな感じ。
100%ぐらいの効果を目指すから、今までとは異なるアイデアを持ち出す必要がある。
じっくり計画を立てて、壮大なイメージを十分に練って、トライアルを実行して仮説を試す。

一方、時間がなければ、対処療法的な意思決定を下す時が多い。
まずはパッチ当て。
その後で原因を分析し、根本治療を目指す。

そういう意味ではGTDに似ている。
メール処理みたいに、情報を分類して、条件分岐に従って意思決定を素早く下す。

GTDは箱の使い分けが鍵を握る: プログラマの思索

このやり方でやれば、日々の業務的意思決定は効率的かもしれない。
一方、企画書や提案書をじっくり書き上げたり、機能の実装でどれが一番最善7日考えながらプログラミングする方法には向かないのではないか、と思った。

いろいろ試してみる。

| | コメント (0)

2022/01/16

「世界を動かすプロジェクトマネジメントの教科書」の概念図

「世界を動かすプロジェクトマネジメントの教科書」の本を読んだ。
自分の理解を深めるために概念図を書いたのでメモしておく。
ラフなメモ。

世界を動かすプロジェクトマネジメントの教科書 ~グローバルなチャレンジを成功させるOSの作り方:書籍案内|技術評論社

【1】「世界を動かすプロジェクトマネジメントの教科書」で気づきがあった点は、プロジェクトの立ち上げ・計画フェーズが最重要であることだと思う。
日本企業では誰が最終責任者なのか分からない場面が多々あるが、「世界を動かすプロジェクトマネジメントの教科書」のシナリオでは、プロジェクトマネージャすら不在の場面がある点も驚きだった。


【2】「世界を動かすプロジェクトマネジメントの教科書」の一節に、ソフトウェア企業のSEが、「SIerでは、プログラマ→SE→シニアSE→プロジェクトマネージャのようなキャリアが多いです」と話す部分がある。
僕の経験上、シニアSE→プロジェクトマネージャの断絶は大きいし、仕事内容も大きく変わる。

100人月以上の案件のプロジェクトマネージャの仕事では、もはやPJの細部の作業まで見ていない。
プログラミングや設計書の作成などの実務にタッチしないし、実作業の進捗管理すら、各サブチームのサブリーダーに任せている。
では、プロジェクトマネージャは何をやっているのか?

彼らの仕事の中身を見ると、ひたすらプロジェクトの計画書、見積書、報告書の作成とそれら書類を利害関係者に説明する会議に出ているだけだ。
顧客への説明はもちろん、インフラ基盤や開発、製品端末などを委託したベンダへの説明がほとんどだ。
その会議のための報告書を作成するために、社内の法務部、購買部、部門長、他部門の関係部署、場合によっては役員と交渉している。

第三者が見ると、プロジェクトマネージャは報告書作成マシーンに見える。
その作業だけで手一杯なのだ。
プログラミングや設計が楽しい人から見れば、そういう作業が楽しいのかなと思う時もある。
ひたすらドキュメントを作っているだけだからだ。

【3】一方で、プロジェクトマネージャのレベルになると会社の中では中間管理職に相当するので、それなりの役職を持ち権限と責任を持つ。
すると、会社内ではそれなりのパワーを発揮できる醍醐味もある。
案件に必要なリソースを自由に使えるからだ。

プロジェクトマネージャはコミュニケーションが重要、とよく言われるが、僕はその言葉はあまり本質的ではないと思う。
直接的に言えば、組織から与えられた権力を正当に行使できるし、むしろ、その権力を案件の達成のためにどんどん使って、部下はもちろん、社内の他の部署、社内の経営層、お客様まで巻き込むことだと思う。
だから、政治家みたいに、権力行使が好きな人の方が向いているという気はする。

しかし、たとえば、IT企業であれば、単に役職さえ与えられればプロジェクトマネージャとしてやれるわけではない。
技術力は当然必要だし、PMBOKに代表されるようなプロジェクト管理技法は一通り知っておく必要がある。
その他に、PJの原価や利益などに関する財務会計の知識、請負・準委任契約や知的財産などの法務の知識、部下をコントロールしたりやる気を起こさせるような人事手法やリーダーシップなども当然要求される。
単純に知識さえあればOKというわけではない。

「世界を動かすプロジェクトマネジメントの教科書」を読むと、改めて、IT業界以外のプロジェクトマネージャも別の観点で苦労しているんだな、とか、IT業界では当たり前でも他の業界では当たり前でないんだな、とか、気付きも多かった。

この辺りはまたまとめてみたい。

| | コメント (0)

2022/01/15

Redmineにメンション機能が入るらしい

Redmine5.0にメンション機能のパッチが提供されたのでメモ。

akipiiさんはTwitterを使っています 「すごく嬉しい。RT @g_maeda: Redmine 5.0 でメンション機能が入りそう。 https://t.co/NY2SqPQ05P」 / Twitter

Feature #13919: Mention user on comment/description using @user with autocomplete - Redmine

@ユーザIDでメンションできる機能のパッチができた。
Redmineコミッタ Marius BALTEANUさんが提供しているので、おそらくtrunkに入るだろう。

Twitter、Slack、Teamsでも、メンション機能は当たり前。
この機能がないとすごく不便。
なぜなら、コメントした時に、相手に依頼したり問いかけても、応答しなかったり、そもそも気づかない場合もあるから。

こういう機能改善を見ると、Redmineは古株のPJ管理ツールなので、昨今流行している機能を取り込んで追随していく方向性になるかもしれない。
たとえば、似たような機能で今はない機能として、いいねボタンの機能もある。

とは言え、長年親しんで使い慣れたRedmineだからこそ、こういう細かい機能追加はとてもありがたい。
今後もチェックしていく。

| | コメント (0)

2022/01/14

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

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

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

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

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

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

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

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

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

| | コメント (0)

2022/01/10

チケット管理の運用を支える体制とは何か #redmine

チケット管理の運用を支える体制についてツイートがあったのでメモ。

【発端】
ところてんさんはTwitterを使っています 「「なんでプログラマーはチケットシステムが上手く回って、それ以外の部門ではうまく回らないの?」 「プログラマーの世界はプログラマーの中で比較的閉じてるからじゃない?部門をまたいで同じシステムを使わせるというのが色々と大変なのかも」」 / Twitter

akipiiさんはTwitterを使っています 「チケットシステムがなぜプログラマ以外では回らないのか?と言う問題提起」 / Twitter

Dr.とまてぃ@セミコンエンジにゃあさんはTwitterを使っています 「@akipii 一応工場で導入に成功はしましたが最低限チケット管理システムの扱いをわかっている人(≒プログラマ)と、管理が腐らないよう見張ってくれる人が複数いないと機能しないですね」 / Twitter

akipiiさんはTwitterを使っています 「@tomati2020 Redmineコミュニティでは、チケット管理のルールが守られて運用されているか定期的に巡回する人を「お巡りさん(Redmine警察)」、現場の独自プロセスにFitさせる為、チケット管理ツールをカスタマイズする人をマイスター(Redmine職人)と呼んでます。まさに2つの役割に相当していますね!」 / Twitter

Dr.とまてぃ@セミコンエンジにゃあさんはTwitterを使っています 「@akipii ですです。 なのでなんとか自部署での運用は成功しているんですが、適用範囲を拡大しようとすると自助努力ではどうしようもないので会社ぐるみでの研修プログラムなどが必要になってくるかと思われます。」 / Twitter

【1】チケット駆動のタスク管理は、一度運用が回ればスムーズに回る。
チケット管理ツールを基盤としたチケット駆動開発は、アジャイル開発のタスク管理と相性が良いので、変更の多いタスク管理に適用しやすい。
また、アジャイル開発のプラクティスを自然に適用できるので、朝会やKPTによるふりかえり、ペア作業、メンバーの自発的行動を促す雰囲気作りを適用することで、メンバの貢献意欲を引き出しやすい。
結果的に、チームの一体感も高まり、チームの雰囲気もすごく良くなる。

【2】しかし、いつもチケット管理が上手くいくとは限らない事実は以前からRedmineコミュニティでも議論されていた。

その原因の一つは、チケット管理を刺させる体制が不十分なので、チケット管理の運用ルールが守られず、形骸化してしまうことだろう。

【3】経験上、チケット管理をスムーズに運用する為には、4種類の役割が必要になると考える。

①お巡りさん(Redmine警察)
チケット管理のルールが守られて運用されているか、定期的に巡回する。
また、メンバーが困ったときには手助けをする。
Scrumで言えば、スクラムマスターみたいな感じだろうか。
チケット管理の守護神のようなイメージかな。

②マイスター(Redmine職人)
現場の独自プロセスにFitさせる為、チケット管理ツールをカスタマイズする。
それぞれの現場では独自のプロセスがあり、そのプロセスに基づく組織文化や業務手順がある。
それらをチケット管理ツールに反映することで、利用者の操作感を良くして、取っ付きにくさを軽減する。

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

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

③エバンジェリスト
チケット管理の伝道師としてメンバーを啓蒙する。
こういう熱い心を持った人が、チケット駆動開発を導入する時に旗印となって、メンバーを啓蒙して、心の熱量を注入していく。
もちろん、メンバーやプロジェクトマネージャへの教育も兼務するだろう。
最初は、エバンジェリストのような熱量のある人が、組織に息吹を吹き込む必要があるだろう。

④活動家
活動ログから現場の業務活動をモニタリングし、組織のあるべき姿(全体最適化)を目指す。
たとえば、標準化推進のPMOや、プロセス改善や品質管理を担当するSEPGが相当するだろう。
彼らは、Redmineの活動ログを元に、各PJの活動を見て、PJの進捗・品質・コストで異常がないかモニタリングし、何かあれば、プロジェクトマネージャにアドバイスする。

活動家はお巡りさんよりもさらにメタな観点で、チケット駆動開発をモニタリングする立場だろう。

【4】では、チケット管理を支える体制では、この4種類の人達だけで十分なのか?
その他のロールはないのか?
あるいは、2種類や3種類の役割に減らしても、チケット管理は上手く回るのだろうか?

こういう疑問を数多く集めて、この主張をさらに強化したいと思う。

| | コメント (0)

2022/01/09

「RubyやRailsは終わった」という記事のリンク

「RubyやRailsは終わった」という記事があったが本当なのか?
見つけた記事だけをリンクしておく。
自分が後で読むためのメモ書き。

【参考】
“Rubyは死んだ”のか? まつもとゆきひろ氏が語る「プログラミング言語サバイバル」とRubyの未来 - Part1 - ログミーTech

Ruby2系はチームの幸福度を最大化できなかった - Qiita

「Railsは終わった」と言われる理由 - Qiita

Rubyは死んだというが。流行り廃りに拘らず、便利なものは活用すればいいのに - Qiita

Rubyは果たして死んだのか | 日経クロステック(xTECH)

Rubyは終わった?将来性と今後の展望をまとめてみた│エンジニアハック

将来性のないプログラミング言語5選として「Ruby」が挙がり話題に | スラド IT

個人的にはRubyは好きだ。
メタプログラミングRuby 第2版」を読んで、色々動かして、やっとダックタイピングの意味が分かった。
やはりRubyはJavaとは違う。
Rubyは究極のオブジェクト指向言語なのかもしれない。

また、Rubyというコミュニティも素晴らしいと思う。

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

一方、RubyはPerlのシンタックスを受け継ぐ部分があるせいか、初心者には読みにくい記法がある。
慣れないと使いこなせない部分もある。

「Rubyのしくみ」を読んだ後のRubyの感想: プログラマの思索

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

Ruby初心者が間違いそうなこと: プログラマの思索

メタプログラミングRubyの感想: プログラマの思索

Rubyのブロック、Proc、lambdaのメモ: プログラマの思索

RedmineやRubyについては今後も追いかけていく。


| | コメント (0)

実践した後に勉強するのがエンジニアの本来の道

実践した後に勉強するのがエンジニアの本来の道というツイートに共感したのでメモ。

はじめ??ソシャゲフリーランスエンジニアさんはTwitterを使っています 「中島聡さんが プログラミングの勉強は、アプリの開発を通してするもの と仰っていたけど完全同意です 恐らく100冊の技術書を読むより1アプリを作るほうが勉強になる そして1アプリを作った時の答え合わせのために技術書を読む 勉強→実践が普通の思考ですが 実践→勉強がエンジニアの本来の道です」 / Twitter

エンジニアは、仕事でシステムを開発して経験した後、技術書を読んで自分の経験を振り返る方が良い。

なぜなら、IT、プログラミングの技術書は抽象的で具体性がない。
具体性をいくら書いても、所詮プログラムなので、実際に動かさなければ、どこに落とし穴があるか分からない。
本の中身を丸暗記しても、実際にプログラミングがスムーズにできるとは限らないし、思ったようにプログラミングできない場合が多い。

一通りプログラムを書いて、アプリを動かして体験した後で、その体験内容を技術書で採点する感じ。
技術書に書いている内容に、ふむふむその通りと納得する時もあれば、こんな使い方があったのか、もっと速く知っておけばよかった、と思う時もある。
一方、こういう部分が泥臭くて難しくてハマる部分なのに、技術書に書いていなくて、消化不良だな、と思う時もある。

| | コメント (0)

プログラミングしてる時はでっかいピタゴラ装置を作ってるみたいな感じ

「プログラミングしてる時はでっかいピタゴラ装置を作ってるみたいな感じ」というツイートを見つけたすごく共感した。

【参考】
Rui UeyamaさんはTwitterを使っています 「少数派の意見かもしれないけど、プログラミングしてるときはでっかいピタゴラ装置を作ってるみたいな感じで、数学が関係ある感じがあんまりしない。」 / Twitter

結城浩さんはTwitterを使っています 「@rui314 デバッグしてるときと証明読んでるときはなんか似てる。素直に読みつつ穴探ししてるみたいな感覚。」 / Twitter

英語勉強中さんはTwitterを使っています 「@rui314 めちゃくちゃわかります。僕は書いてるとき数学のことなんか考えてないです」 / Twitter

akipiiさんはTwitterを使っています 「プログラミングはこの感覚に近いな」 / Twitter

プログラミングは「ブロックを組み合わせる」感覚に似ている: プログラマの思索

「プログラミングのできる羊とできない山羊を区別する方法」の記事のリンク: プログラマの思索

「60%の人間はプログラミングの素質がない」記事のリンク: プログラマの思索

プログラマに必要なスキル: プログラマの思索

プログラムを書いている時、数学の知識を使っているかと言われるとそうではない気がする。
むしろ、APIやFWのライブラリをまずは頭に叩き込んでおき、自分が実装したい目標に対して、それらAPIをどうやって組み合わせて意図通りに動かすか、に注力している。
ちょうど、ブロックで巨大な積み木を組み立てている感じに似ている。

だから、「プログラミングしてるときはでっかいピタゴラ装置を作ってるみたいな感じ」にはとても共感するし賛同する。

たとえば、RDBでSQLをデータ抽出したり、機械学習や深層学習のライブラリを使って母集団を推定したり、マーケットを予測したり、Web上の通信を暗号化したりする時、数学の理論はAPIやライブラリの中に隠れてしまっている。
それらライブラリを呼び出すだけで、高尚な理論を使えるのは素敵だが、だからと言って、プログラミングが楽になっているわけではないと思う。

一方、やりたいことを実現するには、PythonやRDB、Webサーバー、Dockerなどの開発環境を揃えて、Githubで構成管理し、CIツールでビルド&デプロイできるようにして、Jupytorを動かせるようにしたり、IntelliJなどの開発環境を構築したり、とプログラミングの前準備がすごく多い。
普通の初心者はこの部分で挫折するのだろうと思う。

僕自身、新しい環境を揃えてプログラミングスタイルを覚える時は割と苦痛に感じる時もあった。
Ruby on Railsもそうだし、AWSでの環境構築、GNS3でのCiscoルータ&スイッチの環境構築の時もそうだ。
Python+Anacondaはまだマシだった。
プログラミングは奥が深い。

| | コメント (0)

2022/01/01

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

ITの地殻変動はどこで起きているのかを2022年現在で考えてみる。
ラフなメモ書き。
特に後半は、ロジックが飛んでいるが、自分のアイデアを書き残すことに重点を置く。

【過去の記事】
ITの地殻変動はどこで起きているのか?~2006年: プログラマの思索

ITの地殻変動はどこで起きているのか?~SeasarとRuby、そしてPF: プログラマの思索

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

ITの地殻変動はどこで起きているか?~Agile2.0をサポートするチケット駆動開発: プログラマの思索

ITの地殻変動はどこで起きているのか?~チケット駆動開発が進むべき道: プログラマの思索

ITの地殻変動はどこで起きているのか?~アジャイルへの流れと設計技法の違和感: プログラマの思索

ITの地殻変動はどこで起きているのか~アーキテクチャ設計技術にクラウドが必須になった時代: プログラマの思索

ITの地殻変動はどこに起きているのか~ソフトウェアの複雑さをどのようにして手なづけるか?: プログラマの思索

ITの地殻変動はどこで起きているのか~技術革新の流れはWebから機械学習やデータマイニングへ: プログラマの思索

【1】コロナ時代でのソフトウェア事業の問題点

ソフトウェア開発やソフトウェア事業を中核としたIT事業は、2000年頃から大幅に広がり、コロナ時代に入るまでに、GAFAに代表されるように全てのビジネスの中核となった。
ソフトウェアこそが今は、すべての事業の中核システムにある。
コロナ時代になって、対面での営業、対面での人間関係が厳しく制限されて、全ての人間関係がオンライン上で実行せざるを得ない環境に追い込まれて、ソフトウェアはビジネスだけでなく、人々の生活インフラの中核にまで覆い尽くした。

従来の製造業、小売業などの従来型のビジネスモデルは、ソフトウェアを基盤とした事業モデルに大きく変革を強いられた。
それは、業務を単にIT化するだけではない。
単なる業務のペーパーレス化、情報の一元管理が目的なら、コスト削減が目的であり、それはERPというパッケージ製品の導入と同じだ。

では、どんな変革を強いられたのか?
それは、ソフトウェアで作られたシステムを基盤として、企業が提供する価値とそれを購入して消費する顧客をつなげるバリューチェーン全てをシステムで一元管理することだ。
今風に言えば、それはプラットフォームビジネスであり、DXであり、SoEとも呼ばれるのだろう。

全てのバリューチェーンをシステムで一元管理できるとどんなメリットが出てくるのか?
それは、製造業の生産プロセス、小売業の販売プロセス、在庫プロセスという企業内部の情報を一元管理できるだけでなく、販売した顧客の購買履歴や活動履歴をも一元管理することで、顧客関係性を強化でき、顧客の声を生産プロセスや販売プロセスにフィードバックすることで、自社の業務プロセスを改善できるチャンスが増えることだろう。
しかも、アジャイル開発を適用できれば、1ヶ月間というスプリントよりももっと短いサイクルで業務を改善する仕組みさえ作れる。

このDXというソフトウェア基盤にはクラウドというスケールしやすいインフラがあり、MLやDLのようなAI基盤を使って、顧客が望むものを分析し提示することすらできる。
DXを構成する開発基盤や技術が一通り揃ってきたからこそ、すべての事業をソフトウェアで丸呑みして完全に実現できるようになってきた。

事業を一度ソフトウェアで実装してしまえば、アジャイル開発プロセスに従って、いつでも方針の変更が容易になるし、顧客の情報をより簡単に入手できて分析できるから、ビジネスのKPIに適用して、ビジネスそのものの診断ツールにも使える。

しかし、製造業も小売業もその他の業界の事業も全てソフトウェアで実装してしまえばいいだろうが、実際にはその転換は従来のビジネスモデルを構築した企業ほど難しい。
なぜ、ソフトウェア事業へのビジネスモデルの転換は難しいのか?

【2】DXとは「逆コンウェイ戦略を適用する」組織論である

ソフトウェア事業へのビジネスモデルの転換は難しい理由は、ソフトウェア事業に向いた組織を作るのが難しいからだろう。
チャンドラーは、組織構造は経営戦略に従う、と言った。
つまり、ソフトウェア事業に向いた組織構造を構築する必要がある。

一方、コンウェイは、ソフトウェアは組織構造に従う、と言った。
複雑な多重階層構造を持つ組織は、ソフトウェアをより複雑化させる。
人月の法則の通り、ソフトウェアの本質は複雑性にあり、ソフトウェアの複雑性を飼いならすのは非常に難しい。
つまり、ソフトウェア事業に向いた組織構造を作ろうとするが、従来の組織に単にソフトウェア開発を担当させるだけでは上手く行かない。

特に、ソフトウェア開発は、規模の経済が適用しづらく、少数精鋭の優秀な人材の開発チームで実行する方が成功しやすい。
だから、従来の製造業や小売業のように、大規模な設備、大量の人員を用意していても、ソフトウェア開発には向かない。
人月の法則の通り失敗しやすい。

そこで、コンウェイの法則の逆張りを考えて、逆コンウェイ戦略を取ってみてはどうか、という話になる。
つまり、ソフトウェア開発は少人数の開発チームの方が適しているなら、システムの構造に従って、開発チームを構成し直して、そこから組織を作ればいいのでは、となる。
たぶん、今、ScrumがIT企業だけでなく、製造業や小売業など他の業界にも適用されて浸透しようとしているのは、そういう理由があるのではないか。

たぶん、そういう動きは一部の企業に過ぎないだろうが、ソフトウェア事業が中核になれば、従来型の企業もそういう流れに傾いていくのだろうと思う。

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

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

【3】今後の課題は、ソフトウェア事業におけるエージェンシー問題を解決すること

他方、会社という大きな集合体の中で、ソフトウェア事業を委託する人と、ソフトウェア事業を実行するの間には、利益が相反する緊張関係があると思う。

株主や経営者、生産プロセスや販売プロセスに従事する事業部門の人達は、プリンシパル(=委託者)になる。
彼らはソフトウェアやITに詳しくはないので、専門技術を持つエンジニアに、事業のソフトウェア化を実現するために、事業システムの構築を依頼する。

一方、エンジニアは、プリンシパルのために代理で活動する代理人をエージェント(=受託者)になる。
彼らは、ITの専門家として、プリンシパルの目標や要望を聞き出し、彼らの期待を実現する為に働く。
彼らは、事業のソフトウェア化を実装するために、業務システムだったり、Webシステムだったり、スマホアプリだったり、機械学習基盤だったり、クラウド基盤だったり、いろんなソフトウェア基盤を構築してリリースする。

しかし、経営学で習ったプリンシパル=エージェント理論では、エージェントがプリンシパルにとって望ましい行動を行わないというエージェンシー問題が必ず発生する。
一般に、エージェンシー問題が生じる要因として、「プリンシパルとエージェントの利害の不一致」と「情報の非対称性」の2点がある。

組織運営支援|マーサージャパン

ソフトウェア事業でも、委託する人達はシステムのことが分からないので、結局は、委託者であるSIの言いなりになってベンダロックインされやすい。
製造業や小売業などの発注者も、システムのことは分からない、システム開発をコントロールする難しさは体験済みなので、一括請負契約を結ぶことでシステム開発リスクをSIに全て押し付けようとするが、どうやってもベンダロックインされやすい。
その理由は以前書いた。

一括請負契約はソフトウェア開発にやっぱり向いていない: プログラマの思索

【4】ソフトウェア事業におけるエージェンシー問題を解決するための組織構造とは何か?

従来型の生産プロセスや販売プロセスを持った事業をおなっている会社が、ソフトウェア事業を中核に据えようとする場合、下記のようなイメージで、ホールディングスの持株会社を作り、親会社と事業子会社とシステム子会社がそれぞれ役割分担と制御構造を持つ必要があると考える。

親会社(ホールディングス会社)の役割は、企業グループの全体戦略を策定することだ。
その全体戦略に従って、個別の事業の戦略を策定し、その事業に必要なIT戦略、つまりシステム投資の計画を策定する。

事業子会社は、親会社が策定した事業戦略に従って、その事業に合った業務プロセスを構築し、その業務を実行する。
事業を支える業務には、業務システムが使われるため、自分達の事業に合った業務システムの要求や要件をシステム子会社に提出したり、一緒にIT計画を策定することになる。
事業子会社の成績は、事業のROIで測定されるので、事業のROIを親会社に毎年報告することになる。

システム子会社は、親会社が策定したIT戦略に従って、個別の事業を支援する業務システムを構築し、保守していく。
彼らは、事業子会社の事業戦略に従って、いつまでにリリースする必要があるのか、どれだけの開発予算が必要になるのか、をシステム計画としてまとめて、システム計画を事業子会社と親会社に承認してもらってから、実行に移すことになる。
つまり、システム子会社の主な仕事は、事業を支える業務システム構築とその保守になる。

ここで重要な点は、事業は外部環境や市場の変化によってどんどん変わるので、事業を支える業務システムは一定期間しか使われないという前提で、リプレースする機関と計画を事前に策定する必要がある点だ。
たぶん、減価償却が5年間という制約条件とか、外部環境の変化で事業の寿命は5年とか、そういう単位で、業務システムは定期的に破棄されて、新規に再構築されるように計画しておく。
そうすれば、事業小会社の事業では、たとえば5年おきに新しい業務システムに支えられるので、その時代の最新技術が使えたり、その時代の要件に合ったシステムを使えるようになる。

このように、定期的にシステムはリプレースすべきだ、と親会社も事業子会社もシステム子会社も事前にIT戦略に埋め込んでおけば、時代の変化にあった事業に対応できるはずだ。

さらに、上記のような三者の組織構造があれば、システム子会社は親会社や事業子会社に定期的に報告する義務が生じることで規制をかけられるし、システム構築の目的が親会社や事業子会社の要件に合うように考えさせられるので、システム子会社が暴走するリスクも小さくなるだろうと思う。

【5】事業を支えるシステムの企画は誰が責任を持つのか?

一般の日本企業では、メーカーであれ、ユーザ企業であれ、SI企業であれ、予算駆動だから、システムが必要になったら、その企画フェーズが必要で予算取りの根拠を作らねばならない。
では、その企画フェーズを担当する最終責任者はいったい誰なのか?

ソフトウェアPJの企画フェーズの責任者は誰なのか?: プログラマの思索

本来は、システムの企画フェーズでは、親会社や事業子会社が主導権を持って、事業に必要なシステムの要求や要件を企画すべきである。
なぜなら、彼らが使いたいシステムなのだから。

しかし、僕の経験でもそうだが、ITやシステム開発を経験していない人達がシステム企画を担当すると、割と揉める。
いろんな要求や要件は出てくるが、その時代に合ったIT技術を組み合わせて、品質・コスト・スケジュールのトレードオフに落とし込む作業が難しいのだ。
結局、システム子会社を持たない発注者は、SIやITコンサルに丸投げして、だめなシステムを計画してしまいがちになる。

システム子会社を持っていても、彼らがソフトウェア開発部隊を持っていなかったり、クラウドやAIなどの新技術に関するソフトウェア開発の経験がなければ、SIベンダに丸投げするリスクがある。
結局、企業グループの中核にシステム子会社を持ち、彼らが一通りの技術力を常に研鑽しておかなければならないのだ。

だから、システム子会社の開発者が企画プロセスに入り込んで、彼らが主導権を握る場合が多い。
そして、親会社・事業子会社のユーザと、システム子会社の開発者の間で、対立関係が発生する時もある。
AsIsはユーザが詳しいが、ToBeはユーザでは作りにくい。
開発者がToBeを作ることが多いが、ユーザが果たして納得してくれるのか?

こういう問題にどう対処するか?
たとえば、匠メソッドの匠モデルではこたつモデルを持ち出す。
ユーザ・開発者・営業担当者がいきなりToBeモデルを作る。
事業側も開発側も同じゴールを目指すべきという思想で対応するからだ。

たとえば、Scrumでは、プロダクトオーナー1人が企画プロセスを担当するだろう。
プロダクトオーナーがいるおかげで、開発チームは彼を頼りにしてシステム開発に専念できるはず。

Scrumではどのプロセスを誰が担当するのかが明確ではないかと思う。
企画:ProductOwener
開発:Team
プロセス全体の守護神:ScrumMaster
という仮説も成り立つ。

それから、システムはリリースしておしまいではない。
システム投資の予算を立てて投資するのだから、投資対効果もIT計画に盛り込んで、リリース後に半年後、1年後に実際にROIが予定通りなのか検証したい。
そうしなければ、次のリプレースに活かせないからだ。
また、システム投資のROIを測定する作業をシステム子会社に課すことで、彼らにROIの意識付けもできるようになる。

システムの投資対効果(ROI)を検証するプロセスはどんな構造になるのか?

GoalやToBeでは、システム構築の目的にROI向上(工数削減、経費削減、売上向上)があるはず。
たとえば、システム化することで、手作業から自動化されて工数が削減される。
ペーパーレス化されて、経費が大幅に削減される。
システム化されて、新規顧客に利用してもらって、売上拡大を図る。
そんな内容がROIになるだろう。

稼働後に検証しなければ、一連のPDCAが回らない。
投資対効果=ToBe-AsIs で測定することになる。

企画プロセスでToBeを定めているので、リリース後に実際に、工数や経費、顧客数と売上を測定して、その差分を見ればいい。
もちろん、リリースが遅れると、その分、投資対効果が得られる期間が先延ばしになるので、メリットが薄くなる。
システム構築のコストが増えれば、もちろん投資対効果は薄れるし、使いづらいUIだったり、処理が遅かったり、まともに動かないシステムだったら、投資対効果はゼロかマイナスになってしまうだろう。

【6】こういうホールディングス会社、3社の企業構造をもたせれば、ソフトウェア事業におけるエージェンシー問題をかなり和らげて、エージェントであるシステム子会社が暴走したり、システム構築の目的を忘れてしまうリスクを減らせるのではないだろうか?

逆に言えば、IT計画策定やROI測定などの仕組みを課さないと、事業を支える業務システムを構築できないのではないだろうか。

| | コメント (0)

チケット駆動開発のプロセスと開発基盤を再考する #Redmine

チケット駆動開発のプロセスと開発基盤を書き直してみた。

チケット駆動開発のプロセスとチケット管理システムの全体像 #Redmine: プログラマの思索の図を改良している。

チケット駆動開発は基本的に、ScrumやXPに似たアジャイル開発のプロセスと同一視される。
なぜなら、ロードマップをScrumのスプリント計画、XPのイテレーション計画とみなして、リリースサイクルに従って定期的にリリースされる仕組みとみなせるからだ。
つまり、チケット駆動開発は小規模リリースを実現するプロセス基盤でもある。

他方、チケット駆動開発というプロセスから発生する情報は、チケット管理ツールに全て集約される。
チケット駆動開発プロセスは、チケット管理システムに支えられて実装される。
チケット管理システムの構造は、Input,Process,Outputという単純なプロセスから成り立つ。
中核となるPMISは、フロー管理とストック管理という2つの機能を持つ。

フロー管理の機能は、チケット管理、チケット集計、ロードマップ、ワークフロー管理などがある。
つまり、チケットは流通媒体であり、ステータスに応じてサクサク流れる。
チケット集計には、ガントチャート、カレンダー、かんばんなどがある。
ロードマップとチケット集計を区別したのは、ロードマップがScrumのプロダクトバックログに似た機能であり、スプリント計画あるいはイテレーション計画で使われる重要な機能だからだ。

ストック管理の機能は、チケット管理、SCM連携、Wiki、トレーサビリティなどがある。
つまり、チケットは記録媒体であり、作業履歴や課題の内容、障害管理票などの帳票として記録される。
ただし、記録される媒体はチケットだけでなく、Wikiもあるし、GitやSVNなどの構成管理ツールにもある。
これらの情報と相互リンクすることで、チケット管理ツールにすべての情報が集約されて、ナレッジ基盤になる。

チケット駆動開発はプロセスであるから、処理が主人公になる。
一方、チケット管理システムは機能から構成されるので、機能を通じて記録されるデータが重要になる。
そのデータの特徴はフローでもありストックでもある。

チケット管理システムは、チケットにフローとストックの両方の意味を故意に持たせることで、幅広い運用が可能になる。
ある側面では、タスクかんばん上でステータス管理できるし、ある側面では、そのタスクや課題のチケットには、数多くの情報が記録されているし、その変更履歴も記録されているので、経緯や意図を把握できる。

このチケットの二重性という特質がチケット管理ツールに豊かな機能や利用シーンを生み出してくれるのだ。

Redmineのチケット駆動開発では、チケットに複数の意味を持たせて運用した方が上手く回る: プログラマの思索

Redmineによるチケット駆動開発はストック型プロセスとフロー型プロセスの二面性を持つ: プログラマの思索

| | コメント (0)

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