「ソフトウェアアーキテクトが知るべき97のこと」（外部リンク）という書籍が 10／5 に発売されました。

スピーカーは監訳者の鈴木雄介さん、日本人執筆者の id:naoya 、小野和俊さん。

ガチガチのソフトウェア話ではなく、アーキテクト／マネジメントに関する話を具体例で示しつつ進めるという内容でした。
その点で、企画側に立つ人間として非常に役立つ内容。元 SE でもあるので、その点でも共感できることが多かったように思います。

内容をまとめたので、こちらを読んでいただいた方が理解も早いでしょう。いくつかリンクしたいのですが、また後日貼りたいと思います。

ソフトウェアを作る上で、コードを書く以外に大事なことトークセッション

鈴木雄介さん × 伊藤直也さん × 小野和俊さん（以下、敬称略）

鈴木：
今回の97本日本語版を出すにあたって、せっかくだから日本人にも書いてもらおうと。
コードをバリバリ書くという以外に何かを持っている方に執筆をお願いした。
今トークセッションでは伊藤さん、小野さんにお越しいただいた。

自己紹介
・具体的な例でエッセイを説明していただければと

伊藤：
内容についてはほぼエッセイに書いた通り（※オーディエンスには印刷したエッセイが配布されました）
はてなブックマークを開発したことについて少し。
はてブは膨大なデータを貯めているが、利用者には少ししか見せられていない。実際活用出来ているのは 5% ほど。
はてなの検索エンジンにおいてプリファードインフラインストラクチャーと一緒に仕事をしていて、
データを貯めるだけでなく、見せる、有効に活用するという技術も重要だと分かった。

小野：
コードを書くことについて。
以前はペアプロばかりだった。ペアプロは、短い時間でバッと帰られるのがメリットでもある。
ただ、以前会社の若いメンバーとのペアプロであれこれ指示をしたところ
「小野さんには分かるかもしれないけど、私にはすぐに理解できない部分もあるんです」と言われハッとした。
仕事や相手によって、仕様書を出して説明する必要があるケースもあるだろうし、ペアプロが向いている人もいるだろう。
TPO によってやり方やコードの書き方は異なってくる。

鈴木：
SIer につとめている。SIer は相手の会社の歴史や文化とどうつきあっていくか。
具体的な例として。相手は、とある医療機器の企業。
在庫の回転率が悪い商品が見つかった。このことを指摘したら、先方に怒られてしまった。
「有事の際に工場がストップしてしまい、在庫の冗長性が取れないとその機器が必要な患者が困るからだ」
という指摘であった。企業文化とのつきあい方を考えさせられた。

・いまなにをやっているの？

伊藤：
20〜30 人だった社員数が、いまは70人に。
はてブがメインで、他のはてなサービス、技術者全体のマネジメント／ファシリテーションを行っている。

小野：
マネジメントから戻ってきた人間。いまはほぼプログラミング。

鈴木：
パワーポイント：プログラミング：マネジメントが１：１：１の割合。
予算獲得のためのパワーポイント資料も書くし、プログラミングもするし。

・最近興味があること

伊藤：
最近検索エンジンに関わってきたこと、あと学生時代からコンピュータサイエンスは勉強していなかったことから、
統計、数学を勉強している。

小野：
クラウド。バズワードと言われているが、バスワードではなくなるはず。
クラウド上で何を残して、何を使って、データをどう連携させるかに興味がある。

鈴木：
業務モデル分析をやっていく上で、どう推量エンジン（？）を使えるか研究をしている。

以下、アーキテクトということで話のネタを

・アーキテクトとしてのターニングポイントはどこだった？

伊藤：
在京時のはてなでは、マネジメントしていなかった。
まずエンジニアは苦手なことを避ける傾向にある。
ある時期、インフラがボロボロになった。インフラをデータセンターできっちり構成することに。
インフラ構成はチーム作業。サーバーをマウントし、OS をインストールするという泥作業も。
マネジャーとして、モチベーションを与えながら作業分担をすることに。

インフラだけでなく、例えば現場に潜ってると障害発生時などは、そこに集中する。
そこでマネジメントなんて出来ない。そういう時に「次のミーティングの件なんですけど…」と言われても対応できない。
全体を見る人がいない。そこでファシリティの重要性を実感。

小野：
米国サンマイクロシステムズ時代の話。ダグラスの件。忙しいときほど、重要なことがいくつあるか分からなくなる。
米国時代に、一回仕事のリセットボタンを押す重要性を教わった。でもそれはあくまでも米国サン時代の話。日本の方が品質はいい。
両方組み合わせたらいいものが出来ると考えたのが、企業のきっかけ。
いまデザイナーとプログラマーは合体している。同じようにアーキテクチャーとエンジニアは一緒になるべき。
今の会社（アプレッソ）には DJ が多い。会社に DJ 部を作ったのは良かったと思っている。

鈴木：
最初、アーキテクトと言うのが恥ずかしかった。会社経営を考えるにはマネジメントをやらないと、うまく回らない。
そこで、アーキテクトという言葉がぴったりだった。みんなにアーキテクトという言葉を広めたい。
プログラマーという職種とは別なものなんだと。

・過去のソフトウェア開発での失敗談など

伊藤：
マネジャーなんて必要ないと思っていた。
天才プログラマが一人でもいればマネジメントの必要ないんじゃないか？ということはなくて、
例えばその人にお願いする人が必要になる。
プログラムに自信がある人ほど、プログラマーの言うことを聞く。自分はある程度プログラミングが分かるのが良かった。

小野：
プログラマーも、相手がプログラムに自信がある人なら言うことを聞くよね。
あとは徹夜の話から教訓を学んだ。

伊藤：
障害が発生しないシステムを考えるのは当たり前で、それでも障害は発生する。
人の割り当てとか、アーキテクトが重要なんだと。

小野：
サッカーの話で例えれば、11人全員が相手陣にいくようなもの。
みんなでワーっとやれば一体感もあるし楽しいが、試合には負ける。

伊藤：
サッカーということで言えば、今までサッカーや野球の監督、オーケストラの指揮者なんて必要ないと思っていたが、
いまの立場になって重要性がわかる。

鈴木：
失敗談で言うと、3年かけてＷｅｂサービスを立ち上げようとしたが、うまくいかなかった。
別のチームが引き続きやってくれたが、エンタープライズの感覚と、伊藤さんのように
Web サービスを立ち上げる感覚は全く違うもの。そのバランス感覚をそこで学んだ。

・アーキテクトの視点から見たマネジメントの必要性の有無、有るとしたらその意義

伊藤：
はてなは仕事を依頼されるわけではない。自分たちでサービスを考えないといけない。
家でコードをよく書く。コードを書いて、プロトタイプを作って、会社で見せるような。

鈴木：
人と仕事の分析。設計書やパワーポイント資料の作成は大事だが、コードで表現することも大事。

伊藤：
データマイニングの重要だと思って人にやらせようとしても、結果が面白くない場合、モチベーションを下げることになりかねない。
まず自分でやってみるのが大事。

小野：
マネジメントがまったくない状態は、つまりマネジメントレスは問題だが、マネジメントも必要悪的にとらえている。
3人で新製品を作ってるが、そこではマネジメントをあまりしない。ここがいい、どこが悪い、ということだけを見るようにしている。
新製品を作るプログラマーだけで話をさせるようにしている。

鈴木：
マイクロソフトには、MS 認定アーキテクトというのがある。ただ、試験監督は社外のアーキテクトを使っている。
大企業には大企業のやり方があるんだなぁと感じた。

・良いソフトウェアを作るために心がけていること、大事にしていること

伊藤：
はてブの土台設計をしっかり作ることによって重要性がわかった。
コメントが一覧で見られるというところから、設計的にこうするべきだろうというのが分かった。

鈴木：
作ることは大事だが、使うことが大事。
作りやすいからいいよね、使いやすいからいいよね、のバランスを取るための視点が大事だと思ったりする

伊藤：
以前は作りやすい方向に向かっていた。
はてブも自分で書いていたが、あるときにニコニコ動画部隊の方から「自分で書いちゃだめですよ」と指摘されて、
自分で書くことについて見直した部分がある。

小野：
使いやすいソフトウェア。ユーザビリティの良いソフトウェアは場合によって違うと思う。
米国はあまり情報を集めていない。意外と情報に疎い。

いま会社では新製品開発に携わっているが、新製品を作るときに既存製品は一回壊す。
何かを作るときに、いま必要な情報をバーっと集めてやっている。それが新しい技術だとは限らない。
速さとか使いやすさとか、そのときによって使う技術は異なってくる。
壊すという意味で、意識的にリセットボタンを押すようにしている。

鈴木：
もうちょっと抽象度の高い話があれば。

伊藤：
twitter や iPhone を持っていない。会社を見ても、周りはみんな使っている。
例えばそれを使って、それに先鋭してしまうと、非利用者の考えがわからなくなってしまう。

小野：
自分は好きなことはのめり込むタイプで、こうしているのが嫌いというのはない。
WoW のクエストを日本語化したことによって、仕事に技術的に反映されていることもある。
結果的にいいフィードバックだったりもする。

鈴木：
ポリシーとして、本屋でソフトウェアの本は買わない。
ここジュンク堂もだいぶお世話になっているが、買うのは建築の本だったり、芸術の本だったり。
ソフトウェアやプログラミングについては、社内の詳しいエンジニアに聞くようにしている。

ここで質問です。

質問１．ＩＴ業界は不景気と言われているが。

小野：
ラストマン戦略があることが大事。

伊藤：
もう一つ軸を持つこと。たとえば執筆の仕事とか。
マーケティングや経理など、基礎価値があると不況にも強いんじゃないかなと。

鈴木：
一時期、○○思考法という本をたくさん勉強した（※私も一時期読んでました。読まなくなったなぁ）
あとライフハックという言葉が嫌い。ライフハックというのは、自分のクロックアップ。
そんなことをしても世の中をフォローするだけになってしまうのではないかと。
やはり、お二人がいま話したような、別の軸があるというところではないか。

小野：
同じくライフハックという言葉は好きじゃない。
コモディティ化しているだけ。資格も似ている。
ある資格を取得しているとして、同じ資格を持っている人が代わりになりますよ、という証明書になってしまっている。
よほど難しい資格でもない限り、自社採用基準では意味がない。

伊藤：
自分も採用という点で言うと、資格は見ない。
いくつか資格を持っているが、例えば履歴書ではブログの URL が書いてあれば見る。
毎日コードを書いているとか。あとは過去に作った作品とか。

質問２．小野さんは起業されたわけですが、採用する上で一緒に仕事をする人間として何を見ているんですか？

小野：
自分のコアコンピタンスはどの場所にいるか。

伊藤：
チームを作る上で、それぞれセンスの違うエンジニアを集める。
アルゴリズムを考えるのが得意な人間、ユーザー登録フローに自信がある人間、UI にセンスのある人間、など。

質問３．鈴木さんに質問。コミュニケーションをデザインすることとは？

鈴木：
ユーザーから見たときに、ボタンがあるとして、ボタンを押すことについてユーザビリティだけでなく
何をしたいのか、何をするのか、ユーザーがどうするかまで考えたほうがいい。
経験の相対化が重要なんじゃないか。

伊藤：
はてブを作ったときに、コメント一覧を出したときに、他にどうするかじっくり考えた。
レコメンドとか古い記事を出すとか。