コード日進月歩

しんくうの技術的な小話、メモ、つれづれ、など

『DevLOVE X 〜 それぞれの10年、これからの10年〜』の2日目に行ってきたよメモ

行ってきたメモ

DevLOVE X 〜 それぞれの10年、これからの10年〜に行ってきたので、昨日に続き 2日目のメモ

各発表の感想

※資料スライドは見つけたら貼ります。

技術に対する愛が人生を大きく変える !!

ということで内容メモでお送りします

発表メモ

若い方に何かを伝えられればという形でいままでの人生のお話

学生時代

  • 今は英語ができるが、高校大学でも英語ができたわけではない
    • 英語の授業も決していい点数ではなかった
    • そんな状況でも今は英語を仕事で使うことができている
    • 最初からできたわけではない、やるかやらないかが重要
    • 新しい技術、情報を正しくキャッチアップするには英語は重要
  • 大学の頃に同じバイトとして働いていたいた人に大学でちゃんと学ぶべきという旨に気付かされる
  • 気付かされた大学3年からどんどん勉強を重ねて行ってJavaやUnixへの道へ進んでいく
  • 伝えたいこと：子供の頃から優秀だったんじゃない、自分自身が変わろうと思ったら変われる。いつからでも遅くない人間変わろうと思えば変われる

最初の失敗

  • 最初はGlassFishというプロダクトがエバンジェリストになったきっかけ
    • 良いプロダクトだったが営業さんなどはあまり見向きもしていなかった
    • そこから広めたいという気持ちからいろいろな人を伝ってエバンジェリストのグループに入る
  • JJUGではさくらばさんへの思いから、9割の参加者を寝させてしまう
    • すごい人に声をかけられたということから、ニッチな内容のプレゼンをしたら一般参加者を眠りに誘ってしまった
  • 伝えたいこと：最初は失敗した、みんなも怖がらずチャレンジしてほしい

伝説の謝罪会見

  • 時代背景的にJavaへの風当たりがひどい時期にデブサミのプレゼンに呼ばれる
    • 発表にたつときはどんな言葉が飛んでくるかわからないからすごく緊張した
    • 緊張が聴衆まで伝播してしまい、謝罪会見と称されるぐらいになってしまう
  • この登壇でエバンジェリストとしての振る舞いが変わる
    • 何があっても自分が矢面にたつ。いいことも悪いことも受け止める。
  • Javaが好きだからできる
  • 伝えたいこと：技術に対する愛が人生を大きく変える

てらだよしおがんばれ

  • 日本各地を回るなどして、JavaOneTokyoの開催を盛り上げる
  • ただしリハーサル日にアクシデントが発生、ただなんとか当時には持ち直す
  • そんな中「てらだよしおがんばれ」のハッシュタグがTwitterに溢れた
  • イベントは成功、最終的に功労者として打ち上げで胴上げされるぐらい
  • そのあと日本オラクルがJavaに投資してくれたのはこのイベントがあったから
  • 伝えたいこと：コミュニティの盛り上がりが各テクノロジーや企業にとって大事

転職

  • 強い日本のJavaコミュニティに戻った
  • Javaも20周年が節目になった
  • そんななか様々な同僚や仲間に出会えた
  • 伝えたいこと：良き同僚、友人、先輩との出会いが今の自分を作っている、頑張っていると味方ができる

いま現在

  • マイクロソフト社にいるが、サンマイクロシステムズ時代は思いもしなかった
  • ただいまのMSは昔のSunのような雰囲気を感じている
  • いろいろ騒いではいったものの成果がでない時代を経て、いまでは自身でJavaの案件を引っ張ってきている
  • 伝えたいこと：過去の栄光やタイトルにしがみついてはだめ、今そこで何を成し遂げるかが大事

最後に

  • エンジニアは何歳になっても成長できる、過去の財産が今に生きる
  • 今は他の人のロールモデルと言われるぐらいになっている
  • みんなOnly oneのものがあるはずなのでそれを伸ばす
  • 好きな言葉Dreams Come True
  • 未来は明日からではなく、今日から始まる

感想

  • 全然Javaの世界には触れていないエンジニア生活を過ごしていたので時代的な背景も含めてそういうことがあったんだということを知ることができたし、それに対しての寺田さんの話がエモいし、最高によかった
  • 英語に関しての部分はすごく刺さったというか、「最新の技術をキャッチアップするためには英語が重要」という言葉で考えさせられた
  • こうやって年を重ねてきた方の話を聞くと、自分の未来も何か動きたいなと思ってしまうし、動きたいと思った

関連リンク

データ駆動 x リーン x スクラムを組織文化に浸透させ、プロダクトをグロースさせる

感想

  • どうやって1→10のプロダクトを成長させていくかという観点のお話
  • スクラム、リーン、データ駆動開発をどうやって絡めて言っているかを元ネタ含めて解説
  • データの奴隷にならないように、ちゃんと意思決定の中にデータを持つという考え方に関しては改めてそのとおりだなと考えさせられた

関連リンク

スクラムの原典を読み解く(1)：An Agile Way：オルタナティブ・ブログ - 今回いろいろなところで出てきたスクラムの原典に関しての話

価値の源流に向かう旅

www.slideshare.net

発表メモ

  • いままでの10年、翻訳と仕事をやってきたが実は領域はかぶっていない
  • 翻訳は全体像の網羅、仕事はどんどんお客さん側へ、すなわち価値の源流に進んでいった
  • 理論を学び、できる限り地に足のついた言葉を学ぶ
  • アリスター・コーバーンのたとえで空と海と魚という表現があり、空がSummryGoal、海がUserGoal、魚が具体的な実装という考え方。この中でもUserGoalを考えるのが大事。
  • 屏風と虎の話があるが、屏風の虎を追い出すのと虎を捕まえるのでは難易度の性質が違う。この寓話のように設問が正しくない場合がある。
  • 「高速に答え合わせをすることは適切に問いを立てることを代替しない」
  • 問が正しくないと解決がしっかりできないので問を正しく立てることに向き合う
  • SummaryGoalは明確にあるが、それを実現するためのUserGoalを適切に設定するのは難しい
  • それを設定するためにはドメインエキスパートと対話する
  • 実システムの設計もちゃんと業務知識を吸い上げて適切なものか向き合う必要がある
  • 「 包括的な方法論を学ぶことは具体をコツコツ考えることの上位互換の関係性ではない」別のもの

感想

  • システムと向き合うときにどうやって立ち向かっていくかというのをユースケースなどの切り出し方から話された感じだった
  • アリスターコーバーンの話が出てたが元ネタがわからない…そしてぐぐっても出てこないので出典を知りたい…！ 出典まではわからなかったが、どういうことを表すことかの情報はいろいろ出てきた。
  • 発表が公開されると思って油断していたのでメモが結構曖昧、スライドが公開されるのを待ちたい
  • 問いを立てて高速で解いていくことが正しくなることかと思っていたが、一休さんのたとえを見ると一概にそうも言えないということに気付かされれる。
  • まずは基礎理論とか学んでから実践だ！というのは正しいのかもしれないが、方法論を学んで具体の経験を積まないというのはやっぱりなんかすっぽ抜けることになるんだなと改めて思った。

関連リンク

技術ブロガーを育てる！ブログメンタリングで何を教えているのか

kakakakakku.hatenablog.com

感想

  • 技術ブログといえばおなじみカックさん、もとよりこのブログもカックさんの記事に影響されている部分もある。
  • 発表もテンポいいし小ネタいい感じに挟むしでうまい。
  • かなり自分がしていることの答え合わせ的な感じの内容だった。このブログは割と近い思想で運営されている感じはある。
  • メンタリングの回はすごい学びがあった。有事の際の下書きとか、汎化というワードは確かにという感じだった。
  • 弊ブログは一年間で365記事書くというのが目標なので時間の概念のしばりは割とゆるいのだけれど、ちゃんと習慣化することが肝心なので改めて行きたいなと思った。

関連リンク

ソフトウェア設計の学び方を考える

感想

  • 設計のレベルアップとその契機に関してのタイミングに関しての話。
  • 「構造と秩序」という形で表現し、その秩序が崩れたときに治すのではなく新しい秩序を加えていくという表現はかなり的を得たものだと思った
  • 設計において4つのステップに分けて仮設と実験はやっているが、それ以外のことを観察と考察と捉えてそこを意識的にやる大切さに関して丁寧に説明されていて納得感が多かった
    • 観察は広く多くを知って、必要な情報を引出せるようにすること。枯れた技術の水平思考に近い考え方でもある。
    • 考察はなぜちゃんと動いた、いい形になったかをしっかりと見つめ直すという動作
  • 写像に対して逆写像ができるかはオブジェクトをなぜ作るかという話の一つの回答になりそうだった
    • 「なんでわざわざオブジェクト化するんですか？プリミティブで十分じゃないっすか？」と良く問われていい回答が思い浮かばなかったのでありがたい
  • 20%の更に20％の洗練化は本当にマスターへの道という感じがする
  • 色んな所で増田さんの話を聞いているが、毎回少しずつ切り口が違うので毎回発見があるし、重ねていくことで新たな発想力を養われている気がする
  • ダイクストラ法から考える歴史は温故知新という感じで聞いてみたかった

関連リンク

自己組織化されたエンジニアチームを作る習慣 〜プログラマが経営者になって10年の学び

発表メモ

自己紹介

もともとプログラマーで今は経営者 ソニックガーデンの経営と、北欧暮らしの道具店の社外取締役をやっている。 ソニックガーデン2011年、社内ベンチャー時代があった ソニックガーデンはいろいろ注目されている

  • 納品のない受託開発
    • 月額定額というサービス（毎月お金もらう）
    • 要件定義をしない、見積もりしない、人月をださない
    • 客との関係性は顧問弁護士や税理士と同じモデル
    • 人少ないほうが生産性が高い
    • エンジニアが気兼ねなくお客さんにサービスができる
    • 時間で商売したくない、客先には行かない、1時間いくらはやらない
    • 毎週成果出すからそれでいいかって聞く、時間で働いたじゃなくて成果を聞く
    • 詳しくは「納品」をなくせばうまくいくを読んで
  • リモートワーク
    • 打ち合わせはテレビ会議にしよう、オフィスやめようとなった
    • 2016までは渋谷にオフィスを借りていたが、手放した
    • 在宅勤務第一号はJunichi Ito
    • ネット上にログインしたら出社、ログアウトしたら退社としても問題がなかった
  • 管理しない会社
    • 指示命令系がない、評価しない、進捗管理しない
    • セルフマネジメント、給料は一律
    • 管理ゼロで成果があがる
    • なぜ管理しないのか？ソフトウェア開発はどうやったら生産性あがるのか、内発的動機づけでうごくようにした
    • 同じプログラムを書くということは絶対ない、再現性がめちゃくちゃ低い仕事、そういうのはクリエイティブな仕事
    • クリエイティブな仕事は管理しないほうがつよい
    • これが自己組織化されたチーム

どうして自己組織化チームを目指すようになったか？

  • 学生時代からベンチャーに働いて、研究室でプログラミングをしていた、それらはユーザーから喜びをもらえるのめっちゃ嬉しいというところがあり、そこが原体験としてあった。
  • そこから就職した1999年はマネジメントの時代、技術のTISと言われていた会社に就職したのにマネジメントが台頭してきていた。
  • 実装工程に入る、火が吹いているところに入るという、学生時代のプログラミング時代との体験の違いに気づく
  • なぜこうなっているのかヒアリングに行くと、わかったのは上流に行けば行くほど慌ただしくない清らかな世界で、これの根源はウォーターフォールであり、よくないと感じる
  • ここでアジャイルとである、エクストリームプログラムを知り、アジャイルを広げようする
  • アジャイルを現場でやっていこう、としたら大失敗した
    • お客さんからは50%できたところで残り50％いらないと言う話になったが、検収的にできなかった
    • 開発してるチームメンバーとしても「振り返りいらない」と言われてしまう
    • 正しいことをしているが正しいとは限らないと思い知る
  • 一括請負のなかで繰り返しやるのは意味があるかというと、そうでもないということに気づく
  • そこから社内システムを作る立場として管理職からプログラマーに戻った、Rubyを使って2年目と作ってた
  • 社内システムは予算とほかプロジェクトのの炎上に弱い
    • 炎上するとメンバーがすぐに引き抜かれる
    • 同じ思想の人とチームがやりたいが予算が削られる
  • 売上が立てばそういう影響をウケないだろうと言うことで、ということで社内ベンチャー
  • 事業計画書をつくったが、お客さんが取れないという自体になる
  • その時から管理をやめ、みんなで考えるようにした。そこから自己組織化できるチームになる

自己組織化するための週間

  • 自己組織化を目指した
  • セルフマネジメントできるように育てたし、セルフマネジメントできる人たちだけを揃えた
  • どんどん見直していくことをやってく、価値を出すとかを大前提にしていく

  • 大きく3つのことに取り組んだ

  • 小口化

    • なんでも小さくするとうまくいく、小さくすることがアジャイル化
    • 例えば会議出る人数は減らす、オーディエンスと参加者を分ける
    • 単位を小さくしたほうが軌道修正しやすい
  • ふりかえり
    • YWTをつかってやっている
    • 計画を建てないし、目標をチェックしない代わりに観察をする
    • 何が起きたか事実を確認する、そこから何を学べたかを深掘りする（主観に変わる）
    • 深掘りにするところでなにがを大事にしていることはわかる
    • わかったことをつきつめると、次にやることが見えてくる
  • ザッソウ（雑談 + 相談）
    • 報告は要らないけど、相談は大事だろう。相談しないと解決しないことだらけ。いきなり知らない人を相談するの難しい。
    • 普段から雑談することを推奨。雑草しましょうとする。心理的相談

自己組織化のきっかけ

  • 3人の出会いがあった
  • 牛尾さん(NECの方、現MSの人）
    • 脳のブレーキを壊すということを教えてくれた
    • 誰かができると思うとできるとできる
  • 平鍋さん
    • 外に発信していきたいときに当時は雑誌の寄稿がメジャーだった、そこに関して軽く返事をしてもらえた
    • このときから相談された側は軽く返すのがいいと考えている

  • TISの専務

    • 3年目で動いたときにコメントされたことが印象に残っている
    • 仕事をとる、と、仕事をするは違う、一人でやるのは楽しくない
    • なので、（仕事が取れるように）有名になりなさい、仲間をつくれ

  • 人と人とのつながりが今を作っている、自分自身を変えた

  • 資本主義を疑ったほうがいい、資本主義は1をもらったら1を返す考え、それでは何も変わらない
  • 1を返したら1.1を返す、そうするとうまくいく

感想

  • スライドがないのにめちゃくちゃ内容の濃い振り返りトピック
  • ソニックガーデンさんはRubyとしても、リモートワーク事例としても、振り返りフレームワーク事例としてもいろいろ学ばせて頂いているので、その源流や原体験みたいなものを聞けてよかった
  • プラクティスがだいたい日本語なのが面白い

関連リンク

我々はどこまでいっても、ぼっちだ。 それでも、ともに。進んでいく。

感想

  • ソフトウェア開発がどんどん複雑化、多様化しているというのは確かにそのとおりだなというところでそこに対してどういうアプローチを考えていくのは本当に次のフェーズを生き残る上で大事だなと思える。
  • ともにある、ということで今まで以上に誰かのことを思える、思われることが大事だしそういう気持ちとちゃんと向き合える人、向き絵あるような場作りが大事だなと思えた

関連リンク

全体を通しての感想

  • 2日いたのですが、主に「これまでの10年、これからの10年」だったのでエモい話から、自分のモデルケースの肉付けになる話題まであり、技術的な肉付けというよりは開発者としての人間的な肉付けのさせかたを考える、知るという機会になりました。
  • ハンガーフライトということばがあるように、誰かの経験談は100%ではないが追体験できるのでそれをもとに自分の進むべき道の道標になるなと思った。
  • 「これまでの10年、これからの10年」を書いて発表するワークがあったのでそこで出たことはやっていきたいなと思った、特に、英語を…