2022年9月アーカイブ

Amazonアフィリンク

中から大規模のソフトウェア開発の実例から、ソフト開発がうまくいかないことによる損失が見過ごせないほど大きいことをデータで示しつつ、旧来のウォーターフォール的なやり方からアジャイル的なやり方へ転換すれば改善できると説いた本。

アプローチとしては、いわゆる「アジャイル宣言」にほぼ沿っている。つまり、エクストリームプログラミング・スクラム・アジャイル・ペアプログラミング・CI,CD・Devops・テスト駆動・リファクタリング、といった内容になる。なぜこれらが良いのかについての根拠が若干弱い気がするが、いずれにせよ、旧来からの開発のやり方から脱却するためのプラクティスとして説いている。

ただ、これらプラクティスのエッセンスという意味では、この本を読むよりも、それぞれの内容そのものにフォーカスした別の本を読んだほうがいいんじゃないかと私は思ってしまった。この本ならではの点が何かを考えてみるに、開発方法の転換を図りたくてもなかなかできないような現場にて上を説得するための材料や根拠をコンサル視点っぽく提供してくれること、なのかな。

とはいえ、最後の章が典型的だけど、やろうと思ってもなかなかできないのが現実で、ひたむきに真摯に取り組み続けることの難しさみたいな精神的な面を語っていたりもする。本著のタイトル「レガシーからの脱却」はそういうところなのかとも思う。

というわけで、アプローチのエッセンスについてはそれぞれの個別の本を参照したほうが良いと思う。アジャイル的な話の中身をわかっちゃいるけど実践できないような停滞感のある現場を知っている人がそれでもやっぱり転換したいと思ったときに手に取るのがよいではないかと思う。

ページ28 2.3.2蔓延「バグ修正に多くの時間を費やす人は少ない」え？逆じゃないの？バグ解析や修正に時間がかかることが多いんじゃないの？ものすごく違和感を感じる記載だった。

ページ63 5章プラクティス1「開発の半分もの時間が要求収集に費やされていた」 ソフトウェア開発者がソフトウェア開発をやっていないというのはもはやこの業界のあるある。仕様を取りまとめたりチェックシートを整備したり進捗確認したりバグチケットの取締をしたり、そういう中間管理の仕事をする人が＊割を占める。＊には好きな数字を入れてくださいな。

● 前置き
世界中の言語の文字を統一的に扱えるようにするという野望を実現するには、自らの常識にとらわれないようにしつつ真摯にUnicodeの仕様に向き合わねばならない。

● Unicodeという名前の誤解
「16bitで1文字にすれば世界中の文字を扱えるやろ」のノリでUnicodeが始まったため、今では UTF-16 と呼ばれているエンコーディングを、昔はUnicodeと呼んでしまっていた。のちに16bitでは扱いきれない事に気づき、16bit超えも考慮したエンコーディングに拡張し(サロゲートペア)、UTF-16以外のエンコーディングも認めた上で、文字集合としてのUnicodeとエンコーディングとしてのUTF-16とを概念として分けた。

● UTF-16のワナ
文字終端が \0 ではなくて \0\0、サロゲートペアのせいで固定長ではない、ビッグエンディアンvsリトルエンディアン、BOMのありなし、そもそも圧倒的に世の中に多いASCIIなテキストも全書き換えの上サイズが倍に、などの理由により UTF-16 が実は非常に使いにくいことがわかってしまった。その結果、7bitがASCII互換となるように意図して作られた UTF-8 が実質的なスタンダードとなった。

● 「2バイト文字」のワナ
日本語含むCJK地域で特に、Unicode以前から使われていたエンコーディングのせいで、非ASCIIな文字のことを「2バイト文字」と誤って呼んでしまうことが未だにある。「マルチバイト文字」とでも呼んだ方がいいのかもしれないけど、まぁ 非ASCII で十分かと思う。UTF-8で日本語だと、ひらがなでさえ3バイト、一部漢字は4バイトになる。そもそもの話として、文字数からバイト数を推定してはいけない。

● 右から文字
横書きの時に左から右へと文字を並べる言語が多いが、そうでない言語もある(アラビア語・ペルシャ語)。どちらかに統一された文章ならばまだよいが、混在する場合にややこしい。ALM LRM RLMあたりを普通は使うが、LRO RLO のように強制的に変更するものもある。RLOはWindowsでウィルスに偽装したファイルの拡張子.exeをわかりにくくするために使われたりもした。

● 合成文字
日本語は通常「は」も「ば」も「ぱ」も独立した1つのコードポイントとして扱うことが多い(合成済み文字)。しかし「は」に濁点記号を足すというやり方もできる。「は」(U+306F) 濁点(U+3099) と続けて並べると、フォントとレンダリングシステムが対応していれば、「ば」という見た目で表示され、単独コードポイント(U+3070)のものと見た目では区別がつかない。しかしコードポイントは異なるので、うまく検索できなかったり、非対応アプリでコピペできなかったりする。さらに「文字数ってどうやってカウントするの」問題も起こる。CJKでは合成文字はあまり使われずに合成済み文字(専用のコードポイントを用意する)が多いが、欧米ではちょこちょこ使われ、アラビア語ではどんなふうに合成されるかが比較的ややこしく、タイ語は非常に難しい。なお、レンダリングシステムが難しくなる(ぶら下げのような考えも必要)が、Unicodeとしての扱いはそこまででもない。

● ノーマライズ
上の合成済み文字と合成文字とを相互変換するようなもの、ごめんうまく説明できない。ただし「株」を「木」と「朱」に分解するようなことまでは行わないため、特にCJKでは違和感を覚えるし、分解するのかしないのかわかりにくい例も多い。また、CJK部首補助・康煕部首、という部首(類)として使われることのみを想定した文字もある、らしい。

● IME
CJKでは、キーボードから直接文字を入力するのではなく、キーボード(やフリック)からは基本的な文字のみを入力して文字の組み合わせから別の文字に変換してから入力を完了させる仕組みを使っている。一般的にIMEと呼ばれるこの仕組みは、CJK以外の人からは存在すら知られていないほど理解されていない。

日本語や中国語(繁体字・簡体字)は主に「読み」を表す基本文字を入れて変換をする。ただし中国は文字が複雑でたくさんあるから他の方式もあり、漢字の部品や書き順を選んで漢字を絞っていく方式もある。

ハングルも読みを表す基本文字を入れる点は同じだが、変換は全く別の文字にすることではなく、複数の基本文字を2から4つ組み合わせて文字を組み立てていくようなイメージの操作になる。合成文字ではなく合成済み文字を出力とする。韓国ではUnicodeができる前からコンピュータが使われていたため、変換のために専用のIMEを使うのが一般的である。このため、IME変換とノーマライズがいまいち噛み合わない仕様になっている。

● 空白文字
U+0020のいわゆるスペース以外にも空白っぽい文字がたくさん存在する。このため、文字の間にしれっと挟むことで検索やコピペ対策になったりする。異体字セレクタのような制御文字も見た目に現れないという意味で同様に使える。

● 意味がグリフで変わる
○(U+25CB)は白丸、●(U+25CF)は黒丸、とUnicodeでは定義されているが、実際に表示させると、○は中抜き丸、●は塗りつぶし丸、となる。つまり、背景黒に白い文字という環境だと、○は黒色に、●は白色になる。ちなみに、U+1F534(LARGE RED CIRCLE)なんてのもあるらしい。本当に赤い。マジ闇。

U+1F5FE は日本列島の絵文字であるが、一般的に本州・四国・九州・北海道っぽい4つが描かれる。位置的に沖縄を描きにくいのはわかるけど、北方領土を描くかどうかで領土問題が起こる。例えばロシアが北海道を消したグリフのフォントを作るかもしれない。

U+1F52B はピストルの絵文字であるが、銃規制のゴタゴタの影響か水鉄砲にする話もある。

U+1F363はお寿司の絵文字であるが、にぎり寿司の絵であることは多いものの、何のネタなのかが各社のグリフで異なることが話題になったこともある。

このようにグリフで意味が簡単にねじ曲がってしまう例は非常に多い。

● 国旗の絵文字
国旗の絵文字は、Unicdeのコードポイントが用意されているわけではない。ISO 3166-1に従いRegional Indicatorを2つ組み合わせてCombining Characterとして表現する。このため、表示できるかどうかは環境に依存し、フォントだけでなくレンダリングシステムにも依存する。将来国旗が変更になった場合、旧国旗と新国旗をどう使い分ければいいのだろうか。政府が変わったとかならホント政治問題そのもの。

● 例の文字
KPS 9566は北朝鮮で使われる文字コードだが、トップの指導者の名前が文字コード的に連続するようにするための専用領域が存在する。これを一般的に「例の文字」と呼ぶ。しかしUnicodeに採用はされていない。笑い話のように思えるかもしれないが、明治(U+337E)・大正(U+337D)・昭和(U+337C)・平成(U+337B)・令和(U+32FF)をねじ込んでいる日本はどうなんだという気もする。

● 更新履歴
2022/09/06(Tue)誤字脱字を訂正