SIの中で働き続ける理由

東名高速インターの近く、日本で最も交通量が多く渋滞するという噂の、国道16号と国道246号の交差点。元々246側は陸橋となっていたのだが、この度16号側がその上を走るというクロス陸橋化の工事が完成した。結果として10年以上もの工期を要したらしい。実は自分が生まれる前からこの工事には着工していたという噂もあるが、それを除いたとしても、これはとんでもない話。細かい事情は分からないが、建築業界でもこういうことはあるんだ。しかしよくヤリきったな、と思う。これがSI（システム・インテグレーションの略、これを行う会社をSIerと呼んだりする）なら元請けが何回もぶっ飛ぶレベルではなかろうか。

　私がSIの中で働き続ける理由

このブログのタイトルにもある「私」。その私自身の考えとか、価値観とか、なんでSI業界の中に身を置き続けるのか、とかについて今まであまり語ってこなかったので、今回はその辺をザックリ書いてみようと思う。一人称は徐々に「私」から「自分」に戻ります^^;

SIから離れるが、個人的に昔から強く思うことがある。それは『人の可能性は無限大』ということ。この可能性を活かすも殺すも本人次第であり、加えてそれは環境次第でもある、と常々思っている。私の経験上、SIのコアであるソフトウェア開発は"人"の可能性が仕事の面白さに直結する仕事そのものなのである。

冒頭雑談にあった建築業界のように成熟した産業と比較してみると、SI業界のように若い産業(日本で言えば4,50年ぐらいか…)の方が、未成熟であるがゆえ、道具や手法よりも「人」に依存する面が強く出やすい。加えて、ソフトウェア開発の原価がほとんど人件費であることから、SIは「人」が最重要リソースとなる産業構造であるといえる。この業界では「人月」という単位で（1人のエンジニアが1か月150時間働いたアウトプットが1人月）仕事の量を測り見積もりを行ったりするのであるが、この1人月で出来上がる量(そして質)が、個人個人の経験やスキルにとても依存する。しかも一番強く影響するのは、実は、個人個人の「やる気」「柔軟さ」「楽しむ気持ち」といったマインド面であることを、自身の経験からも断言してよい。ただし、このことが真実だとしても、ソフトウェア開発をおこなうSIer(ベンダー)の立場としては大きい声では言えない事情がある。お客様から仕事を請ける以上、うちの開発者の「やる気」が低いと満足なソフトウェアをご提供できないかもしれません、なんて口が裂けても言えるはずがないからだ。

加えてこの21世紀、あらゆる企業は市場で勝ち抜いていくために試行錯誤を繰り返すが、業種業態問わず、如何にITを上手く利活用できるかが求められると言われる。つまり、企業は今後もITにお金を費やし続けるということを表し、一部の内製化は更に進んだとしても、企業のIT投資を受け止められるのは俗に言うSIerで居続ける可能性がとても高い。*1

世の中に必要とされるだけでなく、人の可能性を追求できる面白みのあるのがSI業界。だから自分は、明日も1年後も更にもっと先も、このSIの中で働き続けるだろう。

生きていくためには食い扶持を稼ぐ必要があり、どうせ仕事をしなければいけならば、ワクワクすることが多い方が毎日は楽しいし、モチベーションとかやりがいも得やすいだろうし、その方がプライベートでも自分らしくいられると思う。自分にとってSI業界「人の可能性」を感じられる仕事を通して、世の中に貢献できるとすれば最高ではないか。

このように思い至った背景を振り返り、以下、時系列でダラダラっと思い出してみた。

　社会人0年目

初めてWindows95マシンを購入したのは就職活動の時。会社案内を送ってもらう為にまだ山ほどのハガキを書きまくっていた時代。大学生らしく遊び呆けていた自分が、自身と初めて真剣に向き合い将来を考えたのが就職活動というタイミング。その頃の自分は面接で以下のようなことを言っていたようだ。当時のノートにメモが残っていた・・・

人の可能性は無限である。人と人が共同して何かを成し遂げようとする時、それは１＋１が３にも４にも５にもなる可能性を秘めていると信じている。しかし、時として人と人は足を引っ張りあい、１＋１が２以下になってしまうこともある。それが人と人だと認識している。自分は人と人の無限の可能性を具現化する仕事がしたい。

しかしまぁ、 なんと抽象的な・・・

これを自信満々な顔で面接官に語っていたことを思うと、恥ずかし過ぎる・・・

「人の可能性」を引き出す仕事がしたいという気持ちは、社会人0年目に芽生え始めたようだ。プログラミングの経験もない自分であったが、恐らく、雰囲気でソフトウェア開発に憧れ、気づいたらSIerに就職することになっていた。なんという結果オーライ。

　社会人3年目

社会人も3年目ともなると、大抵の事を経験してくる。入社してすぐは2000年問題対応だったし、納期前の徹夜とか普通だったし、会社の業務時間内に勉強できるノーアサインを指をくわえてみていたこともあった。最初は汎用機プログラマをやりながら、徐々に設計もやり、リーダー的な立場も経験しながら、気付いたら小さい保守プロジェクトのPM。見よう見まねの中でプロジェクトを回すものの、「ちょっとした違和感*2」が胸につっかえたまま毎日を過ごしているとき、たまたま本屋で手にした1冊の本『ピープルウエア』。衝撃を受けた。自分の違和感は間違っていない、と夜も寝れないほど興奮して何回も読み直したことを忘れもしない。

ピープルウエア 第2版 ? ヤル気こそプロジェクト成功の鍵

 当時トム・デマルコがどんだけ有名な人かさえも知らなかった。しかしこの本が、ソフトウェア開発におけるエンジニア、人にフォーカスして生産性やら創造性やらを語っていることは、ビンビン感じるものがあった。席レイアウトなど働きやすいオフィス環境の大切さ、集中している時に電話一本で割り込まれることの影響の大きさ、周囲がどんなに急かそうとも人の考えるスピードは上がらないこととか、思い当たる話ばかりだった。

この本をキッカケにデマルコや、ブルックス(人月の神話)、ワインバーグなどなど・・・20世紀後半のソフトウェア・エンジニアリングの名著を片っ端から読み漁った。社会人3年目、この『ピープルウエア』との出会いは後の自分に大きな影響を与えるきっかけであった。*3

　社会人5〜10年目

プロジェクト・ファシリテーションというのをご存知だろうか？　アジャイルに興味を持っている方であればその日本の第一人者である平鍋健児さんのことはご存知であろう。プロジェクト・ファシリテーションはその平鍋さんが提唱者であり、アジャイルという名前を使わずに、そのエッセンスをソフトウェア開発プロジェクトに取り入れるやり方を紹介していた。

- プロジェクトファシリテーションTOP

このプロジェクト・ファシリテーションに感銘を受け、人生で初めての社外イベントに参加したのもこの頃。そこで平鍋さん直接話すことができたことも、ソフトウェア開発において「人の可能性」をどうしたら活かせるかどうか悩んでいた自分が、アジャイル開発方向にググっと寄ることができたキッカケになった。

思い出した。このイベント、永和システムマネジメント社のオブジェクト倶楽部ってところが主催していたのであるが、初めて参加した際に、勢いだけでライトニングトークスというのにも登壇してみたことも人との出会いを加速させた。「LT面白かったすよ」と立食懇親会でたくさんの人が話しかけてくれたあの体験は、社外との繋がりに目覚めたキッカケにもなった。自分と同じように、プロジェクト・ファシリテーションの裏にあったアジャイル開発の考え方に賛同する開発者がたくさんいることも心強かった。

プロジェクト・ファシリテーションを実開発プロジェクトで試してみてハマる。これが自分と『アジャイル開発』の出会いである。

Webないしは社外コミュニティでいろいろ知り、知ったら試してみたくなるので、実プロジェクトでメンバを巻き込んで、とにかく好き放題やっていた頃でもあった。

ザ・ファシリテーター

 ※ファシリテーションをスキルを学ぼうと思ったのは、この本が面白かったからだったと記憶している

　〜社会人15年目

日本においてもWebサービスに代表されるプロダクト系のソフトウェア開発はアジャイルが当たり前になってきたようだが、ちょうどこの頃の自分は3年間ほど大型ウォーターフォール案件の渦中で踠いていた。これは自分が経験した中で最も過酷なデスマーチプロジェクトであった。終わりの見えないトンネルに迷い込んだ感覚。課題は芋づる式でレビューは時間通り終わることなどなく、連日の深夜タクシーで身も心も疲弊し『アジャイル』なんて言葉自体すっかり忘れてしまっていた。少なくとも、その時の自分には瞬間最大風速200人以上の開発をウォーターフォール以外で進める発想はなかった。大規模SIの厳しい現状を改めて目の当りにし、いつしか「アジャイルなんて別世界の話」と信じて疑わないようになっていた。

さて、3年以上外の世界と接点を絶っていた自分が、久しぶりにシャバに出てみると、世の中の変わりように衝撃を受けまくった。経営側や情報システム部門のクラウド利用に対する心理的抵抗感は随分無くなっていたし、企業によってはエンジニアを抱えて内製化を促進したり、エンドユーザー部門が直接ベンダに発注するプロジェクト形態も増えてきていた。何より一般消費者側の大変化として、急激なスマホ台頭に伴い目に見えて日常生活とITを切っても切れない関係が出来上がりつつあった。SNSを中心としたバイタルマーケティングが今までの常識を変えていた。Twitterで信じられない投稿が相次ぐバカッターに驚く大人の方が急速な変化に置いていかれているようにも思えた。SIという文脈に話を戻すと、企業側もITに対する意識が消費(コスト)から投資に向きつつあることが一番大きな変化であるといえよう。3年間でこれだけ世の中は変わってしまうのか・・・、この衝撃は今でも上手く言葉にできないが、世の中全体がかつての人類史上になかったスピードで革新し始めている、と言っても過言ではないだろう。*4

世の中から「置いていかれた」自分が、この危機感を乗り越えるには、とにかくとにかく行動してみるしかなかった。社外のイベントやコミュニティに行きまくったり、Webや本などで、情報収集しまくる。そういえばアジャイル開発って最近どうなんだろう？*5とカンファレンスに足を運ぶと、最近のアジャイルの話はどこも「スクラム」ばかり。そしてスクラム実践の声を集めていると、インド子会社のエンジニア達からたくさんの話を聞くことができ、英語をもっと自由に使いこなせると幅がグンと広げられることを身を以って実感。この頃だろうか、「SIオワコン」やら「SI終末論」というのがバズるのと共に、「ハイブリッド・アジャイル」やら「エンタープライズ・アジャイル」というキーワードを良く目にするようになってきたのは。

思い返せば2000年代初頭、アジャイルが最初に流行ったころから、自分も受託SIの中にアジャイルを取り入れようといろいろ工夫はしたものの、「契約の問題などなど日本の請負ビジネスモデルにアジャイルは馴染まないよね」というのが定説に自分も飲み込まれつつあった。しかし、皮肉なのか運命なのか、自分が3年に及ぶ大規模SIのデスマを経て分かったのは、SIのビジネスモデルに対する問題認識は業界全体に蔓延しているということであり、そのブレイクスルーを目指してエンプラ系の受託SIでアジャイルを再度取り込もうとする動きが本格化しつつあることを確信した。

ただし、いくらアジャイルの良さを叫ぼうとも、SIの請負というビジネスモデルが変わらない限り、本質的には変わらないのでは、という諦めに似た気持ちも正直あった。ところが、ソニックガーデン倉貫氏の取り組みを知り、もう既に日本のSIも少しづつ変わり始めていることに驚愕する。

もうこれは、ウカウカしていられない!!!! 

「納品」をなくせばうまくいく ソフトウェア業界の“常識"を変えるビジネスモデル

　〜現在

世の中の動きとSIの現場を見ながら、今の日本のSIにおける請負型ビジネスを変えようとしても、発注側と受注側でこのビジネスモデルが成り立っている限りは、簡単に変わる訳がない。ひとつ言えるのは、日本の中だけを見てても変わらないということ。今こそ、日本企業が世界で勝ち抜くためのIT利活用・ソフトウェア開発を、模索し直す時期に来たのだろう。

日本のソフトウェア開発、特にエンプラ系SIの文脈において、業種業界問わず日本企業が世界と戦うために身に着けるべき武器は、IT以外に何があろうか？

日本の請負ビジネスモデルにアジャイルは適さないって話に関連して、日本の外注SIと、アメリカの内製化を比べる話をよく耳にする。日本とアメリカを一括りにすることで、なんとなくそれっぽい話に聞こえるが、この問題はとても複雑で根は深い。よく耳にする話として、ウォーターフォール vs アジャイルという構図や、日本のSI産業とアメリカの内製化を直接比較して、だから日本からはITイノベーションは起きないんだ、とか「ちょっと待って」と言いたくなる話がWebのコラムに多々散見される。問題の根が深いだけに、あまり抽象化してしまうと本質が見えなくなってしまうようなイメージ。このことにより自分の身の回りでも、立場や文脈によって捉え方や言葉の使い方が異なるところで、例えば「アジャイル」のような言葉が出てくると、急に会話が噛み合わなくなってしまうようなケースも増えた。

問題の根っこを掘り下げようとすると、ウォーターフォール vs アジャイルの話は、そういう対立軸が分かりやすいことは認識した上で、ナンセンスでしょう。日本 vs 欧米のソフトウェア開発の話も、内製が進んでいる度合いとか傾向の違いがあることは認識した上で、議論の皮切りにはなるが、解決策にはまだたどり着かないでしょう。日本と諸外国を比較する場合、日本のソフトウェア開発(もちろん受託SIを含む)における人の生産性をどうとらえるか、良くある開発プロセスの特徴や、技術レベルの本当の違いに目を向けた方が、日本のSIにおける請負ビジネスモデルを変える突破口が見つかりそうな気がする。ただし、自分の知る限りここの情報量が圧倒的に少なすぎる。。。

貴重な情報のひとつとして上記blogは、良くチェックしている。著者の牛尾氏のように英語を使ってのソフトウェア開発に携わる現場に身を置くのはとても素晴らしいこと。日本の文化・慣習レベルでのもっと知るべき点が自分にはありそうだ。なぜならば、日本のソフトウェア開発(特に受託SI)が抱える課題は、日本文化や日本人の特徴に繋がる気がするからだ。 日本のSIが変わるカギは、我々自身が握っているということではなかろうか。

　まとめ（SIの中で何を目指すか）

ダラダラと時系列に今までのことを書いてきた。自分はSIという産業でしかまともに働いたことがないと言えばそれまでだが、顧客ビジネスの課題をITを使って解決する受託SIが好きなことは間違いない。これが天職だなんて思ったことは一度も無い。でも忘れられない達成感は多々ある。自分の数少ないプロジェクトの経験からの話だが、より良いソフトウェアを開発しようとすることは開発に携わる『人の可能性』を追求することに繋がるし、ビジネスで求められるシステムやソフトウェアの要求を開発しようとすることは、特にユーザー側の『人の可能性』を追求することにも繋がる。そして受託SIだからこそ、契約書面に記載できないような発注側と受託側のコラボが生まれることも珍しくはない。ありふれた言葉で言えば、受託SIはWin-Winを身を以て体験できるという感じ。まぁ、その分、苦しい時は相当苦しいし、人が居てはいけないようなデスマーチも珍しくない訳だが。

ここ数年、アジャイルコミュニティとは関係ない業界団体*6にも出入りさせてもらいながら、日本を代表するような超大手企業(ユーザー側)のSIに対する課題認識、日本の大手SIer(ベンダー側)の課題認識をそれぞれ見聞きしていると、注目ポイントにズレがあったり、認識GAPも多いにあるのが現状。エンタープライズ分野のSIから、サービサーや新興ITベンチャーに開発者が流れている危機感を認識していない人も意外に多いようだ。いずれにせよ、業界根本の課題として認識し、次のSIの形(答えはひとつではないだろう)を模索する動きは枚挙にいとまは無く、エンタープライズアジャイルはそのひとつに過ぎない。

ということで、自分はこの受託SIという世界に身を置きながら、日本企業がもっと上手にITをビジネスに利活用し、日本経済復活の一翼をITで担う側でいたい。ビジネスモデルも大事だが、それと同じぐらい『人の無限の可能性』を引き出せるソフトウェア開発の模索も大事だと思っていてで、自分はその両方を実践し続けていきたい。*7

　あとがき

当記事を書いている最中にUPされた素晴らしいと感じた記事。前記事のde:code講演音声も聞かせていただいたが、かなり本質的かつ具体的な話になってきている。 

終盤の「"人"を信じて"人"の能力を最大限に引き出し、そして育んでいこうとする」点は自分の理解にとても近く、自分自身が大切にしたい価値観と通ずるものがある。是非、近いうちに自分の意見を記事に起こしたいものだ。

【更新履歴】

　　　2016/6/27 誤字脱字修正、読みにくい表現修正

*1:グローバル規模でSIerの競争は更に熾烈になる意味も包含した上で

*2:*別記事で改めて書いてみます

*3:この頃はダニエル・ピンクの「モチベーション3.0」なんて当然知らない・・・

*4:この3年間の後、業務上はSIの現場から少し離れて組織プロセス改善を行うのであるが、これもまた別に書いてみたい

*5:この当時携わったCMMIの最新版はアジャイルに対応していたようだ

*6:JI●AとかJU●Sとか・・・

*7:アジャイルは手段のひとつ。ヒントは山ほどあるだろうが、こだわり過ぎるとダメ!!

アメリカ海兵隊(非営利型組織の自己革新)

2016年2回目の投稿。最近サボり杉で放置blogとなっています・・・

先日、当blogの序盤に書いた野中郁次郎先生らの「失敗の本質」を書いたのが最も良く読まれている記事となっていることに気づき、野中先生の研究がスクラム（Agile開発のひとつであるScrumは、元々のネーミングは野中先生の論文からだった）の誕生にどのように繋がっているのかを追ってみるのが個人的な研究テーマになっていたにもかかわらず、途中のまま放置していたことを思い出し、慌てて当記事を書いているという訳であります。

念のためリンクを置いておきます。

ということで、経営学の分野で世界的に著名なDr.Nonakaこと野中郁次郎先生が、何故「知識創造企業」「SECIモデル」「スクラム」に至ったかのか。昔の日本の製造業の何が世界に誇る強みだったのか。イノベーションを起こす組織の必要条件とは。を紐解くには、『失敗の本質』に続いて、アメリカ海兵隊に目を向ける必要があるのだ。

それほど長い本でもなかったので、当記事では、読んで分かったポイントを自分なりにまとめてみた。

アメリカ海兵隊―非営利型組織の自己革新 (中公新書)

　日本軍とアメリカ海兵隊

先の第二次世界大戦における、アメリカとの戦争に日本軍が敗退した理由はいろいろあるが、『失敗の本質』では日本軍の組織的な特徴が個別の作戦失敗の共通した理由にあることが書かれている。その個別作戦のうち、ガダルカナル戦の敗因分析の際に、日本軍が対峙したのはアメリカの陸軍でも海軍でもなく、水陸両用の海兵隊だったことが、野中先生の研究において掘り下げるキッカケであったとの事だ。

海兵隊は水陸両用なのだが、実はこれは元々ではなく、日本軍と戦っている最中にコンセプトを作り直して組織として進化した結果だというのだ。そんな戦いながら自らを進化させるアメリカ海兵隊が、組織が自らを進化させた実例として、野中氏の研究テーマになったなったとのことである。

なお、日本と海兵隊は歴史的に因縁が深いらしい。ペリー提督率いる東インド艦隊が浦賀に来た際に上陸したのは海兵隊であり、ガダルカナル戦はもちろん、沖縄陸上戦で戦った相手も海兵隊であった。

　アメリカ海兵隊の歴史

私は軍事素人であるが、一般的に海軍・陸軍・空軍が存在していることは知っている。よくマリーンと言われるのは海軍だと思っていたが違うらしく、マリーンは「海兵隊」のこと。海軍はネイビー(確かに言われてみれば)。

元々、陸海空でそれぞれ軍隊がある中に、アメリカ海兵隊ができたのは1700年代後半の独立戦争の時で、最初は酒場でならず者を寄せ集めただけの集団だったと聞く。ちなみにそもそもの海兵隊はイギリスを真似ただけで決してアメリカ独自のものでもない。

その後、1800年代の南北戦争など、陸軍をお手伝いしたり、船上の治安を守る警察的なことをしたり、常にその存在は危ぶまれながらも生き残っていく。1900年代前半の第一次世界大戦でも飛行団を結成して果敢に戦い、約7万人の国民に認められる海兵隊に育っていった。

そして第二次世界大戦で、日本軍との戦い(ガダルカナル・硫黄島・沖縄など)を中心に26回の上陸作戦を経て水陸両用のコンセプトと方法論を完成させるまでに至り、アメリカ海兵隊は大活躍。大戦後も朝鮮戦争やベトナム戦争で海兵隊は重宝されたようだ。

現在の沖縄、何かと問題・事件が取りざたされるが、普天間基地に海兵隊が駐留しているのはご存知の通りである。

この歴史の中でも、この野中先生が特に目をつけた「進化する組織、イノベーションを起こす組織」であったことが分かりやすいのが、第二次大戦中の日本戦で水陸両用部隊に進化してことであった。

　アメリカ海兵隊は自己革新組織

この「アメリカ海兵隊」の本の言葉をそのまま流用すると、アメリカ海兵隊は自己革新組織である、ということだ。

自己革新組織とは、絶えず自ら不安定性を生み出し、そのプロセスの中で新たな自己創造を行い、飛躍的な大進化としての再創造と連続的で漸次的な小進化を、逐次あるいは同時におこなうダイナミックな組織なのである。

第六章　組織論的考察ー自己革新組織　より抜粋

アメリカ海兵隊は引用した自己革新組織の要件を満たしていた。この引用部分にある進化とは、新しい情報や知識を組織的に学習していくことであり、正に「知識創造企業」や「SECIモデル」に繋がる話である。海兵隊も、毎回毎回組織としての存続の危機に晒されながら、自分たちはどうあるべきかというコンセプトまでも作り直し、学習しながら水陸両用の戦い方を身につけ、しかも暗黙知から形式知として組織的に進化するプロセスを経ていたのだ。

同じ失敗を繰り返す日本軍に対して、失敗しても自らを進化させ相手を乗り越えていく海兵隊という、両者の組織としての違いが今回のとても重要なポイントである。

 ということで、

『失敗の本質』『アメリカ海兵隊』の研究を経て、野中郁次郎氏は、竹内氏と共に、知識創造企業を発表する。また、ほぼ時を同じくして(1986年)、同じく論文"The New New Product Development Game"をハーバードビジネスレビュー誌に掲載されるのだが、この論文の中にスクラムの語源が登場するのである。

続きを乞うご期待。

いつになることやら(；´∀｀)

『ハッカーと画家』を読んだ

2016年ももう6月、今年の半分が過ぎようとしているようで、マジでビビる。そして今年は記事を一本も書いていなかったことに気付き、マジで焦る。書くネタが無い訳ではないが、何でもかんでも記事にしている場合ではないこともあり、なんだか頭が重い。ということで取り敢えず髪でも切ってみたりしたのだが・・・

さてと、社内のモノ好き達とともに毎月行っているコミュニティももう少しで丸3年を迎えようとしているらしい。去年から読書会となりつつあり、現在２冊目。１冊目は『TeamGeek』ってやつですた。（↓これ）

２冊目の『ハッカーと画家』、実はまだ中盤戦なのだが、個人的な事情でこの夏以降は独り読書会になるため、ここまで読んで感じたことを書いてみる。

　何故ハッカーと画家なのか？

本を手に取るまで、著者Paul Graham氏のことは失礼ながら良く知らなかった訳だが、どうやらアメリカの有名なプログラマらしい。20世紀末、今で言う楽天みたいなネット上のショッピングサイトの先駆けを作って、それがYahoo!に買収されYahoo!storeになったとか。とにかくスゴいプログラマであり、所謂ハッカーって訳だ。

ポール・グレアム - Wikipedia

そんな彼曰く、ハッカーと画家はとても似ている、と。

ハッカーと画家に共通することは、どちらもものを創る人間だということだ。作曲家や建築家や作家と同じように、ハッカーと画家がやろうとしているのは、良いものを創るということだ。良いものを創ろうとする過程で新しいテクニックを発見することがあり、それはそれで良いことだが、いわゆる研究活動とはちょっと違う。（第２章「ハッカーと画家」より引用）

 つまり何を創るか考えながらしながら実際に手を動かして創り上げていく。渡された設計書どおりに作る職業プログラマとは異なり、創りたいものを創るってイメージ。

自分はSIという仕事に携わりながら、常々、ソフトウェア開発は「R＆D」的な側面と、「工場での大量生産」的な側面の両方があると思っていた。誤解を恐れず端的に言ってしまえば、前者が仮説検証を繰り返すアジャイル的なやり方で、後者がフェーズドアプローチで大きいものを分解しながらそれを積み重ねていくウォーターフォール的な活動であると。でも「研究活動とはちょっと違う」とあり、少し考えてみた。完全に想像の世界だが、確かに画家は食い扶持を稼ぐ為にも売れそうな絵や、依頼主の満足する肖像画を描くだろうが、本質的にはインスピレーションやパッションで絵を描いているのかもしれない。

なるほど、本当に優れたプログラマ＝ハッカーは、自分の創りたいモノをプログラミングする人たちなのかもしれない。ビジネス的な成功（売れる）とプログラムの中身はリンクしない。だって顧客はソースコードの中を見ることが出来ないし。

　ビジネスにハッカーは必要か？

ハッカーが「創りたいものをつくる」「やりたいことをやる」ということは分かった。オレにはソースコードで自分の意志を表現することはできないが、ハッカーとしてビジネス的な成功も納めた著者の言いたかったことを掘り下げてみたい。

ビジネスという視点では「売れる」ということが重要であり、ハッカーにはその視点がないのか、というと直接的には無いけど間接的にはあるのでは？と感じた。つまり、どんなものを「創りたい」と思うかを想像すると、直接的に「売れるヤツ」という発想はハッカーには無いのだろう。むしろ「あったら良いな／こうなったら便利だな／こういうのってクールじゃん」って発想がハッカーの「創りたい」に繋がると仮定すると、これは間接的に顧客のニーズを満たすものになる可能性を秘めている、と言える。

お金は欲しいものを手に入れる為に単なる中間段階・省略記法に過ぎない。ほとんどのビジネスがやっていることは富を生み出すことだ。人々が欲しがることをやるんだ。（第６章「富の創り方」より引用）

なるほど。生み出すのはお金ではなく「富」だと。この「富」が原文でなんとなっているかは次の読書会で確認しよう。Wealthかな?Valueかな?（※読書会のメンバ半分は原文を読んでいるので）

いずれにしても、あなたの目の前にあるビジネスの成功には今までになかった価値が必要なのであれば、ハッカー的な発想の持ち主はとても重要になるのではなかろうか。

　ハッカーはアジャイル実践者なのか？

最後に、このブログのタイトルにもある「アジャイル」に強引に繋げてみる。そもそも自分が「アジャイル実践者」を語るほどの者ではないことは大前提になるのだが、ここでいうハッカーが行っている「創りたいものをつくる」「やりたいことをやる」というソフトウェア開発のやり方はアジャイル的なのかどうなのか、について考えてみた。

そもそもこの本の中に「アジャイル」というキーワードは出てこなかった。自分の読んだ限りだと。著者は私よりも一回り上の世代だし、時代背景として1990年代を彷彿させる文章が多いからだろう。マイクロソフトがIBMを凌駕したとか、WindowsNTとか、ビルゲイツはハッカーを恐れているはずだ、とかあるし。

「アジャイル」というキーワードは無いが、アジャイル的な発想の抽象的かつ重要な点として、ソフトウェアは早く市場に出して顧客のフィードバックを得るべきという話が随所にある。具体的な例として著者はViawebというYahoo!に買収されたサービス（ネットショッピングのソフトウェア）を開発した話とか。

自分でも使いたいと思うような明快で簡単なものから作り始めることだ。バージョン1.0を素早く出して、それからユーザーの声を聞きながらそれを改良していく。（第５章より引用）

製品開発に長く時間をかけ過ぎると危険だ。この危険はハッカーには既に知られている。（中略）バージョン1.0を可能な限り速く出そう。ユーザーを獲得しない限り、手探りでの最適化から逃れられない。（第６章より引用）

非常に優れたプログラマであるハッカーは、富を生むようなソフトウェアの作り方として、顧客のフィードバックによりソフトウェアを成長させるやり方を元々知っているという訳だ。アジャイルとかいう表現は後からついてきただけと言った方が良いだろう。

何故ハッカーはこのようなやり方を知っているか？それは技術的な興味がアイディアを生み、それを試すやり方としていち早くリリースすることで顧客のフィードバックを得ることに繋がる、ということなのだろう。

ハッカーは現在の技術の中身を覗くことで次世代のアイディアを得る。（中略）事実、コンピューターの次世代技術を見てみると、外部の人間により作られたもののほうが多いくらいなんだ。（第４章より引用）

ハッカーは天才的なプログラマであり、でも自分のアイディアを実現する事で富を生むソフトウェアを作るのではなく、市場（ハッカー以外の外部の人間）からのフィードバックがそれを作っていく。つまりハッカーは技術的な興味をベースに、市場の声を謙虚に受け入れながら、ソフトウェアの形を進化させることが出来るプログラマということだと感じた。

なるほど。

結果的にはアジャイルの実践者と言っても良いのだろう。ハッカー自身はそう呼ばれたく無いのかもしれないが。

ひと通り読んでみて頭を整理してみると、自分自身がハッカーでもなく、アジャイルの実践者でないことを思い知らされた。それは事実として、ビジネスの成功とITがこれほど密接になってきている現在だからこそ、ハッカー気質のプログラマたちともっともっと話が出来るようにならないとダメだな、とも感じた。

ことSIの世界では、アジャイルをやれば良いソフトウェアが出来ると思ってしまっている人がまだまだ居そうなので。

最後の最後に、この『ハッカーと画家』、Webで読めてしまうらしい。

嗚呼・・・なんてこった・・・(´・ω・｀)

matome.naver.jp

2015年が終わろうとしているが…

2015年も最後の12月。そして今日は大晦日。このBlogの記事を書こうとするのも何ヶ月ぶりだろうか。すっかり存在すら忘れていたかもしれない最近、年が変わる前に思い出したことだけは評価したい。自分を褒めたい。いやまじで。多分、今日気付かなかったら、この2015年に気付かなかったら、、、そう、SNSなんて言葉も無かった大昔のみくしー的な時みたいにパスワードを忘れアカウントも死にドメインになり、そして存在も忘れ去ってしまう系になっていたでしょう。。。

10ヶ月放置だったこの「部屋とアジャイルと私（仮称）」ですが、来年以降どうなるか分かりませんが、紅白が始める前に酔いつぶれてしまわないようにも、いっちょ軽く「ふりかえり」を行って、新年を迎えてみたいな、と思う訳です。

　とりあえず定量的なデータ

2015年1月〜2015年12月をワカル範囲で書いてみる。

• 記事の数：3本　(2014年より−19本)
• セミナー等に行ってきました系：1本
• 社内勉強会：1本
• 本：0本
• Mac：0本
• その他：1本
• 合計アクセス数：5726ぐらい（1日平均15ぐらい）
• 1日での最大アクセス数：たしか300

　マジで・・・

全然更新していないのに1日30アクセスとかマジですか〜（これはちょっとビックリ）

まぁ、自分が発信したいと熱を入れた記事と、人がアクセスするページは別なのですが、それにしても、この事実を踏まえると、インターネッツ上のこのblogスペースをもっと上手く活用することを考える人も沢山いるのでしょうな。。。

　結論ではないが。

このblogをもっと上手く自分自身にとってプラスとなる方法を今年、2015年中に、あと6時間以内、NHKから除夜の鐘が聞こえる前までに、考えてみることにしよう。

今年は上期、下期と、別のことに熱中していたため、社外活動というかblogに書けるネタのようながなかったのも事実。まずは来年の社内読書会のために、本を読まなきゃ。

で「ハッカーと画家」読み始めたのですが、これって自分的には難しいというか、なんか頭にパっと入ってこないんですよねぇぇぇ・・・(´・ω・｀)

最近本を読んでないから？

飲み過ぎで酔い過ぎでしかも二日酔いだから？

このblogをないがしろにしていた罰ってやつでせうか？

ハッカーと画家 コンピュータ時代の創造者たち

読書会をすることになった!! 〜TeamGeek〜

油断するとあっという間に１ヶ月が経ってしまう（当blogに記事を書かないまま）、今年もそんな感じですが、その辺は　ゆるーり　ヨロシクです。

さて、今までもアジャイル系の社内勉強会に関することをupしたことがありますが、今日はそのネタです。

この会は一昨年の夏から毎月行っていて、まだちゃんと続いているものの、メンバが固定気味という良くあるパターンに陥りつつあり、でもそんな中、年も変わったし改めて仕切り直してイコウゼ!!ってことでひとつ決まったことがあります。

（ゴホン）

ど、ど、読書会をすることになりました(・∀・)♪♪♪♪

対象の本はいくつか候補があったのですが、満場一致で『Team Geek〜Googleのギークたちはいかにしてチームを作るのか』に決定!!

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

自分も前から読もう読もうと思っていてAmazonのカートの中に眠っていたのですが（汗）この度無事に購入して、早速読み始めましたよ。

結構アツい！ヤバい！これはオモロい！

エンジニア自身（ヒト）とかチーム・組織（人間関係）とかにフォーカスしつつ、状況を想像しやすい例え話があったり、これは読書会、盛り上がりそう。いやマジで。

取り敢えずは１ヶ月に１章のペースで進める予定。ま、あまり無理せずに。

１月：この本を選定

２月：第１章、天才プログラマの神話

３月：第２章、素晴らしいチーム文化を作る

４月：第３章、船にはキャプテンが必要

５月：第４章、有害な人に対処する

６月：第５章、組織的操作の技法

７月：第６章、ユーザーも人間 

てな予定です。

社内勉強会と言っていますが、混じりたい人が居たら連絡くださいなwww

いつも都内中央区の某所ですが、その時は本気で検討しまつ( ｰ`дｰ´)ｷﾘｯ

ちなみに、

実はこの読書会で１つチャレンジがあります。

それは、訳本（日本語）を読んでくるメンバと、原著（英文）を読んでくるメンバを混在でやっちゃおうってことです。

技術情報のソースって英文が多いですし、社内では外国籍の人も増えてきたし、でも自分は、訳書をノータイムで買っている訳ですが・・・( ´ Д｀)

さて、どうなるでしょうか？

乞うご期待！

Team Geek: A Software Developer's Guide to Working Well With Others

PS.

会のメンバから提案があったんですが、読書会の様子とかこういったblogというかインターネッツで公開してみるのも面白いかもーーー

ありがたい話を聴いてきました!!

実家にいた時はメインのターミナル駅であった上野。

この上野に久しぶりに行ってきましたよ、ありがたいお話を聴けるということで。

キャンセル待ちからの参加で、話を聴く前からありがたさMAX。

ありがたい話 公開版 - 永和システムマネジメント | Doorkeeper

永和さんのオフィスに着くや否や、座ると同時にお茶とお菓子とプレゼント攻撃。

話を聞く前からありがたさMAXMAX。

カレンダーとステッカーをゲットしたのですが、この卓上カレンダよく見ると・・・右下に「オブラブ」とある。　もしかして、あのオブジェクトクラブなのか？　オブクラではなくオブラブの方のあれか・・・！？

その昔、はじめてライトニングトークスというものを知った（自分の中の）あの伝説の１日が脳裏に甦る(´・ω・｀)

ホントに、話を聴く前から、ありがたさMAXMAX、emacs。

ということで、このイベントはいつもは永和さんの社内イベントらしいのですが、今回は公開版ということで社外の人も参加可ってことでで、ありがたい話を聴いて参ったわけでございます、はい。

　ありがたい話ダイジェスト版

スピーカーは３名。

お三方の話、いずれもありがたすぎる話ばかりだったのですが、その一部をちょっとだけ抜粋してみると・・・

「journey through the programing language」 @takkanm氏

• プログラミング言語は沢山知ってた方がいいよってお話
• 確かに言語に興味を持つと、なんでこの言語だとこれが出来ないん？とかこういう書き方したらどう動くん？とか、プログラミングスキルに厚みも出来るとおもう
• 氏はHaskellとの出会いが運命を変えたらしい
• 母国語を１つ持っておく、か。　自分の母国語はなんだろ？　その昔、超マイナーなヤツを極めたこともあったが日本人数名か中東に数名しか使い手がいないヤツだったから素性がバレルので、COBOLということにしておこ。

「INSPIRE FUTURE GENERATIONS」 @koic氏

•  氏のお話は去年のXP祭りで聴いたが、その時よりも距離感が近かったので、その躍動感・リズムがとても印象的だった

　　　XP祭り2014に行ってきました!! - 部屋とアジャイルと私（仮称）

• ベースはXPの話
• ユーザーの権利、プログラマの権利、それらは両輪ってヤツを沢山実践しているんだろうなーって感じ、勝手ながらとても親近感を感じさせていただきました
• 特にユーザー側も成長するんだっていうのは正にその通りで、成長するのは開発者だけじゃなくお互いだって関係を築く事ができると、同じシステムを長くやっていても沢山新鮮なことがあるんですよね。ホントに。
• ああ、現場でプロジェクトを回したくなってきたぞ！！

INSPIRE FUTURE GENERATIONS from Koichi ITO

「お気にいりの道具を見つけよう」 @mtsmfm氏

• 大変失礼な言い方になってしまうが、とってもビックリだったのは氏が新卒２年目なのに、話している事は職人のプロの領域の話だったってこと。トークの腕も自分より数段上・・・orz
• 開発者としてお気に入りの道具（キーボードやマウスなどのハード面も、エディタとかソフト面も両方）を見つけるやり方から、日々のメンテまで、とっても身近な話だが、道具にこだわるプロのプログラマーのお話でした
• 先輩の一挙手一投足を一ヶ月間見続けるという「着席」という新人教育プラクティスにはマジで驚きました！こんなの、そんじょそこらじゃ出来ませんよ！永和さんのプロがプロを育てる現場の一端を感じさせていただきました
• 道具にこだわるって超大事で、ともすれば「ボール磨きは１年やっとけ」って現場が世の中には多い中、トラックボールとかちゃんと毎週自分で磨く（油は共同購入w）って神髄かとおもいます！

 ってな感じ。

　おまけ

ありがたい話を拝聴したあとは、ビールと寿司ピザが振る舞われるという、これまた信じられないような展開。

今夜のすべてのありがたさを胃袋に消してしまうのはもったいないので、ブログに書いてみました。しかし本当にすごい企画です。これでプライスレスとは( ﾟдﾟ )!!!!!

※奥の緑の一升瓶、日本酒だったらすぃwww

司会進行の方は麻雀好きということで、そんなお話も聞けたりと、牌から離れてしまった自分としては、これまたありがたい話。

そうそう、あと、オブラブ2007「帰郷」でのLTを覚えてくださった方が居たりして、これまた、別の意味でありがたい話。

本当に本当にありがとうございました！！

上野の永和で「ありがたい話」を聞いてきた。振る舞われた寿司が一番ありがたかった( ￣▽￣) そして上野の夜に消えることにしよう。。。 今日はありがとうございましたm(__)m http://t.co/ompwnf4CBu pic.twitter.com/W1XuSHWTH8

— Ryohei (中澤 良平) (@ryohei_nakazawa) 2015, 1月 16

ということで、

上野の夜に消えた自分はというと・・・

テレカをよく買いにきていた頃を思い出しだしながら・・・

10枚センエン、10枚センエン・・・

締めのラーメン食してまっつぐ帰りましたとさ（自宅以外に遠いwww）

ありがたや〜  (´・人・｀)

ありがたや〜  (´・人・｀)

ありがたや〜  (´・人・｀)

2015年にあたって

もう新年って感じではありませんが、改めまして、あけましておめでとうございますm(_ _)m

さて、今年一発目のpostなのですが、ネタは去年いままで以上によく聞くようになった「エンタープライズ・アジャイル」にしたいとおもいます。

今日はあまり深く立ち入らず、これは見といた方がいいよっていうスライドの紹介で。

アジャイル界で知らない人は居ない、ご存知あの平鍋さんのスライドです。

スライドの枚数もさることながら、今後いろいろと議論するに値するネタが盛りだくさんな印象です。 

What is Enterprise Agile from Kenji Hiranabe

特にスライド14と56あたり。

自分も行けるときには顔を出している、要求開発アライアンスの山岸氏と萩本氏の話も紹介されています。

それから、某情報システム系のユーザー協会において、新年早々話す機会があったので、この平鍋さんのスライドの一部をみんなに紹介したいな、とおもいつきました。

早速、平鍋さんにご連絡したところ、即レスで快諾して頂き、「投影だけじゃなくても良いよ」とまで行って頂き、新年早々これまた本当に感謝感激です！！

※無事発表は終わりました＾＾；

今年はこの辺の話を、当ブログでも掘り下げていきたいな、と思いながら、新年一発目の投稿とさせて頂きます。

今年もヨロシクお願いいたしますm(_ _)m