Chromebook Flip C100PA を買いました
普通に働き始めると、やっぱりいつでもPCは持ち歩きたいなぁ、と思ってしまう、PC原理主義者の私です。スマホもタブレットも電子書籍端末もいいのですが、受け身なだけでは満足できないのです。……が、そこはオールドタイプなので、何かを書こうとするとキーボードが欲しくなってしまいます。
というわけで、主に常時携帯のモバイルPCとして Chromebook Flip を買いました。
10インチっていいよね！
結論から言えば、小さくて軽くて安いからです。
ご存知の通り、今年の頭に ThinkPad X121e を買ったばかりなのです。11インチの X121e は、世間一般には十二分にモバイルPCなのです。
なのに新たにモバイルPCが欲しくなったのは、わたしにとって11インチは常時持ち歩くには少し大きくって、少し重い。お外で明確にPCを使う用途がある場合にはいいのですけれどね。
このサイズ・重量感は 多分わたしにとっての最初のモバイル機 ThinkPad s30 から来ているもので、10インチ、だいたい1kgくらいというあたりに「超えられない壁」があるみたい。
どうして Chromebook Flip?
一時期のネットブックブームも去りタブレットに淘汰され、10インチPCは非常に選択肢が厳しくなりました。このジャンルは結構水ものなので、市場にあるうちに買わないとダメ…というのがわたしの経験則。後継機待ってみても碌なことないです。
今買うなら Let's Note RZ4 か この Chromebook Flip。両方共とても魅力的です。ヨガタイプなのも「悪魔でPCだけれども、ごろ寝シチュエーションでタブレット風にもつかえる」という体はいいですね。トップヘビーにならないし、合体ゆえの重量増もないのでキーボード付きでも軽く仕上がるのは美徳です。
そんな両者の中でChromebook Flip を選んだのは、なんといっても値段のやすさ。そして Chrome OS への好奇心。ついでのおまけで見た目が好み*1。どうせ Linux を使いたいので、その環境構築の容易さもあるかな。
開封の儀
と、前口上は以上にして、開封の儀。……実はわたし、Amazon.comから個人輸入で買っているのですが、記事にする前に 日本でも発売開始されちゃって、ちょっと…いえ、だいぶ悔しい。
ちなみに購入したのは上位の 4GBメモリモデル。お値段は、ちょうどセール中でちょっとお安くなっていて、送料込で $268.87。これに輸入税等の前払金が $21.51 （後で戻ってくるかもと淡い期待）の、トータル $290.38 、日本円にして \36,369 でした。国内コンシュマーモデルはメモリ2GBしか選択できなくって \42,980 なので、日本語キーボードにこだわらなければ、こちらのほうがお得です*2。
さてさて、話はそれましたが
箱はこんな感じです。……なんだか送られてきたときから開封済みだったのですが。
まぁ、気にしないことにします。
箱をあけるとこんな感じ。
決してコストをかけているわけではないのですが、シンプルで好印象なパッケージ。
箱から取り出してみれば、なんだか MacBook っぽいアルミのボディ。パクリ(というかリスペクト？）といったら見も蓋もないですが、ミニマリズムなデザインは、Chromebook のコンセプトとあっていて、可愛くて好き。
サイズ比較と各種ポート
さて、これまでのモバイルマシンと比べてみましょう。
フットプリントはほぼ互角ですが、
厚みはこんなにちがいます。Chromebook Flipならば 2冊……ううん、3冊は束ねられそうです。
ちなみに マイ初代モバイルPC の ThinkPad s30 と比較。
横方向のサイズ感は近いですが、さすがに4:3のアスペクト比だから奥行きはだいぶ違います。
ちなみに、現在のメイン Linuxノート ThinkPad X121e と重ねるとこんな感じ。
11インチと10インチじゃ、やっぱりだいぶ大きさが違いますね。
サイズ感がわかりやすいように文庫本と重ねてみました
こう見るととても小さいパソコンに見えますね。
ポート類
左右のポートを見てみましょう。
電源は「ちょっと厚めの Micro USB」といった風情の独自のコネクターになっています。ACアダプター部は Nexus7(2012)のを彷彿するもので、PC用というよりスマホかタブレット用という印象なのですが、見た目と裏腹に 12V 2.0A の出力なので、もちろん Micro USBでは給電出来ません。将来、後継機種がでたら USB Type-C ポートに置き換えられそうですね。
その並びにはインジケータLEDと電源ボタン、音量ボタンが。いよいよタブレットPCじみてきますね。 ちなみにChromebook は ファンクションキーの位置に音量ボタンがあるので、こちらは音量ボタンはホントにタブレットモード専用です。
反対側（右側面）。USBとかmicroHDMIとかmicroSDカードスロットとかのI/Oポートで固められてます。
ちなみにこの写真では microSDカードが挿入済み。挿しっぱなしでも出っ張らないので、16GBしかないストレージの拡張に良いかな？*3
キーボード
いつまでもアルミ板風の状態で眺めていても仕方ないので、起動しませう。
天板はアルミ、ボディ底やヒンジは銀色塗装の樹脂、キーボードの面はおそらくアルミ版のプレス加工かな。一見 MacBookっぽいく仕上がっていて、その実しっかりコストダウンしているのですが、手に触れる面がちゃんと金属になっていて、ひんやり感触に高級感を感じて良い感じ。
キーボードは Chromebook のシンプルさと相まってかなりかっこいいです。
肝心の打鍵感ですが、ストロークが若干浅いかな、というところはあり、底をフォローすべくかクリック感が強めになっているのは、薄さを追求している「いまどき」のキーボードだな、と思います。が、それでもそれなりのストロークを確保していて、かつ、打鍵感もクリアな感じで結構打ちやすい、総じて悪くないものに仕上がってます。
この薄さ、この価格帯であることを考えれば、購入前の想像以上に立派なキーボード仕上がっていて、満足です。天板が一応アルミプレスなので、強度的にたわみにくくなっているのも貢献してるのかな？
キー配列
Chromebook のキーボードデザインは PC の歴史的経緯を引き継がず、あくまで Chromebook として ChromeOSと抱き合わせで再設計されています。だから大変シンプルで使いやすい配列に仕上がっています。
スペースバーの列がスッキリしているのが好印象です。必要なキーに絞り込んで、残したキーには十分なサイズと必要な「空白」を与えるというのは、優れたキーボードデザインの鉄則です。
CapsLockを排して 検索キーを配置しているのは さすがだな、と思いました。Windowsですと、同等の役割のキーを「Windowsキー」と呼び、スペースバーの列に無理やり割り込ませてしまったのは、アドホックの極みでしたから.. (^^; 一方でここは、このユーザーの好みがうるさそうな一等地。OSの標準機能で簡単にアサインを変更できるあたりは「わかってる」と嬉しくなります。もちろんあたしは「CtrlはAの横」！
大胆に Deleteキーを削ったところもいいです。当然 PgUp/Down や Insert, Home/End もなくなってしまいましたが、これら「デスクトップPCでメインキーの隣にあったキー」は、ノートPCではいつでも配置に困ってしまうものでしたが、旧来の互換を考えると削れない部分でもありました。これは OS毎デザインできる強みですね。
ファンクションキーの列に用意されたキー郡は、Chrome OS とノートPCに必要な、「ファンクションキー」がアサインされています。使ってみれば確かに「キーとして有ると便利」とか「物理キーで操作できないと困る」機能で、ちゃんと考えられてアサインされているな、と実感します。
このソフト・ハードが一体で設計されている感とそれゆえの設計の美しさは、どことなく Mac を想像させます。なるほどChromebookを指してのプアマンズMacBookは、こういうところを指してるのかな？と思いました。
さてさて、話は変わって、こちらは発売されたばかりの日本語版 Chromebook Flip のキーボード。カタログもWebサイトも英語配列の写真なので、店頭展示機をパチリさせていただきました。
変則キーサイズなのは BackSpace の横のキーくらいで、CtrlもAltも大きく、小さいPCの割にはキーサイズに余裕があってこちらもいい感じ。
crouton で Ubuntu を入れる
ChromeOSだけで完結するのが本来の使い方だとは重々承知しているのですが、やっぱりLinux使いたいよね、ということで Cruton を使って Ubuntu 14.04LTS (Xfce) を入れてみます。
crouton(ChRome Os Universal chrooT envirONment) を使えば、お手軽簡単に chroot環境下に Ubuntuとかをこしらえることができます。
crouton を使うには、まずはデベロッパーモードを有効にします。esc + reload を押しながら電源ボタンを押すと、レスキューモードで起動します。
そこで Ctrl + d を入力するとデベロッパーモードに移行します。
デベロッパーモードに移行するにはローカルデータ消しちゃうよん、やだったらすぐ電源切ってね、と言われるので無視します。
デベロッパーモードでは crosh (Ctrl-Alt-T で起動するChromeOSのCUI）で shell と入力することで bash が使えるようになります。ここから
$ wget http://goo.gl/fd3zc -O ~/Downloads/crouton $ sudo sh -e ~/Downloads/crouton -r trusty -t xfce,keyboard,audio,cli-extra,extension,xiwi,chromium
で、Ubuntu 14.04 環境を構築します。ちなみに -r オプションは インストールするディストリビューションを、-t はパッケージを選びます。
Shellが動くとなんか「パソコン」って感じがしていいですね。ちなみに結構時間がかかりますので、気長に待ちます。
インストールが終わったら、Chrome 拡張の 「crouton integration」 を入れておきます。
sudo startxfce4
すると、(当然ですが) Chrome とは別プロセスで xfce デスクトップが立ち上がります。
わーい。
ちなみに crouton integration は、先ほどの -t xiwi と合わせて、Chrome のタブとして Ubuntuを動かすことができるようにする Chrome拡張です。はこれなしでも crouton は使えるのですが（その場合はCtrl + Altで切り替えるそうな)、やっぱり、
みたいなことができるのは、とても便利です。
日本語環境化
日本語環境化は、とても簡単なので、ちょろちょろっと。
$ sudo apt-get install language-selector-gnome
$ gnome-language-selector
で日本語を選んで、ログアウト→ログインするだけ（...だったと思う）。
追記:
上記内容は多分嘘で、ubuntu 日本語 term の PPA の追加とかやらなきゃダメだと思う。参考:ubuntu on Chromebook の日本語化 - 物欲投げ捨てblogさん。あと、最初「うわーん、日本語のWebページが文字化けしてるよぉ」とまずフォントだけ入れた記憶もあったり。
(追記おわり)
日本語入力環境はもう少しだけ面倒くさくって、
$ sudo apt-get install fcitx fcitx-mozc fcitx-libs-qt5 fcitx-frontend-qt5
で環境を入れたら、Xfceの[アプリケーションメニュー]→[設定]→[xcitx設定]を選び、お好みに設定。
sudo で エディタを起動して、 /etc/profile に以下を書き込み
export GTK_IM_MODULE=fcitx export QT_IM_MODULE=fcitx export XMODIFIERS="@im=fcitx"
電子書籍リーダとしてとか
Chromebook Flip を選んだのは、いつでもモバイルPCの用途と共に、ゴロゴロ Web閲覧ツールとしても期待していて、そういう用途に ChromeOSはピタリとハマるんじゃないかな、と期待しています。タブレットみたいにもつかえるノートPCですね。
タブレット風でもその実態はノートPCなので、いつでもキーボードが引き出せて、お腹の上とかでタイピングできるのが強みです。
で、ChromeOS、もちろんブラウザは問題ないのですが、電子書籍リーダとしてはちょっと弱いな、というところ。でも Kindle Cloud Reader で少なくとも洋書と漫画は読めますので、弱いながらもそれなりに。
両手なら楽勝、片手でもギリギリ重くないかなってくらいの重量ですので、一応タブレット的に使うのも現実的な大きさ・重さです。
電子書籍リーダーとしての Chromebook Flip ですが、画面面積からいうと、だいたい Nexus7(2012)と同じサイズのページを見開きで表示できるような感じ。
Nexus7を上に重ねてとってみました。
だいたい同じくらいのサイズですね。
このサイズは漫画文庫よりもちょっと小さいかな、くらいで結構読みやすいサイズだと思います。が、Nexus7 は あの大きさで1280x800px。Chromebook Flip も面積は倍以上なのに 1280x800px なので、やっぱり解像度が足りません。
うーん、粗い。
PCの画面としては十分な解像度なのですが、漫画を読むにはもうちょっと解像度がほしいですね。とはいえ、「読む」ことは十分できますので、電書リーダーとして意外に活用してしまってます。
で、ChromeOSってどう？
なんといっても、この低スペックマシン(Rockchip)であっても、軽い軽い！ サクサク動きます。専用機ってすごいね。そしてバッテリーが信じられないくらい持ちます。こんなに薄くて軽くて9時間持ってしまう。ChromeOS という割りきり環境のおかげだけれども、実感としてのコストパフォーマンスがすごいので、これは本当にメリットですね！
キーボードの項でも語ったのですが、キー配列のデザインは、OSと一体で考えてあるだけあって、チョイスや使用感が「理にかなっている」と感じます。Aの横にCapsが来た経緯とか、日本語キーボードの醜い拡張劇とか、とかくキーボード配置は惰性と考えなしと政治で汚れ続けた歴史なので、理詰めで最小構成を目指したギークらしい使い勝手のキーボードが「標準」であることは、本当に快適です。
アーキテクチャの視点でメリットを語るならば、いわゆるアプリケーションがインストールできないことが、操作体験の統一に役立っているのですね。Chrome というアプリに向けて「いわゆるOS」も含めた 何もかもが最適に組み立てられるのです。これはちょっとAppleっぽいユーザ体験ですね。
よく「ブラウザしか使えないPC」「普通のPCに比べてできることは限られる」と紹介されて、それは間違ってはいないのだけれども、そういう「Limited PC」というのとはちょっと違う感触です。この blog を見に来る人には通じるかな、とおもいますが、いわゆる「Emacsから出ない」と本質的に変わらないかな、と思いました。
つまり Emacsian に（比喩ではなく、本当に） EmacsOS を与えてしまったようなもの。…そう考えれば、この OS が 意外にも玄人好みのアーキテクチャであるという感触に共感してもらえるんじゃないかしら。
Chrome OS の不満点は？
今のところの唯一の不満が、Google日本語入力で ローマ字テーブルをカスタマイズできないことです。つまり AZIKが使えない。
より本質的には、不自由さや不具合を自前で解決することができないことでしょうか。そこは割り切りですけれど、環境側の整備をまたなくてはいけないので、不運にもちょっとした「障害物」が現れた時、それを避ける手段がないため、ショーストッパーになってしまうこともあるでしょう。特に日本のユーザはまだまだ少ないので、不具合が未解決だったり、必要な道具が揃ってなかったりというシチュエーションに遭遇することが多そうです。「普通の人向け」は、まだちょっと危険かな？
まぁ、そこは Linux 上で暮らせばいいわけでして、そういう人にはとても過ごしやすい環境です。
「もう少し内蔵ストレージほしい（Ubuntuも入ると16GBじゃ不安です)」とか「Amazon さん Cloud Reader で日本語の技術書読ませて」とか「Dropbox クライアントは ARM 対応して欲しい」とか、小さなハードルはあるのですが、そこも醍醐味です。
なにげに満足度の高い買い物で、わたしはとても気に入っています。
コミケット1日目
（自分向けメモという感じです。忘れない内にメモっとけ！）
- 素敵なカタログ
- 総本部88
- 東京タワー擬人化
- フィギュアの完成度が凄い（写真）
- 服の部分は3Dプリンターだそうです
- タイプライターを触らせてもらいました
- うまく文字が打てない! こんなに難しいんだ
- いつものトイレットペーパ写真集
- 一発ネタとおもいきや、すっかり定着しました
- 今回は冬。雪によく似合います。
- マリみて
- 既に主コンテンツは EOL になって久しい感じで大分規模が縮小してますが、今残っているサークルはずっと残るんだろうな、という顔ぶれです
- ドム御一行さん
- ストーリとして起承転結がしっかりした作品が多いドム御一行さんですが、今回はおしりが中途半端。
- でも、「おまけ」の部分がとても良い感じで、好印象。さすがにうまいなー。
- イングレス本
- ノスタルジックアイス
- 真夏の会場でこの本は卑怯です。凄い食べたくなって、帰りにアイスキャンディー売りのおじさんからアイスキャンディーを買ってしまいました。
- 技術女子の日常 お徳用1
- 人生ハードコースだと、やたらポジティブになりますよね
- 震災→タイ洪水のコンボとか、リーマン・ショック後の派遣切りとか、自分の思い出とリンクしてやたら懐かしモードになりました。
- 「どうせやるならでっかい会社で仕事がしてみたい。そう思い、派遣会社に就職をした。学歴も経歴もないので、派遣でしか大手企業で働くことはできなかったためだ。派遣で働くメリットはそこだと思っている」
- なぜか小説ブースでみかけた Qt本
- まさかのアサルトリリー本
もっといろいろあったハズだけれども、1日あけたらすっかり忘れてしまいました...。
傘についてつれづれと
富士通の川崎工場は、せいぜい4階程度の低階層ビルと余裕のある庭園や更地・駐車場を擁する広大な敷地の中、一つだけ 21階建ての高層ビルがそびえ立つ構成であるため、ビル風が半端ないことでも有名です。わたしも、川崎工場におじゃまするときはそのビル風で泳いでも泳いでも岸に辿りつけないカルガモをみてはムフフと微笑んだものでした。
この突風は「アンブレラクラッシャー」としても有名です。本社下は風向きが変わるため、傘の向きを壊れないように保つのは至難の業で、わたしも手持ちの傘を次々とクラッシュさせられてしまったのでした。
さてさて、というわけで、そうです。傘が無いのです。
先日、一張羅の傘が老衰のためお亡くなりになり、急遽、お出かけ前に代替の傘を選ぼうとしたのですが、上述の理由でビニール傘を含めた余分の傘が一掃されており、本当にお勤めに持っていける傘がなく困りました*1。もう、何年も前の話なのになー*2。
そこで、先日このような傘を購入しました。
http://www.mabuworld.co.jp/products/storm.html
http://www.mabuworld.co.jp/products/storm.html
グラスファイバーの骨とおちょぼになっても大丈夫な機構で、風で壊れにくいことを歌った傘です。・・いえね、結構トラウマだったので(^^; でもおかげでこないだの台風のときに早速壊さずに住みました。
まぁ、それはそれとして、この傘のグリップ形状をみて、おもいだしたものがあります。
http://www.mabuworld.co.jp/products/storm.html
昔、こんな握り手のビニール傘があったような。ものにかける輪っかの部分がもっと独特だったと思うのですが、グリップの部分はそっくり。
そういえば、あのビニール傘も骨を樹脂にすることで「壊れにくい」を歌っていたはず。あれ、なんて傘だったかしら。
・・というわけでちょっとネットを捜索。そうそう、これでした
http://www.nikkeibp.co.jp/article/column/20090205/130111/?rt=nocnt
http://www.nikkeibp.co.jp/article/column/20090205/130111/?ST=manufacture&P=3
ひょっとしたら、と思ったのですが、残念、今回買った傘のメーカーさんではないのですね。
Evereon というお名前のこの傘ですが、ビニール傘なのにちょっと強気のお値段と、独特の握り手の形状で、昔欲しかったのですよね。ビニール傘の方が視界が確保出来て便利・・・だけれども、「安物」「野暮ったい」「壊れやすい」というイメージがあるので、そこを払拭すればニーズができるかも・・という話は、当時共感したものでした。
街の傘売り場で見かけなくなったので、いまでも売ってるのかな、と思い調べたのですが、元気に販売中のようです。今ではなんと替え革まで売っているようです。当時「環境負荷を軽減する」と行っていたとおりですね。
というわけで、どうせ傘のストックもないのですし、よしっ、これも買っちゃおうかしらっ♪・・と思ったら、梅雨が開けてしまいました...。
というわけで、秋の長雨か、来年の梅雨時までに、忘れないように備忘も兼ねてエントリーした次第です。うにゃうにゃ。
ThinkPad が dis られて悲しい
職場に ThinkPad X240 が まとまった台数購入されていて、しかもそれへの不満から ThinkPad が盛大に dis られていて悲しいです。いわく、
- 5ボタントラックパッド が大層使いにくい
- 品質がよろしくない
・・・・うっ。
最初のやつ、5ボタントラックパッドですが、まぁ、すごく使いにくいですね、アレ。
2015年モデルからはトラックポイントの物理ボタンが復活しているので、この特徴は 2014年モデル一世代のものとなりましたから、買った時期の運が悪かったという話なのですが、運で片付けてlenovoを擁護するような話でもないのは確かです。
わたしも店頭に触りに行って「これはないわー」とかやっていたのですが、はじめて「実作業」で使用すると、想像以上に使いにくいですね。十年来のThinkPadユーザなのにまったくTrackPoint がうまく操れないという..。手がTrackPointを覚えているから、バーチャルな感じのボタンでも行けると思ったんですけど、甘かったです。
X1 Carbon の Adaptive Keyboard といい、ちょっと試作してみただけで使いにくいことくらいすぐにわかったでしょうに、どうして強行してしまったのか、とは思います。
品質面については、直接見ていないので又聞きですが、無線LANがプツプツ切れたりとか、いろいろあったみたいです。X240に限らず、lenovo になってからは トラブルが多いという印象があるようです。ネットでも目にしますね。
この点については、IBM時代もモデルによっては持病持ちとかいろいろあったなぁと思いますので、わたし個人としては、設計的な品質じゃなくって、製造的な品質ですとかサポートの問題ですとか、そういうパラメータが大きいような気がしているのですが、本当の所はどうなんでしょうね？
実態はともあれ、「ThinkPad は堅牢」「壊れにくい」というイメージが失われてしまっているのは多分確かで、だからこそ最近「日本・米沢生産」を強調し、品質のイメージアップを頑張っているのかもしれませんね。
* * *
ThinkPad の売りといえば、「奇をてらわない『標準』であり、品質がよく、なにより頑健」というイメージでした。この３つは「プロの道具」として素晴らしいブランド力ですね。
「標準」は PC の本家 IBM だからこそですし、その象徴としての7段キーボードでしたし、ユーザが保守・修理することを想定したハードウェアでありました。クォリティの高い UI や UX のためにコスト増になっても良いと考える社風と、ノートパソコンに求められるUX のために必要とされた頑健さが ThinkPad の ファン層を育んできたのでした。
「標準を大切にすること」については、lenovo自身が「やめました」と公言しています。これについては賛否両論なのかもしれません*1。でも、品質論についてはみんなが「ちょっとなー」と思っていると感じていて、それは先に述べた問題もあるのですけれど、なによりも今の ThinkPad ってすごく安っぽく感じるんですよね。
たとえば X240 って X121e や Edge とかの「XじゃないライトX」「ThinkPad じゃない ライトThinkPad」と、もう品質の差――コストをかけた頑健さやUI/UXのリッチさを感じられないのですよね。X100 や Edge が登場したときには確かにあったそれがなくなったということは、つまりクォリティダウンしているということになります。
往年のThinkPad ファンとしては「lenovo は もう二度と買わない」と言われると悲しくなるのですが、反論できずに頷くしか無いというのが、また、たまらなく切なく感じました。
もしかしてそれは lenovo になったからというより、環境がかつてのThinkPad のようなPCが商売になるような時代とは違う、ということなのかもしれませんが、どちらにしても「終わった」ことには変わりがないのです*2。
ご報告
というわけで、さらっと職場の話が出てきたとおり、めでたく就職することができました。
転職先を決めないで「会社やめる！」と踏み切った時は、かなり楽観していたのですが、現実は「お祈り」されること多しでした。しくしく。それは、自己評価が高すぎた、という大きな要因はさておいて(^^;、チャレンジャブルな転職が難しい年齢になってしまったのね、とも、しがらみが求人案件のガード条件として予想以上に強く働くことを実感したりとか。そうしてみて、はじめて「何を選ぶか」を真剣に考えた気がします。
やめたよエントリのコメント欄で求人についていろいろな方からご親切を頂いたのですが、返答もせず不義理をしてしまい申し訳ありません。悩んでいる内にお返事の時期を逸して放置となってしまいました。
実際の所、終わってみれば自分にとってもサプライズ転職な感じになりまして、辞めた時にやりたかった「チャレンジ」とは別のことになってしましましたが、ことチャレンジャブルという点については他の選択肢と比べても、相手をとって不足がないものとなりました。
この先自らがどうなってしまうのかさっぱり予想が付きませんが、とりえあえず当面の収入が安定したので我慢していた技術書買いまくってます。リーマン・ショック以降下がった年収分のしわ寄せがここに来ていましたので、欲しい本がいっぱい溜まっておりましたのよ。しあわせです。
続・技術的負債というメタファーについて
昨日 技術的負債というメタファというエントリーを書いたけれども、それから少し考えてみたら、間違ってたかなと思う所があったので、続編エントリーを。
わたしの感覚ですと、okuさんのエントリーの「汚い方」――Smart UI と、「綺麗な方」――Layered architecture で作られたソフトウェアは、同じものの汚い/綺麗というよりも、たまたまある領域では同じ目的につかえるけれども本質的には全く別の製品であって、それをわたしは「プレハブ」と「きちんとした家」に喩えました。
そして「プレハブで十分なところにきちんとした家を立ててもしかたがない」というジャッジが、真か否かを問うのに「技術的負債」というメタファに基づくモデルで語る領域じゃないんじゃないかしら？――というのが前回のエントリーのダイジェスト。
だけれども、わたしが間違っていたのは、okuさんの文脈でも技術的負債についてはすでによく語られていて、例えばファウラーの以下のエントリーはそのものズバリということになります。
ファウラーのエントリーでは以下、「プロジェクトのスタミナ」というキーワードを元に、このジャッジメントについて考察が続きます。
設計に関する作業には時間も労力もかかる。それは間違いない。でも、それだけの価値はある。 将来そのソフトウェアを成長させるのが楽になるからだ。設計をサボったら、短期的には時間の節約になるだろう。 でも、そのぶんだけ技術的負債はかさみ、後々の生産性を落としてしまう。 ソフトウェアの設計に力を入れると、あなたのプロジェクトのスタミナが向上するのだ。 成長する速度も上がり、長生きできるようになる。
設計を軽視したプロジェクトの問題は、設計を軽視したが故に、 コードベースがだんだん劣化して変更しづらくなるということだ。 その結果、生産性も下がる。というのが、グラフの勾配にあらわれている。 きちんと設計をすれば生産性もきちんと維持できるので、ある時点（design payoff line：設計償却線） に達すると、設計を軽視したプロジェクトよりも累積の納品量が上回るようになる。 そしてその後は、ずっと上回ったままだ。
この仮説から、こんな系を導ける。設計償却線に由来するものだ。 最初のリリースに含まれるある機能が仮にこの線より下にあるとすると、 設計を軽視してでも開発速度を追い求めた方がいいかもしれない。 でも、もしこの線より上にあるのなら、そんなトレードオフはまやかしだ。 納品予定の機能が設計償却線を上回る場合は、設計を無視すれば、必ず納期は遅れる。 これを技術的負債の用語で言い換えると、融資を受けたのにその元金をずっと使わずにいる状態に等しい。 ある一定の時期を過ぎてから使い始めると、支払う利息が増えてしまう。
oku さんの エントリーはファウラーのこのエントリーの payoff line がどこにあるかを 負債というメタファーでバインドした金融のモデルにて検証しようとしたもので、面白い試みです。ただ、この payoff line については ファウラー自身は
ここで気になるのが、じゃあ実際のところ、設計償却線はどのあたりにあるのかということだ。 設計＝スタミナ説に賛同してくれる人たちの間でも、この件については大きな見解の相違がある。 私は個人的に、一般に言われているよりもずっと低い位置にあると思っている。数ヶ月ではなく、数週間というあたりだ。 しかし、これはあくまでも個人的見解だ。
と言っていて、わたしもそれに同感です。
okuさんが例として示した「年単位の運用 / Smart UI VS. Layerd architecture」 では、なんぼなんぼでも「そんなトレードオフはまやかしだ」に該当するかと思われます。つまり okuさんのエントリーは「例」がいささか非現実的に感じるので、大本のアイデアも眉唾に感じてしまったということです。
ですが、そういう ノーデザインとグッドデザインの選択 自体を技術的負債という文脈で語る事自体は 的外れではないので、わたしの先のエントリーはダメダメでしたね...orz
* * *
その反省の上でもう一度語るならば、技術的負債は 運用保守にのみ関わるのではなく、リリース前の開発中の生産性にも関わるので、「初期開発コストと運用コストのバランス」の「初期開発コスト」として、SmartUIは そもそも安くつくのか？に疑問を感じます。
本当に「クソコード」は 初期開発コストが安くつくのか？ という問について、現実的なプロジェクトでは、概ね否かと思われます*1。喩え3ヶ月程度の短納期プロジェクトであったとしても、どんなに仕様がシンプルに思えたとしてもです。「安くつく」という感覚は、ファウラーのいうとおり「まやかし」に過ぎません。
では、oku さんのアプローチが当てはまるケースがないのかというと、それは「きちんとした設計」の中での「可能性への拡張性」へのジャッジメントとして、あるいは「きちんと設計仕様としたけれども、負ってしまった負債を返却すべきか」のジャッジメントとして、生きてくる話なのかな、と思います。「今から思えばこのモデルは間違っていた」というのを 直せずに保守し続ける……というのはよくあるお話であって、その「直したほうが得か否か」を客観的に判断できるのであれば、それはとてもナイスなことです。
ファウラーも語る通り、生産性は計測不能 だし、設計の品質もまた計測不能なので、okuさん的なお話で正しいジャッジを出来るのかについての検証は非常に困難に思えますし、できるとしても実際に適用する段において 正しいパラメータを導き出せるのかは、やはり難しいように感じます。
ですが、その「難しい感じ」を、金融のモデルを「技術的負債」に当てはめるアプローチがうまく扱えるかも、という話になっていると聞きおよび、「技術的負債」が比喩を超えてそういう面白いことになっているということを今日まで全然知らないでいましたので、きっかけを頂いた oku さんのエントリーには感謝です。
まとめにかえて
okuさんのところで紹介されていた
「「技術的負債」を問いなおす」というタイトルでJAWS DAYS 2014で話してきた #jawsdays
のスライドがとてもよかったです。
古典的な（=わたしの）「技術的負債」についての認識を
- 適切に返却される分には、開発のスピードアップという意味では、むしろ望ましことですらありうる
- “技術的負債”は、技術者間のみならず、非技術者との間でのコミュニケーションに役立つ比喩であるべき
- そのために、どういう“負債”があるのかを分類・整理する
- まず意図的か、非意図的かに分類できる。次に無鉄砲に行われたか用心深く行われたかに分類できる
- そもそもこの比喩は「ダメなコード」を意図的に書くことを支持するものではない。そうではなく、あとでリファクタリングできるという認識が大事
と簡潔にまとめた上で（特に最後の１項が超大事！）、「技術的負債」という比喩がひとり歩きすることによる問題に触れ（前回のエントリーで書きたかったこと）、それでもあえて比喩を更に押し広げてみることに有用性を見出す
- 不確実性のもとでの意思決定プロセスについては、経済学やファイナンスにおいて蓄積がある。そうしたモデルが役に立ちうる(Kruchten et al.,2012)
- “負債”という比喩の可能性をもう少し押し広げてもよさそうだ
という面白いアプローチについて説明していて、読みやすく、誤解に基づく批判に先の杖をついてある、納得しやすい良資料でした。
ちゃんと読んでからエントリーを書けばよかったですね...。
技術的負債というメタファ
技術的負債についてはじめて知ったのは、マーチン・ファウラーの「技術的負債」というエントリーでした。
システムに新しい機能を追加するとしよう。2つのやり方があるはずだ。ひとつは、早いけれど、ぐちゃぐちゃになるやり方（将来、変更が困難になることは分かっているよね）。もうひとつは、キレイな設計だけど、導入に時間のかかるやり方。
「技術的負債」とは、Ward Cunningham が作ったメタファーである。上記の問題について考える際に、この言葉が役に立つ。このメタファーを使うと、早いけれど汚い解決方法は（ファイナンなどスの負債と同じく）技術的な負債が発生する、ということになる。 通常の負債と同じく、こちらの負債も利子を払う必要がでてくる。
(中略）
このメタファーを使うと、早いけれど汚い方法がなぜよく使われるのか、ということを説明できる。ビジネスの世界で市場機会の優位性を得るために負債を負うのと同じように、開発者たちは重要な納期に間に合わせるために、技術的負債を負うことがある。ただ、あまりにもよく見受けられる問題は、開発組織は自分たちの負債をコントロールできなくなり、将来的な開発作業の多くを利子を払い続けるということに費やさねばならなくなる事だ。
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?cmd=view&p=TechnicalDebt&key=%B5%BB%BD%D1%C5%AA%C9%E9%BA%C4
ソフトウェアに対する 機能修正を行う際（これは機能追加だけでなく、仕様バグ・設計ミス（仕様の認識間違い）などによる機能修正も含む）、「汚いけれども早いやり方」を選ぶ場合、その早さの代償としてソフトウェアが背負うものを「負債」に喩えたものです。
かつてわたしが師匠の元ので組込みソフトウェアを開発していた際、テストフェーズ以降に発生した修正については、設計上正しくはないけれども修正による影響範囲が最小で、素早く修正出来る方で修正していました。この項目についてはかならすメモを取り、納品（リリース）後 だいたい1週間という期間を切って、その期間無いで出来るのであれば綺麗な修正に置き換えました。できない場合は本来やるべき綺麗な設計をドキュメントに残しました。
リリース後のコードから「汚い部分」を取り除く作業を、師匠のチームでは「ブラッシュアップ」と読んでいて、かならすそこまでを工数としていました。
もし、本当に納品したソフトウェアがそれっきりのものであった場合、この1週間の工数は払うべきでないのかもしれません。しかしリリース後に出てきた「要望」に対応したり、そのソフトウェアを土台として新たなソフトウェアを作るということは、実の所、よくあることです。
そして、どうせ技術的負債を返すならば、そのソフトウェアのことを覚えている内に返してしまうのが一番です。日を於けば忘れてしまうことで、思い出したり、理解する工数が発生してしまいます。だからリリース後すぐにブラッシュアップするのが一番オトクです。徹底的に合理的であった師匠らしいプロセスでした。
しかしこれを独り立ちしたわたしがやろうとするときに立ちふさがる「そういう事態が発生してからで良いじゃん」という意見は「動いているならそれが正しい」「汚くっても正しく動くならなにが問題あるのか」という観念と深く結びついて、そういうことを肌で知っている人以外に、うまく納得させることができるのかというと、難しいな、と思っていました。
後日この「技術的負債」というメタファーを知ったと時、この払うべきコストを「わかっていない人」に「払うべきだ」と納得させるのに、とても良いメタファーだと感心したのを思い出しました。
* * *
JavaBlack さんの「技術的負債は避けるべきか？」もちろんです． - カレーなる辛口Javaな転職日記 を読んで、そんな師匠との きゃっきゃっうふふ な エピソードを思い出しました。
その必要性を理解出来てない人に説明するのに「うまく出来ているな」と思われたメタファーを逆手に、「返さなくていい条件はいずこ」と考察する okuさんのエントリー はある意味びっくりでした。読み物としては面白いと思ったのですが、はたしてこの「負債」というメタファーはそこまでの検証に耐えるほど、きちんと「負債」のモデルに乗れるものなのか。
技術的負債というメタファで大切なところは、
- 早くて汚い修正の対価は「負債」に似ている
- 「負債」を抱えるという選択肢はもちろんあるが、「負債」には利子が発生する
- 「負債」を抱えすぎるとやがて返済不能に陥る。
というところだと思います。
上記エントリーに対する個人的な見解は、技術的負債は「最初から汚い設計」の問題点を語るためのメタファにはあまりふさわしくはないのでは？、です。Smart UI を選ぶべきシチュエーションの考察において、「技術的負債」というメタファを持ち出すことは、モデルとしてあまり有益には感じません。
「プレハブ小屋でよいところに立派な家を立てる必要がない」という程度のお話に「負債」というメタファが登場する必要性をあまり感じないからです（負債云々の前にプレハブ小屋は構造的に増築できませんし、ある程度の規模以上のものをプレハブで安全な建造物にすることはできませんから）。
※これは「顧客が本当に必要だったもの」の文脈かもしれませんね。
ですので、この文脈で技術的負債を引っ張りだすのは、言葉遊び以上の意味はないと考えますが、あえて乗っかるとするならば、利子が利子を呼び借金だるまになって首が回らなくなる様が「技術的負債」という比喩の肝だと思っておりますので、JavaBlack さんの
なんで糞コードの維持工数が「定数」なんだよ
に深く共感いたします。また、その「利子」の示すものは単に運用工数だけでなく、指数関数的に高まっていくバグの発生率という面もありますので、バグによって発生する損害という形で表面化する「コスト」もあわせて考察すると、より面白い読み物になるかな、と思いました。
新しい回路図の記号について
恥ずかしながら最近知ったのですが、新しい JIS 記号だと*1 AND とか OR とかのシンボルの形状が変わったそうです。
JIS C 0617 電気用図記号 [cega]
抵抗がキザキザ線から箱に変わったりしてたのは知っていたのですが、こんなのまで変わってしまっていたとは知りませんでした。
なぜ、こんなふうに変えたのか、本当の背景はよく知らないのですが、専用の作図ソフトじゃなくても WordやExcel の 図形でも描けるようにするため？ とか想像します。各論理が形として区分されない改変ですので、図としては見難くなる方向だと思います。あまり嬉しくはないですね*2。
おそらく技術の現場ではガン無視でしょうけれども、学校教育ではこちらを使うんでしょうねぇ。中の文字の意味 (=1 とか ≧1 とか)は、入力がこの条件を満たしたら真が出ると意味……ポイですが、ここがテストで混乱して学生を悩ませる所になるのでしょうか。
