「失われた30年」を取り戻したい
なーんてことを最近、真剣に考えちゃったりします、こんにちは。そういえば先日、認定スクラムマスター（LSMの方）になったのですが、その時のコーチ（Scrum.Inc副社長らしい）が何回も言っていて忘れられないこと。"Agile is mind-set."って。まーねー、そーだよねー、なんて顔しながら自分の頭の中では、そろそろブログタイトルの「アジャイル」は止めようかなーなんて考えていました。自分がそのアジャイル・マインドセットを理解しているか否かとかそういう問題ではなく、そう言えば最近アジャイルアジャイル言う人がいなくなった気がするな、とかそんな理由ですが。
実は、と言うほどのことでもありませんが、つい最近、人生2回目のジョブチェンジをしました。この3社目にジョインしてまだ3ヶ月程度ですが。思い返せば新卒以来、これまで主に製造業向けの受託SIを長くやってきて、初転職で外資系コンサルいったら見事なカルチャーショック＆世間の見え方がガラリと変わり（この話は別で書こう）、そして辿り着いたのは会計パッケージ屋さん（みたいなところ）。仕事内容というか職種としてはコンサル兼エンジニア兼プロマネ的なイメージです。それなりにグローバル化も進めている日本の製造業がクライアントとして多い印象。結構どのクライアントもそれなりに世界で通用するモノを作ったりブランドを持っているという自負があるようなのですが、組織としてイマイチ元気ないというか、経営も現場もイケイケな勢いはなくシェア争いに疲弊しちゃっている感も少なくない。ここでタイトルの話になるのですが、ふと思ったのです。
日本の「失われた30年」を取り戻さにゃいかんぞ!!これは。
って。まぁ、別に国の経済政策を論じたいとかではないです。なんでこんなことを思ったのかを、今日は少し書いてみようと思います。
photo by mauspray
というか「失われた30年」ってあんまり聞かないですよね、10年でもなく20年でもない。30年って。詳しいことはわかりませんが、一説によると失われた10年のスタートは1992年頃で、その頃から日本経済の長い不景気・デフレが始まった*1。で、2021年で日本の経済情勢が今とあんまり変わらない感じだと「30年」になってしまうんだとかとか。あ、自分の言っているのは、長引く日本経済の低迷をなんとかするためにマクロ経済の施策が云々とか、ではないです。単純に日本企業もっともっと頑張れ的な感覚で、日本企業がグローバルでもっともっと目覚ましく活躍する時代にしたいなと思っていて、もう一度「ジャパン・アズ・ナンバーワン」とか言われた80年代を取り戻そうよ、という話をしてます。
もちろん簡単な話ではないのですが、まずは、日本経済を支えいるたくさんの企業が、もっともっと元気になってもらわなきゃダメだし（偉そうな言い方でごめんなさい、でも元気ハツラツな会社ってあんまり無いように感じている）、そうなる必須条件として、企業はITを最大限ビジネスに活用しながらグローバル市場で勝ち抜くこと、が求められると思ってます。日本版Teslaとかのベンチャー発な企業が生まれるのでも良いのですが、分かりやすさとして、日本を代表するようなエンタープライズ企業（個人的に製造業を中心にしています）がそれぞれの分野で例えばTOYOTA以上になって欲しいのです。
photo by Pascal
偶然か必然か今の職場環境ではこの「失われた30年を取り戻す」ことに直結する仕事が沢山できそうというのもあり、毎日ワクワクすることが山盛りです。この3社目の会社は会計パッケージ屋と書きましたが、私の所属する事業部のビジネスは「会計」というよりは「マネジメント・経営管理」の領域を対象としています。SCMの文脈に近いですが、ある程度の規模を持つ製造業の多くは部品製造とか組み立てとかアジア中心に海外でやってますし、マーケットも日本以外が半分以上というのも普通な話で、そのような企業での経営判断は当然連結ベースの数字が用いられるのですが、その仕組みを支えるITはまだまだExcelの世界だったりする会社も多いようで、色々課題は盛りだくさんだとか。日本を代表する企業と言っても良いTOYOTAでさえも、経営者の悩みは尽きることはないと想像します。
車とかオーディオとかゲームとか日本を誇るブランドは沢山ありますが、大企業になればなるほどIT調達は、伝統的な手法である「丸投げ」傾向というか、事実上メガSIerへの外注となっているのが殆どである、とも聞きます。ふた昔前ぐらいから、どのような企業も情報系システムへ投資だとか、DWHとかOLAPとかBIとかマイニングとかのシステム構築・パッケージ導入がお盛んでしたが、それでも今の実態を鑑みるとまだまだITをうまく活用し切れていない企業の方が多いのではないでしょうか。この文脈でITをビジネスに活用することを考える際、冒頭の「ブログタイロルとしてアジャイルは止めよう」にも繋がるのですが、最も重要なのはスピード。ITをベースとしたソリューションを提供し、ビジネスサイドからのフィードバックを受け、次に活かす。この流れをスピード命で高速に回し続けていくイメージが真っ先に思い浮かびます。ここでアジャイルという単語はむしろ要らない！失われた30年を取り戻すアプローチはこれしかないと思っています。
一昨年に書いた記事で、SI Loveを宣言したのですが、
結局自分は既にSIerの中で働き続けていないのですが、でも、あの時書いた想いは変わっていないですし、その延長線上に、今の自分も居ます！ その延長線上で、失われた30年を取り戻すとか言い始めちゃったのです(￣▽￣)
そう言えば、ここ1ヶ月はSASでプログラムも作ったりしています。経営判断に使う数字を見える化したり、分析するようなBAツールの基盤のひとつとして、SASはなかなか魅力的な部分も感じます。システムの特性上、扱うデータは構造化されているのだが、RDB脳だとついていけないところが山盛りなので、そこも今まであまり触れてこなかった世界なので面白くもある。
とりとめもなくなってきたので、今日はこの辺で。
あ、Tweet数をみたら次が1000ゲットらしいwww
【ご報告】何とか生きてます。
小学校の頃、タミヤは神でした。グラスホッパーというRCで遊んでいた時期があります。だからなのか「ホッパー」という単語には元々過敏症で・・・時折よく耳にする「ジョブホパー」とか「マネーホッパー」とかに結構ドキドキする最近です。お久しぶりです。ちゃんと生きています。
相も変わらずこのblogはAnnual Report化している訳ですが、そろそろせめて、四半期決算ぐらいはした方が良いのではとのツッコミもごもっともな訳で、忙しいことを理由にアクションしないのは猛省すべきと自覚もしております。
さて、実はネタは盛りだくさんでして、ここは今まで溜まった分を一気に、初夏の収穫祭といきたいところなのですが、長くなると記事を書き終わる前に、割り込みタスクに流されるといういつものパターンに陥ってしまうため、今日はこれから書きたいことを箇条書きするに留めたいと思うのであります。
＜このblogで書きたいこと＞
(1) ブログタイトルを真面目に直した方が良い件
(2) デジタルトランスフォーメーションの裏で起こりつつある、品質保証トランスフォーメーションの件
(3) プロセス・コンサルテーションって何だ？コーチングと何が違うの？
(4) 心理的安全性は本当に必要なのか話（もっともっと良いチームを作りたいぞ）
(5) ダーマの神殿に行ってきました話（計画的偶発性理論を考えてみる）
(6) 失われた30年にはならない理由（≠五輪ネタ）
(7) 英語ネタ（単語の後入れ先出し法、覚えたらその分忘れるのです）
とりあえず７つ。ま、実際にはこの通りにならないと思うし、そもそもちゃんと記事を書くのか？と本人が一番怪しいと思っているし、ま、ゆるーくやっていこうかな、と。そういうコンセプトのblogだったはずだしw
最後に少しだけ、この１年間をサマリして駄文を。
いやですね、７０歳まで働き続けるとすると、まだ折り返し地点にもいない自分がわかったようなことを言うべきではないのですが、価値観とかべき論とかっていつの間にか気づかないうちに自分の中に確立しているものなんだな、と。いつも会話する人が変わったり、扱う物事が変わったり、環境が変わると視点も変わると信じていたのですが、そんなことはないんだな、と痛感したのがこの１年でした。一言で言うと。具体的な話として、かなり久しぶりに７つの習慣を読み直したのですが、インサイド・アウトっていうのは本当に深いな〜っと。もう少しいうと、自分の中の価値観とかべき論がある程度確立していればいるほど「それは違うよ」って思うことが多くなってしまう可能性が高く、この1年間自分はそうだったな、という強い反省が生まれたのです。つまり自分は正しい・あなたが間違っているというフレームで無意識にモノを見てしまっていたことに気づいてしまった、というか。これってアウトサイド・インだと思うのです。７つの習慣をものにする前提として必要なパラダイム・シフトが、今こそ自分に必要なのだと思っています。
昔読んだ本を見直すというのも、面白いものです。
ま、読み直したのはマンガ版ですが〜(・ω・)
ではでは。
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冊の本『ピープルウエア』。衝撃を受けた。自分の違和感は間違っていない、と夜も寝れないほど興奮して何回も読み直したことを忘れもしない。
- 作者: トム・デマルコ,ティモシー・リスター,松原友夫,山浦恒央
- 出版社/メーカー: 日経BP社
- 発売日: 2001/11/26
- メディア: 単行本
- 購入: 26人 クリック: 339回
- この商品を含むブログ (197件) を見る
当時トム・デマルコがどんだけ有名な人かさえも知らなかった。しかしこの本が、ソフトウェア開発におけるエンジニア、人にフォーカスして生産性やら創造性やらを語っていることは、ビンビン感じるものがあった。席レイアウトなど働きやすいオフィス環境の大切さ、集中している時に電話一本で割り込まれることの影響の大きさ、周囲がどんなに急かそうとも人の考えるスピードは上がらないこととか、思い当たる話ばかりだった。
この本をキッカケにデマルコや、ブルックス(人月の神話)、ワインバーグなどなど・・・20世紀後半のソフトウェア・エンジニアリングの名著を片っ端から読み漁った。社会人3年目、この『ピープルウエア』との出会いは後の自分に大きな影響を与えるきっかけであった。*3
社会人5〜10年目
プロジェクト・ファシリテーションというのをご存知だろうか？ アジャイルに興味を持っている方であればその日本の第一人者である平鍋健児さんのことはご存知であろう。プロジェクト・ファシリテーションはその平鍋さんが提唱者であり、アジャイルという名前を使わずに、そのエッセンスをソフトウェア開発プロジェクトに取り入れるやり方を紹介していた。
このプロジェクト・ファシリテーションに感銘を受け、人生で初めての社外イベントに参加したのもこの頃。そこで平鍋さん直接話すことができたことも、ソフトウェア開発において「人の可能性」をどうしたら活かせるかどうか悩んでいた自分が、アジャイル開発方向にググっと寄ることができたキッカケになった。
思い出した。このイベント、永和システムマネジメント社のオブジェクト倶楽部ってところが主催していたのであるが、初めて参加した際に、勢いだけでライトニングトークスというのにも登壇してみたことも人との出会いを加速させた。「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も少しづつ変わり始めていることに驚愕する。
もうこれは、ウカウカしていられない!!!!
「納品」をなくせばうまくいく ソフトウェア業界の“常識"を変えるビジネスモデル
- 作者: 倉貫義人
- 出版社/メーカー: 日本実業出版社
- 発売日: 2014/06/12
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (6件) を見る
〜現在
世の中の動きと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 誤字脱字修正、読みにくい表現修正
アメリカ海兵隊(非営利型組織の自己革新)
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になったとか。とにかくスゴいプログラマであり、所謂ハッカーって訳だ。
そんな彼曰く、ハッカーと画家はとても似ている、と。
ハッカーと画家に共通することは、どちらもものを創る人間だということだ。作曲家や建築家や作家と同じように、ハッカーと画家がやろうとしているのは、良いものを創るということだ。良いものを創ろうとする過程で新しいテクニックを発見することがあり、それはそれで良いことだが、いわゆる研究活動とはちょっと違う。（第２章「ハッカーと画家」より引用）
つまり何を創るか考えながらしながら実際に手を動かして創り上げていく。渡された設計書どおりに作る職業プログラマとは異なり、創りたいものを創るってイメージ。
自分はSIという仕事に携わりながら、常々、ソフトウェア開発は「R＆D」的な側面と、「工場での大量生産」的な側面の両方があると思っていた。誤解を恐れず端的に言ってしまえば、前者が仮説検証を繰り返すアジャイル的なやり方で、後者がフェーズドアプローチで大きいものを分解しながらそれを積み重ねていくウォーターフォール的な活動であると。でも「研究活動とはちょっと違う」とあり、少し考えてみた。完全に想像の世界だが、確かに画家は食い扶持を稼ぐ為にも売れそうな絵や、依頼主の満足する肖像画を描くだろうが、本質的にはインスピレーションやパッションで絵を描いているのかもしれない。
なるほど、本当に優れたプログラマ＝ハッカーは、自分の創りたいモノをプログラミングする人たちなのかもしれない。ビジネス的な成功（売れる）とプログラムの中身はリンクしない。だって顧客はソースコードの中を見ることが出来ないし。
ビジネスにハッカーは必要か？
ハッカーが「創りたいものをつくる」「やりたいことをやる」ということは分かった。オレにはソースコードで自分の意志を表現することはできないが、ハッカーとしてビジネス的な成功も納めた著者の言いたかったことを掘り下げてみたい。
ビジネスという視点では「売れる」ということが重要であり、ハッカーにはその視点がないのか、というと直接的には無いけど間接的にはあるのでは？と感じた。つまり、どんなものを「創りたい」と思うかを想像すると、直接的に「売れるヤツ」という発想はハッカーには無いのだろう。むしろ「あったら良いな／こうなったら便利だな／こういうのってクールじゃん」って発想がハッカーの「創りたい」に繋がると仮定すると、これは間接的に顧客のニーズを満たすものになる可能性を秘めている、と言える。
お金は欲しいものを手に入れる為に単なる中間段階・省略記法に過ぎない。ほとんどのビジネスがやっていることは富を生み出すことだ。人々が欲しがることをやるんだ。（第６章「富の創り方」より引用）
なるほど。生み出すのはお金ではなく「富」だと。この「富」が原文でなんとなっているかは次の読書会で確認しよう。Wealthかな?Valueかな?（※読書会のメンバ半分は原文を読んでいるので）
いずれにしても、あなたの目の前にあるビジネスの成功には今までになかった価値が必要なのであれば、ハッカー的な発想の持ち主はとても重要になるのではなかろうか。
最後に、このブログのタイトルにもある「アジャイル」に強引に繋げてみる。そもそも自分が「アジャイル実践者」を語るほどの者ではないことは大前提になるのだが、ここでいうハッカーが行っている「創りたいものをつくる」「やりたいことをやる」というソフトウェア開発のやり方はアジャイル的なのかどうなのか、について考えてみた。
そもそもこの本の中に「アジャイル」というキーワードは出てこなかった。自分の読んだ限りだと。著者は私よりも一回り上の世代だし、時代背景として1990年代を彷彿させる文章が多いからだろう。マイクロソフトがIBMを凌駕したとか、WindowsNTとか、ビルゲイツはハッカーを恐れているはずだ、とかあるし。
「アジャイル」というキーワードは無いが、アジャイル的な発想の抽象的かつ重要な点として、ソフトウェアは早く市場に出して顧客のフィードバックを得るべきという話が随所にある。具体的な例として著者はViawebというYahoo!に買収されたサービス（ネットショッピングのソフトウェア）を開発した話とか。
自分でも使いたいと思うような明快で簡単なものから作り始めることだ。バージョン1.0を素早く出して、それからユーザーの声を聞きながらそれを改良していく。（第５章より引用）
製品開発に長く時間をかけ過ぎると危険だ。この危険はハッカーには既に知られている。（中略）バージョン1.0を可能な限り速く出そう。ユーザーを獲得しない限り、手探りでの最適化から逃れられない。（第６章より引用）
非常に優れたプログラマであるハッカーは、富を生むようなソフトウェアの作り方として、顧客のフィードバックによりソフトウェアを成長させるやり方を元々知っているという訳だ。アジャイルとかいう表現は後からついてきただけと言った方が良いだろう。
何故ハッカーはこのようなやり方を知っているか？それは技術的な興味がアイディアを生み、それを試すやり方としていち早くリリースすることで顧客のフィードバックを得ることに繋がる、ということなのだろう。
ハッカーは現在の技術の中身を覗くことで次世代のアイディアを得る。（中略）事実、コンピューターの次世代技術を見てみると、外部の人間により作られたもののほうが多いくらいなんだ。（第４章より引用）
ハッカーは天才的なプログラマであり、でも自分のアイディアを実現する事で富を生むソフトウェアを作るのではなく、市場（ハッカー以外の外部の人間）からのフィードバックがそれを作っていく。つまりハッカーは技術的な興味をベースに、市場の声を謙虚に受け入れながら、ソフトウェアの形を進化させることが出来るプログラマということだと感じた。
なるほど。
結果的にはアジャイルの実践者と言っても良いのだろう。ハッカー自身はそう呼ばれたく無いのかもしれないが。
ひと通り読んでみて頭を整理してみると、自分自身がハッカーでもなく、アジャイルの実践者でないことを思い知らされた。それは事実として、ビジネスの成功とITがこれほど密接になってきている現在だからこそ、ハッカー気質のプログラマたちともっともっと話が出来るようにならないとダメだな、とも感じた。
ことSIの世界では、アジャイルをやれば良いソフトウェアが出来ると思ってしまっている人がまだまだ居そうなので。
最後の最後に、この『ハッカーと画家』、Webで読めてしまうらしい。
嗚呼・・・なんてこった・・・(´・ω・｀)
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をないがしろにしていた罰ってやつでせうか？
- 作者: ポールグレアム,Paul Graham,川合史朗
- 出版社/メーカー: オーム社
- 発売日: 2005/01
- メディア: 単行本
- 購入: 109人 クリック: 4,884回
- この商品を含むブログ (582件) を見る
読書会をすることになった!! 〜TeamGeek〜
油断するとあっという間に１ヶ月が経ってしまう（当blogに記事を書かないまま）、今年もそんな感じですが、その辺は ゆるーり ヨロシクです。
さて、今までもアジャイル系の社内勉強会に関することをupしたことがありますが、今日はそのネタです。
この会は一昨年の夏から毎月行っていて、まだちゃんと続いているものの、メンバが固定気味という良くあるパターンに陥りつつあり、でもそんな中、年も変わったし改めて仕切り直してイコウゼ!!ってことでひとつ決まったことがあります。
（ゴホン）
ど、ど、読書会をすることになりました(・∀・)♪♪♪♪
対象の本はいくつか候補があったのですが、満場一致で『Team Geek〜Googleのギークたちはいかにしてチームを作るのか』に決定!!
Team Geek ―Googleのギークたちはいかにしてチームを作るのか
- 作者: Brian W. Fitzpatrick,Ben Collins-Sussman,角征典
- 出版社/メーカー: オライリージャパン
- 発売日: 2013/07/20
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (19件) を見る
自分も前から読もう読もうと思っていてAmazonのカートの中に眠っていたのですが（汗）この度無事に購入して、早速読み始めましたよ。
結構アツい！ヤバい！これはオモロい！
エンジニア自身（ヒト）とかチーム・組織（人間関係）とかにフォーカスしつつ、状況を想像しやすい例え話があったり、これは読書会、盛り上がりそう。いやマジで。
取り敢えずは１ヶ月に１章のペースで進める予定。ま、あまり無理せずに。
１月：この本を選定
２月：第１章、天才プログラマの神話
３月：第２章、素晴らしいチーム文化を作る
４月：第３章、船にはキャプテンが必要
５月：第４章、有害な人に対処する
６月：第５章、組織的操作の技法
７月：第６章、ユーザーも人間
てな予定です。
社内勉強会と言っていますが、混じりたい人が居たら連絡くださいなwww
いつも都内中央区の某所ですが、その時は本気で検討しまつ( ｰ`дｰ´)ｷﾘｯ
ちなみに、
実はこの読書会で１つチャレンジがあります。
それは、訳本（日本語）を読んでくるメンバと、原著（英文）を読んでくるメンバを混在でやっちゃおうってことです。
技術情報のソースって英文が多いですし、社内では外国籍の人も増えてきたし、でも自分は、訳書をノータイムで買っている訳ですが・・・( ´ Д｀)
さて、どうなるでしょうか？
乞うご期待！
Team Geek: A Software Developer's Guide to Working Well With Others
- 作者: Brian W. Fitzpatrick,Ben Collins-Sussman
- 出版社/メーカー: Oreilly & Associates Inc
- 発売日: 2012/07/18
- メディア: ペーパーバック
- この商品を含むブログ (1件) を見る
PS.
会のメンバから提案があったんですが、読書会の様子とかこういったblogというかインターネッツで公開してみるのも面白いかもーーー
