検察庁法改正案のまとめ
#検察庁法改正案に抗議する、というタグが twitterで話題になっていますよね。 では実際に検察庁法改正案とは何なのか、どうして話題になっているのか調べてみました。
という、まとめブログみたいな書き出しをしてみましたが、とりあえず気になって調べてみたのですが飽きてきたので、 なれないながらもまとめておいておこうというブログ。
自分が 1時間ほど調べた感想としては
- 検察庁法改正案自体はたしかに問題かもしれないけど程度はよくわからん。三権分立が脅かされる、というのは大げさすぎ。
- すこし前に話題になった黒川検事長の定年延長は納得行かないけど、技術的には話は別
- それをわざとセットにして政治闘争化するのはいいのかよくわからんが、乗りたくはない
- 自然言語で書かれた法律面倒だなあ。ロジバンで GitHubで管理できないかな
検察庁法改正案ってなんなの?
検事の偉い人の役職
そもそも、検察の中でも偉い人たちの人事が問題になっているので、そこらへんのひとはどういう人たちかを調べた。 検察庁:検察官の種類と職務内容によると以下のよう。
- 検察官は検事総長、次長検事、検事長、検事、副検事からなる
- 検事総長、次長検事、検事長は内閣が任命
- 検事総長、次長検事は最高検察庁の長。それぞれ日本に一人
- 検事長は高等検察庁の長
- 検事正は地方検察庁の長
国会議事録
その上で、どう改正するかは 内閣官房:201回国会議事録 にまとまってる。
国家公務員法等の一部を改正する法律案:概要は以下のようなことが書いてある:
- 定年の段階的引上げ: 2030年には 65歳定年
- 管理監督職は 60歳まで
- 60歳以上の給与は 70%
- 早期退職、定年退職者のパートタイム採用
- 防衛庁、検察官も同様、2022年 4月より施行
国家公務員法等の一部を改正する法律案:比較は、読もうとしたけどややこしすぎて挫折した。
改めて改正案とは？
まず前提として、検事とかの定年は一般の国家公務員とは別に決まってた。 検察庁法22条によると検事総長は65歳、その他の検察官は63歳定年だった。 それを全部 65歳にするのは既定路線らしい。ただし、検察総長以外の偉い役職は 63歳になるとやめさせられるのが原則。
しかし一緒にいろいろ延長するための条項も改正案についてきている (改正法案第９条第３項ないし第５項、第１０条第２項、第２２条第１項、第２項、第４項ないし第７項)。 これらは内閣の意向によるもので、これを餌に検察官をコントロールできるのではないか という懸念が生じてるということらしい(東京法律事務所:火事場泥棒を許さない とかより)。
エンジニア的な「動いていたものを変えるな」という勘からして、ここは嫌な動きだと思う。 なくてもやってこられたものになんでそんな例外をつけるのか。 ハンロンの剃刀が好きなので悪意があるとは思いたくはないが、もっと説明が必要な気はする。
とはいえ、そもそも検察総長、次長検事、検事長は内閣に任命されるので、最初からある程度内閣の影響は出ている。 ということで、絶対的に変わるのではなく程度問題なのではないか。 どの程度目くじらを立てることなのかよくわからない。
もう一つ、三権分立の点で言えば、検察は司法府ではなく行政府に属する。というわけで、言葉の上では三権分立とは関係ない。 ただ、それとは別に検察の独立性というのは必要な気がするので、そこの影響は考えなくてはいけないだろう。
黒川検事長の定年延長
それと混同されてる雰囲気を感じるのが、今の黒川検事長の定年延長問題。先に書いたように、これは本来検察庁法改正とは別の話だ。
といっても NHK:揺らぐ“検察への信頼”～検事長定年延長が問うもの～ で理解した 以下の事実からなのだが。
- 稲田検事総長: 2020-07-25 2年任期満了 2021-08-14 65歳誕生日
- 黒川検事長: 2020-02-08 63歳定年のはず (しかししなかった)
- 黒川検事長の定年を 2020-08-07 まで延長することを閣議決定
ということで、なんでここで閣議決定しちゃうのかな、というのはかなり納得行かない。 ここも内閣側の説明が必要とされるところだろう。
まとめ
ということで、改正案自体は問題がある気がするけど、そんなにみんなで大騒ぎするほどではないのかなあ、という気がする。
現黒川検事長の定年延長はもっと突っ込んでほしい気がする。とはいえ閣議決定をひっくり返すってどうやるんでしょ。 三権分立の図で言うところの「輿論」ってやつなんでしょうか。 それを盛り上げるために、今国会で審議されている「検察庁法改正」をつかって twitter上で盛り上げるというのはありなのかもしれない。
いずれにしてもこうやって自分の時間を使って調べさせられてしまったので、ハッシュタグ的には成功ということなのでしょうか。
結局、煮え切らない結論でしたがいかかでしたでしょうか。
自転車を盗まれた
人間というのは、何かがなくなった、もう出会えないという事実を処理するのが下手なのではないだろうか。 とくに、それが愛着のある人や物ならなおさらである。 自動的に、もう出会えないという悲しい事実を認めるのを避けるべく、深層心理が悪魔の証明を求めて悪あがきする。 諦められずに、もしかするとあそこにあるのかもしれない、またちょっとしたら帰ってくるかもしれないと希望する。 ストレスに耐えるための正常化バイアスが発動してるのだといえよう。
ということを話すのも、愛用していた自転車がなくなったからだ。 状況証拠的に言えば、盗まれたというのが正しいのだろう。 朝、会社に乗ってきて、駐輪場に留め、夜、乗って帰ろうとしたらなかった。
観測した事実はそれだけである。 もしかすると、駐輪場の管理会社が移動させたかもしれず、風にのって飛んでいったのかもしれず、 いやむしろ駐輪場に留めたというのも記憶違いかもしれない。 なかった、という事実も信じられず、その後10回ぐらいは見に行った。
いずれにしても希望は砕かれた。管理会社は移動させることはないと言い、強風は吹いておらず、 朝かぶってきたヘルメットだけは手元に残った。
自分は、ある程度理性的であると自認している人間ではあるので、盗まれたという結論を認めるのに吝かではない。 実際、もう警察には盗難届を出したし、ネタとして同僚には話した。 購入金額で言えば 20万円ほどになる、そこそこの価値のある自転車なので盗まれるのも無理もない。 逆に、ちゃんとそこを見抜いた自転車泥棒にはなかなかやるなとも思っている。
ただ盗まれた事実を認めると、自分の落ち度というのも認めねばならないことになる。 実際、結構人の出入りの多い駐輪場に、さほど頑丈でもないダイアル式のチェインロックをしただけで放置しておいたのだ。 防犯上の観点からはいくらでも改善の余地がある。 もっと、頑丈な鍵にすべきだったとか、ダイアル式ではなく鍵式の錠にすべきだったとか、防犯ブザーなどのテクノロジーもつけておくべきだったとか、 そもそもそんな高価な自転車を通勤に使うべきではなかったとか。
しかし、錠を頑丈にしとけばよかったのか、というのは内心疑問もある。 開かない錠はない。ただ、開くまでどの程度時間がかかるかだけだ。 もしかして、犯人は毎日そこに高価な自転車が停まっていることを把握してたのかもしれない。 だとしたら、頑丈な錠をつけていても、それに対抗するような道具をもってこられるだけの話かもしれない。
もちろん、通勤に高価な自転車を使わない、というのは一つの解だ。 しかし、せっかく買った自転車を乗る機会を減らしてしまうのはもったいない。 駅に向かう人々を横目に、春風に吹かれて颯爽と駆け抜けた日々が間違いだったと思うのはむなしすぎる。
というわけでうだうだ後悔したりする日々を過ごしているわけである。 最後には諦めなければいけないのはわかっているが、吹っ切るきっかけにならないかなあ、とここに書いて見る次第である。 慰めは喜んで頂戴する。
ALPを支えられなかった技術(3)
いろいろなエイプリルフールの企画とともにふと思い出したので、ALPを支えられなかった技術の続きを書きます。ほぼ一年間もおまたせして申し訳ありません。
一応、あらすじというか過去の話へのリンク:
ALP第三期 - Monolith
さて、やっと Monolithの話が始まります。 Monolithというのはコードネームで、表向きは Emblaze ELSE といっていました。 とりあえず、MWCで発表したときのデモがあるので御覧ください。
MWC - The First Else cell phone brings a unique interface
今みてもそこそこおもしろいUIだと思います。 現在の、マトリックス状にアイコンが並ぶのとは全く違うスマフォの UIを構築しようとしているのがわかります。
この時は 2009年、すでに iPhoneも 3GSが出ており、日本でもソフトバンクが大々的に売り出していたころでした。 のっぺりしたFeaturePhoneの延長線のUIではなく、ヌルヌルしたUIで Appleを殴りに行くぞという気概は見ていただけるでしょうか。 ELSE、また別のスマートフォンという名前の示すとおりです。
ほかに engadgetの記事も見つけたのでリンクを張っておきます。そこそこ期待しつつも、パチモンなんじゃないかと訝しんでいるのが読んでとれます。
イスラエルの Emblaze社
最初の記事に書いたとおり、最初のALPは GTkをもとにした凡庸な UIで、必要なことはできるけど使っていて楽しいUIとは別のものでした。 ACCESSという、受託開発メインでやってきた会社しても、そこを尖らせた UIを作る気概はあまりありませんでした。
それが変わったのは、イスラエルの Emblaze社とくんだからでしょう。 その名前を聞いたのは 2008年の夏頃、自分がまだ LIMOで悪戦苦闘していた頃のような気がします。 遙か中東から引き合いがあるという話を伝え聞いて、また軸がブレるんじゃないか、そんなに手を出してていいのかと思ったのを思い出します。 元上司が酒の席か何かで、イスラエルの会社と付き合うのは面倒だ、と前職の経験をはなしてたせいかもしれません。
いずれにしても、そのコンセプトビデオをみて、えらいことになったなあ、とか思ったものでした。 ビジュアルエフェクトがバリバリかかりまくって画面がぬるぬる動く、いままで ACCESSがやってきた UIとは別物です。 こりゃ、作れないだろう、担当チームかわいそうだ、とあまり関わっていなかった自分は他人事のようにおもったものです。
が、2008年の秋頃には否応なく関わることになりました。 無茶なのは確かでしたが、一方無茶を実現するのが面白かったのもあります。 少なくとも政治的妥協物をでっちあげるよりはよかったです。
技術
技術的には一期、二期の ALPを換骨奪胎したものになります。
まず、GUIは GTkを全て捨て、OpenGLをベースにした Clutter) というツールキットで作り直すことになりました。 そして、慣性スクロールなどのスマートフォンとして当然の UIが実装されることになりました。 また、前掲のデモにあったようなビジュアルエフェクトは、Emblaze側のエンジニアがシェーダをバリバリいじって作ってくれました。 自分の手の中でそのグラフィックスが動いているのを見た時は、やはりやる気が出たものです。
アプリケーションマネージャは、引き続き使われることになりました。 ユーザIDによるアプリケーションごとのセキュリティ境界などは相変わらずありましたが、 アプリをあとから追加できる設計までにはなっていませんでした。 特に、付属のアプリケーション間での連携は頑張っていましたが、 外部と連携するための Intentのような仕組みには至っていませんでした。
個人的には低レベルな部分を見ていたので、サスペンド、レジューム、ブートシーケンスあたりで苦労しました。 本当にCPUが寝ているかどうかを、電流をはかって調べたのも良い思い出です。 思い返してみればそこでちゃんとレイヤーが切れておらず、アプリケーションレベルの動作がサスペンドなどの基本的な動作に 用意に影響してしまうのがダメダメだったともいえるでしょう。
中止
技術的にはいろいろチャレンジングで面白くはあったものの、いろいろな問題があって開発は 2010年の夏には正式に中止されることになります。 「イスラエルのEmblaze社、First ELSEの開発中止を発表」にあるように、 販売に達するまでのクオリティを達成できなかったのが一番の敗因でしょう。
ACCESS社員の立場から見ると、開発が遅れているにも関わらず必要な機能を絞り込めず、様々なギミックの実装やデバッグによる時間を取られすぎた、という感もあります。 とはいえ、そういった偏執狂的な妥協のなさというのはあの時点で iPhoneと戦うためには必要なものだったのかもしれません。 キャリアと握ってなんとか出せればいい、というものではあの時点では勝てないので。 勝たなくてもいいから Androidと iPhoneの間でニッチを確保する、などというのも無理だったのは TIZENや Windows Mobileの現状を見れば明らかでしょう。
いずれにしても、あの時点では撤退しかなかったのはもったいないけど仕方がなかったとは思います。
ALPを支えられなかった技術(2)
ALPを支えられなかった技術(0) - Snippets の続きです。
ALP第二期 - LIMOを狙って
便宜的に分けた ALPの第二期は LiMo を巡る動きとなります。
とはいうものの、この期の分け方は適当で、実際には複数のプロジェクトが同時に走っていて、 GTkをつかった第一期のプロジェクトと LiMoむけの第二期は社内でも平行して走っていました。 自分は前者のプロジェクトにメインで関わっていたので、LiMoむけの作業はちょっと手伝っただけです。
というわけでどちらかと言うと LiMo関係については担当者の愚痴やらで伝え聞いた部分が多いので ネガティブな印象になってることは否めません。その点はなるべく割り引いて書くようにしますが。
LiMoとは
Wikipediaにあるとおり、ハンドセットメーカー 4社とキャリア2社が連携して携帯用プラットフォームを作ろう、 というものでした。 大同団結といえばいいけど、呉越同舟というか同床異夢な感は当時としても否めませんでした。 具体的になにを作ってなにを達成しようとしてたのか、が末端エンジニアにはよくみえず、 やりにくいなあ、ということは感じたものです。
やりたいこととしては、Nokiaやら Microsoftやら (まだ出荷されてなかったけど) Android や iPhoneに市場を席巻されないようにしよう、という後ろ向きの目標のようなものは感じられました。 ただ、いままで別々にソフトを開発してきて、違う市場に対応してきた各社があつまって 意味のあるものを作り上げられるようには見えませんでした。
LiMoは APIでしかない
今から考えてみると LiMoとは TRON、もしくは POSIXのようなものだったのでしょう。 あくまで APIを一致させ、その上で共通アプリケーションを作り上げられるという。 APIを一致させておけば、アプリケーションとミドルウェアの組み合わせは選べるという。 というわけで、ACCESSが ALPをベースにして作り上げたものは「リファレンス実装」という 位置づけになります。
とはいうものの、世の中はそんな絵空事どおりに動きません。 APIだけでは依存関係を解決することはできず、そこから派生したエコシステムやらがひっついて 回るのが必定です。 Windowsの POSIXサブシステムがあったって、 世に多く普及している Linuxやらのアプリケーションは動きません。
ましてや、まだアプリケーションもない LiMoのことです。 ハンドセットメーカー各社に、共通の LiMoのAPIだけをつかってアプリケーションを書く モチベーションがあったか疑問です。 また、それ以外のプレイヤーがアプリケーションを書いて流通させるチャンスがあったかも よくわかりません。
ACCESSの作ったリファレンス実装
ACCESSはそのような動きの中で、ALPと、すでにあたった Docomoの Linuxプラットフォームを 合わせてリファレンス実装をつくることになりました。 ここらへん、ACCESS以外の各社の IPに関することにもなるので、いろいろ大変だった、 とごまかさせてください。 ただ、いろいろと NECの人などからガラケーのガラケーたらしめる作り込みについて 話を聞けたのは面白かったです。
LiMoのまとめ
個人的見解としては、LiMoは ALPの中では傍流、DoCoMoにお付き合いするための プロジェクトという理解です。 もちろん、そこから LiMoがひろがって各社でつかわれることをもくろんでいたのかもしれませんが、 そこにはいろいろと政治的なとりひきをしなければならなかったでしょう。 個人的にはあまりお付き合いをしたくない分野です。
というわけで技術的な話は今回はあまりありませんでしたが、 次回、Monolithのはなしまでお待ち下さい。
ALPを支えられなかった技術(1)
ALPを支えられなかった技術(0) - Snippets の続き、というか Activityについて突っ込まれたので補遺的に。
Activityと画面遷移
ALPもやはり Androidと同じように Activityの遷移によって画面を構成する、というものになっていました。 これは、Palmからの共通進化といっていいでしょう。 Backボタンを付けてスタック的な動作を可能にしたのも共通です。 Palmにはない機能ですが、Webの Historyから両方共おなじものを学び取ったような気がします。
ただ、Intentのような動的な Activityの解決はありませんでした。 連携先として呼び出される Activityは静的に決まっていました。 ここは、SDKを公開してアプリケーションを作ってもらう体制になっていなかったせいでしょうか。 先に書いたように、アイディアとしてはあったものの未来のものとして先送りでした。
Activityの突然死に対する対策は、呼び出される Activityのパターンが決まっているため それほど洗練されてはいませんでした。 一般的なコールバックとかはできておらず、それぞれのアプリが頑張っていたような気がします。 一つのアプリに関して複数の Activityのインスタンスができた場合どうするのか、とかは 恥ずかしながらボロボロだった気がします。
ALPを支えられなかった技術(0)
歴史だ! 読んで、泣け!
「Androidを支える技術」の著者に煽られたので書いてます。 もう終わった過去の技術の話ですが、エイプリルフールの余興にでもなれば、と。
ALPとは何か
Wikipediaにある ように、日本の ACCESS社が USの PalmSource社を買収して作り始めたスマートフォン OS (or ミドルウェア) です。 とはいうものの、一度も出荷されたことがないので外部の人はちゃんとしたことはわからず、Wikipediaに書いてあることも「違うなあ」という感じです。
煽ってきた有野くんも ACCESSに在籍したとはいえ、ALP開発のころにはすでに MS帝国の人になっていたので、そこら辺の事情を知りたくて煽ってきたのもあるでしょう。
ALPはひとつのプラットフォームのように言われますが、実をいうと市場の変化に対応する 形で融通無碍に変わってます。 2006年の開発開始から 2010年の開発中止までの間に随分とターゲット、 そして使う技術も変わっています。
そこでここでは便宜的に ALPを 3期に分けたいと思います。
ALP第1期は、Palm臭をいかしつつも、DoCoMoとかに売り込めないか、と作業していた頃です。 iPhoneも発売されておらずのどかな時期です。
ALP第2期は、2008年ごろ、もっと DoCoMoにすりより、 LIMO として活路を探っていた頃です。 なんというか、いろいろ政治的な動きがうんざりする頃でした。
ALP第3期は、2009年、起死回生の手を探り Emblazeというイスラエルの会社と Monolithというデバイスを作っていた頃です。 無茶なことを言ってくる会社ではありましたが、技術的には面白かった頃です。
ここらへん、厳密に区別があるわけではありません。 また、当時の資料も私の手元には残っていないので記憶に頼って書いてます。 間違いがあったらもうしわけありません、といいつつ書いていきます。
ALPのはじまり
ALPの開発が始まったのは 2006年、iPhoneも Androidも世に出ていない頃です。各社が組み込み OSの上に独自に作り上げた Feature Phoneが花盛りだけど、Symbianや Windows Mobileなどがその先をにらみつつ小競り合いをしてた頃です。
もちろん ALPもその小競り合いに加わろうというプラットフォームだったのは間違いありません。 小競り合いを勝つための武器の一つが、買収によって手に入れた PalmSource (およびその一部となっていた BeOS) のユーザベースと技術です。 もう一つとして iモード時代に築いた DoCoMoとの関係というのもありましたが、これが吉と出たかはよくわからないところです。
PalmSourceのもっていたもの
PalmSourceは2000年前後には PDAおよび携帯電話用 OS、PalmOSを出荷し時代の寵児でした。 ただ、その後の発展に伸び悩んでました。 マルチメディア、マルチタスク系の機能を伸ばそうと (あの Jobsに負け Appleに買収されなかった) Beを買い取り、 Cobalt を 発表しましたが出荷には至りませんでした。
そうしてジリ貧感が漂っていたところに日本のよくわからん 組み込みソフトウェア会社に買われたわけです。
ジリ貧とは言え、BeOSから引き継いだ技術はいろいろ目につく物がありました。 まずは、Androidでも採用されている分散オブジェクト技術 Binder です。 組み込みOSからは発想が及ばないものでした。
また、Palm時代から培われた Usabilityに関する哲学 Zen of Palm も、 「Androidを支える技術」を読んだあとだと重要なものだったんだなあ、と思えます。 あとがき に 書いてあるような小さい画面での UIデザインについて最先端を走っていた会社ではあるので。
また、その延長線上で Intentや Activityという 技術についても検討されてました (Android以前に!)。
持っていたものではなく失ったもので言えば、 Dianne Hackboneという、後に Androidの開発の重要な部分をしめる開発者も PalmSourceにいたのですが、私が ALPに joinしたころにはもういませんでした。
第1期ALPが選んだ技術
第1期 ALPが選んだ技術はすごい特筆すべき者は実はありません。
まず、GUIは独自のものを作らず Gtkを使っていたあたりで 今から考えるとわかってない感がしますが、当時の技術者の意識としてはそんなもんです。 X11ではなく DirectFBという技術を使おうとしていたのが組込系ですが、 マルチプロセスのときの動作でいろいろと苦労して X11に戻った記憶があります。
あと、実は Binderを使うのは諦められました。 既存の Unix系の技術と相性が悪い、とかいう理由だったかと思います。 IPCは昔ながらの socketをつかってやる、ある意味融通の聞かない形式になりました。
プログラム言語は Cでガチガチに書きます。 Javaのようなミドルウェアを作り込むリソースはなかったのと、 速度が実用的だとは思われてなかったせいでした。 MIDPなどをサポートしたおまけ程度の Javaは視野に入れられてましたが。
今から振り返ってみれば、Androidとの共通点はいくつかあります。
- Zygoteのように、予めライブラリをロードしておいたプロセスから folkするようになってた
- アプリごとに uidを割り振ってセキュリティを確保してた
- Linux Input Subsystemの多用
UI的には Palmを延長したようなものを目指しており、 もちろん flickなどは考えられてませんでした。
このような商品を PalmOneはじめ各社に売り込んでいましたが、残念ながら採用に 至るメーカはありませんでした。
そうこうしてるうちに iPhoneが出て (2007年)、Androidも出荷され (2008年) あわてることになります。
つづき
ちょっとここまで時間がかかったので公開します。 第2期以降はまた後日。
なんで勉強しなきゃいけないの?
雑に書く。
一般的に子供からよく問われるものとして「なんで勉強しなきゃいけないの?」というのがある。
正直、自分はこれに関する答えを持っていない。
自分の体験から言えば、理数系の科目は好きだからやっていただけで「勉強」とはちがう。もちろん、それは役に立っているとは思うがそれは結果論であり、役にたてようと思ってやったわけではないし、役に立ってないこともいっぱいある。
一方で「勉強」の害悪というのもある気もする。単に教わったことを鵜呑みにするような癖である。日本の教育の先生モデルでは起こりやすそうだ。更に訓練されると「学問」は「勉強」という言葉遊びの架空のゲームであり、学生の間だけ覚えていればいいものだという反応を身につけそう。もったいないものである。
そこから踏み出して外発的動機づけによる勉強はよくない、といってしまうとそれはやはり勇み足だろう。いやいやでも計算する癖をつければ日常でも計算はしてしまう。それは単純に検算とかのいみで役立つだろう
まあ、そういう意味で役に立つ部分もあるよね、ってことで一般的な答えになってしまう。あたりまえだ。
さらに言えば疑問の持ち方を変えて「この勉強は役に立つのか?」という個々の問題に変えて考えたほうがいいんだろうなあ。
教育業界的にはもうすこしメタレベルに「勉強するくせ」とかいうのはあるけど、これはこれで別の話になるので別に考えたい。
というわけで雑に考えたので散漫になってしまったが、とりあえず公開しとこう。
