経営・法律・ビジネス

2021/02/25

デブサミ2021の感想~コミュニケーションスタイルがオフラインからオンラインに激変している

今年のデブサミはOLだったので、在宅勤務中でも、ラジオ番組みたいに流していた。
来年度以後もこういうスタイルであって欲しい。
思いつきをラフなメモ書き。

Developers Summit 2021(2021.02.18-19)

(1)動画を見るよりも、講演者の声がハッキリしているか、発言内容にキレがあるか、の方が印象の残り方がまるで違う。
最近、ClobuHouseが流行しているらしいけど、動画よりも音声の方が今後重視される気もする。

(2)沢渡さんのパネルディスカッションは聞いていてとても楽しい。

ファンを3つ作る。
技術のファン、プロダクトのファン、カルチャーのファン。
デベロッパーこそ、ファンを増やし、自己ブランディングしていくべき。

今はデベロッパーのルネサンス。
コロナ感染の現状では、アナログの環境よりもデジタルな対話が当たり前。

そして、先進的なデベロッパーが使っていたツールが当間になった。
Slack+Zoomが一般的。
会社組織ではTeamsになるだろうか。

つまり、対面の対話が今は物理的に難しくなり、OLコミュニケーションが当たり前となった。
OLツールが使えない人は致命的。
誰とも会話できなくなる。

(3)日立の方の講演では、コロナ禍で社内・プライベートのコミュニケーションが全てデジタル化されたことにより、OSS開発者の価値が上がった、とか、コミュニティ活動の経験者がより上手く適応している、みたいな話があった。
社内の根回し、とか、顧客調整が得意であっても、今はTeamsでやり取りするしか無いから、こういうツールに慣れていないと能力を発揮できない。

一方、OSS開発者は以前から世界中の開発者とオンラインでやり取りしてきたので、何も変わらないし、彼らのやり方をSIも既存企業も真似ようとしている。
また、コミュニティ活動の経験者も、こういうツールに慣れている人も多いし、ノウハウを共有する場作りに長けているから、彼らもその能力を発揮しやすい。

今は、コミュニケーションのスタイルが完全に変わってしまった。

(4)コミュニケーションのスタイルがアナログからデジタルに変わった事態により、何が起きるのか?

年を取るほど、大企業の社内の人間関係をベースにした根回しが期待されてくるが、Teamsでしかやり取りできない現状では、全く無意味なスキルになってる。
新人の営業マンが訓練と称されて、100枚の名刺を配って新規顧客をどぶ板で集める手法も、コロナ感染の現状では実現不可能。

オンラインのツールで他人と深く関わるやり方に早く慣れないといけない。
たぶん、多くの人が試行錯誤しながら、OLツール上で初対面の人と会った時、どうやって仲良くなって意思疎通できるようになるか、試しているはず。

(5)緊急事態宣言のもとでは、外食チェーンや居酒屋、個人料理店ですら、大人数で集まって会話することさえ禁止された。
ショッピングモールや百貨店、商店街などに行くことすら、緊急事態宣言のもとでは、ちょっとした罪悪感さえ感じさせられた。

デジタルネイティブ世代がコンシューマになって登場したら、現状のままでいると、おたくの会社の製品は買ってもらえないですよ、と言われているが、まさにそう。

オフラインで、街中でビラ配りしたり、イベントを開いて沢山の人を集める、というプロモーションは今は事実上禁止された。
つまり、今後は、オンラインのプロモーションが重要になるし、O2Oと言われるプロモーション、つまり、オンラインで集客してオフラインの店に来てもらう、というプロモーション手法がより一般的になるだろう。
以前は一部の企業しか試していなかったが、今は大企業だけでなく、中小企業や個人商店ですら、O2Oを実行しなければ生き残れないのだろう。

(6)オフラインからオンラインにコミュニケーションスタイルが激変した事態のもとで、従来の既存ビジネスをいかにIT化で売上を維持、拡大していくべきか、という問題にすり替えた。
この問題こそ、DXというのではないか。

| | コメント (0)

2021/02/13

トランザクティブ・メモリーを使え~「プロジェクトをリードする技術 / Project Leading is Skill」の資料はプロジェクトリーダー初心者にお勧め

プロジェクトをリードする技術 / Project Leading is Skill - Speaker Deckを読んで、特に「トランザクティブ・メモリー」が良かった。
良い資料と思ったのでメモ。

【参考】
akipiiさんはTwitterを使っています 「良いスライド資料だなあ。進捗管理で、ボトルネックを常に移動させることは僕も感じていた。プロジェクトをリードする技術 - kakakakakku blog https://t.co/vB5toW5fSy」 / Twitter

プロジェクトをリードする技術 - kakakakakku blog



【1】プログラマ上がりのプロジェクトリーダーは、プレイングマネージャーだと思う。
すると、一人でプログラムを書いたり、自分でバグ修正した方が速いわけだが、それではチームは回らない。
いかにチームを回すか?

上記の資料で良いと思ったのは、アジャイル開発でやればいいんだ、みたいな一本調子ではなく、バランスが取れている所。
たとえば、「計画が得意=クリティカルパスの見極め」は、ガントチャートでも、バックログ管理でも、スプリント管理でも重要だ。

以前、どこかの本で、MSProjectでいちばん重要な機能はガントチャートではなく、PERT図だ、と喝破した記載があって、同意する。
優れたリーダーは、タスクにばらした時に、ネットワーク図をイメージして、どのパスが最短ルートなのか、を頭の中でイメージしている。

ソフトウェア開発が難しいのは、日々の状況によって、クリティカルパスがどんどん変化することだろう。
たとえPJ計画当初にガントチャートを作っても、初めての技術、コロコロ変わる要件、仕様への落とし込みで、クリティカルパスはコロコロ変わる。
つまり、ボトルネックは常に推移していく。
駄目なリーダーはガントチャート保守でボトルネックを見出そうとするが、その作業に追いつかずに破綻する。

【2】チームビルディングも重要な技術の一つ。
タックマンモデルとか色々あるけど、「トランザクティブ・メモリーを大切にしよう」という言葉は僕も同意する。
メンバーの役割分担をリーダーだけでなく、メンバー全員が知って、リレーのバトンを渡すように上手く回す。
そのためには、誰がどんな専門スキルを持ち、誰が暗黙知を持っているのか、を知っておけばいい。

「トランザクティブ・メモリー」は僕は以前は知らなかったので、もっと早く知っておけばよかったと思う。

「トランザクティブ・メモリー」という言葉は、「ビジネススクールでは学べない 世界最先端の経営学」ではなく「世界の経営学者はいま何を考えているのか――知られざるビジネスの知のフロンティア」を読んで僕は初めて知った。

【3】「世界の経営学者はいま何を考えているのか――知られざるビジネスの知のフロンティア」では、トランザクティブ・メモリーの社会実験でこんな話がある。

交際期間が3ヶ月以上の大学生のカップル60組を集めた。
そのカップルの半数はそのまま、残りはランダムな組み合わせのカップルにする。
そして、それぞれのカップルに、記憶力ゲームを試してもらう。

具体的には、科学、歴史、食べ物、テレビ番組などのカテゴリの文章を、カップルは自分の判断で選択して記憶し、どれだけ正確に記憶できていたかを試す。
カップルごとの合計点で評価する。
つまり、記憶作業は1人で行うが、パフォーマンスの優劣はカップルの合計で決まる。

この実験のポイントは、カテゴリ選択時にカップルが相談できないこと。
つまり、カップルはお互いに相手がどんなジャンルを覚えているのか、知らない。

さらに、交際していたカップルと赤の他人同士のカップルをさらに半分に分けて、もう一方には、男性は歴史、食べ物、テレビ番組、女性は残りのカテゴリと指定しておく。

つまり、
①交際しているカップルでジャンル指定のないカップル、
②他人同士でジャンル指定のなかったカップル、
③交際していて男女それぞれが覚えるべきジャンルを指定されたカップル、
④他人同士で男女それぞれが覚えるべジャンルを指定されたカップル、
の4つでランダム化比較試験を行うわけだ。

その結果はどうなるか?

①のカップルの方が②のカップルよりも結果が良くなった。
交際していたカップルの方が記憶力がいい、というのは常識の範疇。
なぜなら、交際していたカップルは、彼と彼女の強みの部分をお互いに知っているので、強みを発揮できるジャンルをお互いに選べばいいから。

しかし興味深いのは、③のカップルよりも④のカップルの方が結果が良かった。
つまり、あらかじめ記憶するジャンルを指定されてしまうと、交際していたカップルよりも、赤の他人同士のカップルの方が記憶力が良かったのだ。

この実験が意味していることは、「ある程度の交際期間を経たカップルは、お互いにどんな強みや弱みを持っているのか、というトランザクティブ・メモリーを自然に持つようになる」ということだ。
たとえば、彼が映画に強いけど彼女は弱い場合、彼女は彼に聞けばいい。
一方、彼女は美味しいレストランはよく知っているが、彼は知らない場合、彼女に聞けばいい。

つまり、Who knows What、誰が何を知っているのか、誰が組織内で特定分野の専門知識や経験を持っているのかを知っていること、というトランザクティブ・メモリーの重要性を示す。

他方、カップルとして自然に形成されたトランザクティブ・メモリーを新しい枠組みで無理に歪めると、非効率を生み出し、カップルの記憶力は著しく落ちてしまう。
むしろ、赤の他人同士のカップルの方が、ジャンル指定だけに基づいて記憶するので、トランザクティブ・メモリーを歪められてしまった交際カップルよりも、はるかに効率的に記憶できたわけだ。

この実験の話を読んで連想したのは、暗黙知を重視する、トランザクティブ・メモリー型の組織文化を故意に歪めた事例は割と多いのではないか、と思った。

たとえば、自社でソフトウェア開発しないユーザ企業やSIでは、大量の派遣プログラマを案件ごとに短期間に総動員してはリリース後に切り捨ている。
すると、案件のプロマネは、トランザクティブ・メモリーに依存しない、属人性のないPJ管理、属人性のない技術で管理したくなる。
そのやり方は、メーカーの単一製品の大量生産方式のように、単純労働者が多い場合には、トランザクティブ・メモリーを重視しなくても、効率的なオペレーション管理を重視すれば成功しただろう。

しかし、ソフトウェア開発のように、暗黙知があまりにも多いビジネスでは成り立たない。
むしろ、苦労して開発してリリースにこぎつけた時、数多くの暗黙知は派遣プログラマに残っているが、彼らが解き放たれたら、そのチームに得られた暗黙知は雲散霧消してしまう。

たとえば、M&Aで買収した企業の社員を、買収元の経営者が勝手に異動させてバラバラにさせてしまうと、せっかく買収先の企業の社員の中であったトランザクティブ・メモリーが破壊されて、M&Aの相乗効果が得られなかった、とか。

うまい例が思いつかないが、トランザクティブ・メモリーを有効活用していない組織や企業は、日本に割と多い気もする。

なお、「世界の経営学者はいま何を考えているのか――知られざるビジネスの知のフロンティア」も「ビジネススクールでは学べない 世界最先端の経営学」の本もお勧め。

| | コメント (0)

2021/01/14

みんなのPython勉強会#65の感想~社会変革の鍵はIT技術者にあるのかもしれない

みんなの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技術者が多数必要になる。

つまり、それぞれの分野で一流の人を集めて、彼らを的確にアサインし、振ってくる問題をさばいていくことが求められる。
そういうことを実施する時、トップが全ての分野に精通して理解できるのは難しいだろう。
トップは全ての分野に精通した専門家ではないのだから。

では、そういうチームを編成して、問題を一つずつ解決していくことを成し遂げるには、何が必要なのだろう??
専門家でもないリーダーには、どんなスキルが求められるのだろうか?
どんなリーダーシップを発揮したら、問題となる状況を解決できるのだろうか?

何故ファシリテーションが流行しているのか?: プログラマの思索

| | コメント (0)

2020/12/05

IPAがDXのパターン・ランゲージを公開している~新しい組織文化が新しい経営戦略を生み出す

IPAがDXのパターン・ランゲージを公開しているのでメモ。
ラフなメモ書き。

【参考】
トランスフォーメーションに対応するためのパターン・ランゲージ(略称トラパタ):IPA 独立行政法人 情報処理推進機構

変革のススメ vol.2 沢渡あまね 氏:IPA 独立行政法人 情報処理推進機構

トランスフォーメーションに対応するためのパターン・ランゲージ(略称トラパタ)

今のIT業界のバズワードはDXではないだろうか。
経産省が「2025年のITの崖」の記事を公開してから、特にDXという言葉が独り歩きしている気がする。

そもそもDXとは何だろうか?
僕の考えでは、DXとは、ソフトウェアが本業でない企業がソフトウェア中心のビジネスモデルを構築して事業構造を変換していくこと、と捉えている。
つまり、ソフトウェア開発の特徴や本質をあまり深く知らない人たちが中心になって、ソフトウェア開発のビジネスモデルを作って、売上を拡大していくための仕組みを作るもの、と考えている。
実際、小売業界、自動車などの製造業では特にそういう傾向が強いのではないだろうか。

すると、以前の「日本企業の強みであるモノづくり」というQCDと効率性を重視したビジネスモデルから、「市場に合わせてタイムリーなソフトウェアを提供していく」ソフトウェア開発中心のビジネスモデルに変わることになる。
「ソフトウェア・ファースト」本が言う通り、結局、QCDのスコープが確定した売り切り型のプロジェクト開発ではなく、SaaSをベースにして継続的な運用保守を前提としたアジャイル開発に取り組まざるを得ない。

よって、ビジネスモデルという経営戦略の変革を起点として、その戦略を活かす組織文化、マインドが必要になるわけだが、従来の製造業の生産管理をベースにした組織文化では、ソフトウェア開発になじまない点に苦労している。

そこで、トランスフォーメーションに対応するためのパターン・ランゲージ(略称トラパタ)のような道具を使って、会社にソフトウェアを開発しやすい組織文化を定着させるような仕掛けを導入しよう、という動機が生まれたのではないか、と想像している。

実際、トランスフォーメーションに対応するためのパターン・ランゲージ(略称トラパタ)の中身は、「未来への羅針盤」「共感は発信から」「多文化の架け橋」「自律自走する組織」「多様性が育む」などのパターンのように、ビジョンという共通目的の共有、メンバーに貢献意欲を植え付ける仕組み、メンバー同士のコミュニケーションの活性化、のような組織文化に関わる内容ばかりだ。
つまり、DXを実装するプロセス論や技術論よりも、組織文化の方を重要視している、と推測している。

個人的には、IPAがトランスフォーメーションに対応するためのパターン・ランゲージ(略称トラパタ)の読者層を誰に設定しているのか、が気になっている。
おそらく、本来は、DXを推進する経営層ないし経営トップがこのガイドを読んで、DXのリーダーシップを発揮してください、と言いたかったのではないだろうか。
なぜならば、新しい組織文化を定着させるには、そういう組織文化を取り入れて実現しよう、とトップ自らが汗をかき、リーダーシップを発揮して説明して、メンバーに影響させて、経営戦略のゴールに対し、それをブレイクダウンした目標をメンバーに提示し、メンバーに目標達成意欲を植え付けて焚きつける必要があるからだ。

そんな事を考えながら読んでみると、より一層真剣味が感じられるように思った。

| | コメント (0)

2020/11/23

組織は記憶能力を持つのか~トランザクティブ・メモリーという概念

世界の経営学者はいま何を考えているのか――知られざるビジネスの知のフロンティア」を読んでいて、組織は記憶能力を持っているのか、組織は学習する能力を持つのか、という問いがあった。
内容がとても面白かったのでメモ。

せきねまさひろぐ: 『世界の経営学者はいま何を考えているのか』

「世界の経営学者はいま何を考えているのか」で明かされた9つの意外な事実 | netgeek

【新連載・入山章栄】経営理論は“モヤモヤ”を言語化する武器。「思考の軸」をつくる教養を磨け | Business Insider Japan

「世界の経営学者はいま何を考えているのか」書評と要約:旧・本を聴く日々:So-netブログ

トランザクティブ・メモリーとは | 人事のプロを支援する | HRプロ

トランザクティブメモリーとは?組織の知を最大化する方法 | BizHint(ビズヒント)- クラウド活用と生産性向上の専門サイト

トランザクティブ・メモリー・システムとは何か(村瀬俊朗)|英治出版オンライン

組織のラーニングカーブは存在するのか?
組織は経験から学習するのか?

個人は経験から学習して、個人の能力を高めていく。
人は経験から記憶する。
組織も同じだが、その構造は異なる。

100人がばらばらに学ぶ場合と、100人が一つの組織で学習する場合、組織で得られる知の総量は違うのか?

結果は異なる。
組織は、トランザクティブメモリという、誰が何を知っているのか、という知識を蓄積することで、より多くの専門知識を持つことができる。
つまり、組織内の個人は機能別組織として、その専門性を発揮するが、ばらばらの専門性の知識は、組織内の権限と責任の一致によって、組織内の専門知識に自由にアクセスできる構造を持つ。

組織は、自然に形成されたトランザクティブメモリを持つが、それを新しい組織構造に変換して無理にゆがめると、組織内の軋轢を引き起こし、組織内の記憶力は著しく落ちていく。

このトランザクティブメモリの概念を、ソフトウェア開発に適用するとどのように解釈されるのか?

たとえば、専門性を持つ技術者が集まったチームが生産性を発揮しても、そのチームを一度解体してしまうと、組織の記憶力は低下し、組織の生産性も著しく落ちてしまう。

スクラムではチームを重要視する。
チームはブラックボックスとして扱い、プロジェクトマネージャのマイクロマネジメントは許さない。
チーム内ではメンバーの専門性は最大限発揮できるような環境が提供されている。
つまり、トランザクティブメモリが発揮できるような仕組みをスクラムは開発チームに提供している。
そういうトランザクティブメモリがスクラムチームに自然に埋め込まれているならば、困ったときに、専門性を持つ人に声をかけて支援してもらい、問題解決することが可能になる。

ソフトウェア開発では、長年保守してきたシステムの知見、技術、業務の知識を持つ技術者が非常に重要だ。
そういう属人生を排するような仕組みを組織的に作り出そうと四苦八苦してきたが、むしろ、そういう技術者が能力を最大限発揮できるような仕組みを作り出すほうが重要ではないだろうか?

トランザクティブメモリの豊かな組織では、組織が記憶力を高めて、組織の学習能力を高めてくれる。
ここで、組織の記憶力はあくまでも、専門性を持つ人の情報を共有する点に着目していること。
単に、Wikiで情報共有すればいい、というわけではないのだ。
誰が何を知っているのか、という暗黙知が知のインデックスカードのような役割を果たしている。

トランザクティブメモリのおかげで、知の探索、つまり、試行錯誤しながら新しい知見を蓄積しいていく試みが可能になる。
つまり、アジャイル開発を実践するには、組織にトランザクティブメモリという性質が必須要件なのかもしれない。

世界の経営学者はいま何を考えているのか――知られざるビジネスの知のフロンティア」には、ほかにも面白い話がいくつかあるので、その内容も別でメモしておく。

| | コメント (0)

2020/11/07

手段を目的化するのは日本人の病

「手段を目的化するのは日本人の病」という言葉にすごく惹かれたので、メモ。
ラフなメモ。

【参考】
「手段を目的化するのは日本人の病」元最強の会社員・田端信太郎が語る“会社で働く”意味 20’s type - 転職type

(引用開始)
僕は会社って乗り物みたいなもので、会社選びは交通手段を選ぶのに似ていると思っています。目的地を定めて、そこまで最短で行くなら新幹線や飛行機を使えばいいし、寄り道しながら行くならレンタカーが適しているかもしれない。

僕は自分一人では行きにくいところに連れていってもらうための手段として、ある程度まで新幹線で行き、目的地に近づいたらレンタカーを借りて自分の思うように進むような組み合わせが一番いいと思って、昨年末に会社を辞めて独立しました。

とはいえ、今はレンタカーで自由気ままに楽しんでいるけれど、遠方に行きたくなったらまた電車に乗るでしょう。結局はその時々に何がしたいかですよね。

要は自分のゴールと行き先が一致している限りは乗っていればいいし、そうじゃなくなったら降りればいいわけです。例えば東京から奈良に行くのに、新大阪までは新幹線に乗るとする。その時に、乗り心地がいいからって新大阪で降りない奴はバカでしょ?

忘れてはいけないのは、乗ること自体は手段だということ。「なんとなく乗り心地が良いと聞いたから」って動機で就活している人が多いけど、乗ることが目的になってしまうのは寂しいと思うんですよ。それこそコロナショックで在宅勤務になって、グリーン席に座れなくなった人もいるわけだし。

手段が目的化しがちなのは、就活に限らず、日本人の病。就職が全てではなくなり、選ぶのはより難しくなったけれど、本質は「どこに行きたいか」であることは変わりません。それだけは忘れずにいてほしいなと思いますね。
(引用終了)

戦略家ポーターも、日本人経営者には経営戦略の思考がない、みたいな意見があったな。
ソフトウェア開発のプロセス改善、製造業のQCサークルなどを振り返ると、日本人は現場のプロセス改善が大好きだし、すごく向いている。
全体最適よりも、現場での局所最適の方が正確的に向いているのかも。

「選択と集中」による経営戦略は何となく日本企業に向いていない気もする。
むしろ、自社の強みをベースに、既存ドメインの事業を横展開しながら事業を広げてチャンスを伺うという多角化戦略の方が、日本企業の経営戦略に向いているのかもしれない。

| | コメント (0)

2020/09/02

問題解決アプローチを見極める『クネビンフレームワーク』のメモ

問題解決アプローチを見極める『クネビンフレームワーク』を知ったのでメモ。
結論のないメモ。

【参考1】
akipiiさんはTwitterを使っています 「クネビンフレームワークの説明が参考になった。問題のドメインが時代で変化しているからソフトウェア開発プロセスも変化する。非開発者のためのアジャイル開発入門 by @haradakiro #agile #complex https://t.co/2iCYVDeddY」 / Twitter

More Effective Agile ? “ソフトウェアリーダー”になるための28の道標|かず|note

複雑な世界を捉えるためのカネヴィンフレームワーク(Cynefin Framework) ? ゲームを用いた企業研修なら| 株式会社HEART QUAKE

(引用開始)
カネヴィンフレームワークは1999年にIBM Global Servicesのデイブ・スノーデン(Dave Snowden)らが提唱したもので、状況・問題を大きく4つのドメインに分類するフレームワークです。(上画像)

1.Simple(シンプル):単純
⇒問題の因果関係・構造が明確

2.Complicated(コンプリケーティッド):煩雑
⇒少し分析すれば、因果関係・構造が明確

3.Complex(コンプレックス);複雑
⇒因果関係が複雑、調査・探索が必要

4.Chaotic(カオス):混乱
⇒因果関係が不明確で、状況や問題を理解することも難しい

その他.Disorder(ディスオーダー):無秩序
⇒直面する問題に適切な解決策がない

さらに、1のSimpleと、2のComplicatedを予測可能な問題、3のComplexと、Chaoticを予測不可能な問題と分類することもできます。
(引用終了)

製造業における製品製造の大量生産方式のビジネスと、エンジニアやコンサルタントなどの知的労働者がプロジェクトで仕事するビジネスは、本質的に何かが違うといつも思っていた。
その理由の一つは、問題解決アプローチが全く違う、という指摘を、クネビンフレームワークは教えてくれる。

クネビンについて講演してきました | サーバントワークス株式会社

(引用開始)
(クネビンフレームワークが必要とされる)背景としては、「正解がない」多様化した問題と現実解に対しての理解を深めることが第一義です。第二儀としては、アジャイルの必然性の腹落ち感があります。
(引用終了)

アジャイル開発が昨今必要とされる背景には、従来の問題解決の手法が通用しなくなってきていて、新しいフレームワークや考え方による問題解決手法が必要とされているのだろう。
「More Effective Agile ~“ソフトウェアリーダー"になるための28の道標」では、アジャイル開発による問題解決の観点はクネビンフレームワークの「複雑(Complex)」に当たるのではないか、という内容があるらしいので、今度読んでみたい。

【参考2】
複雑な世界を捉えるためのカネヴィンフレームワーク(Cynefin Framework) ? ゲームを用いた企業研修なら| 株式会社HEART QUAKE

クネビンフレームワーク Cynefin Framework :臨機応変の意思決定手法 ? I & COMPANY / アイ&カンパニー

カネビン・フレームワークで問題解決策を見極める

クネビンフレームワークを使ったテクニカルサポートチームの行動指針の立案 | Developers.IO

問題の解決アプローチを見極める『クネビンフレームワーク』をざっくりまとめる - コード日進月歩

(引用開始)
これをエンジニアのロールに置き換える広木さんのツイートはすごいなと思ったので参考まで
(引用終了)

広木 大地/ エンジニアリング組織論への招待さんはTwitterを使っています 「CTO/VPoE/TechLead(スペシャリスト)の仕事って一体どう言う役割分担なの?みたいなことを聞かれる。 これはクネビンフレームワークで捉えるとわかりやすい CTO は Chaoticな問題 -> Complex VPoE/EMは Complexな問題 -> Complicated TechLeadは Complicatedな問題 -> Simple 不確実性が減っていく https://t.co/un1FX3QQ53」 / Twitter

akipiiさんはTwitterを使っています 「クネビンフレームワークでカオスで複雑・複合的な問題を分類する。CTO/VPoE/TechLeadというエンジニアのロールはクネビンフレームワークで整理すると分かりやすいという指摘。 問題の解決アプローチを見極める『クネビンフレームワーク』をざっくりまとめる - コード日進月歩 https://t.co/exz3rCJnfw」 / Twitter


| | コメント (0)

2020/07/07

ソフトウェアの政治的影響力とは何だろうか

今年になって、台湾の天才IT大臣の記事をチラホラ見かける。
ソフトウェアの政治的影響力を上手に使いこなしているな、と感じたのでメモ。
ラフなメモ書き。

【参考1】
「マジで胸アツ」台湾の天才IT大臣、東京都の新型コロナ対策サイトの修正に自ら参加し話題に

(2) akipiiさんはTwitterを使っています 「時代の変化は速いよね。「マジで胸アツ」台湾の天才IT大臣、東京都の新型コロナ対策サイトの修正に自ら参加し話題に https://t.co/drVTKoZz74」 / Twitter

新型コロナ“神対応”連発で支持率爆上げの台湾 IQ180の38歳天才大臣の対策に世界が注目 (1/4) 〈dot.〉|AERA dot. (アエラドット)

新型コロナ“神対応”連発で支持率爆上げの台湾 IQ180の38歳天才大臣の対策に世界が注目 (2/4) 〈dot.〉|AERA dot. (アエラドット)

新型コロナ“神対応”連発で支持率爆上げの台湾 IQ180の38歳天才大臣の対策に世界が注目 (3/4) 〈dot.〉|AERA dot. (アエラドット)

(引用開始)
タン氏にインタビューした経験がある前出の近藤さんは、こう話す。
「両親の職業がジャーナリストということもあり、彼女は『情報』が人々にどのような影響を与えるかをとても理解しています。
また、現役の閣僚でありながらも特定の政治的立場に立つのではなく、むしろ意見の対立をIT技術で可視化して、解決につなげることを考えている。
入閣した時に『公僕の中の公僕になる』と宣言したとおり、特定団体の利益のために動くのではなく、テクノロジーを駆使して台湾の人々と行政院をつなぐ“パイプ”になっています」
(引用終了)

akipiiさんはTwitterを使っています 「ITによる可視化で政治的対立を消化させる道具にする発想が素晴らしいと思った。Redmineにも通じる。「むしろ意見の対立をIT技術で可視化して、解決につなげることを考えている」新型コロナ“神対応”連発で支持率爆上げの台湾IQ180の38歳天才大臣の対策に世界が注目 AERA dot. https://t.co/GORTP5vWb4」 / Twitter

【参考2】
台湾の天才IT担当大臣オードリー・タンに訊く、新型コロナウイルスの先にある未来の国家とは - Engadget 日本版

akipiiさんはTwitterを使っています 「ソフトウェアの政治力を良く知り尽くして活躍されてる事例。参考になる。” 台湾の天才IT担当大臣オードリー・タンに訊く https://t.co/zxSe7tNwVZ」 / Twitter

こーじさんはTwitterを使っています 「>その一方でパニック買いなど、噂による行動は防ぐ必要があります。そこに対しては、インフォデミック(≒情報の氾濫)より面白いユーモアを発信するという対策に取り組みました。 これ凄い面白い取り組みだな」 / Twitter

akipiiさんはTwitterを使っています 「@saba1024 台湾のIT担当大臣は、人々がシステムやSNSを使うと、どんな行動に走るのか、それを遠くまで見通して意思決定している点が凄いです。ソフトウェアの開発力だけでなく、その政治的影響力、行動経済学の知見、社会心理学の知見を知り尽くしてる、そんな気がします」 / Twitter

こーじさんはTwitterを使っています 「@akipii まさに仰るとおりですね! 時代が人を作るのか、人が時代を作るのかというのはよく言われる話題では有りますが、この方は間違いなくこの時代に必要とされる方ですね。」 / Twitter

台湾の天才IT担当大臣の振る舞いをツイッター上で眺める限り、ソフトウェアの調達方法や影響力の行使の仕方をよく理解しているな、と思う。
たとえば、コロナ感染症サイトへのプルリク、マスク在庫サイトの構築方法、記者会見をすべてオンライン化などがすぐに思い浮かぶ。

彼女のやり方で参考になる点はいくつかある。
1つ目は、ソフトウェアの開発はベンダー委託ではなく、オープンソース開発者のコミュニティを使って、アジャイルに開発していること。
公的なソフトウェアの開発は、官公庁の内部調整やベンダーへの委託によるリスク回避など、数多くの組織的な壁がボトルネックになりがちだ。
しかし、本来、公的なソフトウェアは国民全てがその利益を享受できるものだし、その重要性は高いのだから、いち早くリリースして、漸進的にVerUpしながら開発していくべきだ。
しかも、ソフトウェアは請負契約で作ったら終わりではなく、SaaSと同じく、運用しながらどんどん改善していく開発スタイルなので、ベンダーへの一括委託は元々なじまない。
現在のソフトウェア開発の技術革新の場所は、ベンダーではなく、オープンソースコミュニティに移っているのだから、彼らの力を利用して、国民すべての利益にかなうようなソフトウェアを作るべきだろう。
彼女の言動や行動した結果を見ると、ソフトウェア開発の特徴をよく理解しているように思える。

2つ目は、情報を発信すると人々がどのように影響を受けて、どんな行動に移るのか、という事を彼女はよく考えて理解しているように思えることだ。
「現役の閣僚でありながらも特定の政治的立場に立つのではなく、むしろ意見の対立をIT技術で可視化して、解決につなげることを考えている」という記事の言葉から想像すると、行動経済学の知見をよく知っているのではないか、と思う。

実際、コロナ感染が流行している時期にマスクの情報を何の仕掛けもなく公表するとどうなるのか?
本来マスクが必要な人に情報を知らせるにはどうすればよいのか?

皆が混乱している時に、その情報をIT技術で見える化することで、真実を共有し、そこから各人のあるべき行動を促す。
IT技術は本来、そういう問題解決に使うべきものであるはずだ。

そして、単に、マスク在庫のシステムをアジャイルに作るだけではない。
彼女や他の大臣が率先して、その規範を示していることも大事だ。

「例えば、支給マスクの色がランダムで、ピンクが当たった男子生徒が登校拒否になっているという声が届きましたが、その翌日には閣僚の男性陣によるピンクマスク着用のキャンペーンが始まりました。」という記事の通り、大臣自らが率先して見せれば、他の人も自然にその行動変容を受け入れてくれる。

「組織文化は組織のトップが作り出すもの。組織のトップはもっと汗をかくべき」と、とある先生から組織論の授業で習った。
僕が理解するには、人がたくさん集まっても、単なる集団であり、何かの目的を成し遂げるための組織にはなりえない。
トップがリーダーシップを発揮して、共通目的を語り、メンバーの貢献意欲を引き出し、コミュニケーションを活性化して初めて、集団は組織に変わり、人々の行動を変容させる。
また、社会や組織の中にいる人達は、社会的地位が低かったり、経済力がなかったり、政治力がないために、他の力の強い人達の影響を受けやすい面がある。
だからこそ、規範となるべき人があるべき姿や目的を語ることで、人々の意欲を引き出し、人々の行動を変容させる。
つまり、社会に流通する価値観や規範は、そのトップのリーダーシップから生まれるものだ。

そして、昨今の環境では、SNSを使えば、簡単に周知させやすい。
人の気持ちを盛り上げて、意欲を引き出すような言動をリツイートさせることで、人々に行動を変えさせる事が以前よりも格段に簡単に、かつ、その影響力が大きくなった。
その分、この使い方も難しい。
行動経済学が考えているように、人は合理的な存在ではなく、時代や環境に依存したバイアスを持って価値判断を下し、経済効果を生み出す。
そういう考え方を利用する方法もあるだろう。

| | コメント (0)

2020/06/17

相殺フィードバックを再考

システム思考で出てくる相殺フィードバックをメモ。

【参考1】
学習する組織 - ごろにゃ~の手帳(備忘録)-パーソナルMBA的な

(引用開始)
強く押せば押すほど、システムが強く押し返してくる
よかれと思って行った介入が、その介入の利点を相殺するような反応をシステムから引き出す現象である。
私たちは誰もが、相殺フィードバックに直面するのはどんな感じか知っている。
押せば押すほど、システムが強く押し返してくる――つまり、物事を改善しようと努力すればするほど、 さらに多くの努力が必要に思えてくるのだ。
(引用終了)

【参考2】
組織は「苦労」や「一生懸命努力すること」を美化してはいけない。 | Books&Apps

(引用開始)
MITスローン経営大学院のピーター・M・センゲは著書「学習する組織」においてこの現象を「相殺フィードバック」と呼ぶ。
多くの企業が、自社製品が突然に市場での魅力を失い始めるとき、相殺フィードバックを経験する。企業はより積極的な売り込みを推し進める―それが今までいつもうまく言っていたやり方だ。宣伝費を増やし、価格を下げるのである。
こう言った方法によって、一時的には顧客が戻ってくるかもしれないが、同時に会社からお金が流れ出ていくので、会社はそれを補うために経費を切り詰め、サービスの質(例えば、納期の早さや検査の丁寧さ)が低下し始める。
長期的には、会社が熱心に売り込めば売り込むほど、より多くの顧客を失うことになるのだ。
(中略)
私が見た現象は、サービスの質を改善せず、全員を「テレアポ」と「飛び込み」などの労働集約的な仕事に邁進させる、というやり方だったが、上と全く結果は同じであった。顧客は流出し、人材は会社を辞め、競合にシェアを奪われたのだ。
(引用終了)

相殺フィードバック: プログラマの思索でも書いたが、IT業界は相殺フィードバックによる問題発生が多い。

たとえば、過去に直したバグ修正が、今の障害の発生原因になっている。
たとえば、以前下した判断や意思決定が、今回の問題の発生原因になっている。
その時は良かれと思ったことが、実は場当たり的な対応であって、より一層症状を悪化させた。

僕の経験上、相殺フィードバックという症状は、ソフトウェア開発で非常に発生しがちと思う。
従来のソフトウェア開発の現場では、元請けのPMと下請けのプログラマが混成チームを形成するが、彼らは顧客と切り離されているので、顧客からのフィードバックを得るタイミングが最初と最後のフェーズしかない。
だから、現在の意思決定がどんな影響を及ぼすのか、想像できない。

ソフトウェア開発は自己目的化しやすい: プログラマの思索

相殺フィードバック: プログラマの思索

僕は、相殺フィードバックをなくすには、システム思考に出てくる因果ループ図のような発想方法よりも、ランダム比較化実験を使って行動経済学の知見を導き出す手法の方が効果的ではないか、と直感している。
最初から、相殺フィードバックにはまらないような意思決定を下すのは難しい。
できれば、傷が浅い程度の失敗は許容できる時期に、2つの意思決定をランダム比較化実験で試して、人間の行動や集団行動がその後にどのような影響を与えるのか、を見極めた方がいいと思っている。

以前はそういう手法が使えなかったが、今はWebアプリはクラウド上で即座に作れるし、スマホ経由でランダム比較実験をしてみるのは易しい。
行動経済学の知見をソフトウェア開発やソフトウェア工学に活用するアイデアは試して見る価値があるように思える。


| | コメント (0)

2020/06/14

SaaSのビジネスモデルがアジャイル開発を促進したという仮説

「ソフトウェア・ファースト」を読んで、改めて、アジャイル開発はSaaSの開発プロセスを発展させたものとみなすのだと考えた。
ラフなメモ書き。

【参考】
ソフトウェア・ファーストの感想: プログラマの思索

【1】「ソフトウェア・ファースト」を読むと、製造業などの一般産業は、SaaSのようにどんどんサービス化すべきだ、という主張が背景にあるのが分かる。

では、SaaSというビジネスモデルの特徴や本質は何だろうか?

この問いに自分なりに考えてみたら、複数の特徴があるように思う。

【2】SaaSはScrumと相性が良い。
たとえば、パッケージ製品ビジネスや大量生産ビジネスでは、たくさん作って販売してそれで終わり。
一括請負契約で作って納品したら終わり。
顧客とメーカーは、クライアント-ベンダー-アンチパターンにはまりやすい。

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

一方、SaaSでは、常にサービスや機能を頻繁にVerUpしていく。
その頻度も1ヶ月に1回ではなく、1日に数十回もざらだ。
SaaSのインターフェイスは、ユーザがスマホやPCで触っているので、すぐにその機能を試してもらえるし、彼らの要望を即座に反映するほど、顧客満足も高まる。
そういうニーズがあるので、頻繁なリリースを実施する動機づけになる。

その場合、社内の開発体制はScrumに似せると開発しやすくなる。
マーケティング担当者や経営者がプロダクトオーナーの役割を担えば、社内に開発チームとスクラムマスターを作れば、即座にScrumが出来上がる。
SaaSの場合、プロダクトオーナーに相当する人が社内に存在し、その能力を持ち合わせている時も多いのがメリットだろう。
その後は、会社の規模やビジネスの規模に合わせて、Scrumをスケールすればいい。

【3】SaaSはDevOpsと相性が良い。
リリースしたら、その後も運用し続けるので、開発と運用保守は一体化すべき流れになる。

一方、普通のSIであれば、インフラチームと開発チームは分離されていて、機能別組織になりやすい。
機能別組織の弱点は、チームや組織ごとに体制の壁ができてしまい、意思疎通が困難になることだ。
コンウェイの法則「アーキテクチャは組織に従う」によって、システムのアーキテクチャは縦割りの複雑な組織構造を反映した形になってしまい、システムはどんどん複雑化してしまう。

もちろんSaaSも、ビジネスが発展すれば肥大化するだろう。
しかし、開発と運用保守は一体化した方がいいというビジネス要求や現場からの要求が出てきやすいので、DevOpsを推進する動機づけになる。

もちろん、技術的にも、SaaSはクラウドと相性が良い。
だから、クラウドエンジニアはインフラエンジニアだけでなく、開発者でもありうるので、事実上、インフラチームと開発チームは一体化しやすい。

また、ここからマイクロサービス・アーキテクチャも実装しやすい。
AWS上でSaaSを運用すれば、LambdaやAurora、AWSの各種サービスを利用することになるだろう。
単に性能改善やスケールメリットが活かせるだけでなく、システム基盤をマイクロサービスとして組み立て直すことにより、SaaSは汎用的なAPI基盤になっていくだろう。
そうすれば、外部サービスと連携できるので、より多種多様な機能を顧客に提供しやすくなるメリットも出てくる。

【4】SaaSはB2Cのプラットフォームビジネスと言える。

アメリカのGoogle、Amazon、Apple、Facebookがそうだし、中国のBATも同様だ。
多数の顧客に対し、プラットフォームを提供することで利便性がどんどん増していく。
そのビジネスの本質は、製造業が持つ規模の経済ではなく、ソフトウェア特有のネットワークの経済という理論が背景にあるはず。
たくさんのユーザが使ってくれるほど、SaaSは重要性を増して、売上を指数関数的増大させていく。
「プラットフォーム革命――経済を支配するビジネスモデルはどう機能し、どう作られるのか」を読むと、プラットフォームのビジネスモデルは独占ビジネスなので、その売上は、そのサービスの市場規模と同等になるまで高められる。
つまり、市場規模と同等だから、小さい国家のGDPよりもはるかに大きな利益を得ることも可能。

SaaSはB2Cのビジネスなので、顧客のフィードバックをすぐに取り込みやすい。
ランダム実験やABテストも実現しやすいので、サービスやビジネスモデルを仮説検証しやすい。
つまり、SaaSでは、念入りに考え抜いた計画を作って数年かけてリリースするよりも、仮設を立てたら、複数のサービスを同時リリースして、ランダム比較化実験でその効果を測定した方が速い。

興味深いのは、米国や中国では、SaaSのトッププレーヤーはB2Cなのに、日本の楽天やモノタロウなどはB2B2Cというスタイルで異なる点だ。
もちろん、LINEのように、日本国民の殆どとつながっていて、その連絡先とつぶやきのようなログデータを既に持っている会社はB2Cだ。
しかし、日本で目立つSaaSプレーヤーはB2Bのクッションを通過した後でB2Cを提供するビジネスモデルが多いように思える。
その理由は分からないので、いつか知りたい。

プラットフォーム革命の感想~プラットフォーム企業は新たな独占企業である: プログラマの思索

規模の経済と経験曲線効果のメモ: プログラマの思索

【5】SaaSでは、大量のログデータがビジネスの副産物として採取される。
データはいくらでもある。
そこから、機械学習やディープニューラルネットワークに大量データを食わせることで、優れたAIエンジンを生み出すことも可能だ。
B2Cのプラットフォームビジネスでは、ユーザの個人情報は特定できるし、その購買行動はプラットフォーム上で全て追跡できる。
よって、ペルソナを仮想的に作って、より購買を促すようなプロモーションを打ち出して、潜在ニーズを掘り起こせる。

「告発 フェイスブックを揺るがした巨大スキャンダル」によれば、Facebookで、個人に68個のいいねがあれば、その人物に関する非常に具体的な情報をモデルから予測できる。
70個のいいねで、そのユーザの友人が知るよりも、その人の多くの個人情報がモデルから推測される。
150個のいいねで、親よりも、その人の多くの個人情報がモデルから推測される。
300個のいいねで、パートナーよりも、その人の多くの個人情報がモデルから推測される。
さらにその多くのいいねを見れば、ユーザが自分自身について知っていると思っている以上の個人情報がモデルから推測される。
つまり、個人の大量のログデータを収集できれば、その個人を丸裸にできる。
その個人情報を他人が知っている情報だけでなく、その個人自身が知らない潜在ニーズまで推測できるわけだ。
すなわち、ジョハリの窓という理論は、AIを使えばほぼ完全に実現できる可能性があると思う。

(それを悪用したのが、ケンブリッジ・アナリティカであり、彼らは、どの個人にどんなプロモーションを送ればどんな選挙行動に移してくれるか、を徹底的に研究して、トランプ効果や英国のEC離脱を生み出したわけだが。)

そんなことを考えると、SaaSは機械学習やニューラルネットワークと非常に相性がいい。
だから、テスラみたいに製造業もどんどんSaaSにシフトしているのだろうと思う。

| | コメント (0)

より以前の記事一覧