DeepResearch っぽい Research-mini を作ってみる

研究職に話題な DeepResearch ですが、簡易的なものであればさっくりと作れます。というテストです。

「さっくり」とは言いましたが、それなりに OpenAI API の作り方を知っていないとうまくいかないとは思うのですが、まあ、そのあたりも ChatGPT やら Copilot やらを使えばなんとかなります。

ざっと方針を決定する

この手の調査はよくやる話なので、人間がやっていることを AI に任せればokです。

  • キーワードを入れて、関連する WEB サイトを探す
  • WEB サイトの要約を表示する

の2段階があれば十分でしょう。実際、Google とかでキーワードを入れて一覧を作ってから、ぽちぽちと WEB サイトに飛んで、ページをコピペした後に要約するのはよくやる作業です。実に面倒くさいのですが、AI ならなんとかやってくれます。きっと。

ChatGPT に尋ねる

いきなりコード生成するのもよいのですが、ひとまず概要を伝えてみましょう。第一段階のキーワードにマッチするようなWebサイトを探して貰うコードを作ります。

テーマを指定すると、関連する WEB サイトの一覧を取得するコンソールツールを作って。

実は、この時点では Google で検索するコードを Python で出してくれます。確かに Google でもいいのですが、ここは OpenAI API を使ってもらいましょう。

openai API を使う書き方に直して。

OpenAI の gpt-4 モデルを使った Python コードに直してくれました。ただ、私の場合は .NET でやりたかったので、C# に書き直して貰います。

C# のコードに直して。

この時点で、かなり動くコードがでてきます。

class Program
{
    private static readonly string apiKey = "your_openai_api_key";

    static async Task Main(string[] args)
    {
        if (args.Length == 0)
        {
            Console.WriteLine("Usage: dotnet run <theme> [-n <number_of_results>]");
            return;
        }

        string theme = args[0];
        int numResults = 10;
        
        if (args.Length > 2 && args[1] == "-n" && int.TryParse(args[2], out int parsedNum))
        {
            numResults = parsedNum;
        }

        Console.WriteLine($"Searching for: {theme}\n");
        var results = await SearchWeb(theme, numResults);

        if (results.Count > 0)
        {
            Console.WriteLine("Related Websites:");
            for (int i = 0; i < results.Count; i++)
            {
                Console.WriteLine($"{i + 1}. {results[i]}");
            }
        }
        else
        {
            Console.WriteLine("No results found.");
        }
    }

    static async Task<List<string>> SearchWeb(string theme, int numResults)
    {
        using HttpClient client = new HttpClient();
        client.DefaultRequestHeaders.Add("Authorization", $"Bearer {apiKey}");

        var requestBody = new
        {
            model = "gpt-4",
            messages = new[]
            {
                new { role = "system", content = "You are a helpful assistant." },
                new { role = "user", content = $"List {numResults} websites related to {theme}." }
            }
        };

        string jsonRequest = JsonSerializer.Serialize(requestBody);
        var response = await client.PostAsync(
            "https://api.openai.com/v1/chat/completions",
            new StringContent(jsonRequest, Encoding.UTF8, "application/json")
        );

        if (!response.IsSuccessStatusCode)
        {
            Console.WriteLine("Error: Unable to fetch search results.");
            return new List<string>();
        }

        string responseContent = await response.Content.ReadAsStringAsync();
        using JsonDocument doc = JsonDocument.Parse(responseContent);
        var content = doc.RootElement.GetProperty("choices")[0].GetProperty("message").GetProperty("content").GetString();

        var results = new List<string>(content.Split('\n', StringSplitOptions.RemoveEmptyEntries));
        return results;
    }
}

プロンプトで「iBeaconのフォーマットについて」で検索させるとこんな感じです。

URLが出てくるので、これをピックアップするためのコードを Copilot に書いて貰いました。

    static List<string> ExtractUrls(List<string> results)
    {
        var urlPattern = new Regex(@"https?://[\w./?=&-]+", RegexOptions.Compiled);
        return results.Select(result => urlPattern.Match(result).Value).Where(url => !string.IsNullOrEmpty(url)).ToList();
    }

あとは、URL を読み込んで要約を出すわけですが、これも Copilot を使っています。

    /// <summary>
    /// URLを指定したら内容を要約して返す関数
    /// </summary>
    /// <param name="url"></param>
    /// <returns></returns>
    static string Shlink(string url)
    {
        using HttpClient client = new HttpClient();
        client.DefaultRequestHeaders.Add("Authorization", $"Bearer {apiKey}");

        var requestBody = new
        {
            model = "gpt-4",
            messages = new[]
            {
                new { role = "system", content = "You are a helpful assistant." },
                new { role = "user", content = $"Summarize the content of the website {url}." }
            }
        };

        string jsonRequest = JsonSerializer.Serialize(requestBody);
        var response = client.PostAsync(
            "https://api.openai.com/v1/chat/completions",
            new StringContent(jsonRequest, Encoding.UTF8, "application/json")
        ).Result;

        if (!response.IsSuccessStatusCode)
        {
            Console.WriteLine("Error: Unable to fetch search results.");
            return "";
        }

        string responseContent = response.Content.ReadAsStringAsync().Result;
        using JsonDocument doc = JsonDocument.Parse(responseContent);
        var content = doc.RootElement.GetProperty("choices")[0].GetProperty("message").GetProperty("content").GetString();

        return content ?? "none";
    }

こんな風に関数を作ってもらって、それを main に組み込みます。関数を作って貰うときは、関数の定義(ここでは、static string Shlink(string url) の部分)を書いたあとに、関数の前にコメントを書くと Copilot が自動補完してくれます。

この操作は、ChatGPTのブラウザ上でやってもいいでしょう。私の場合 Copilot のほうが慣れているので、Visual Studio Code 上でやっています。

表示しているところを何回かに分けて書き直しています。

        Console.WriteLine($"Searching for: {theme}\n");
        var results = await SearchWeb(theme, numResults);

        if (results.Count > 0)
        {
            Console.WriteLine("Related Websites:");
            for (int i = 0; i < results.Count; i++)
            {
                Console.WriteLine($"{i + 1}. {results[i]}");
            }

            Console.WriteLine("urls:");
            var urls = ExtractUrls(results);
            urls.ForEach(url => Console.WriteLine(url));
            foreach (var url in urls)
            {
                var summary = Shlink(url);
                Console.WriteLine("--------------------");
                Console.WriteLine($"Summary of {url}");
                Console.WriteLine("\n");
                Console.WriteLine( summary);
            }
        }
        else
        {
            Console.WriteLine("No results found.");
        }

デバッグ動作も兼ねて、区切りを入れたり URL を表示させておきます。

注意)何回か動かすと openai API のリクエスト制限に引っ掛かるらしく TooManyRequests のエラーが返ってきます。いまテストしていたら引っ掛かってしまったので、また明日追記の予定。

こんな感じで、一発でプロンプトを使ってコードを出力するわけではなくて、ChatGPT や Copilot を使いながら何回か出力してコードを組み立てていく例です。コード自体は1時間ちょいぐらいで動くようになります。その後、何回かテストするの1時間ぐらいかかるけど。

実行例

そのままだと、OpenAI の回答が英語になるのですが、プロンプトを追加すれば英語から日本語に翻訳してくれます。

        var requestBody = new
        {
            model = "gpt-4o-mini",
            messages = new[]
            {
                new { role = "system", content = "You are a helpful assistant." },
                new { role = "system", content = "応答は日本語に翻訳して" },
                new { role = "user", content = $"Summarize the content of the website {url}." }
            }
        };

日本語訳

iBeacon の場合は企業サイトが多いので直接クローリングができないっぽいです。公開されている技術文書や論文とかだったらいけるんじゃないかな。

公開コード

https://github.com/moonmile/research-mini

カテゴリー: 開発 | DeepResearch っぽい Research-mini を作ってみる はコメントを受け付けていません

GitHub Copilot で iBeacon 発信ツールを作れる?

要は「GitHub Copilot x Python」本の宣伝記事です。自前のブログ記事だから自前の本の宣伝をしてもよいのですが、内容を紹介しているだけでは “私が” 詰らないので、もうちょっと先のところを書きます。

この書籍ではPythonを学ぶことになっていますが、実はGitHub Copilotを学ぶのが目的です。GitHub Copilotはコーディング時に適した生成AIで Visual Studio Code と Copilot を組み合わせて使います。昨今では、プログラムのコーディング時に生成AIを使う(ChatGPTとかGeminiとか)を使うことは普通になってきましたが、もう一歩進んでコーディングに適した使い方を学んでいこうというのが主旨です。なので、実はツールは問いません。この本ではGitHub Copilotを使っていますが Cursor とか他のツールでも構いません。

生成AIを伴ってコーディングをする

ChatGPTなどのツールをコーディングに使おうとしたとき、真っ先に考えるのは「○○のツールを作って」というプロンプトを使ったコード生成の仕方です。実際、簡単なゲーム(インベーダーとかブロック崩しとか)のコードは、これだけのプロンプトでも簡単に作ることができます。色を付けたり、音が付いたりするので、かなりの驚きを覚えるのですが、まあ、実際のところインベーダーゲームを作ったりブロック崩しを作ったりしたいわけではないので、その後が続きません。

最初に断っておくと、おそらくですが「ゲーム」のように閉じられた環境の場合には、このプロンプトの方式はかなり有効です。おそらく、同じパターンでロールプレイングゲームとかか未芝居型のギャルゲーとかもいけそうです。小学生向けのさんすうゲームとかもいけそうです。おそらく、小奇麗なショッピングさいととも可能かもしれません。

これはいわゆる巷にあるテンプレート的なものに対して生成AIのコーディング力が非常に強いためです。ある意味、プログラミングというものが既存のライブラリの組み合わせや、Webのユーザーインターフェース(HTMLとCSSの組み合わせとかアニメーションとか)のサンプルコードがインターネットにたくさん紹介されていて、それらのノウハウの蓄積が早いからでしょう。

ただし、この手の目的にぴったりのモノが出てくる場合はいいのですが、ぴったりのものが出て来ない場合はどうすればいいでしょうか?ひたすら生成AIに渡すプロンプトを工夫してコードを練り上げていく方がよいのでしょうか?

ひとつの方法として「何度もプロンプトを繰り返す」というのもあるのですが、もう少しプログラマらしい手法を取ってみましょう。というのが主旨です。なにも、全てを生成AIに任せるのではなく、生成AIに足りない部分は人が補い、逆に人に足りない部分(知識とか時間とか)を生成AIで補わせるという方法です。端的に言えば、生成AIとペアプロをするという方法です。

iBeacon を発信させる

GitHub Copilot の細かい使い方やPythonの文法などは先の本に任せるとして、ここでは先に進んでみましょう。

注)最初に書いておきますが、Windows 環境で Python を使って iBeacon を送信することはできません。そうそう、.NETでもできなかったんですよね。WSLを使うとできるようなできないような感じでしたが…ひとまず、それを忘れて「Windows で Python を使って iBeacon を送信していみよう!」と思って、作り始めた記録です。

仮想環境 .venv を作って vscode に transmit-ibeacon.py というファイルを開きます。

まずは、初手として Copilot にプロンプトを入れます。色々設計してもよいのですが、作りたいツールを直接入れてしまうのが初手としては手っ取り早いです。

「iBeacon を発信するコードを書いて。」

中味は GPT 4o なので結構コードが生成されます。

これを「同意する」を押して確定させます。

import time
import bluetooth

# iBeacon settings
uuid = "12345678-1234-1234-1234-123456789abc"
major = 1
minor = 1
tx_power = -59

# Create the iBeacon advertisement packet
def create_ibeacon_packet(uuid, major, minor, tx_power):
    prefix = b'\x02\x01\x1a\x1a\xff\x4c\x00\x02\x15'
    uuid_bytes = bytes.fromhex(uuid.replace('-', ''))
    major_bytes = major.to_bytes(2, byteorder='big')
    minor_bytes = minor.to_bytes(2, byteorder='big')
    tx_power_byte = tx_power.to_bytes(1, byteorder='big', signed=True)
    return prefix + uuid_bytes + major_bytes + minor_bytes + tx_power_byte

# Transmit iBeacon
def transmit_ibeacon():
    ibeacon_packet = create_ibeacon_packet(uuid, major, minor, tx_power)
    sock = bluetooth.BluetoothSocket(bluetooth.LE_ADVERTISING)
    sock.bind(("", 0))
    sock.send(ibeacon_packet)
    print("iBeacon is transmitting...")

    try:
        while True:
            time.sleep(1)
    except KeyboardInterrupt:
        sock.close()
        print("iBeacon transmission stopped.")

if __name__ == "__main__":
    transmit_ibeacon()

実は、このプログラムを実行すると bluetooth ライブラリが無くてこけます。

どうやら、先頭の「import bluetooth」がエラーになっているので、インポートするライブラリが足りないようです。

ここで「Copilot を使用して修正する」を選択します。書籍のほうでは、いろいろと試行錯誤をしていますが、ここではちゃっちゃと聞いてしまいましょう。だいたい、pip コマンドでライブラリを入れれば解決できる話なので。

予想通り、pybluez と言うライブラリを入れればよさそうですね。

pip install pybluez

これを仮想環境でインストールしましょう。

実は bybluez は Windows 環境にはインストールできません。Linux 用の Bluetooth ライブラリなので、Windows 環境では動かないのです。

おそらく Linux 環境で動かせば Copilot の提案通りに動く筈なのですが、いまは Windows 環境で動作させたいので、これは使えません。さてどうしたものか。

プロンプトで Copilot に頼んでみましょう。

Windows 環境で動くように書き換えて。

これはうまくいきませんでした。なにか変な import を追加しますが本筋ではありません。

仕方がなので、チャットを開いて pip で出て来たエラーを貼り付けて問い合わせをします。

(.venv) PS H:\BLE\py> pip install pybluez
Collecting pybluez
  Using cached PyBluez-0.23.tar.gz (97 kB)
  Preparing metadata (setup.py) ... error
  error: subprocess-exited-with-error

  × python setup.py egg_info did not run successfully.
  │ exit code: 1
  ╰─> [1 lines of output]
      error in PyBluez setup command: use_2to3 is invalid.
      [end of output]

  note: This error originates from a subprocess, and is likely not a problem with pip.
error: metadata-generation-failed

× Encountered error while generating package metadata.
╰─> See above for output.

note: This is an issue with the package mentioned above, not pip.
hint: See above for details.
(.venv) PS H:\BLE\py>

チャットの様子

実は、このエラーを Copilot のチャットや ChatGPT のプロンプトに貼り付けて問い合わせをするのはよくやります。コンパイル時の長いエラーや、ややこしいエラーメッセージなどを生成 AI が解析してくれるので便利です。

この回答では、setuptools や wheel の更新を求めていますが、実は駄目です。最後の「pip install bleak」というところで、bleakというライブラリを使うことになります。

最初から書き直して貰ってもいいのですが、bluetooth のところを直せば良さそうなので、この部分で「bleakで書き換えて」とプロンプトに入れてみます。

そうすると、Bleak ライブラリを使った形で書き換えてくれます。

出来上がったコードです。

import asyncio
from bleak import BleakScanner, BleakAdvertiser

# iBeacon settings
uuid = "12345678-1234-1234-1234-123456789abc"
major = 1
minor = 1
tx_power = -59

# Create the iBeacon advertisement packet
def create_ibeacon_packet(uuid, major, minor, tx_power):
    prefix = b'\x02\x01\x1a\x1a\xff\x4c\x00\x02\x15'
    uuid_bytes = bytes.fromhex(uuid.replace('-', ''))
    major_bytes = major.to_bytes(2, byteorder='big')
    minor_bytes = minor.to_bytes(2, byteorder='big')
    tx_power_byte = tx_power.to_bytes(1, byteorder='big', signed=True)
    return prefix + uuid_bytes + major_bytes + minor_bytes + tx_power_byte

# Transmit iBeacon using Bleak
async def transmit_ibeacon():
    ibeacon_packet = create_ibeacon_packet(uuid, major, minor, tx_power)
    advertiser = BleakAdvertiser()
    await advertiser.start(ibeacon_packet)
    print("iBeacon is transmitting...")

    try:
        while True:
            await asyncio.sleep(1)
    except KeyboardInterrupt:
        await advertiser.stop()
        print("iBeacon transmission stopped.")


if __name__ == "__main__":
    transmit_ibeacon()

さて、これを動かし見ると実はエラーで動きません。

これを Copilot に聞くと BleakAdvertiser 自体が無いことがわかります。つまりは Copilot のハルシネーションですね。勝手に作った(あるいは、どこかのサンプルコード?)になります。

あらためて、Copiot に尋ねてみましょう。

「Windows 環境で Python を使って iBeacon を発信するには?」

提案されたコード

import pygatt
import time

# iBeacon settings
uuid = "12345678-1234-1234-1234-123456789abc"
major = 1
minor = 1
tx_power = -59

# Create the iBeacon advertisement packet
def create_ibeacon_packet(uuid, major, minor, tx_power):
    prefix = b'\x02\x01\x1a\x1a\xff\x4c\x00\x02\x15'
    uuid_bytes = bytes.fromhex(uuid.replace('-', ''))
    major_bytes = major.to_bytes(2, byteorder='big')
    minor_bytes = minor.to_bytes(2, byteorder='big')
    tx_power_byte = tx_power.to_bytes(1, byteorder='big', signed=True)
    return prefix + uuid_bytes + major_bytes + minor_bytes + tx_power_byte

# Transmit iBeacon using pygatt
def transmit_ibeacon():
    adapter = pygatt.GATTToolBackend()
    adapter.start()
    try:
        ibeacon_packet = create_ibeacon_packet(uuid, major, minor, tx_power)
        adapter.sendline('sudo hcitool -i hci0 cmd 0x08 0x0008 ' + ibeacon_packet.hex())
        print("iBeacon is transmitting...")
        while True:
            time.sleep(1)
    except KeyboardInterrupt:
        print("iBeacon transmission stopped.")
    finally:
        adapter.stop()

if __name__ == "__main__":
    transmit_ibeacon()

実行してみると、実はこれも動きません。

提案されている pygatt は Linux の BlueZ を使っているので、Windows では動かないんですよね。

結論的には Windows 環境から iBeacon を発信することはできないので、別の環境が必要です。Linux で hcitool を使うか、Android とかを使うか。

ちなみに M5Stack を使った例を示しておきます。

M5Stack で iBeacon を飛ばす(PlatformIO環境) | Moonmile Solutions Blog https://www.moonmile.net/blog/archives/11081

なので、これだとアレだから、Android で iBeacon を作る例を続きへ。

カテゴリー: 開発 | GitHub Copilot で iBeacon 発信ツールを作れる? はコメントを受け付けていません

フジテレビでの会見の考察

午後4時からスタートした会見が翌日の午前2時半ごろまでかかったので、長丁場の10時間の及んだ記者会見ですが、ちょうど午後4時から2時間ほど見た後に、午後10時頃から午前2時までは見ていたので、そのあたりの感想をまとめておきます。

フジテレビ記者会見 10時間超に 新社長に清水賢治氏 港浩一社長 嘉納修治氏 遠藤龍之介氏 金光修氏ら出席 | NHK | テレビ局 https://www3.nhk.or.jp/news/html/20250127/k10014704771000.html

すぐにでも youtube に全会見が上がりそうな勢いですが、NHKの一問一答があるので、これを参考にでもしてください。

会見の争点

見ている人によってそれぞれの立場があるので会見の味方が異なります。視点としては、ビジネス寄りにして「今後のフジテレビが存続し得るか?スポンサー会社は戻ってくるのか?戻れるのか?」で見ています。なので、具体的な性被害/性接待については別途中居問題としてでてくるだろうし、週刊誌等が追うでしょう。それはそれで必要なんだけど、株主のいる株式会社としてフジテレビは今後どうするのか?ということです。

問題となるのは、

  • スポンサーが一斉に降りてしまった責任を誰が取るのか?
  • フジテレビ自体を今後どうするのか?立て直すのか?
  • スポンサーが戻る余地があるのか?

ということです。明らかに第1回の閉鎖的な会見が良くなくて、その後のスポンサーが一斉に抜けたわけで、それをなんとか収拾しないと株主としてもスポンサー会社としても困るわけです。

会見の良かった点

先に会見の良かった点をあげていきましょう。実際のところ記者会見としては比較的良かった部類に入ると思うのです。一部の記者(望月記者など)の怒号や主張が長かったという意見もありますがそれを受けての記者会見ではあるし、長時間にわたってしまったのはひとりひとりの記者に必ず質問の機会が与えられていたという進行のためなので、仕方がないでしょう。逆に言えば、長時間にわたってしまったが、記者が質問をするという形式は確実に守れたと思われます。

  • 港前社長の退陣が決定していた
  • 清水新社長の新体制や第三者委員会の解説が明確であった
  • 日枝相談役に関しては、相談役として据えているだけで強烈な影響があるわけではない(まあ、多少はあるにせよ)

少なくとも株主への説明やスポンサー会社への説明のための材料は揃えていたような気がします。元凶が前社長の対応の杜撰さにあるので、これを払拭できるかわかりませんが少なくともフジテレビの社長と会長を退陣させることでそれの決着はできるでしょう。副会長が留任しているのは副会長の言葉が実に真摯であることからわかります。5人の会見でしたが、港前会長が一番駄目で、他の4人はそこそこ答えている感じでした。

フジ・メディアHDの社長の言葉は、たしかにフジテレビの株主会社なのでこういう言い方しかできませんよね。もう全面的に港前社長と周辺の役員、その下に連なるディレクターが不味いって話でもあります。

フジテレビの買収の恐れに関しては、フジ・メディアHDの社長の説明する通りメディア業務が50%を越えることを前提にHD自体が作られているそうなので「買収はあり得ない」と考えられます。買収されたときは、HDごと買収されることになるので、あの社長は必至で抵抗するでしょう。それがHDの役目でもあるのでそこは相談役ともども乗り込んでくると思われます。例の外国株主からの件は、そのあたりの事情が良く分かっていないのかもしれません。フジテレビの株を持ってはいるものの、番組内容や会社の態勢はHDが株主的にも優先度が高いのではねのけるかなと。

あと、フジテレビで会見を最後まで生放送(10分遅れではありますが)したのは、フジテレビの制作担当だそうです。ちょくちょく入っている音声なしの状態も、その遅延の間に消しているので流石報道制作部(多分)というといころですね。これはバラエティだとしても同じで音声やカメラの切り替えで放送事故になりそうなものを瞬時に切り替える技術のたまものです。

個人的にはもっと音声がなくなると思っていたのですが、かなりピンポイントで削られているだけでした。おそらく編成担当の部署に役員がいて色々指示することが無かったんじゃないかなと思われます。単なる記者会見ではなくて、自社の社員向けでもあるということも含めてできるだけ流すという方針にしたのは良かったです。所謂、のり弁になるのを危惧したのですが、それは無かった。

会見の良くなかった点

この会見のよく無かった点としては港前社長の不誠実な回答に付きます。おそらく、実際のところ該当の女性からの報告(女性の同僚や医師)をかなり分かっていないのが丸見えで、当時ながらわからないところがあったにせよ、そのあたりを謝罪しないと前に進まないのですが。そこは第1回目の会見を閉鎖でやったところもあって「さもありなん」という体ですね。

おそらく前社長の保身が今回の騒動を大きくしてしまった(発端は中居問題にせよ)のではないかと考えられます。

非常に気になる(印象がよくない)のは、

  • 女性が事実を知られたくないまま復帰したいと望んだので、それに応じて隠した。中居番組も続けた。
  • 今回の件は非常に「特殊」であった。できれば女性本人に会って謝りたい。

の2点です。

「女性が事実を知られたくないまま~」が言い訳になっているに過ぎません。少なくとも株主やスポンサーからは会社としての危機にあっているのに、当時の女性の気持ちのせいにしている前社長を信用することはできません。むしろ、当時の状態として女性の意図を間違って汲み取ってしまって、コンプライアンス的にも人権的にも誤った行為をしてしまった、と謝罪したほうが受けがよいです。そうじゃないと、単なる女性社員の一存で社長が振り回されている感じがするし、先導できていません。まあ、実際そういう訳で馘なので決着は一応ついているのですが、本人が分かっているかどうかが分かりません。

実際のところは第三者委員会の調査を待つところですが、性被害(セッティングに突っ込んだの女性本人の意思だとしても、性被害とみられるような行為をされるのはそれは犯罪ですよね)にあった人にとってその直後はその事実を否定したり自分を過度に責めたりすることはよくあることです。心理的にその事実を無くしたいという思いがあるので、向き合うので「事実が知られないまま復帰」を望むわけですが、実際そういうのでは心的被害が残ります。想像ではありますが、前社長が何度も「特殊」なというのは、かなり深刻な状態だったと思われます。本人が強烈に隠蔽と復帰を望むと同時に、おそらく自殺を図ったのかもしれません。自殺すると一遍に情報が洩れますからね。ちょっとしたセクシャルハラスメントとは状況が違うわけです。副会長が言う通り、フジテレビ内でもちょくちょくセクハラやパワハラでコンプライアンス部への報告もあったのでしょう。でも、それは自殺レベルではなかったかと思われます。そういう意味で実際に「特殊」だったのでは?と想像ができます。

で、午後1時過ぎの前社長の言葉ですが、既に退職していますか?という記者の質問に対して「在籍しています」と答えています。何度も「直接会って謝りたい」と言っていますが、現在も社員であれば直接会うのは容易ですよね。会わない、あるいは会えないのは何か理由があるのでしょうか?女性に拒否されている?変な勘ぐりをされてしまう状況です。

勘ではありますが、被害女性は躁鬱症状態になっているのかなと思います。これ個人の特定とかそういう範囲になってしまうのですが(実は、今の私が被害女性が誰だったかを詳しく調べていません。うちの奥さんからパリ五輪に見に行っていた、と聞いたぐらいで世の中としては特定されているようなのですが、あえて調べていません)、躁鬱症の場合は本人の言葉を医師が鵜呑みにすることはまずないんですよね。なので、性被害をあった直後に「復帰したい」とかいう言葉を鵜呑みにすることはないのです。あと本職のカウンセリングだとそういう個人的な話を会社に伝えることもないんですよね。おそらく、フジテレビ内の産業医レベルかもしれません。個人的なカウンセリングを受けたほうが良いかと。

余談

ハッキリ言って、細野不二彦著「電波の城」を思わせます。というか「電波の城」の連載自体がそういうテレビ業界の裏話をベースに作った漫画なので、そのあたりは多少の誇張はあるにせよ当時のテレビ業界の雰囲気がこんな感じだったわけです。なので「女子アナ」というジャンルが、いわゆるコンパニオン役を担わされていた時代背景もあります。

そこが一般企業の認識とずれて居るところに、前社長の言葉のずれぐあいが集約されていますね。

もうひとつ、日枝相談役の存在は河合隼雄著「中空構造 日本の深層」を読むと詳しく書いてあります。いわゆる日本神話から続く、日本の権力構造がほぼ空位である天皇というもので存在して、権威ではあるが権力がないという中空構造を保っている歴史的経緯があるのです。これは、外国の株主には理解しがたい現象かもしれませんね。

カテゴリー: 開発 | フジテレビでの会見の考察 はコメントを受け付けていません

機動戦士ガンダム ジークアクス劇場版の発想元を考える

盛り上がっているうちに観ていきますかということで近場の映画館で観てきました。平日の水曜日で昼からなのですが、それなりに人が来ています。詰め詰めじゃないけど、がらがらというわけでもなさそうで、年齢層は幅広く入っていたかなぁと。

以下、ネタバレになるので、できれば映画館で観た後に。ネタバレ大丈夫な場合(私はそっちのほう)は、ざっと予習してから見に行っても楽しめます。

ひとことで言えば、「ガンダムを観に行ったらガンダムが始まった!」という感想に付きます。「水星の魔女」の場合は、第1話がガンダムっぽくないものからガンダムっぽいところで終わるのですが、ジークアクスの場合はガンダムで始まってガンダムで終わります。

端的に言えば、初代ガンダムのリメイクから始まるわけです。

仮想戦記という考え方

そもそも機動戦士ガンダムというアニメが仮想戦記なわけで当然のことながら史実に基づいているわけではありません。しかし、ところどころに出てくる地名が第二次世界大戦を思わせる地名だったり(ジャブロー、ソロモンなど)、登場人物がレーニンやスターリンを思わせたりするものがあって、史実を参考にしているところが多いのです。仮想戦記/ifシリーズと言えば「紺碧の艦隊」や「沈黙の艦隊」、「戦国自衛隊」など史実を交えながらも、ちょっとだけ当時の事実が変わって、日本軍が勝ったりするストーリーが流行っていました。

そういう点で、ジークアクス劇場版はifシリーズの系譜に相当します。もしも、ジオン軍が年戦争で勝っていたらという話ですね。もっと直接的に言えば、アムロの代わりにシャアがガンダムに乗っていたらというifシリーズです。

ちなみに、初代ガンダムでは「戦局が個人の能力に左右されることはない」という思想が強いので、シャアがガンダムに乗ったからといってジオン軍が勝つことはない、と思うのですが、せっかくだからジオン軍が勝ったという仮定をしてみましょう。

って、去年の12月にネタバレしている椎名先生はエスパーですか!?

って、一方でマフィア梶田氏が「ジオン軍が勝ったストーリーを見てみたい」という放送がカットされたという話もあるので(苦笑)、いろいろとガンダム界隈でチェックが入っていたみたいです。

作り手の発想元ネタを探ってみる

初代ガンダムネタがいろいろな方がやっていると思うので、ガンダムシリーズとは違うところから持ってきたであろう、という妄想も含めて発想元のネタを考えてみましょう。

  • ジークアクスの世界でのグランバトルは、ボトムズの地下闘技場を思わせる。そのうちキリコっぽい人がでてくるかも。
  • キラキラの部分は「夜のクラゲは泳げない」にそっくりで、なんとなく黒髪のキャラもにている。あるいは涼宮ハルヒのSOS団マークに似ているかもしれない。時空のトンネルを越えるとかの前兆?
  • 女ボスは、タイムボカンシリーズのドロンジョですね。
  • 時空のトンネルは「エウレカセブン AO」あたりに似ている。
  • マブ(MAV)は「マブダチ」が元ネタなんだけど(映画では理屈をこねているが)、タイガー&バニーのダブルデッカーですね。ダグ&キリルでもいいです。
  • 赤いガンダムの搭乗者は、どうみても「ハウルの動く城」のハウルにしか見えない。たぶん、性格もハウルに寄せてくる。
  • 全編で「ピキーン」のニュータイプ音が響くわけですが、ジークアクスがニュータイプに寄せていくかどうかは不明。どちらかというと、プラモ狂四郎とかプラレス3四郎のようなエンジニアちっくなものに寄せるような気がする。
  • ビギニングのほうは、ギレンの帝国や、サンダーボルトに雰囲気を寄せている。コロニーの脇を疾走するシーンは、そのまんまサンダーボルトにあります。
  • 奪取したガンダムをキシリアが赤く塗らせたシーンは、そのまんま「トニーたけざきのガンダム漫画」そのものです。とりあえず赤く塗っとけ!と切れるキシリアを思わせる
  • ティム・レイの工作ボックスは、Google かなんかで型番を検索して出てくるほど量産品になっていて、とってもHDDっぽい。ぴかぴかしているし。
  • ガンダムの四ツ目はエヴァそのもの
  • 木馬の左舷は~、が健在です。初代ガンダムネタは鹵獲された木馬を始めとしてあちこちに出てくるので初代を見ておくと面白いですよ。

シャリア・ブルの立ち位置は?

実は、偶然にもジークアクスの劇場版を見る直前に、富野版の初代ガンダムの小説を再読していました。シャリア・ブルは、テレビ版にも小説版にも出てくるんですが、初代ガンダムの劇場版ではカットされているんですよね。当時の理由はよくわからないのですが、後にある小説版の方に出てくるところを見ると、それなりにキャラ建てはできていたと思われます。

逆に言えば、シャリア・ブルの周辺は当時は特に設定がないわけで、シャアと組ませて話を広げやすかったという理由でしょう。特に裏設定とかなさそうなので、ジークアクスの世界でのシャリア・ブルを彼なりの正史にしやすいという図式でしょう。

個人的に言うと、ニュータイプ的な「覚醒」はあまり面白くないんですよね。旧人類が重力に引かれている=既存の構造主義や権力に縛られているので、それから解き放されたスペースノイドは呪縛から解き放されるので、構造から脱することができる「脱構築/脱構築」というスタイルが望ましい…のですが、果たして。

ガンダム史と社会思想に関してはまた別途。

カテゴリー: 開発 | 機動戦士ガンダム ジークアクス劇場版の発想元を考える はコメントを受け付けていません

mini pc に Ubuntu 24.04 を入れる

家族用の mini pc が手狭になったので退役させて新しい mini pc を購入しました。

MINISFORUM の3万円程度だったと思うのですが、CPU スペックはこんな感じ

外観…というか後ろ姿はこんな感じです。

中味が Windows 10 なのですが、CPU の関係で Windows 11 にアップデートができません。そのまま廃棄してもよいのですが、いったん Ubuntu を入れてみようということです。

USB で Ubuntu を起動させる

実は直接 Ubuntu を mini PC に入れたかったのですが、その方法がなかなか見つかりませんでした。何故か USB メモリから起動するサイトはたくさんあるのですが。

Ubuntuのインストール用のUSBメモリを作成する方法 | kantan-prog https://kantan-prog.com/ubuntu-install-usb/

起動用の DVD を作ってもよいけど面倒くさいし、ひとまず USB 起動でよいか、ということで Windows 上で USB メモリで起動する Ubuntu を作成します。BIOS を設定して、USB から起動させれば Ubuntu を動かせる環境の完成です。

直接 PC から Ubuntu を起動させる

で「USB メモリ起動でもよいか」と思っていたのですが、実はUbuntuのインストーラーがUbuntuのデスクトップに配置されていたのですね。なるほど、そういう訳で、USB メモリから起動した Ubuntu から PC 本体に Ubuntu を入れます。

なんじゃ、つまりは2段階で Ubuntu を起動すればよかったわけです。

  1. 一旦、Windows から USB メモリ起動の Ubuntu を作成する
  2. USB メモリ起動の Ubuntu から PC 本体へ Ubuntu をインストールする

Windows からリモートデスクトップ接続する

Ubuntu へは Windows 11 からリモートデスクトップ接続ができます。以前は VNC でつなげていたのですが、リモートデスクトップ接続ができるようになって便利です。と言いますか、現在の Ubuntu 24.04 では VNC が無くなってリモートデスクトップ接続がデフォルトになっています。ややこしいですね。

第819回 Ubuntu 24.04 LTSのリモートデスクトップを深掘りする | gihyo.jp hうtps://gihyo.jp/admin/serial/01/ubuntu-recipe/0819

で、24.04 では、リモートデスクトップの設定場所が変わっていて「システム」→「RemoteDesktop」の中にあります。

「Desktop Sharing」と「リモートログイン」の2つのタブがあるのですが、Windowsから接続するリモートデスクトップは「リモートログイン」のほうです。ポート番号がRDPの3389番になっています。

もうひとつの「Desktop Sharing」のほうは画面共有方式のほうで、3390番になっています。通常はこっちのほうでつなげるようなのですが、Windows のほうは 3389ポートがデフォルトなので多分「リモートログイン」でつなげるのが正しそうです。実際に、それでしか繋がらないし。

何に使うかと言うと、ひとまずマイクラサーバーの移行と Blazor 本書きですね。

カテゴリー: 開発 | mini pc に Ubuntu 24.04 を入れる はコメントを受け付けていません

イーロン・マスクの示す「目標設定」と「権限移譲」について

とある Youtuber(かな?)の動画にイーロン・マスクの経営方法に関しての話がありました。そこで「権限移譲」の話がでてきたので、ちょっと記録をのこしておきます。

How Elon Musk Gets So Much Done – Marc Andreessen

ここで話している マーク・アンドリーセン氏は「イーロン・マスク氏と仕事をしたことはないが~」と明言しているので、実際のマスク氏がどういう考えで経営をしているのか不明ではあるのですが、アンドリーセン氏から見た良い点を語っているという視点でみてください。

マーク・アンドリーセンって名前を聞いたことがあるような無いような気がしていたのですが、モザイクやネットスケープの創始者プログラマですね。現在は投資活動が専門のようです。

https://ja.wikipedia.org/wiki/%E3%83%9E%E3%83%BC%E3%82%AF%E3%83%BB%E3%82%A2%E3%83%B3%E3%83%89%E3%83%AA%E3%83%BC%E3%82%BB%E3%83%B3

そういう意味ではプログラマ的な視点でもあるのかも。

目標設定

Youtubeの動画をざっと見たところ(字幕を日本語にして)、肝となるのがトップダウンによる明確な目標設定と、現場で自由に実行できるようにする権限移譲が重要です。

株式会社の最終目的は「儲けること」というな訳ですが、単純に「儲ける」にしても手段が色々あります。イーロン・マスク氏がどう考えているか分かりませんが、少なくとも赤字を垂れ流しながら福祉活動をするという訳ではなさそうです。そういう意味では一般的な株式会社ととしての目標設定(売上とか販売シェアとか)があるでしょう。

トップの仕事として何らかの具体的な数値目標を立てることも重要ではありますが、彼ほどたくさんの会社を持っていれば(これは孫正義氏もそうだと思うのですが)、手持ちの複数の会社を組み合わせてより利益を上げる方向を考えます。まあ、そのために大手の会社は買収をしたりグループ会社を作ったりするわけで、全体としての最適化を図るわけですね。

そう、部分最適化ではなくて全体最適化です。マスク氏が持つ会社あるいはマスク氏の周辺にあるアメリカ合衆国という国も含めて、マスク氏は最適化を図ろうと考えるわけです。このあたり、トランプ氏の思考回路も似た感じで、トランプ氏が持っている株や会社がうまく業績があがるようにアメリカ合衆国やその周辺の国を動かそうとします。実に分かりやすい「アメリカ第一主義」の発想です。この発想の良い悪いは別として、この発想の仕方からみると、マスク氏やトランプ氏の行動は予測しやすいと考えられます。特に、マスク氏のほうは自らの嫌悪感ではなく合理的に進める傾向が強いので、これも予測しやすいです。もちろん、予測しやすいからと言って同じようにできるわけではありません。同じようにできるのはマスク氏の胆力と献身性(自らの考えに献身するという意味で)に原動力があります。

そういうなかで手持ちの会社=つまりはカードを最適に動かすための「目標設定」を考えます。アンドリーセン氏が言う「ボトルネックを見つけるのうまい」というのはそういうところです。目標が明確になっているので、その障害となっているものを取り除く、あるいは弱いところにサポートしていく合理性をマスク氏は持っています。

これ、TOC(制約理論)の考え方そのものなんだけど、アンドリーセン氏や Youtube のインテビュアが知っているかわからないのですが、制約理論自体は MBA の教科書に載っている位なので、おそらく知っています。気づいているかどうかはわからないけど。

権限移譲

合理的な思考ができれば目標設定ができあがります。いや、合理的ではなくても目標設定ぐらいは誰しもができるでしょう。例えば、「来年の年末には宝くじ1億円をあてる」という具体的な目標を設定することは簡単です。これを達成するための手段が不可能ってだけで、具体的な目標を立てるのはそう難しくはありません。「売上○○億円を達成する」とか「アイドルになる」とか「今年は○○キロ減量する」とかいうのも似たような感じです。

要は、どうやって目標を達成するのか?という道筋を作らないといけないのです。

「今年は○○キロ減量する」という個人的な目標は自分で動かないといけないし、自分が動けばいいので達成は可能そうですね。NHKの減量コーナーは運動や諸々をみながら自らが動くことになります。

しかし、マスク氏のように多くの会社を持っている場合はどうでしょう?それぞれの会社に対して具体的な目標設定をしたところで、果たして彼はそれぞれの会社にいちいち口を出さないといけないのでしょうか?

実は、この手の組織論に堀江氏をはじめとする「フラットな組織論」というのが流行った時期があります。社長が社員という二階層だけにして、社長がひとりひとりの社員の活動をメールなどを受けてさばくという会社のシステムです。このフラットな組織がうまくいったのかどうかはよくわかりませんが、社長のマンパワーに依存しているのは確かなことです。社長の時間は24時間しかありませんから、どう効率よく動いても24時間しかありません。フラットな組織は中間層を排除してしまって、全体の組織が社長の手足のようにスピード感あふれる動きかたが出来る…というように見えますが、それは社長の24時間に達するまででしかありません。あるいは、社長の能力を会社は越えられないのです。ある意味、社長の能力までは会社は成長しますが、それ以上にはなりません。

まあ、そうなるので、一定の金銭を得た後は投資家は投資に走る(金が金を生むという仕組み)わけですが、マスク氏の場合は自社に投資をするという別な形に効率化を推し進めていきます。

つまりは、マスク氏が全体の最適化の図を描き、手持ちの会社の目標設定をした後は、その目標を達成するための手段を会社自体に「権限移譲」するわけです。目標が達成できればよいし、達成できなければ目標を達成するための手段を考えます。ボトルネックを一緒に探したり、そもそもの目標設定を達成可能なものに書き換えたりするわけです。

この権限移譲の考え方はリッツカールトンのクレドに近いです。ホテルのリッツカールトンでは、スタッフに相応の自由に活用できる金額を申し渡しています。お客を助けるためにスタッフの自由意志によって会社の予算が自由に使える訳です。ある程度の上限は決まっていますが、自由裁量の幅が他とは違います。このためにホテルに滞在しているお客に対してサービスの自由度が大きくなっています。

フラットな組織は一見、中間層がなくなって決断がスピーディになる(社長と社員が直結するので)ように見えますが、先に言ったように社長の24時間運用が上限になります。それ以上になると、社員からの問い合わせが待ち行列に入ってしまいますね。

ところが、リッツカールトン方式になるとホテルのスタッフの自由裁量によりホテルのオーナーや総支配人の許可を得ずに、お客へのサービスを提供できます。決裁権がスタッフ/社員側にあるというわけです。

これを大手の会社やグループ会社に拡大してみましょう。トップのオーナーであるマスク氏の意向をや目標設定ををクレドに書き込み、グループ会社の社員に渡したとしましょう。到底それはうまくいきそうにありません。社員が善人であるという前提も必要ではありますが、現場で動いている社員がうまく動けるようにマネジメントする層が必要なのです。この中間層が「知識創造企業」で云うところの「ミドル」という層です。中間管理職と言ってもいいし、プロジェクトマネージャと言ってもいいし、スクラムマスターと言ってもいいです。

つまりは現場が現場で動き、トップはトップで全体最適化を図るように目標設定をする。そして、中間のミドルマネジメント層がトップより「権限移譲」された決裁権などを利用して、現場の取り纏めや外渉などを行います。現場の人が外渉や調達までするのは大変ですからね。そこのあたりはPMBOKに書かれているところです。

中間層と現場の選定

目標設定と権限移譲の組み合わせなんだが、これには「きちんと仕事をする」という前提が必要になる。例えば「リモートで在宅勤務にしている社員がサボるのではないか?」とか「チームでのサボりをなくすために日報を提出させよう」とか考えてはいけません。というか、そいう社員やスタッフが社内に存在してはいけないのです。

なので、ある人にとっては「とてもそんな組織はうまくいかないよ」という見方もありますが、ある人にとっては「結果さえ出ればいいんだから、可能だよ」という見方もあります。でもって、マスク氏が選定しているのは後者なわけです。

これは組織論の話であって、人権だとか国民だとかという話ではありません。あくまで会社という組織つまりは中途採用などを含めて、なんらかの選定があって会社が成り立っているわけです。その選定さえた人材だけでグループ会社を作って、それに対して目標設定をして全体最適化をイーロン・マスク氏は廻しているわけです。

理屈はわかるし、うまくやればできそうでしょ?実際マスク氏はできているわけですが、私自身がその組織に入りたいかと言うと(入れるかと言う問題もあるけどw)、

という気持ちです。スターリンクもテスラも魅力的な商品ではあるけれど、そこで働きたいかどうかは別ですよね。日本の場合はもう少し別のやり方もあるし、大きな会社でなんやかやと中間層や現場で働きたいわけでもないし。ちょっとずつ首を突っ込んでは来たけど、もうちょっと別のやり方もあります。

とはいえ、アンドリーセン氏から見たマスク氏の経営術は実に合理的なもので、あるい意味でプログラマ的でありソフトウェアエンジニアとして共感できる部分が多いです。特にスペースXの開発アプローチは、従来のモックアップ&試験の繰り返し違い(実は、トヨタでも大量のモックアップを作る方式にシフトしているけど)、ソフトウェアテスト的にスクラッチビルドを高速に繰り返して発展させる成功例ですから。資金力があればこそなんですが。

参考文献

TOC(制約理論)やボトルネックの理解に

リッツカールトンのクレド、権限移譲の方法

スクラム、ミドル・マネジメントの考え方

確か、MBA マネジメントにCCPMとか制約理論が載っていたはず。

カテゴリー: 開発 | イーロン・マスクの示す「目標設定」と「権限移譲」について はコメントを受け付けていません

烈烈布神社に参拝して集団心理の毀損と進化に至る話

新年あけましておめでとう御座います。ぐらいは書いておこうと思いつつ、現代思想2025年1月版のロスト・セオリー(絶滅した理論)に興味をそそられたので記録しておきましょう。最近、ブログ書きに戻ろうとしているのはツイッターのX化もあるし、散漫に残しているだけではどこかに散ってしまいそうだからという理由もある。もちろん、以前と同じく「moonmile 〇〇」という形で Google で検索すれば自分のブログが引っかかるので、全文検索替わりになるというのもある。Google検索のAIはあいかわず当てにはならないのだけど、自分のブログの特殊なものも拾ってくれるのもいいのではないだろうか?

烈烈布神社に参拝する

年末年始に実家に帰ると近場の烈烈布神社に参拝することにしている。以前は、車で北海道神宮神宮まで行っていたのだが、父が亡くなってからは私自身が免許を持っていないし、まあ近場でよいだろうという感じになっている。

初詣の神社参拝は鉄道会社の宣伝という話もあるけど、それは遠地の観光地化された神社の話であって、近場の神社に参る場合にはそれ以前からある。どれ以前かは知らなけど、少なくとも明治以前も神社があったはずだし、初詣の習慣は江戸時代にもあっただろう。

初詣に行かないとダメというわけではない。別にいかなくてもいいのだが、ちょっとした切っ掛けがあるときには面倒でなければ行っておいたほうがよい。つまりは、

「今年は初詣に行かなかったから、この仕事がうまくいかなかったかも」

という憂いを避けるためである。「仕事」の部分は、学業でも受験でも就活でも構わない。これは、実際に子の大学生に言った話であるが、「それならば」という形で重い腰を上げさせることに成功している。罰があたるわけでもなく、ご利益があるわけでもなく、個人的な「憂い」を払拭するために初詣に行くのだ。

烈々布神社の歴史

烈々布神社の歴史であるが、当然のことながら明治以降である。函館の五稜郭があったり札幌の屯田兵があったりして、徐々に札幌の町を広げた結果が、今の烈々布神社ともいえる。

https://hokkaidojinjacho.jp/%E7%83%88%E3%80%85%E5%B8%83%E7%A5%9E%E7%A4%BE

天照の御霊がどれほど広く届くかわからないが(少なくとも日本全土には即なのかもしれない、よくわからんw)、菅原道真公も入っていてなんだかよくわからない感じになっている。ただし、氏子(たぶん、開拓民の子孫と思われる、かつ地元の企業)もそこそこいるので、神社としての体裁以上ものは備わっている。

ただし、見ての通り明治以降の建立なので、歴史的な価値はまるでない。神話的に意味もあるかどうかも微妙なところである。門前に建立されている石碑も昭和のものなので、比較的新しい。

しかし、なぜここに「初詣」することができるのか?というのを心理的に読み解いてみようというのが、今回のブログ記事の主旨である。そう、おわかりのように暇なのだ。

神社へのいたずら書きを考察する

神社の架空性を問うだけでは詰まらないので、去年あった靖国神社へのいたずら書きをあわせて考えてみよう。

靖国神社 落書き事件 14歳の中国人少年に逮捕状 落書き見つかった当日に中国帰国 | NHK | 事件 https://www3.nhk.or.jp/news/html/20241121/k10014645201000.html

「礼拝所不敬罪」とかにあたるらしいのだが、いわゆる公共物損壊の罪だろう。礼拝所不敬罪という意味だと、いわゆる尊属殺人を想起させるわけで、公共物としては神社仏閣であろうと通常の公共物(区役所とか公園とか)と同じ列に据えてもよいはずだ。しかし、なぜか、不敬罪という形でワンランク上の罪をかぶせようとしたがるし、一般的には不敬罪であろうという思い強い。私も直感的には不敬罪にあたるだろうと感じてしまう。

しかし、ちょっと考えなおしてみよう。不敬罪という言い方をするが、何に対して不敬なのだろうか?靖国神社自身に対してなのか、靖国神社で奉られている英霊に対してなのか、それとも靖国神社をたたえている人たちに対してなのか?ここを分解してみようという試みである。

靖国神社を烈々布神社に置き換えてみよう。烈々布神社にいたずら書きがされたときにどうなるだろう。一般的な神社仏閣に対していたずら書きをさえたときには、たしかに礼拝所という特別な場所(何に対して特別であるかは、後述する)への公共物損壊には違いないが、靖国神社ほど怒るとは思えないし、それほどニュースとして広まらないだろう。場合によっては、天照や道真公を毀損されたとも言えなくもないが、そこまで考えて怒る人は、烈々布神社の氏子ぐらいなものだろう。

靖国神社には氏子相当の人が多い(いわゆる、戦没者が安置されている、とされるので。戦没者でも安置されない場合もあるけど)と勘がられるので、氏子という意味では烈々布神社よりも多くてニュース性が高いかもしれない。しかし、靖国神社へのいたずら書きは単に氏子が多いという問題以外のところにある。つまり、別のものを毀損されたとほとんどの日本人が感じるからだ。もちろん、毀損されたと感じない日本人もいるわけで、今回はそれは例外としてとらえておく。まあ、ニュースになったという事実からして、それなりに「事件性」があるとということだ。

偶像崇拝と組織進化論

靖国神社が一般的な概念として偶像崇拝であることは間違いない。仏教も仏陀の教えそのものだけでなく仏像をあがめることも多いので偶像崇拝である。イスラム教ではないが、偶像にはちょっとした価値がでてきてしまう。偶像そのものに価値がでてきてしまう。

偶像としては芸術的な価値もあるのだが、ここでは靖国神社自身の価値を考えてみよう。狭い範囲でいえば、いたずら書きされた石碑そのものと言ってよい。

現代芸術もそうだが、芸術対象や宗教的な対象そのものには価値がない。話がずれるが、「壺」だった、壺自身に価値があるわけではない(価値があるとして売られているが)。とある宗教的な意味(芸術的でもいいし、かつての持ち主でもいいし、芸術家自身がつけた解釈自身でもよい)。ときどき、Xに流れてくる「バナナをキャンバスに貼り付けた」だけでも構わない。金銭的な価値というものはそういうものだし、それぐらいの価値しかない。

じゃあ、石碑自身には価値がないが、これにいたずら書きをされたときに、何が毀損されるかというと、石碑をあがめている人達になる。いわゆる、氏子が最初にあがるわけだが、靖国神社の場合は氏子だけに限らない。いわゆる、右翼的な積極的な靖国崇拝者もいれば、なんちゃってネット右翼のコスプレ団体かもしれないし、戦時を抜けてきた老人かもしれないし、漠然と日本の神社のくくりとして靖国神社を毀損されたという漠然とした厭らしさかもしれない。

ここでは、より消極的な「漠然とした厭らしさ」に焦点をあてていこう。

普段は積極的に靖国神社に行こうとは思わないが、靖国神社の石碑にいたずら書きをされるとちょっと嫌な感じがする、という程度のことである。でも、この「ちょっと嫌な感じがする」はどこからくるのだろうか?

同じように、たいていの日本人が知らない烈烈布神社の何かの石碑に同じようにいたずら書きをされたと仮定しよう。そうすると、感じるだろうか?別になんとも感じない場合もあるけど、ちょっと嫌な感じがする人が多いと思う(ここはアンケートなどでフィールド調査しないといけないところだが、思考実験で済ますw)

つまり、日常の中で特に意識はしていないが、神社というものが毀損されるとちょっと嫌な感じがするわけである。とくに「神社」を崇拝しているわけではない(崇拝する場合もあるけど)が、漠然とした偶像崇拝を神社という形で存在させることができるぐらいには許容しているわけである。同じものに、神社の鳥居がある。これはよく言われるように、小便をさせない場所に鳥居の記号を書いて避けさせるぐらいいは、呪術的な効果がある。そう、この呪術的な部分と「ちょっと嫌な感じがする」というのは同根であるのだ。

神社あるいは仏閣をそこかしこに配置させるだけの心の余裕を日本人は持ち続け現在にいたる。もちろん、明治の初期の廃仏毀釈があるので一筋縄ではいかないが、単純化して現在では神社仏閣を毀損しない程度の集団に日本はなっている、ということが靖国神社のいたずら書きの事件から読み取ることができる。

そこで、日本人の魂とか言ってしまうと速攻陰謀論になってしまうので、組織進化学の話につなげていこう。組織進化という視点では、いっていの集団には一定のゆるいルールが存在し、そのルールを尊重する人たちが集まって組織を担っているのである。「ゆるいルール」というのが重要で、これが厳しい罰則付きのルールであると村八分や外乱の取り込みができなくなって組織を継続して存続させることができなくなってしまう。「ゆるいルール」というのは、組織外にあるルールさえも少し取り込むことができるという緩さ必要になる。

つまりは、日本という組織(国ではなく、自分は日本人であるという意図的な従属の関係?あるいは承認意識?)をまとめているものひとつとして、「神社に対してなにかいたずらをしてはいけない」という共通認識があり、それが緩いルールになっていて、不敬罪というのを認める形になってるということである。「不敬罪」というのが、昔の尊属殺人罪ほど強い印象を与えないのはそのためだろう。尊属殺人は儒教の教えもあるだろうが、西洋でのエディプス・コンプレックス論にもでてくるので、東洋に限った話ではない。

おまけ、男女という枠組みを外す

ここでは「女性への痴漢」という言葉を出したが、言い直せば「人への痴漢」である。女性への痴漢があれば、男性への痴漢もある、さらにその中間もあるのだから、性別や年齢に限らず「人への痴漢」行為はあかんだろう、というのが共通認識になればよいのだ。

だから、Xでよく出てくる「男が~」「女が~」という言葉に敏感に反応してしまいがちなのは、そこが男性あるいは女性というカテゴリー/セグメントに無意識に分けてしまっているのが問題なのであって、これをヒトというひとつのカテゴリにしてしまうと問題が少なくなる。このあたりは類型論と特性論(精神分析と臨床心理学)に属するので、日を改めて書くことにしよう。

カテゴリー: 開発 | 烈烈布神社に参拝して集団心理の毀損と進化に至る話 はコメントを受け付けていません

年末なので五行思想でコンピュータサイエンスを解説してみよう

もともとの発端はここから。五芒星か六芒星が一部で流行っているらしいので、どうせならば本格的にやりましょう、という発想。

実は、個人的に陰陽道とか五行思想には詳しい(趣味レベルですが)ので、けっこうイケる感じではあります。

ざっと、次のところまでつなげておきましょう。

参考文献

いきなり本格的なものを読むとつらいので、次の2冊からスタートするといいです。

シム・フースイは風水をテーマにしたミステリー小説です。荒俣宏が書いているので、安全に風水ワールドを観察できます。

禁止目録は五行機関がでてくるところまででいいです。アニメの第1シーズンだけでもいいけど、基本的な用語がでてきるので、それでも十分だったりします。

五行思想

いきなり、陰陽道につながっても怪しいだけなので、鍼灸のところからスタートしましょう。安倍晴明とか陰陽道からスタートしてしまうと、単なる幻魔大戦の雰囲気になってしまうので(ラノベ的にはそれでもよいけど)、もっと現実的に五行が使われているところからいきます。

要するに、『「木・火・土・金・水」という「五行」によって』のところがキーポイントで、「木火土金水」という5つの要素で東洋医学のツボや健康などを見ていきます。「木火土金水」は、色でいれば「緑赤黄白黒」か「青赤黄白黒」です。古来より緑/青が混在されるので、どちらでも構いません。

いわゆる、三原色に白と黒を混ぜて5つにするわけですね。光の三原色、ものの色の三原色とありますが、とにかく5つになることが重要です。

相合・相克とありますが、これもどうということはありません。理論的な根拠はなくて、あてはめて後付けしているだけです。あるいは、相合・相克っぽいものを、五行にあてはめてなにかとこじつけをします。

これをコンピュータにあてはめると、このようになります。

よく、コンピューターサイエンスでは、

  • 演算装置(CPU)
  • メモリ
  • 入力装置(キーボード、マウス)
  • 出力装置(モニタ、プリンタ)
  • 補助記憶装置(HDD、SSD、データベース)

が使われます。最近はこれにネットワークを付け加えて六芒星…じゃなくて、6個の分野に分けることが多いのですが、ここは五行思想に従って5つのまま使いましょう。

なんとなく、相合・相克ができたら完成です!

五行大儀

この適当に5つに分けるというのは、私のオリジナルではありません。実は「五行大儀」(あるいは五行大義)という本に書いてあります。

なにかと、物事を5つに分けて分類すると便利ですというパタン・ランゲージみたいな本です。

先の「木火土金水」だけでなくて、色とか味とか様々なものを5つに分類します。5という家数に特に意味があるわけではありません。慣習的に5つに分けるという話です。

なので、方角であっても「東西南北」の4つに「中央」を加えて5つにするとか、味を5味にするとか(甘味、酸味、塩味、苦味、うま味)のように分けるとかします。味の場合は、先に五味があって、味蕾を探すという逆転現象が起こっています。5つ分ける元ネタはだいたいこれが原点です。戦隊もののゴレンジャーとかもそれですね。

陰陽道と易経

陰陽道は「陰」と「陽」を用いて2つに分類するところからスタートします。太極図が示すように陰陽は二つで一体であるし、どちらが上とか下とかいうわけではありません。

陰陽思想自体は世界各国にどこにでもあります。男女であったり性器の形であったり、白と黒であったり、真偽(True/False)であったり、二値のあらゆるものは陰陽思想が発祥です。

この事象を陰陽/正負/真偽にわけて二分岐させたものが、陰陽道であったり易経であったりします。いわゆる占いですね。何かの事象に対して、判断をYesとNoに分けて考えるわけです。何故なに思考は5行思想にあわせて、5回やることにしていますが。易経の六十四卦は2の6条で6回分岐します。これは、卦を3本と3本に分けて混ぜるので計6本になるわけですね。

そんなわけで、易経では未来を64分割して予想します。この考えた方はリスク管理の基本でもあります。リスクを判断するときに発生する割合をYes/Noなどで分けていって、最終的に5,6回ほど判断していけばいいわけで、最終的に大きなリスクやきわめて高い確率で起こる事象ということが分かってきます。同じパターンでプロジェクトの予想もできます。ぜひ、易経をプロジェクト管理に利用してみてください。

さらに、陰陽道では方角の示すことができるので、先の五行コンピュータサイエンスと合わせると、どの部位にトラブルが発生しそうか、あるいは設計に力をいれないといけないかを確認できます。これにより、禁書目録などであるように、玄武などの色を配置してトラブルをさけたりモジュールの強化をすることができますね。これも陰陽道の盤を買って試してみてください。

老子

老子の道教も外せません。かつて、物理学者が道教にはまってしまったように、コンピュータサイエンスを道教に嵌めるのも容易です。

量子力学のスピンやカラー、チャームなどの用語は道教が由来ですし、道教が先の発見者…ということにしておきましょう。ファンタジー味が増すので。

攻殻機動隊の第1巻の最後に出てくるスピンの話とか、仙術超攻殻ORION」に出てくるアマテラスなどの登場人物も無縁ではありません。ぜひ、古事記を読み通してください。日本書紀のほうはまあいいです。ファンタジー味が少ないので。

そんなわけで、道教のタオイズムは物理業界では一定のブームでした。いまはどうかわからないのですが、50歳オーバーの人には非常になじみが強いし、それ以前の物理学者は実際にインドに行って修行をしてしまうぐらいのでオカルトな世界に足を突っ込んでいるので、いまの陰謀論やらなんたらを笑えません。

老子を読むと、色即是空とか、陰陽の玄とか出てくるのでぜひ活用してみましょう。

あと、儒教由来の孔子に対抗するために、老子の道教を持っておくと便利です。先祖崇拝の儒教はなかなか呪縛が多いので、対抗で道教を持ち出すといいです。

具体的にコンピュータサイエンスに活用する例

基本章情報処理的に五行思想や易経を使ってみましょう。先に例を出した演算装置のあてはめやプロジェクト管理だけでなく、いろいろなところに活用…といいますか、こじつけができますw

  • プロジェクト計画を立てるとき、要件定義/設計/実装/試験/運用の5つに分ける
  • コードを書くときに、ベースとなる「土」の部分の共通基盤/ライブラリから作り始める
  • 「土」を肥沃にするためのは、人を教育する「木」が必要となる
  • 五行の「金」は必要ですね。まさしく予算!
  • イテレーション開発のPDCAに対して、「何か」を加えて5つにしいて、サイクルにする。
  • 陰陽の遺伝子を螺旋にしてイテレーション開発する。イテレーションの形は、つまりは螺旋でドリルで、グレンラガンである!

いかがでしょう?いろいろ幅が広がりますよ。

余談ですが、サーバーマシンには落ちないように交通安全のお札を張っておくとよいですよ。

カテゴリー: 開発 | 年末なので五行思想でコンピュータサイエンスを解説してみよう はコメントを受け付けていません

ソフトウェア開発で「生産性」を使うときに注意すること

このあたりの生産性の問題は、リモートワークと社内出社の双方に意見の食い違いがあり、佐藤氏のいう「誰かが顧客要件をキチンとまとめ~」に掛かってきているのかな、というのがある。

著作を出しているので、こっちも踏まえて議論を残しておこう。

主に議論になりそうなのは、第3章からの具体的な開発プロジェクトの話になる。ここの中でリモートとか設計とかコミュニケーションの話がでてくるので、それでよいだろう。

第三部では「現場で役に立つ周辺知識」としてマネジメントの話がでてくる。

  • 第9章 チームビルディング
  • 第10章 設計
  • 第11章 Gitによるリポジトリ管理

ということで前半の技術的な要素(ReactやDjango)とは違い、それらのWebアプリを具体的にどのように会社で開発しているのか?という紹介に近いものになる。

書籍の中には、アジャイル開発、イテレーション開発のような一般的なソフトウェア開発の用語はでてきるのだが「スクラム」や「PMBOK」のような用語はでてこない。これはあえて外したのか、既存のスクラムとはやり方が異なるために「スクラム」という用語を外したのかどうかはわからない。が、第9章や第10章を読む限り、

  • 開発自体はアジャイル開発でやっている模様
  • 顧客とのやり取りやプロジェクトメンバとの情報共有のため文書を積極的に作っている
  • 実際のタスク管理や進捗管理はチケット方式を使っている模様
  • プロジェクトメンバは5名程度で、単独ではない。あるいは大人数(100名とか)ではない。

ということがわかる。

一般的にアジャイル開発でのスクラムやXPなどがうまく回る人数として5~10名程度というものがある。それ以上になると、スクラムチームを分割して別途プロダクトオーナー(社内であればプロダクト・マネージャとか)が担うということなる。これは社内開発=製品開発なのか、受託開発を含めた請負であるのかにもよる。また、本格的な顧客参加型のスクラムチームであるのかにも依るだろう。

なので、「実装に学ぶフルスタック~」にあるソフトウェア開発が適当であるかどうかは、時と場合による。逆に言えば、株式会社オープントーンでは、この方式でうまくいっているという事例となる。

「誰かが顧客要件をキチンとまとめ~」の部分の生産性を考える

先のツイートから伺い知るに、既にチケット化されているものに対して自宅などを使ったリモート環境ではうまく生産性を上げることはできるが、それ依然のチケット化する工程において(設計や要件定義など?)ではリモートワークでは難しいのではないか?という話だろう。第9,10章を読むと、「他メンバーの課題・問題を感知しにくくなる」や「リモートでは仕様書の文書化を意識的に取り組む必要ある」という書き方があるので、プロジェクト内での情報共有や相互のサポートに難点が感じられたのであろう。また、「タスクマネジメントしづらい」という点を挙げていて、手が空いている人にタスクをうまく割り振りにくいという書き方もされている。つまりは、暇な人と忙しい人の見わけがリモートワークでは見つけづらいという難点をあげている。

ここの点からいえば、チケット駆動であれば本日こなすチケットを自らが取りに行くという方式がとられるし、スクラムであればスクラムミーティングというものが存在する。リーダーあるいはマネージャがタスクを割り振るのではなく、メンバー自らがタスクを取りに行くのだ。このあたり、スクラムの手法に沿っていないゆえの懸念点のような気もするのが、うまくいっているのであれば別に大丈夫なのだ。

論点は、それ以前のチケットを作るときの問題となるだろう。

顧客要件をまとめる、おそらく要件定義をまとめたり設計をまとめたりした段階で、WBSに落としていると思われる。この割り振りを誰がするのか?という話になると思うのだが、一般的なアジャイル開発(特にスクラム)の場合は、

  • 顧客の達成目標がプロダクトオーナー=顧客自身が立てる
  • スクラムマスターが、達成目標を適宜ピックアップして、スプリントする
  • スプリントの中で、チームのメンバーがタスクに落とす

という手順になる。なので、チケット(あるいはWBS)に落とすのはメンバー自身だし、つまりは顧客要件=達成目標をブレークダウンするのは、スクラムマスターとメンバーの共同作業となる。

が、先のようにマネージャが顧客の達成目標(つまりは要件定義など)をブレークダウンしようとすると、そのWBSを誰がやるのか?=マネージャがやる、WBSをどうやって計画通りに割り振るのか=マネージャがやる、というスタイルにならざるを得ず、そのために「誰かが顧客要件をキチンとまとめ~」という誰か=マネージャという主張となってしまう。

どうやら、このツイートを受け取った開発者(マネージャも含む?)の意見が分かれるのは、この部分で、

  • チケットはマネージャが作成し、メンバーに割り振る
  • 達成目標はメンバーがブレークダウンして、メンバー自身がチケットを受け取る

という開発スタイルの違いに他ならない。

ゆえに、そこの「生産性」も違ってしまうのだ。

では、プログラマ自身の生産性はどうなのか?

プログラマはプログラムを書くことだけが仕事ではないが、主な仕事はプログラムを書くことだ。昨今では、いろいろな仕事を平行で動かすことも必要なのだが、まあ、最終的にコードを書かないとソフトウェアというものは動かないのは確かだ。

まあ、例外的にノーコードっていう方法もあるけど、それはまた別の機会に。

で、私のツイートした「正直言うと~」の部分を解説しておこう。要するに、ソフトウェア開発のスタイルで、一番高速にモノができあがるのは「ウォーターフォール開発/計画駆動」であることを忘れてはいけない。これには異論があるだろうが、つまりは

  • 事前に完全な計画ができあがること
  • 計画通りのタスクを分割できること
  • タスクは計画通りに進み、手戻りや遅延がないこと

が、最高速にプロダクトができあがっていく計画駆動の条件となる。つまりは、自動車工場におけるオートメーションをソフトウェア開発に応用すればよい。ソフトウェア開発の大量生産工場のできあがりである!

のだが、そんなことは不可能だ。ということは皆わかっている。今では皆わかっているが、かつてはそうしていたのだ。丁寧な設計書や丁寧なフローチャートや綿密なレビューを繰り返していたのだ。

で、実際のところ、長期では難しいのが1週間程度あるいは2,3日程度の短期間であれば、この計画駆動は実に高速に動く。

これが「正直に言うと~」の前半の部分である。

後半の部分は、実際このようなキリキリに詰めた状態だと、うまくいくのいくのだが、非常に疲れるのである。疲労困憊だし、何度も続けてできるわけではない。最終的な納品直前に馬鹿力を発揮できるぐらいである。

なので、トップスピードを保つことはほとんどやらない。特にアクセルを踏むが、たいていの場合は、ブレーキのほうを踏んだままだ…と前に進まないので、オートマの自動走行位のスピードの気持ちでやることが多い。

それって、生産性が悪いんじゃないですかね?という意見もあるだろうが、長期的に見ればこのほうが生産性がよいのだ。体の故障は少ないし、他の人の気配り(手伝いやアイデアだしなど)の余裕ができる。つまり「ゆとりの法則」ができるわけだ。きちきちの作業をやるだけでは、ピースは全く動かなくなっていまう。ある程度の余裕がないとチームはうまく動かない。

わたしの場合は、フリーで仕事を受けることになるので、多数の仕事が平行で走る。シングルタスクの最速スピードよりもマルチタスクのスレッド操作のほうが遅くなるのは IT 屋では周知の事実だと思う。思うが、実際のところは

  • お客からの回答待ちなどで、こっちに待ち時間が発生する
  • 開発が先にできあがっても、お客の都合でリリースなどで待たされることが多い
  • 協力しているメンバーの進捗スピードなどで、待たされることも多い

ということで、結構な確率で「待ち」が挟まってくる。この場合、会社に居れば、待ちの状態でぼんやりと椅子に座っているのも可能(だとまずいんだけど)なのだが、リモートワークをやっていると、じゃあ気分を変えて別のに手をつけておくか、という形にできるわけだ。

ある程度、開発力があればシングルタスクで仕事をやるよりも、ある程度のマルチタスクのほうが作業効率がよいことがわかるだろう。新人レベルならばひとつの仕事べったりのほうがいいだろうが、ある程度年季が入ったプログラマならば、マルチでやらないとちょっと無駄が多いわけですよ。

アジャイル開発スクラムやチケット駆動、PMBOKの基本的なところは下記の本に書いたので、それを入口にして本格的なスクラムやPMBOKの書籍にあたってみてください。もちろん、いきなり「アジャイル開発スクラム」にあたるのもよいです。

カテゴリー: 開発 | ソフトウェア開発で「生産性」を使うときに注意すること はコメントを受け付けていません

GoFとMVCパターンと、ソフトウェア工学のデザインパターンのその後を私見で

せっかくなので、ソフトウェア工学における私がみつけたパターンをいくつか書いておきます。

原著の「Design Patterns」

いわゆる「GoF本」です。「デザパタ」と略されることもあるのですが、巷のデザインパターンの本と区別が付きづらいので「GoF本」で通しています。

日本語訳でもいいのですが、手元には原著のKindle版があります。Kindleってことは、だいぶん後に買ったので、当時(1994年)に読んだわけではありません。日本でのデザインパターンブームが2000年頃(だったっけ?)なので、原著(あるいは訳本)を読まないままデザインパターンを知った或いは覚えた人も多いと思います。私の入り口もそれですね。

ただ、それだけだとコード寄りになってしまうので、いったん原著にあたっておくといいです。が、中身がC++なのでC++が読めないと辛いです。確か、Javaへの翻訳本もあるはずなのですが、GoF本の発端自体が、C++あるいはMVCパターンによるアプリケーション開発の現場からの抽出なので、当時のC++の状況がわからないと読み込めません。いまのJavaやC#だと、GoFの各種パターンが言語仕様に組み込まれた状態になってしまっているので、そのまま読んでも「何でこんなややこしいことになっているの?」としか見えません。

2016年の自分のブログ記事ですが ふと GoF のデザインパターンを再考しておく で GoF パターンを C# で検証しなおしたものがあります。

同時期の Smalltalk best practice patterns

先の GoF 本と同時期に出たケント・ベック氏の書いた本です。買ったのは随分後なので、当時がどういう状況だったのかはよくわかりません。結構高いので、参考までに持っておくというので良いです。

GoF 本と同じく「パターン」と書かれていますが、GoF とは異なり、アレクサンダー氏の「パタン・ランゲージ」を元にしている訳ではありません。UMLのクラス図もありません。コードがSmalltalkで書かれているので、これに慣れていないと読み取れません。

という難点がありますが、ケント・ベックが書いたということと、オブジェクト指向(クラス構造であれメッセージングであれ)を語る上で Smalltalk は外せないので持っています。持っていますが、私としては Smalltalk でオブジェクト指向を語る気はありません。どちらかというと、クラス構造としてのオブジェクト指向(C++やJavaなど)寄りのところで過ごして来たので、別の流れもあるということですね。

ちなみに、メッセージングのほうのオブジェクト指向は Web APIの呼び出しにてかなり実現されていると考えられます。HTTPプロトコルのステータス無し、Cookie等によるステータスの付与、物理的時間的に遠地にあるファンクションのコールなど、Smalltalk の語るオブジェクト指向が別系統でも実現されつつあるかなぁと。つーか、それで十分ではないか、その先に行きましょうよ、って感じですね。

ちなみにその先のパターンに関しては後述します。

追記しておくと、冒頭にある MVCパターンの論文はここにあります。

https://ics.uci.edu/~dfredmil/ics227-SQ04/papers/KrasnerPope88.pdf

大本のデザインパターンとしての「パタン・ランゲージ」

デザインパターンブームの元ネタの「パタン・ランゲージ」です。ご存じ、アレグザンダー氏の著書で高いので、ひと苦労です。しかも、コードじゃなくて建築の話です。

これも2000年のデザインパターンブームのときには買わなかったのですが、のちに購入しました。やっぱり原点をあたってみないとわからないということで。

この中で書かれていることから読み取ると、

パターンの原点であるアレクサンダー著「パタン・ランゲージ」では、現在ある構造物(都市とか商店街とか)を観察すると、部分的な構造物が組み合わさって現在の良い状態があることわかる。逆に、部品の良い組み合わせ、つまりパターンを作っておけば、良い結果を得られやすいのではないか?という発想です。
なので、当時のMVC パターンで作られた数々の完成物、更に成功している製品を眺めた時に、内部構造としてGoFで書かれたようなパターンを見出す事ができた、故にGoFパターンを使うと成功しやすい、という帰納的解法と思われます。

というのが私の結論です。

なので、建築のパターンやソフトウェア工学のパターンを、構造物(あるいはクラス)作成の効率化や、アプリオリ的に構造物とその組み合わせ(≒パターン)をしておけば良い結果が得られる、という思いこみは間違いです。

歴史的に良い結果(建造物の寿命や商店街の活性化、ソフトウェアの寿命など)を得られてきたものを分解してみると、ところどころに良いパターンが潜んでいるということです。この良いパターンや組み合わせを使うことによって、最終的に良い結果が得られる可能性が高いということですね。ここは帰納法的な思考になります。「帰納法」を出して来たのは、ちょうど統計学再入門を読んでいるところなので、当時は「経験上、よくわからないがうまくいくパターンがあるので、温故知新を用いて使ってみよう」という具合です。

私が、よく先人の知恵とか温故知新とか書くのはそれです。

GoF 本あるいはデザインパターンのその先へ

ここから本題です。いまさら GoF のパターンを学んでも仕方がないです。というか鵜呑みにしても、先に書いた通りプログラム言語仕様の中に組み込まれているものが多くて、原著を読んで C++ で読み込んでもたいして知識が得られるわけではありません。

個人的には、組み込みシステムや別途スマホアプリに応用が効くので、ひと通り知っておいて設計に活かすのがベターなのですが、C++ や Smalltalk を学び直して読み込む必要はないかなぁと思っています。

デザインパターンというと「アナリシスパターン」や「ドメイン駆動設計」あたりに走ってしまいがちになるのですが、実はもっとその先があります。

というかですね。アレクサンダーの著書である「パタン・ランゲージ」の派生を追っていくと、他の分野にも応用できると主張されている節がある。

実際、アレグサンダー自身が当時のソフトウェア業界(1994年)に講演をしているので、そこの別業界としての接点があります。

じゃあ、GoF の各種のコードあるいは周辺のデザインパターンのコードではなくて、もっと広い意味で都市計画とか商店街とか人の導線とかいう意味で、ソフトウェア工学に「パターン」は何を与えていたかというと、

「Garbage Collection」では、ガベージコレクションの世代交代が実装されている。今だとGC では当たり前なんだけど、単純な GC だと頻繁に配置側が発生していまうので、利用している世代を分ける。いわゆる、利用する頻度によって分類するという分け方です。これは、キャッシュとか予約発券システムとかに使われているパターン。 単純にキャッシュするのではなく、頻度に対して分布を作るところにパターンがある。

画像の深層学習で一掃されてしまったが「Toward Category-Lravel Object Recognition」というアイデアがあった。特徴量を導き出して、相互の距離を計測して画像認識に使う技で Google とかもやっていました。結果的に、隠れ層を使った7層程度の深層学習(Deep Learning)のほうが効率が良いことになったので、このあたりの実装はなくなってしまったのだが、特徴量的な考え方は統計学とか主要因分析にも応用されているし(おそらく、この当時の画像認識の研究が統計学の応用だろうし)、その後の報酬関数(フィードバックシステム)のパターンがこの当時からあります。生成AIもこのあたりの延長と言える。

こちらは工業デザインのパターンということで、ノーマン著「誰のためのデザイン」。現在は認知科学として捉えるべきなのか?単なるエモーショナルな流行デザインに過ぎないのか不明なんところではあるけど(いわゆるグローバルデザインの話になる)、それでも一種のパターンに従えば、利用者の落とし穴を防ぐことができる。これこそパターン・ランゲージの応用例と言える。
ソフトウェア工学として、一時期UIデザインにも取り入られた筈なのだが、iOS7からのフラットデザインから以降、それが本質的に誰のためのデザインなのかわからなくなっているところがある。個人的には、高齢者カスタムのかんたんスマホのUIとかはいいと思うんですけどね。設定がごちゃごちゃなのはいただけないが、ガラケーっぽいUIに揃えてあるのは、ガラケー主流だった高齢者にはよいデザインだと思う。誰が?という意味では、「高齢者」が使うわけですから。

「コンピュータの中の人口社会」に書かれているエージェントシステムは、ソフトウェア工学のなかで MVC パターンと同じぐらい重要なデザインパターンと思われる。全体を統括的に扱うのではなく、個々のオブジェクトを独立してプロセスやスレッドで動かすというパターン。まさしく、オブジェクト指向による「オブジェクト」の実現なわけだが、それぞれを独立して動かすことにより、相互の影響を環境値として与えることができるのがミソ。いわゆる、品質工学などでいう外乱を内部特性を区別できるシステムである。

エージェントシステムの発想は遺伝的プログラミングとか並列処理とかいろいろ発想が効くので知っておくとよいパターンです。

まとめとしてのパターン

そんな訳で、ソフトウェアにおけるパターンはなにもコーディングに限らないので、システム全体の構築やユーザーの利用動向、UIの作成、PMBOKによるプロジェクト管理、DevOpsやテスト駆動による価値の制御(スループットや計測)などいろいろな場面でパターンがあります。細かい単位のプラクティスではなくて、大局としてのパターン、つまりは軍事ドクトリンに近いのです。みなさま、応用しては如何でしょうか?

といういうブログパターンで〆てみるテスト。

カテゴリー: 開発 | GoFとMVCパターンと、ソフトウェア工学のデザインパターンのその後を私見で はコメントを受け付けていません