読書感想文」カテゴリーアーカイブ

あぁ、テストエンジニア

いちばんやさしいソフトウェアテストを読んだ

いちばんやさしいソフトウェアテストの本 (技評SE新書 19) (技評SE新書)
石原 一宏 布施 昌弘
技術評論社
売り上げランキング: 14416

ソフトウェアを開発するうえでテストというものは必要不可欠な話である。ただ、ソフトウェアのテストエンジニアや品質管理者というものを目指す!という話をあまり聞いた事がない。これは私が聞いた事がないだけの話かもしれない。
本書はその現状を打破するために作られた本ではないかと思う。
テスト工程は、あくまでテストする対象となる機能。ここで言うとプログラムがない限りは実際のテストは出来ない。もちろん、仕様上の不備・不具合を指摘したりそれに合わせてテスト計画を練る事もとても重要な作業だ。ただ、肝心の開発が予定通り進む事は稀で往々にして遅れが発生する。その時に削られるのはまっさきにテスト工数がやり玉にあげられる。
バグを見つけたら見つけたで開発側からは裏切り者扱いされたりもするかもしれない。もちろん、バグを見つけたという事は間違いなく評価されるべき事で、そのままプログラムが世に出た時の被害を考えれば素晴らしい事。ただ、納期が迫ってただでさえ遅れが発生している開発担当者の感情的な心根としてそういう発想につながってしまう事もあるだろう。
本書でも第6章で涙ぐましい対策が語られている

常に挨拶と礼節を心がけ、開発者とチームメンバーとよりよい関係を目指します!
(中略)
そこで、テストエンジニアは常に開発者と良好な信頼関係を保ち気軽に話ができるようになっておく必要があります。(P126)

開発側に属する私としては色々と頭を下げたくなる内容だ。
これからのソフトウェア開発を考えると品質というものはより求められ、それに比例するかのようにテストエンジニアの価値というものはどんどん上がっていくだろう。
本書がそのきっかけとなってくれる事を願う。

ただ、本書は対象とする読者をどこに置いているのだろうか?実際に開発に携わっている人間にとっては本書は優しすぎる。そうなると、対象読者はだれになるのだろうか?
第1章は優しいものの、その後はV字モデルの説明、W字モデル。名前だけならAllPairsや直交表も出てくる。
うーん、対象は学生なのかな?

革新的ソフトウェア企業の作り方

Eric Sink著。青木 靖訳の「革新的ソフトウェア企業の作り方」を読んだ。内容は、Eric Sinkという人がMSDNのコラムにしるしたものを集めたのだと思う。

Eric Sink on the Business of Software 革新的ソフトウェア企業の作り方
Eric Sink エリック・シンク
翔泳社
売り上げランキング: 24226

本書はソフトウェア開発者に向けられて作られた本であるけど、実際の内容は完全なビジネス書だと思う。著者はもっと多くのソフトウェア企業が世の中にはあるべきだと考え、マイクロISVという形態を提唱している。
本書で言うところの「マイクロISV」というのは、個人がISV(Independent Software Vendor:独立系ソフトウェア会社)を立ち上げる事になる。ただ、本書で薦められているものは脱サラ起業ではなく、いわゆる”週末起業”的な話。技術者であるソフトウェア開発者がそれを行おうとした場合に何に留意するべきか。どういう方向性で考えて行くべきかが本書では指南されている。
先般、ソフトウェア開発未来会議においてクラウド・コンピューティングが話題になった。ここで個人からみた視点として、iPhoneで言うところのAppStoreを例に挙げ、個人が作成したソフトウェアを世界に向けて配信する方向性の話が聞けた。オフライン会議に参加して、ここに強く共感を覚えたのはおそらく本書を読んでいる最中だったからだろう。

かなり刺激的な内容で、私自身も小さいながらISVに努めている事から色々と学ぶ事が多い一冊だった。また、昨今のクラウドに対する考え方やMarketPlaceがこの時期に出てきたのはもはや自分のためにあるのではないかと甚だ恥ずかしい勘違いをしたくなった。
また、ソフトウェア開発者であるならばぜひ読んでいただきたい私にとってお勧めの本となった。

何を作るのか

どんなアプリケーションを作るのか。技術者の多くにとって不足しがちな商品開発におけるマーケティングの重要性があげられている。私もどちらかというとそうなのだが、”この技術を何かに使えないか?”という出発点ではなく、”この内容を実現するのにはどの技術が使えるのだろうか?”という、本来当たり前の出発点が必要になる。

「重要なのはユーザーにとってどうかということ」というのを覚えておこう。ユーザーが普通の人たちなら、彼らが.NET CLRをダウンロードしインストールする準備ができているだろうか注意して考える必要がある。普通の人々はすべてが「当たり前のように動く」ことを期待している(P.174)

そう、結局のところ技術は技術者にとっては主役なんだけどユーザにとってはどうでもいいことなんだ。Silverlightがどんなに操作性が良くても.Netの生産性が高くて製品の値段が抑えられても、インストールの手間がかかっていたのでは障壁になってしまう。これは意外と馬鹿に出来ないコストだ。言ってしまうと、我々開発者はその技術が一般化するまでは待たなければいけないことになる。ユーザーがアプリケーションを仕事として使っているのでない限り。

また、製品のマーケットの中での位置づけはどうするのか。
最近よく読む”週末起業”だとかの中では主に”その分野の先がけ・パイオニアになれ”という事がしきりに言われている。本書でのアプローチはこうだ

競合を避けることの大きな問題は、それが顧客をも避けることになるという事だ。競合の存在はお金を払っている顧客の存在を意味する。あなたのアイディアで商売をしている人が誰もいなかったとしたら、それが本当にお金になる事なのか怪しいと思うべきだ
(中略)
彼は、一番良いアプローチは「大きくて無能な」競合を見つけることだと言っている。(P.144-145)

完全に新しいマーケット。ブルーオーシャンは認知されるまでに大変大きい労力を要する。個人が週末レベルでそれを広めているのでは何年先になるのかがわからない。また、それがマーケットとして成り立つのかが不明だ。
マーケットの中で出来るだけ無能な競合を選び、そことの差別化を図る。製品の値段を決定する場合にも競合製品と見比べ、さらに価値を高めて値段を上につけて売り出す。もちろん、差別化した内容が、その価格差に適合しているのかは見極めないといけない。
だが、これらを考える基準を作る事が出来るのも競合がいて、そこのビジネスが成り立っているからであろう。やみくもにブルーオーシャンを探してニーズを無理に自分で想像していないか、確認する必要がある。
もちろん、そこにマーケットを見つけ出せるのであればブルーオーシャンを否定するものではない

より多くの失敗をしろ

この本で面白いのは、この主題を書きあげるためにEricが自らソフトを作って試してみたということだ。彼が作った”必ず勝つ方法があるソリティア”。その名も「Winnable Solitaire」だ。だが、彼の試みた今回の挑戦は結果として失敗した。

2004年9月29日の時点で、Winnable Solitaireは6本売れ、あんまりすごくない合計42ドルの収入を上げた。
支出が0だったなら、新たに得られたこの富で豪勢に買い物をするところだが、開発の際、アートワークのために379ドル使った。また、リリースして以来271ドルを広告で使っている。<中略>結論として、私の損益計算書には現在純損失626ドルと記されている。(P.50)

この失敗に対してEricは10の考えを記事にしている。「勝てる」というのは差別化要因としては弱かったのか?別な種類の製品であったなら?等々
これはよく言われる話ではあるけど、成功するためには多くの失敗をし、その多くの失敗から学ぶ必要があるという事だ。今回もEricは「これは素晴らしい失敗の仕方だと思う」、「小さな失敗で私が傷つくことは全くないと思う」等々の記事を記している。
結局のところ、多くの失敗をして学んだとしても次につなげることができなければ最終的な成功を収めることはできない。そのために致命的な失敗をしないための保険なりをかけておくべきなのだろう。
作ったばかりで売れてもいないソフトウェアに一人で惚れこんで、勢いあまって会社を辞めてしまうようなことはするべきじゃない。そこまでしなくてもマイクロISVという形態であれば十分可能性を試すことができるんだよってことだろう。

実際のところ、環境は整ってきていると思う

実際のところこのマイクロISVという事を実践するための環境は着実に整ってきているのではないだろうか。
クラウドコンピューティングは多くの開発者にサービスを提供する場を与え、AppStoreやWindowsMarketPlaceはモバイル端末に対してアプリケーションを配布する一つの入り口としての機能を持っている。
これらの場を生かして、早く、小さくともアウトプットを出していくことが大切なのだろう。エピローグに載せられた言葉をもって今日のエントリーを締めくくりたい

(君の考えは)クールなアイディアに聞こえる。実装はそう難しくないだろう。君にはそれをやる時間がある。基本的に心配すべきリスクはあまりない。このアイディアが良いものか見極めようと多くの時間を使ったところで。結局確かなことはわからないだろう。そうする代わりに、同じ時間をこのアイディアの実装に使う事も出来る。そうすればこのアイディアが良いものかどうかが本当にわかるだろう。

ドラッカー名著集1 経営者の条件

ドラッカー名著集1 経営者の条件を読んだ

ドラッカー名著集1 経営者の条件
P.F.ドラッカー
ダイヤモンド社
売り上げランキング: 772

ずっと気になっていながらも読んでなかった本書。
ようやく手に取ってみたけど…ううむ、やはりドラッカーは濃いな

本書のタイトルは”経営者の条件”としているが、本書は経営者のみを対象とした内容ではない。本書の対象読者は”経営者”ではなく”エグゼクティブ”と書かれ、

本書は、トップが行っていることや行うべきことについて述べたものではない。知識労働者として自らの組織の業績に貢献すべく行動し、意思決定を行う責任を持つあらゆる人たちのために書いたものである。すなわち私がエグゼクティブと名付ける人たち全てのために書いたものである。(P.27)

とある。ここでいう”意思決定”を行う人というのは、肉体労働ではなく知識労働をするものであれば、かなりの確率で当てはまるのではないだろうか。そう考えると、かなり広範囲の人に対して書かれたものであることがわかる。
つまり本書の中でも触れられているが、成果をあげるエグゼクティブの能力。これは決して天性のものではなく考え方や習慣。そして修練によって身につけることができるというものだ。

貢献する

ドラッカーの著作にはたびたび”貢献”という言葉が出てくる。もちろん本書も例外ではない。
本書は全7章から構成されているが、一貫して言われているのが「エグゼクティブは貢献に焦点を合わせ、成果をあげなければいけない」という事だ。

そのためには時間を管理しなければいけない
そのためには人の強みを生かすマネジメントをしなければいけない
そのためには問題ではなく機会に目を向けなければいけない
そのためには集中して物事に取り組まなければいけない
そのための意思決定をしなければいけない

仕事を完了させることを目的にしてしまい、その本来の成果や貢献というものが今の仕事の完了で得ることができるのか?そもそも、その仕事というのは本当に必要な仕事なのか?
まだまだ考えることは多いです

組織の中か、組織を作るか。はたまた仕組みか?

ドラッカーが考えているのは”組織”としての考え方。”組織”そのものやその組織の中でいかに貢献する事が出来るのかに焦点が当てられている。この場合、貢献する対象は様々で、上司や部下であるかもしれないし社外や社会そのものなのかもしれない。
社会に対する貢献や組織内での貢献に関して、自分自身の思いや考えというものが受け入れられるとは限らない。その場合に起業という選択肢を選び、組織そのものを作り上げる方向になるのだろう。
対して先日の仕組みセミナー(id:krote:20090307)で考えられていた出発点は、どうすれば”組織”というものに縛られずに生活をすることができるのかを考え、それを”仕組み”という形で実現していた。

出発点や発想の異なる三者が入り混じって最初考えてしまったので頭がゴチャゴチャしてしまっていた。結局のところ、何が正しいのか。”正解”なんてあるわけじゃないのにね。
今の組織の中で上を目指すのか。それとも組織を起こすのか。組織からの脱却を考えるのか。
それぞれの選択肢があっていいとは思う。今、自分自身が真っ先に思いつくことは組織の中で上を目指すことだ。だがしかし、必ずしも今の組織が満点というわけではない。たぶん不満を挙げればきりがないんだろうけどそこからは何も得ることはできないだろう。
それならば本書にあるように、成果を出し、目指すべき組織にしていかなければいけない。本当の意味で”エグゼクティブ”になれるかどうか。”貢献”に焦点をあてた考え方を身に付け、自分を。そして組織を変えていかなければいけない

農業で1000万円!

先日、書店で面白いタイトルを見つけ思わず購入。

週2日だけ働いて 農業で1000万円稼ぐ法
堀口 博行
ダイヤモンド社
売り上げランキング: 2095

最近は”就農”なんて言葉まで出てきている。農業に対するイメージだとか考え方というのはだいぶ変わってきているのではないか?
私も実家は畑に囲まれているような場所なのでちょっとのんびりとした田舎暮らしも嫌いじゃないぞ!って事で楽しみにしていた。ほとんどジャケ買いである

前提条件がいろいろとある

本書では週末のみの就業で年商1000万円という事をうたっているのだが、前提条件として

  1. 妻は専業主婦(基本的に手伝い)
  2. 親も手伝ってくれる
  3. 何よりも田舎。結構田舎。っていうか北海道

という事がある。実際に著者はそれだけの年収を得ているのだろうから不可能ではないとは思うが、他の人に適用できるかというとかなり限定されるのではないだろうか。
お手伝いに関してはアルバイトという手は確かにあるのかもしれない。ただ、注目が集まっているとはいえ農業のアルバイトがどれくらいいるだろうか。。。
そしてやはり問題なのが場所。
この条件が整って、なおかつ会社勤めが続けられる場所というのは…。また、要所要所で北海道特有の発言が見られている。もう少し一般性を加えて出版するべきではないかと思う。
もしくは、売る場所を考えるか。

ちなみに千葉ではどうなの?って妻に聞いてみた(ちなみに妻はどちらかというと、農業指導を生業としている。普及員の資格も持っていたりする)。

かえる「どっかこのあたりで農地余ってない?」
妻「ない。っていうか、あったとしても果樹」
かえる「え」

結局、場所によって作っているものは違うわけで、都合よく自分が作りたいものを作る事が出来る畑を手に入れることができるのかはわからない。

何か得るものはあるのか?

ない
色々考えたがない
・・・
うーん。私はあまりお勧めはできないかな。。。。

視覚マーケティングのススメ

ウジトモコさん著、視覚マーケティングのススメを読んだ

視覚マーケティングのススメ (アスカビジネス)
ウジ トモコ
クロスメディア・パブリッシング
売り上げランキング: 23182

視覚マーケティングとは

「デザイン」というものを考える上で、ただ単にデザイナーに”いいものお願い”って頼むのではなく、マーケティングをすることで、効果的なデザインが出来上がる。マーケティングをせずに作ったデザインはマーケット上での効果は期待できないという考え方だ。

言ってしまうと、当たり前の話なんだけど、その当たり前のことを細部にまでできているかというとなかなか難しいことだ。一般に、製品を企画する段階では間違いなくターゲットとなるユーザーを設定するだろう。そのターゲットは年代に寄るものかもしれないし業界・業態によるものなのかもしれない。必然的に製品のパッケージや広告・キャッチコピーに関してもそれを意識したものが考えられる。
また、企業のロゴになると自分たちが顧客・ユーザーに”どう思われたいか”を意識して考えられるだろう。
ただ、それが本当にできているのだろうか?製品やサービスの細部。個々のパーツにまで落とし込めているだろうか?

意識されているもの、されてないもの

おそらく、パッケージや広告が表に出てきやすいもの。お菓子や化粧品に代表されるようなものに関してはこのいわゆる”視覚マーケティング”はできているのだろう。化粧品みたいなものは明らかに年代を意識して製品を作っている部分もあるので特に意識されているのではないかと思う。
ただ、ソフトウェアの分野はどうだろう。もちろん意識しているソフトウェアもあるだろうけど、明らかに”機能重視”でデザインに関してはおざなりに済ましてしまっている部分はある。特に基幹系のシステムに関してはその色は強いのではないだろうか。
もちろん、これらのソフトウェアに関しては機能は第1に重要視されるものだと思う。ただ、複数ある基幹システムの候補からどれが選ばれるか。ユーザーの立場で”どれを使いたいか”を考えてみるとその要素の一つにデザインがあってもおかしくないと思う。また、そういう意味で”ファン”を作った製品はエンドユーザーからは根強く支持されたりもする。つまり、デザインによるブランディングができているのだろう。
また、個人のブランド。パーソナルブランディングに関しても意識の差は大きいように感じられる。本書でもその具体例として名刺が取り上げられているところからもそれは感じられる。
最近、セミナーや勉強会に顔を出すようになって様々な方と名刺を交換する機会をいただいている。私は個人名刺を所有していないので会社のを使っているのだが、多くの人は個人名刺を持参している。自分自身をどう見られたいか。どういう人間だと印象付けたいのか。この名刺の目的は何か。考えられた名刺もあるしまずは作ってみたというものもある。私自身、個人名刺に関してはほしいと思っているので、どう思われたいのか?どう表現するのかは大きな課題の一つだ。まずはそこを見つけ出さないことにはデザインも始まらない。

ソフトウェアのデザイン

私はソフト屋なのでどうしてもソフトウェアにあてはめて考えてしまうのだが…
ソフトウェアの分野。先にあげた基幹系システムに関して言うと確かにデザインはいい加減なものが多い気がする。いや、実は結構頑張っていたりもするソフトもあるのだろうけど、VBフォームの延長線をいまだにたどっているソフトも割りと残っていたりする。
シンプルな作りなのがいいという業界もあるだろうし、スタイリッシュな物が好まれる業界もあるだろう。ただ、私自身が最近必要と思っているのは、要するに”スタイル”的なデザインではなく”ナビゲーション”を意識したデザインというものだ。これのいい方法が思いつかない。そういう事が得意なデザイナーもいるんだろうけど…、業界やユーザー層に踏み込んでまで考えられる人は少ないように思う。あ、それは発注側の担当ですか。
以前ペルソナを用いる手法に関する本を読んだ

ペルソナ作って、それからどうするの? ユーザー中心デザインで作るWebサイト
棚橋 弘季
ソフトバンククリエイティブ
売り上げランキング: 21263

まだペルソナに関しては試行錯誤段階で効果は不明だけど、実際に作ってみたペルソナが本当にあっているのかというのはわからない話。結局ウジさんの本にあるようにユーザーへの聞き取りのようなことをしなければいけないのだろう。
試行錯誤。試行錯誤の日々は続く

考具を読んだ

加藤 昌治さん著の考具を読んだ

考具―考えるための道具、持っていますか?
加藤 昌治
阪急コミュニケーションズ
売り上げランキング: 1683

この本自体が2003年に発売され、その後の数々の本や雑誌によって発想法は紹介されているので、特別”新しい”というものはなかった。もちろん、これを2003年に読んでいたら目からうろこ状態で歓喜していたかもしれない。
ただ、”知っている”ということと”できている”ということは別の話だ。「あー、これね。うん、知ってる知ってる」って言ったところでやったことがなかったり実際にそこから気付きが生まれる前に辞めてしまったり。
アイデア・発想法に関しては本書にも描かれているとおり「量が質を生む」という性質はあると思う。それがわかっているくせに続かない私はやはりわかっていないのだろう。

というわけで、さっそく会社で試してみることにした。本書とは直接関係はないのだが、KJ法によって「理想の職場」ってテーマでメンバーを集めて話し合ってみた。

KJ法(Wikipedia)
http://ja.wikipedia.org/wiki/KJ%E6%B3%95

やり方を知ってはいたものの、実際にやってみるとまとめるのが難しい!あまり、仕事直結の話以外に関して意見を出し合う機会も少なかったので、なかなか面白い発見がいくつかあった。
なかなか本で得た内容を実践することは難しいが、やはり実践することによって気付くことは多い。これからも忘れないようにしていかなければいけない。

魔王 JUVENILE REMIX 10巻

週刊サンデーで連載されていた「魔王 JUVENILE REMIX」がこの10巻で完結する

魔王 JUVENILE REMIX 10 (少年サンデーコミックス)
伊坂 幸太郎 大須賀 めぐみ
小学館

あぁ、水曜日の楽しみがまた一つ減ってしまった。

時勢が時勢なだけに、犬飼の人気や、雰囲気に流されている光景は妙に今の民主党人気と重ねてしまう自分がいる。

…そのことの意味をよく考えるべきだ!考えて投票するべきだ!思いつきやムードに流されてはいけない!<中略>この国が独立したひとつの国として確固たる意志と誇りを持つためには、自分の投票に対する意味と責任を理解する必要がある

はたして、作者が犬飼に言わせたこのセリフは漫画の中の話だろうか。

本作、魔王 JUVENILE REMIXは、原作となる小説”魔王”だけでなく、様々な伊坂幸太郎作品の登場人物、セリフ、考え方が出てくる。そのおかげで少し説明セリフが多い気がしないではないが、世界観を垣間見るにはとてもいい、面白い作品だと私は思っている。これをきっかけに小説を読んだ人もいるのではないだろうか。少なくとも私はそうだった。

ロマンはどこだ

サービスは「かけ算」!

中野博著、「サービスはかけ算!」を読んだ

サービスは「かけ算」!
サービスは「かけ算」!

posted with amazlet at 09.09.13
中野 博 蓬台 浩明
東洋経済新報社
売り上げランキング: 252

本書は都田建設という会社をモデルにしたサービスに対する考え方を記した本。Amazonのレビューを見ると都田建設の考え方に感動した!ってレビューがすごい並んでいた。特に私は営業というわけでもないし、直接お客様に接する機会というのは今の仕事においては少ないのではあるが、気になったので買ってみた。

感動すること

本書で多く書かれているテーマの一つに「感動」がある。

あなた自身が感動体質になることで、サービスの本質が理解できること、またあなた自身が受けてきた感動のサービスを多くの方々に分けてあげようとする精神が重要である(P.41)

感動体質…。
別に血も涙もない人間というわけではないけど、どちらかというとひねくれている私からは少し遠そうな内容だなぁと思ってしまった。実際に私に足りないというか、「すごいな」って人を見て思うのはやっぱりこういう素直な人だ。ただ、どうしても変にひねくれてしまう。大事か大事でないかと問われればもちろん大事なことなんだろうけど、それを実際に必要な場面ではそんなことは考えず、いつもの通りひねくれた行動をとってしまう時がある。ひねくれてなくても普通にやり過ごしてしまうのだ

立場を変えれば簡単にわかることでも、わたしたちは意外とできないものです。
なぜならば、それが習慣だからです。同じ目線で見ていると、それが習慣になり、楽だから、ついつい逆の立場で見れなくなってしまうのです(P.175)

うん、そうね。だからこそこれを乗り越えた人が見ていて気持ちのいいひとと感じるのかもしれない。
でも、あまり感動屋さんすぎるとそれはそれでうざったい気になるかもしれないが…。ここは好き好きだろうか

なんか違和感

本書で述べられていることは分かるにはわかるんだけど、出来ればモデルになっている都田建設社長の蓬台氏自身の手によって書いた、「サービス」に関する本であった物を読んでみたい気もした。
言ってしまうと、”サービス”というものではなく、自社をどういうかたちで感動体質に変えていったのか。その端々が分かるような内容でもよかったのではないかなぁ。そうするとグダグダになってしまうかな?
ちょっと読んでいて、話はわかるんだけどなんとなく違和感を覚えてしまった。私の修行が足りないせいかそれともなんなのか。自分自身がサービスというものに対して真剣に取り組んでいないだけなのかもしれない。

会社にとってのお客様と直接接する機会は少ないかもしれない。
しかし、社内の部署同士の仕事の依頼や上司と部下の間で取り交わされる指示・命令を”発注・受注”という見方をとればそこにお客様がいることになる。それを考え、ひとつ見直してみる必要があるか。
あんまり冷めたものの見方ばかりしていても面白くないしね。感動体質に少しでも近づけるようにがんばってみよう!

more joel

Joel Spolsky著「More Joel on Software」を読んだ

More Joel on Software
More Joel on Software

posted with amazlet at 09.09.30
Joel Spolsky
翔泳社
売り上げランキング: 62276

ちなみに本書は「Joel on Software」の続編にあたる
書かれている記事は興味深く、それぞれを取り上げていったらとてもじゃないが書ききれないのでプログラマが置かれている環境に関して考えてみたい。

プログラマに個室が必要か

本書の中だけでなくJoelはプログラマが置かれている現状の状況と、より生産性の高い仕事をするならばどういう環境を構築するべきなのか?そしてそれらがもたらす効果を考えればそれにかかる費用などは問題ではないことを主張してきた。
また、より質の高いプログラマを雇用するためにはより、開発者が幸せになるような環境を用意してあげることが重要であることが書かれている。

ただ、少なくとも私が知る限りでは日本の。特に東京近辺で仕事をしているプログラマの開発環境というのは本書で推奨されているような環境からは程遠く…。いや、遠いなんてものではないかもしれない。個室なんて見たことないよ。
おまけに昨今ではブラックなイメージまでしみついてしまっている感まである

ブラック会社に勤めてるんだが、もう俺は限界かもしれない
黒井勇人
新潮社
売り上げランキング: 6719

原因は何だ

と少し考えてみる。
結局のところ、それらを決定するのはマネジメント層であってプログラマではない。彼らにとって一番下っ端に見えてしまう開発者に対して個室を提供するなんていうのはたぶんあり得ない話だ。
彼らにとっては開発者というのは、だれしもが通る最初の一歩であって、ただの通過点的なポジションでしかないのかもしれない。もしくは自分がそうであったということなのだろう。

業界を変えて考えてみると、製薬会社等の研究所で研究している研究職にはそれなりの環境が整っている。彼らは白衣を着て学術書を片手に研究に没頭するための環境を手に入れている。
向かっている対象が違うといえば違うかもしれないけど、レベルの差こそあれ”物を考えて何かを作り出す”立場は変わらないのにこうも扱いが違うのは、やはり一言で”開発者”と言ってしまうには層が厚すぎるからなのだろうか。
結局のところ開発者にも研究者にも人材はピンキリなのだろうが、母数が違いすぎて、悪いところはとてもよく目に付いてしまう。間違ってみんなに個室でもあげようものなら
「ほら、ただでさえ仕事中にぼーっとWebを見ているような開発者に個室なんて与えたら終わりだよ?あいつらは一日中Twitterしているに違いないさ」
的なことを言われるだろう。そうなってしまう人間がいることは否定はしないが。

憧れ

ただ、憧れの存在として良い環境を手に入れたプログラマが会社に数人はいてほしいと思う。そしてその環境は公平な審査のもとで流動的であるべきだ。
少なくとも周りはプログラマという職種に対して得られる環境の充実さに誇りを感じることができるだろうし、それを目指すことになるだろう。話を聞きつけた学生がうるんだ目で上目づかいをしながら
「インターンしたいんですぅ」
と言ってくるかもしれない。そうすれば歯車は少なくとも悪い方向には回らないのではないだろうか?

結局のところ、これを考えている私自身がプログラマなわけだからすぐにどうのこうのできるわけではないが、そういうことは忘れないようにしなければいけない。

ソフトウェアアーキテクトが知るべき97のこと

O’REILLYから出ている「ソフトウェアアーキテクトが知るべき97のこと」を読んだ

ソフトウェアアーキテクトが知るべき97のこと
オライリージャパン
売り上げランキング: 747

珍しくAmazonが新刊を速攻で届けてくれた。つまり、予約があまりされなかったということだろう。技術書なんてそんなものだ…。

本書は、読んで字のごとくソフトウェアアーキテクトが知っておかなければいけないことや、何に注力していかないといけないのか?ということに関して数々の人がその考えを述べている。
本全体としてまとまっているというわけではなく、どちらかというと「あなたはどう思いますか?」って感じの質問に対しての解答集のようなものだ。

ちなみに、日本語訳は無いが原文はこちらにある

97 Things Every Software Architect Should Know – The Book
http://97-things.near-time.net/wiki/97-things-every-software-architect-should-know-the-book

日本語版である本書は、上記97の内容以外に日本人アーキテクトによる追加の内容11本を含んでいる

何を知るべきなのか

実際には、それぞれの立場や会社の性質。従事しているプロジェクトの内容やチーム編成によっても立ち位置は変わってくると思うので、「おー!そうだよね!!」って思うこともあれば「ふーん」と思うこともあった。
ただ、まとまっていないといっても、考えることというのは比較的似通っていて、言っていることはある程度のカテゴリに分けられている

  1. 技術を正しく把握・使うことの重要性
  2. コミュニケーションの重要性
  3. ビジネスを考えることの重要性

とってもざっくばらんに分けるとこんな感じじゃないかな?
たぶん、この人たちにとっては”ソフトウェアや技術に対する知識を持っているのは当たり前”で、プラスして何が重要かということが言いたいんだろう。技術ばっかりの頭でっかちになってはだめですよって。本書でたびたび出てくるところの「象牙の塔」ですね

  • 象牙の塔 http://ja.wikipedia.org/wiki/%E8%B1%A1%E7%89%99(Wikipedia:象牙)
    • 現実からかけ離れた夢想の世界。学者が閉じこもる研究室の比喩。ミヒャエル・エンデの『はてしない物語』にも登場する

面白いと思い、やはり悩ましいのはコミュニケーションだろう。

そんなときに必要なのは、昔から定評のあるテクノロジーです。実際、そのテクノロジーは、人類の歴史で最も重要な技術上のイノベーションです。何だと思いますか。それは話し合いです(P.6 Mark Ramm)

ソフトウェアアーキテクトをビジネスとデベロッパーの間に置くとなると、やはりこのスキルは必須になるだろう。これはプロジェクトをチームとして、会社として成功に導くためには間違いなく必要なことだ。
その割に、これにかかるコストだとか労力というものは軽視されがちで、結果としてプロジェクトはとん挫したりする。
また、もうひとつ。重要なコミュニケーションがある

ソフトウェア・アーキテクトは、どのプラットフォームの仕事をしているかにかかわらず、相互のコミュニケーションを円滑にするための手段を持たなければなりません。その手段の1つが、アーキテクチャー/デザインパターンによるコミュニケーションです。(P.84 Mark Richards)

そう。同じプラットフォーム、同じ言語で開発を行ったとしても別のチームのプログラマがすぐに他のチームで活躍できるとは限らない。仕様書が情報を知るための重要なリソースになることもあるが、プログラマであればまずソースを見ることが多いのではないか?その時に内容を理解したり、プログラムの意図や流れというものを理解するのにこれらデザインパターンというのは間違いなく威力を発揮する。
逆を言えば、本来であればデザインパターンを適用すると効果的な場面において適用されていないとすると、不必要な誤解を招く可能性まであるということだ。

私自身は、デザインパターンに対して習熟しているとはまだまだ言えない。
一人の技術者としてのコミュニケーションがとれるよう、勉強していかなければいけないと痛感することになった。