以前に書いたのが6年も前になっていたので、最近聞いているポッドキャストについての更新エントリー。6年前から変わったものも変わってないものもあり。英語のポッドキャストが多めです。

Planet Money : NPR

名前の通りマネー・経済系を中心にワントピック20分程度を一話にしたPodcast。話の範囲が幅広く豊富で、また時々出てくる「やってみた」系のネタ「ジャンク債を買ってみた（そして紙くずになった）」「原油を買い付けて製油して売るところまで頑張った」、グッズ販売までしている「MARVELのスーパーヒーローを買い取るぞ！」みたいなのが楽しい。また「夕食の席で死について話す街」なんていう日本でも考えたくなるエピソードもある。

英語の発音もクリアだし、難しい単語もそこまで多く出てこないので分かりやすい。手軽な長さ、かつ話題が豊富で飽きないこともあり英語ポッドキャストを試しに聞きはじめてみたいという人にもよいと思う。新型コロナやウクライナ情勢などの時事ネタを経済面からタイムリーに解説してくれるのもよい。お勧め。

Radiolab

これも以前からずっと聞いているPodcastで、米国ではラジオ放送もされている有名な番組。番組として作られていることもあって話し方や構成、音楽のエフェクトなども凝っていて、活劇的で楽しく聴きやすい。扱う話題も科学、歴史、人物、経済、芸術、などなど幅広く、Planet Money よりも長尺な分だけトピックを掘り下げてくれる感がある。

大体週に1回更新で30分から1時間くらいの長さ。ストーリーとしてまとまっているので、ちょっと長めの時もあるけど一度で聞き切るのがおすすめ。ラジオ番組として始まってからちょうど20周年だそうですよ。

TED Radio Hour : NPR

TEDの数多いトークの中から、なにかしらテーマを決めて4,5エピソードをピックアップし、トークの一部を切り出しつつ解説も含めてまとめてくれる。TEDはとにかく種類が多くて個人的興味からのあたり外れもあるので、こうした公式まとめがあるのはありがたい。

トータルだと1時間くらいのポッドキャストなのでちょっと長いが、エピソードが分かれているので個別に聴くつもりであればさほどの負荷ではない。タイトルを見て気になったテーマの時に聴くのにも向いていそう。

Trash Taste Podcast

以前聴いていたStill Untitled; が終わったので代わりに聴き始めたアニメ・マンガ・オタク系ポッドキャスト。レギュラーは有名アニメ系Youtuberの3名。アニメの話題だけではなく、日本文化と英語圏文化の差異や違和感などもよく扱われていて、なるほど日本はこう見えているのね、と言うのも楽しめる。

構成は 3名のホスト＋αで、皆が一斉にわちゃわちゃ話すほぼ完全フリートークかつ割り込みや笑い声も多く、全般的にかなり聞きづらい。が、英語での趣味の雑談や飲み会の会話ってこういう感じなので、雑談聞き取りの練習を兼ねるのもありかもしれない。

Dan Carlin’s Hardcore History

歴史もの大作ポッドキャスト。某Slackで教えてもらった。1話が数時間から長いものだと5時間を超える超ヘビーウェイトの構成だが、歴史の語り口調がとても上手で、各種文献の引用含めて内容もよく練られているのがすごい。世界史好きならばまず興味深く聴けると思うのでお勧めしたいが、とにかく長いので聴くのには気合と時間が必要。Serial みたいに分割してくれてもいいんだけどな。

The Naked Scientsts Podcast

サイエンス系ポッドキャストは数多いので色々聴いて好きなものを選ぶのが良いと思うが、個人的にはこのポッドキャストが割と好みでよく聴いている。トピックは物理・化学・地学・生物などなど様々で、基本的に科学者個人へのインタビューを中心にした構成になっている。扱う話題もトレンドにかかわらず幅広く、こんな研究をしている人もいるんだなと言う自分の知らない科学の話題に触れられるのが楽しい。

週1度更新で約1時間弱。電話インタビューの形をとるのと、話をするサイエンティストが必ずしもPodcast向けの話し方をしてくれるわけじゃないので、たまにリスニングがしんどい時もある。

Misreading Chat

森田さんと向井さんによる、Computer Science の論文を読んでなるほどって感心するPodcast。これを聴いていると本当にCSの世界は広くて深いなと思うし、その一端に触れられるこのPodcastは大変ありがたい。CSはIT業界と地続きなので、あの技術の裏にはこんな研究や試行錯誤があったんだ、というのが身近に感じられて興味深い。

1本だいたい40分前後で、たまに1時間くらいの長さになることもある。しばらくお休みしていたが最近再開されたようで大変嬉しい。

texta.fm

ピクスタCTOの @_yasaichi さんがホストで、@t_wada さんと主にRuby On Railsを軸にプログラミング・ソフトウェアアーキテクチャの話題を扱っている。_yasaichi さんの話題の振り方と、そこへの t_wada さん解説の切れ味が素晴らしい。

現在のプログラミングトレンドを過去の経緯を話してくれるので、上の年齢の人には「〇〇年代にこれをやっていた業者がたくさんいましたが彼らは全て消えました」みたいなあるあるネタがほっこりする。ウェブ系プログラミングの話題と見せかけて t_wada さんからはエンタープライズ系の話題もよく出てくるのでそうした点でも興味深い。本職がお忙しいようで更新頻度は低いけど新作が出ると楽しみに聴いてる。

Subcscriptions List に入っているその他の Podcast

リストに入れているけど定期的には聴いておらず、トピックを見てたまに聴いているもの。解説は簡潔に。

• a16z podcast
  a16z として著名な Andreessen Horowitz 企画のPodcastで、大企業の創業者・CEOクラスが登場することも多い。ちょっと意識高いなと思いながらたまに聴く。
• Serial
  連続殺人もののストーリー仕立てPodcast。1つのトピックを複数の回で扱う。話題が重たくて長いので気合を入れて聞かないと聞けない感あり。作り自体はよくできていて面白い。
• Stuff You Should Know podcast
  テック、ソーシャルからドラッグまで幅広く扱うPodcast。独特の雰囲気がある。
• BBC World Service - The Science Hour
  BBCの提供するサイエンスニュース。旬の話題が多いのでニュースを追いたい人はこっちが良いかも。
• Science Friday
  これもサイエンス系Podcast。生物や医学系のネタが多めな印象。COVIDトピックが充実していたので一時期はよく聴いていた。
• Tech Break - Twit
  ガジェット系ニュースの短めPodcast。ガジェット系でAppleに偏らないPodcastをあまり見つけられてないので良いのがあったら教えてください。
• Clockwise
  Tech系トピックを2人のホストと2人のゲストで語るPodcast。1本30分弱で軽く聴きやすい。
• Decode with Nilay Patel
  The Verge のチーフエディターによるPodcast。Tech企業系のトピックが多く、こちらも The Verge 主催だけあってゲストが結構豪華。
• Turing Complete fm
  @rui314さんによるプログラミング、それも結構低レイヤー(コンパイラ、リンカ、OSなど)の話題が多いPodcast。大変面白いし個人的には難しいけど何とかわかるレベルの話題で勉強になってたけど、更新が止まって久しいのが残念。

リストにあるのはこれくらいかな。

Podcast クライアント

参考までに、Podcastクライアントは以前と変わらず Android の Podcast Addict が主。Podcast Addict は 別アプリから直接操作をするIntentsが公開されているので、Bluetooth ヘッドセットが接続されたのをトリガーにTaskerから即座にPodcastの続きを再生する、等ができるのが便利。アプリとしてもまだ更新が続いているし、機能としても特に不満がない。

最近の人たちは Apple Podcast や Spotify で聞いているんですかね?

Shockz OpenComm の右こめかみ部分についているマルチファンクションボタン、これにTeamsなどのテレビ会議アプリのミュートを割り当てたい。標準だとミュートは音量＋とーの同時長押しで、かつこれはデバイスのミュートなのでアプリと連動してくれない。残念ながらShockzにはキーのカスタマイズ機能がないため、Autohotkey を使ってWindows側でキーコードの動作を切り替える。

Shockz OpenComm はとても評判の良い骨伝導型ヘッドセットで、耳を直接ふさがないので長時間の電話会議でも耳が痛くならず、音質も会議の用途なら良好で、ノイズキャンセリングもあるのでリモートワークに大変役立っている。

このOpenCommにはマルチファンクションボタンというハードウェアキーがついていて、電話着信・切断や音楽再生・一時停止などシーンに応じた機能を提供してくれるのだけど、テレビ会議で頻繁に使う「ミュート / アンミュート」のトグルがアサインされておらず、ミュートは「音量+/-キーを両方長押しする」などと言う非常に使いづらい操作にアサインされている。

Autohotkey をつかってキーコードをWindowsでの別の動作に割り当てていくのだが、まずはOpenCommがなんのキーコードを飛ばしてきているかを確認する。Autohotkeyの使い方にはここでは触れないので各自検索ください。

• 適当なファイルに #InstallKeybdHook を記載してAutohotkeyとして有効化。
• 有効化したAutohotkeyのウィンドウを開く（タスクバーのアイコンからOpenするなど）
• ウィンドウのメニューから View ⇒ Key history and script info を開く
• OpenComm のマルチファンクションボタンを押し、どのキーコードが飛んできたか確認

Teams 会議中にボタンを押すと Media_Play_Pause が飛んできている。HSPだと思っていたんだけど、AVRCPとして操作している様子。

これが分かれば後は Media_Play_Pause をキーにした Teams の Mute Toggle を Autohotkey に記載すればいい。

TeamsMuteByOpenCommBtn.ahk:

Media_Play_Pause::
WinActive, ahk_exe teams.exe
Send, +^m
return

#z::Reload
return

このスクリプトでは以下の処理を行っている。

1. Media_Play_Pause が送られてきた際に
2. teams.exe のウィンドウをアクティブにし
3. Teamsでのミュートのショートカット (Ctrl + Shift + M = +^m) をアクティブウィンドウに送信

これで概ね機能していてミュートの切り替えが OpenComm のマルチファンクションボタンで出来るようになった。

ただ使っていると、会議開始直後などでキー操作を取りこぼす事がたまにある。似たような操作を F1 キーに割り当てた際も取りこぼしが発生したので、恐らくはAutohotkey側の問題なのかと思う。とは言えさほど気になるほどの頻度でもないし、ヘッドセットのハードウェアキーでミュート切り替えができるのはやはり便利である。

上記設定はとりあえず OpenComm と Teams の組み合わせで使えるものなので、他のヘッドセットと会議システムであれば別の記載が必要になるだろうが、上記手順をいじれば概ね簡単に実現できると思うので各自チャレンジして頂ければ。

追記: AutoHotKey 2.x ではフォーマットが変わったようで以下のように変更した。

Media_Play_Pause::
{
WinActive "ahk_exe teams.exe"
Send "+^m"
return
}

#z::Reload
;return

DXを進めたいと思う企業はコスト削減をゴールにしてはいけない。DXによる新たな収益の創造や経営判断のアジリティなど、将来価値に向けて投資するべきである。

企業がDXを進める際にコスト削減をゴールにしてしまうと、DXの効果の最大値が現行コストで頭打ちしてしまう。つまり、DXには現行コストの更にその一部しか投資が出来なくなる。本来のDXは新規事業の開拓による新たな収入の創出や、経営判断にアジリティをもたらすと言った、現在持ち得ていない将来価値に向けて投資すべきもの。コスト削減をゴールにするとやれることが大幅に狭まる。

なおかつ、ITでのコスト削減と言うのは概ね人員削減なので、これを続けると会社から人が減り、企業として新しいことをする体力が無くなってしまう。DXで新たな収益開拓をしようという目的に対して、これでは真逆の結果になってしまう。

なのだが、現実にはこれは結構難しい。コスト削減と言うのは成果をコミットしやすく測定も容易だが、将来価値の創造と言うのは少なくとも現場レベルではコミット出来ない。つまりこれは経営判断でやるしかない。また事業が新たな収益を生んだとして、それがDXによる効果かどうかは自明ではない。こうした問題を乗り越えるには、経営者がDXで実現できる未来を理解し、確信をもって投資し、先頭でDXの旗を振るリーダーシップを発揮する必要がある。

• 攻めのITを成功させるためには「経営者の確信」が必要不可欠 - W3er

ところが日本企業は往々にしてITのエキスパートが経営層に居ない。ITの力を確信できていない経営者は、現場がコミットする案件にしか投資判断ができない。そして現場がコミットできるのはコスト削減くらいしかない。欧米企業のCxOはITに詳しくないまでもITのもたらす利益は体験済みだったりするが、IT化が遅れている日本企業の生え抜きの経営陣はそうした体験もないのでITへの確信が持てていない。

歴史的に見ても、欧米の労働者と比べて日本の労働者は現場の工夫と苦労で一定以上の品質に仕事を仕上げてしまうので、そうした現場回りのIT化が思ったほどの効果にならない、という原体験が経営者にある。つまりITよりも人間の方が安かったので、日本企業の経営者は合理的判断としてIT投資よりも人手による作業を選んできた経緯がある。

一方で欧米企業ではそもそも現場の作業員はそこまできちんと働かない。例えばこれは2008年のComcast、全米最大のCATV及びインターネットプロバイダーの窓口対応である。

• Comcast との長い戦いの記録 - World Wide Walker

こうした状況はそれこそITの導入により2015年頃にはかなり改善された。改善されたがしかし、それでも日本のカスタマー対応レベルには及んでいないのである。つまり米国企業にはITを導入しなければならない切実な理由があり、一方の日本企業は現場の労働者がそれより高いレベルまで人力でどうにかしてしまってきたという歴史がある。

当初のITは人間の仕事の置き換えや人間の作業の支援だったので、人間が安く、また複雑な作業も身に着けられるならば人間を使う判断もありだった。だがしかし、今のITは人間が出来ないレベルの巨大なデータを高速に処理して迅速なビジネス判断を提供するものになっている。遅いからと言って乗らなかった船が、今は高速ジェット機になっている。

なによりソフトウェアにはビジネス上最強の武器である「後出しジャンケン」、つまり「売った後に商品を改善する」ことが可能なので、市場競争力的に圧倒的に優位に立てる。これを使えない企業の立場は非常に厳しくなる。DXとはそもそも「シリコンバレーの企業の真似をすることで彼らとなんとか競争できる立場に持ち込む」のが本来の目的で、そのためにはソフトウェアの力を活用しないといけない。

日本企業も遅ればせながらジェット機に乗り換えようとしているのだろうが、今まで乗っていた自転車からジェット機へ買い替えるには当然ながら巨大なコストがかかる。DXの進んだ企業が10年かけて段階的に払ってきた費用を、DXが遅れた企業は一括で払わなければならない。ここで投資額が大きくなると当然ながら「費用対効果」を正しく理解し、株主を含めたステークスホルダーに説明しなければならなくなる。かつ、この新しいジェット機のパイロットがいない。これも育てていなければ外から雇わなければいけない。

つまりだ、DX投資の金額はコスト削減だけで説明するにはとても足りない規模に巨大化しており、将来価値に向けての投資を説明できないといけないのだが、巨額の投資を正当化するのに確実なのはコスト削減の方であり、将来価値を理解し、説明し、決断するのは非常にハードルが高い。ましてや日本の経営者には、前述のとおりITの専門知識が足りてない企業が多い。

……どうするといいのか。一応、方法はある。ITの利益を深く理解した経営者を雇うのだ。例のやたがらす人材、これを期待するなら経営陣、しかも最低でも副社長クラスの全社判断に直接指示を出せるところに置くべきなのだ。日本企業がそうした人事をできるのかという不安はあれど、やらなければどろ船で飛行機を追いかける競争を続けることになるだけだ。他企業、特にグローバル企業は待ってはくれないのだから。

個人グループのメーリングリストをここしばらく mailman で運用しているのだが、ある日いつものように apt update & upgrade をかけたら気づかぬうちに mailman (2.1.29) が uninstall されていて大変困ったことになった。多分 python2 を抜いたタイミングだろうか… 見ると mailman3 という新しいパッケージがあるのでこれを入れれば戻るかなと思ったが、そんな簡単な話ではなく、ほぼ最初からの導入設定が必要だったので、備忘録として記録しておく。

なお導入と移行は一応本家にドキュメントがあるにはあるが、英語だという事を差っ引いても分かりにくい。

• https://docs.mailman3.org/en/latest/config-core.html
• https://docs.mailman3.org/en/latest/config-web.html
• https://docs.mailman3.org/en/latest/migration.html

Mailman3 の導入

インストール自体はいつものように apt で終わり。

# apt install mailman3-full

同時に導入される mailman3-web のデータベースは標準のsqlite3を選択。特に普通のSQLサーバを使う規模でもない。

インストールが終わったらまずは mailman3 の基本設定。以下、example.com は自分のドメインに置き換えてください。

/etc/mailman3/mailman.cfg

site_owner: xxx@example.com

ここには自分のメールアドレスを入れておく。続いて mailman3-web の設定も修正。

/etc/mailman3/mailman-web.py

EMAILNAME = 'example.com'

https が使えない場合は ACCOUNT_DEFAULT_HTTP_PROTOCOL を “http” にしておくとよい。

また恐らく mailman の設定が /etc/cron.d/mailman に残っているのでこれは消しておく。

Postfix の設定

メーリングリストなので、メール配送周りを色々と調整しないといけない。mailman2 は /etc/aliases で配送アドレスをコマンドに転送していたので、まずは /etc/aliaces の記載を削除し、 # postalias /etc/aliases で更新しておく。その上で postfix の設定を変えていく。

/etc/postfix/main.cf にこんな記載を追加・更新

# Mailman configrations adding lmtp
unknown_local_recipient_reject_code = 550
owner_request_special = no
transport_maps = hash:/var/lib/mailman3/data/postfix_lmtp
local_recipient_maps = proxy:unix:passwd.byname $alias_maps hash:/var/lib/mailman3/data/postfix_lmtp
relay_domains = ${{$compatibility_level} < {2} ? {$mydestination}:{}} hash:/var/lib/mailman3/data/postfix_domains

配送先や relay の書き換えをしているので、postfix 再起動後はきちんとログを見たりテスト配送しておかしな影響が出ていないことを確認したほうがいい。私の場合は local_recipient_maps や relay_domains が上書きされてしまい、以前に入れていた設定が無効になるというやらかしがあり、あわてて修正した。

apache2 の設定

mailman3-web を利用するためにウェブサーバ側の設定も必要。ここでは apache を使っている。mod_proxy_uwsgi を有効化。

# a2enmod proxy_uwsgi

続いてapacheにmailman3-webのURLを解釈させるよう、設定を持ってくる。名前は何でもいいんだけど分かりやすいように。

# ln -s /etc/mailman3/apache.conf /etc/apache2/conf-enabled/mailman3.conf

Debianのmailman3-webパッケージで導入されるこの設定ファイルには何故か不具合が残ったままらしいので修正しておく。localhost/ の最後についているスラッシュを削除するだけ。

ProxyPass /mailman3 unix:/run/mailman3-web/uwsgi.sock|uwsgi://localhost

ここまでやったら postfix, apache, mailman3 のサービスをそれぞれ再起動しておく。一応これでセットアップ自体は完了。

Mailman (2.x) から Mailman3 へのメーリングリスト移行

幸いなことにメーリングリストのデータ移行コマンドは提供されているのでそれを使う。まずは元々あったメーリングリストを新たに mailman3 で作成し、そのリストにデータをインポートする。なお LIST-ID は各々移行したいリストに読み替えたうえで、移行するリストの数だけ下記作業を繰り返し行う。

# mailman create LIST-ID@example.com
# mailman import21 LIST-ID@example.com /var/lib/mailman/lists/LIST-ID/config.pck

メールアーカイブも移行したいのであれば mailman3-web に含まれるコマンドを使って移行する。

# cd /usr/share/mailman3-web
# python3 manage.py  hyperkitty_import -l LIST-ID@example.com /var/lib/mailman/archives/private/LIST-ID.mbox/LIST-ID.mbox
# python3 manage.py update_index_one_list LIST-ID@example.com

ここまで root で作業しているのでおかしくなっている permission を修正する。これをやらないとログにエラーも出ずにメール配送がひたすら内部で bounce して retry していたりするので気づくまで厄介だった。

# chown list:list /var/lib/mailman3/lists/ LIST-ID.example.com
# chown list:list  /var/lib/mailman3/template/lists/LIST-ID/ja/

これで一応の移行までは完了しているはず。

mailman3-web のウェブインターフェイス側での設定

mailman3 ではフロントエンドを postorius という django ベースのサービス上で構築している。なので django としてのサイト設定など、セットアップの範囲が多少広い。

まずは django / postorius の管理ユーザを作成する

# cd /usr/share/mailman3-web
# python manage.py createsuperuser

ここで管理ユーザのアカウント名、メールアドレス、パスワードを入力してCLI側の作業は一旦完了。ウェブサイトの方にアクセスして設定を継続する。

• https://example.com/mailman3/

にアクセスすると、apache の設定がちゃんとできていれば postorius の画面が立ち上がるのでログインする。なおログイン時には登録したメールアドレスに確認メールが来るので、一旦そちらのメールを開いて確認リンクをクリックすることでアクティベーションを完了する。

ログイン後、上部メニューの Domains からデフォルトドメインを自分のドメインに変えておく。一覧にある SITE_ID = 1 のドメインが example.com になっているはずなので、この隣にある Edit リンクから Django Administration サイトに入って自分が使うウェブサーバのFQDNに書き換えておく。これで一旦完了。

mailman-web からのリスト管理

これで mailman-web も問題なく使えるはずなので、後は List 管理から移行されたメーリングリストのメンバーリストが正しく移行されているかなどを確認しておくとよい。mailman 2.1 に比べてもかなり細かく設定ができるし使い勝手もよくはなっているが、とは言えさほどいじるものでもないかと思う。

かなり間が空いてしまったが、生産性を上げたいならまずその「検討」を止めよ の続きとして、ならばどうやったら「検討」を止められるのかを考えてみたい。

基本的に検討はなんらかの判断をするために行うものなので、「判断」が行われた時点で検討が終了する。であれば判断はどうしたら迅速に行うことができるのか。それに必要な3つの要素は「情報」「専門知識」「裁量」である。判断をするために必要な材料が情報、判断をするための能力が専門知識、組織の中で判断を承認させるための権限が裁量、という形になる。

大事なのは、この「情報」「専門知識」「裁量」を同一人物が持ち合わせること。外からもらえる情報はともかく、専門知識と裁量は同じ人物の中に同居している必要がある。つまり無駄な検討を止めて迅速な判断を行うには裁量を持つ意思決定者が十分な専門知識を持っている必要がある。

多くの場合の判断は未来に対して行うものだ。未来は未知なものであり、未来を判断する情報が全て揃っていることはまずない。そうした状況でも判断するために必要なのが専門知識だ。専門知識によって「明確に劣る選択肢」や「非現実的な選択肢」は即座に破棄できるし、追加検討に何が必要なのかも指示として明確に示すことができる。

日本に限らずどの国でも上級管理職になるほど現場に近い専門知識からは距離が開いてしまうものではある。しかしながら体系だった専門知識を更新するのは不可能ではないし、事実海外の管理者はかなりの量を勉強に費やしている。そもそも専門知識なしに判断するのは非常に困難なのだから、専門知識は必要に迫られて身に着けるものなのだ。

企業における専門職経営層の重要性

多くの国の海外企業では昨今、C-タイトルの種類が増えている。C-タイトルは CEO、Chief Executive Officer (最高経営責任者) のように、ある業務領域での経営トップを示す呼称だが、旧来からある CEO, CFO, CTO, CIO, COO など以外にも、最近は CSO (Strategic), CMO (Marketing), CCO (Communication), CHRO (Human Resource) などなど、C 付きの役職が増えている。

• List of corporate titles - Wikipedia

これは内部の昇格や外部からよい人を取るために待遇と見栄えの良い新しいポジションを作っている事情の企業もあろうが、本質的には経営層レベルに業務領域に応じた専門職が必要になっているという事でもある。各業務の専門性が深まってきており、一人の経営者が全ての専門知識を身に着けて意思決定するのが難しくなっているのだ。

専門経営職の必要性は CFO が分かりやすいかもしれない。CFO を置いている企業で、社長や副社長がCFOを兼ねることはあまりない（もちろんCFO専任の副社長はいるだろうが）。CFOは財務や会計に関するスペシャリストであり、その道の専門知識とキャリアが必要だと認識されているからだ。日本でも恐らく財務担当の上級職は財務畑のキャリアを積んできた人が多いだろう。ところがこれが CTO や CIO になるとそうした認識が薄くなり、副社長等がそうしたCタイトルを数多く兼務している企業もある。

現代のビジネスにおいて専門知識は深化を続けているが、そこには企業経営にITシステムが浸透してきたことが関係している。ITシステムにより、今まで個人の暗黙知やノウハウで行われてきた様々な業務、例えばマーケティング、人事、財務、会計、営業、等々がシステムに実装されることにより形式知として可視化されたのだ。形式知はこれまでのように人間の転職や退職によって消滅せず、よりよい方法を模索しつつ深化していく。この深化についていくために、人間側も個別の業務領域ごとの専門知識を深める必要が高まってきているのだ。

ここでの専門知識とは「20年前はこうだった」や「私の経験からいうと」などという不確かなものではない。専門知識は形式知であり、体系だった学問であり、大勢が業務の中で知識と経験を積み上げたプラクティスの上澄みであり、業界で用いられる標準的なフレームワークである。これは業務経験があれば必ずしも身につくものでもなく、自発的に体系を学ぶことが必要なものが多い。業務からは業務で扱っている事象しか学べないからだ。

特に IT で言えば、情報技術に関する「基礎技術」と共に、また業界の「ベストプラクティス」と呼ばれる知識のライブラリを踏まえることが多い。つまり IT に関する判断には、自身のビジネス現場を理解しつつ、ITが適用される業務ドメインに対して、業界標準に照らしてベンチマークするだけの知識と手法が必要になる。

これは CIO についてのみの話ではなく、他の Cタイトルについてはこの条件が反転する。つまり今の意思決定レベルの人たちは、自身が担当する業務領域の専門知識に加えて、それが駆動するITシステムについての知識もある程度必要になるという事だ。

日本企業における課題としての「プロの不在」

翻って日本企業を見ると、流石に最近はジョブ型だの言われ始めていて専門性の高いキャリアも効力されるようになってきているが、相変わらずジェネラリスト育成を主眼においた定期人事異動をしている企業も少なくないのではなかろうか。まして残念なことに、専門知識のない管理職は再生産される。何故ならいま管理職をやっている専門知識のない人たちは、専門知識がある人をきちんと評価できないからだ。

日本企業、特に大企業における謎の風習に、人事異動時の挨拶がある。「全く新しい業務なので慣れるまで皆さんにご迷惑をおかけするかもしれませんが」というあれだ。若手の担当社員ならともかく、課長職や部長職、下手するとそれ以上の経営層に近い職ですらこうした挨拶を聞くことがある。謙遜されているならばまだしも、実際に未経験の業種に移動させられる管理職は決して少なくないだろう。

これはつまり、その分野の素人が意思決定の責任を負わされているという事だ。別にそうした人たちを責めたいわけではない。彼ら・彼女らもつまるところ制度の被害者なのだから。しかしそれ以上に悲劇なのは、そうした管理職の下で働く人たちだ。そうした人たちは、つまるところ前出の「意味のない利益に結び付かない無限の検討」を続けることになるのだから。

ここから脱する手段は明らかだ。意思決定者に専門知識を持たせる。そのためには企業としてのキャリアパスを見直す必要もあるだろう。意思決定者層に向けた教育プログラムも見直すべきだ。また手っ取り早く会社を変えることを考えるならば最初の経営層専門職は外部から雇用することも必要だろう。専門性のない上司は専門性の高い部下を評価できないので、トップ層に専門職がいることは非常に重要になる。

まとめ

無駄な検討を止めるため、迅速に意思決定を行うためには、「情報」「専門知識」「裁量」が意思決定者に集中することが望ましい。このなかでも外部から与えるのが難しく、意思決定の礎になるのはその判断領域に関わる「専門知識」である。

業務の専門性が深化した現代では、専門知識なしに意思決定をするのはほぼ不可能になっている。特に日本の大企業がよくやるようなジェネラリスト育成、専門性のない人を上級管理職として配属するような人事はやめるべきだ。またとっかかりを作るためにも経営レベルの専門職者が存在すること、いないなら外部から採ることが必要になる。