アリエルはプログラマは威張っています。開発部長も、肩書きは偉そうですが、単なるプログラマです。ながらく、そんな会社で働いていたし、そういう文化にわざとしてきたので、SEって言う職種がなんなのか、本当のところはわかっていませんでした。まあ、まだ、文字の中でしかわかっていないのですが。

さて、「SEとPG、どっちが頭がいい?(2)」 を読んでみるとその疑問が少し解けたような気もします。残念ながら、ここで言うSEもPGもアリエルにはいません。過去に一時的にいたことはあるかもしれませんが、すぐにいなくなってしまいました。結局は仕様を考えて設計してコードをかける人だけが残っています。

さて、一部の非技術系の経営者は上の記事で言うPGをもっと入れて安価に開発する方がいいと考えています。そういうPGがアリエルで働けないのは、ドキュメントが足りなかったり、教育制度が足りなかったり、会社側の責任だと言ったりもします。ある程度は正しい指摘です。かといって、そういうPGを入れたと言っても効率があがることはありません。以前よりも些細なバグの修正量は若干増加するかもしれませんが、それだけです。まっちゃん(自称20歳)の一日分の仕事を数ヶ月かけてするか、数ヶ月かけてもできないかもしれません。

まあ、僕は自分が楽ができればいいので、優秀な開発者を周りにおいておきたいだけかもしれません。

噂では、ターミネートになるかもしれないし、アップデートされるかもしれないMac Miniですが、僕の家には、会社のコンテストと言う名目で半分だまし取ったMac Miniがあります。今まではモニターにつなげていました。

このMac MiniはiTunesとiPhotoとかをメインにつかっていました。それから開発用にもつかっていたのですが、白いMac Bookを家におくことにしたので、開発マシンとしては引退しました。

 写真をみるのはモニターよりもテレビの方がいいです。なので、テレビ(Aquos)にDVIで接続しました。とりえあずうつります。でも、Full HDのテレビなのに 1300 x 700ぐらい（正確な数値は忘れた）しかでません。何も考えずに1980x1080で表示されると信じていたので悲しいです。

プログラマの生産性を左右するアイテムの一つにキーボードがあります。まあ、うちやすいか、うちにくいかです。僕は割と適応性が高いつもりなので、こだわりは少ない方です。

ノートPCは昔はLet'sシリーズを使い続けてきました。B4のノートはキーピッチが狭すぎてちょっと使いにくかったですが、それより大きなサイズは好きでした。そのLet'sシリーズより好きなものがMacBookのキーボードです。このキーボードが一番気に入っています。

デスクトップというか、外付けのキーボードはHHKをずっと愛用してきました。でも、マカーになってからHHKがだんだんうちにくくなりました。たぶん、キーをしっかり押さえ込まなくてはいけないせいかと思います。基本的に使いにくいキーボードはすぐに捨ててしまうので記憶にないだけかもしれませんが、記憶に残っているキーボードでうちにくいものがAppleのキーバードです。MacBookと同じにしてくれればいいのですが、そうはなっていません。キーボードを打っている感がないです。それと同じぐらいうちにくいのが会社のnakayamaさんが使っているキーボードです。 彼以外そのキーボードを使いやすいといっている人をしりません。好みは人それぞれなので、仕方ないですが。

ちなみに、新しいMacのトラックパッドもいい感じです。 

言い方は色々あるんですが，僕が気をつけていることは「びっくりさせないこと」です。たとえば，プロジェクトの終盤になっていきなり「遅れています」と言うと，まわりの人はびっくりします。突然，遅れていると聞かされると感情的になってしまいます。ちなみに，これはあくまで例であって，僕のプロジェクトが遅れていることはありません。

大体，人は何にでも期待します。期待以上の成果であれば，びっくりしますが，このびっくりはほとんどの場合， 問題ないです。期待以下の場合は，いきなり告げるのではなく，前もって下準備をします。下準備をすると，相手の期待値が下がるので，そこそこの成果でもびっくりはしません。

下準備をしようとしているのに 期待値が下がらないことがあります。時々下がるどころかあがっちゃうことがあります。特に社外とのやりとりで多いかもしれません。下準備の仕方がまずいのかもしれませんが，これはどうすればいいのかよくわかりません。開き直るしかないのかもしれません。

いつの間にか強調されなくなっていますが，アリエルでは会社ができて以来，「早めのレビュー」という文化があります。早めのレビューと言うのは，ソースコードを完全に動かない状態でもリポジトリにコミットして他の人のレビューの対象にしようというものです。実際にはコミットしたからと言って常にすべてレビューされる訳ではありませんが，えらーい人とか，ひまそうな人が時々レビューしています。

早めのレビューは，手戻りをなるべく少なくするためのものです。多分，ソースコードに関してはペアプログラミングが一番いい「早めのレビュー」だとは思います。残念なことは，僕がペアプログラミングが嫌いなことなんですが・・・。

さて，「早めのレビュー」は出戻りを少なくするための工夫なので，実装とテストを短くするとか，仕様策定からユーザの評価までの時間をなるべく少なくするとか，いろいろ拡張されてきました。今ではXPだのアジャイル開発だの言われたりもします。

さて，ソースコードの早めのレビューは当たり前のことのようになっていましたが，過去にはいろいろ諍いもありました。年配のエンジニアの方はテストを通っていないコードは頑にコミットしないようにしていました。テスト前でもコードをレビュー出来ていれば実装の方針などをもっと細かに煮詰めることができたりします。

コンパイルが通らずに製品全体がビルド出来ないとか，そういうものは困りますが，そうでなければなるべく早めにコミットしていつでもレビュー可能な状態にしておくのがアリエルのスタイルです。 

いまでもこの文化をなかなか理解してもらえない人がいますが・・・。 

ソフトウェアの開発にはバグはつきものです。すべてのバグはエクセルなんかで管理するんじゃなくって，ちゃんとしたバグ管理システムで管理し，バグのその後のやりとりも記録すべきです。そして，アリエルではTracを使ってバグ管理しています。

バグのレポートがあがると，追加の情報など，逐次書き込まれて共有されます。情報の蓄積だけでなくコミュニケーションのツールでもあります。以下は今日のtrac上での実際のバグのやり取りです。

バグ報告者:

「添付したスクリーンショットを見てください。ボタンが逃げ出して見えません」

おおたに：

「スクリーンショットを見ると，ボタンは逃げ出したんじゃなくって，恥ずかしくって隠れているようです」

nakayamaさん：

「> 恥ずかしくって隠れているようです

　おおたにさんが見つめるからです」 

 そのあと，まじめな田中さんが隠れたボタンを強引に引っ張りだしていました。

それ以外にも，「イースターエッグが更新されていません。このままではリリース出来ません」と言ってリリースが一日遅れたりしたことがあります。

ちょっと変な会社でしょ？ 

たまにバグのやりとりをみて爆笑している人もいます。アリエルはそうした一面もあるのです。でも，僕だけかもしれない・・・。 

新しいMacBookがリリースされちゃいました。新しいMacが欲しいと思っていたときなので，見れば見るほど新しいMacが欲しくなります。MacBookでDVDとかのドライブをオプションか外付けにして，本体を軽くしてくれればよかったのに・・・。

さて，欲しいのがMacBook の無印かAirです。SSDかHDDかという選択もあったのですが，SSDは高いのと，anakaさまがどっちも変わらないとおっしゃられたので，HDDでいいです。でも，無印かAirかでは悩みます。無印は2kgと重いです。Airはトラックパッドにボタンがついています。どうすればいいのでしょう？ 

みればみるほど欲しくなります。 

昔々，「ザ・ゴール」と言う本を読みました。製造工程で部分最適化じゃなく全体最適化をしましょうと言う内容です。その中で在庫は負債であると言うことが書いてありました。まあ，手っ取り早く言えば在庫は悪と言うことです。これは基本的にアリエルの社内のお話です。

アプリケーションの開発では，日々，膨大な量のコードが生まれます。一日に一人の人が千行のコードを書くこともあります。 で，テストを行ない，出荷されるのですが，テストの途中でコードにバグが見つかることはよくあることです。出荷の間際にバグが見つかると，リリースを延期するか，その機能を削るかと言う選択にせまられます(実際にはもう少し選択肢はおおいですが)。

なるべく機能を落とさない方向で調整しているのですが，そのリリースでは機能を削ることが必要だと判断されれば，そうします。そうやって，出荷されない（できない）テストにパスしていないコードができます。ただし，そのリリースでは機能が落ちだけなので，次のリリースには復活する必要があります。まあ，機能を落とすのはよくないことで，落ちちゃうのはエンジニアの力不足のことが多いので，社内ではとても恥ずかしいことになっています。すくなくとも，誰も何も言わないですが自分の力不足と認識してほしいです。

落ちた機能は，リリース後速やかに復活してテストにパスする必要があります。 理由は，テストにパスしていないコードは誰にも何の価値も提供しないからです。そんなコードは単なる趣味です。次に，人は忘れる生き物です。自分のコードもすぐに忘れます。昨日のコードと一年前のコードでは，昨日のコードの方がメンテナンスし易いです。なので、すぐに機能を復活してテストにパスすれば，最初の実装コスト+今回の修正コストになります。それが時間が経つにつれて思い出すコスト，自分のコードを理解し直すコストが発生して，当初の予定してい工数をどんどんオーバーします。

このことは，機能を実装してからテストをするまでの時間でも同じことが言えます。実装とテスト，修正までの時間を短くしないと，余計なコストがどんどん発生します。

まあ，僕は物覚えが悪いので，自分の書いたコードもすぐに忘れるからかもしれません。 

最近，アリエルの開発の中で「顧客の言うことは聞くな」というお達しがでました。アリエルではパッケージ製品を作っていますが，当然，顧客からの要望も吸収しながら開発しています。顧客要望を吸収するのは当然悪いことではありません。でも，アリエルの開発の人たちは，一部のひねくれ者を除いて素直な人たちが多いです。素直な人たちは，忠実に顧客の要望を必死に聞いて，製品に反映します。ただ，顧客の要望を聞いているつもりが，顧客が提案した解決策を必死に聞いてその通りに作ろうとしてしまっています。

さて，顧客が提案した解決策が本当の解決策であれば問題ないのですが，そうでないことも多いです。僕が「顧客の言うことは聞くな」と言ったあとに，ITProに「理由無き要求は機能化してはいけない」と言う記事が紹介されました。 僕はちゃんとこの記事を読んでいないですが，「オレゴン大学の実験」の絵は懐かしいです。「顧客の言うことは聞くな」と言うのはちょっと極端すぎる言い方なので、この記事を読む方がいいかもしれません。

まあ，僕自身，これができているかと言うと怪しいですが，それはこれからの修行かもしれません。 

「プログラマにとっての読み書きそろばん」は，面白いです。

コードを読むことですが，僕は本当はとってもおおらかです。コードを読んで，このコードはメンテナンスできないと思ったことは，２度くらいしかありません。一つは，50才のベテランプログラマが書いた，読んでいてすごくいらいら刷るコードです。プロ(?)が書いたグローバル変数だらけのコードを読んで，グローバル変数の悪い使い方を学びました。いや，本当はもっと酷かったのです。もう一つは，Javaのコードでむやみに例外ばかりが使われていて，コードがどこにどうジャンプするのか分らないものです。

書くことに関しては，まあ，僕は普通です。多分。とりあえず，アリエルでは，とても大きな設計はあってそれは一部の人だけがおこないますが，もう少しミクロなところは，全員がプログラミングします。えーと，悲しいことにコーディングするだけの作業はありません。なんで，そのようなことしかできない人は，アリエルに来てもすることはありません。僕はそれが正しいことだと思っていますが，そうは思わない人もいるようです。

そろばんですが，純粋な数学的なところはまあ，どうでもいいでしょう。大多数にとっては数学的なことはほとんどありません。で，彼はそろばんとは論理的思考だと言っています。 彼に限らず，多くのところで論理的思考が重要であると言っています。でも，実は僕はよくわかりません。自分が論理的な思考をしているとはあまり思えません。道筋だてて説明することはできますが(これは重要)，それが論理的に考えた結果なのかな？ちょっと違うような気がする。

うーん，僕の頭の中は変な絵が動いているのかもしれない。