デブサミ2020に参加して、会社に提出するレポートを書いたものの……。
長すぎじゃないか？
と。さすがに、自分の上司は性格からすると読もうとするでしょうし、このセッションの内容を見たらいいよとピンポイントで勧めたりはしましたが、メモをドカッと渡されても困るだろうと。
結果、こんなことを言われるでしょう。
結局、参加してどうだったんだ？
なので、自分が参加してみた、セッションを統合的に感想を書きたいと思います。
モブプログラミング
今回のイベントは「ともにつくる」というテーマでした。そのためか、エンジニアチームとしてのセッションが多かったです。
そのテーマと世相を最も反映したのが、モブプログラミングではないでしょうか。
簡単に言うと一つのプログラムを皆で作る手法です。
一人のドライバーがコードを書いて、他の皆はナビゲーターとして口出しをするというペアプログラミングの多人数版です。
デザイナーもモブプログラミングに参加するという話もありましたし、テストコードを書くときに使ってもテストケースの漏れがなくなるという話もありました。
一つ一つが確実に終わっていくので、終わったものからコミットしていけば、製品価値として提供できるのでビジネス的にもトータルで見れば一度にまとめてよりも多くの価値が提供できるという考えが出来ます。
オンボーディング
採用のパネルディスカッションで、採用してからフォローに何が必要なものはなんですかという質問があって聞いた言葉。
意味としては、新しく加わった社員に戦力になってもらう育成プログラムです。
これまでの日本だと、要は新入社員研修のことになるかと思いますが、これからは中途入社の社員についても大事になってくるかと思います。
エンジニアの採用は競争が激しく大変です。お金もかかります。
取るばかりで、取った人が戦力にならなかったり、辞めてしまっては意味がないです。
採用と合わせてオンボーディングも考えていくことは必要と感じた次第です。
ウォーターフォール型開発
スクラムとかアジャイルの話をするのがデブサミですが、あるセッションで、
ウォーターフォール型開発をしている人はどれくらいいますか？
これが多かったようです。私もそうです。
ウォーターフォール型は最初に大きな要件を決めてしまいます。ですが、見積もりは外れるもので大きく外れてしまうとリカバリが大変になります。
なのでアジャイルのように小さく作って確認した方がいいですよ、となります。
というのもなかなか、これまでの開発体制から新しい体制に変えるのは壁もあります。
企業としてのスタンスもありますし、ユーザーのこともあります。
メルペイのようなイマドキの企業でも、最初のリリースで後発だったので色々やろうとして、いつまで経ってもリリース出来ない状態であったため、ウォーターフォール型開発で乗り切ったそうです。
GraalVM
AWSのJava On Serverlessのセッションで出た言葉。
会社の勉強会でも聞いてはいましたが、やはりパフォーマンスを上げるのに期待が出来るようです。
残念ながらSpring BootではGraal VMの制約上使うのが大変です。使いたいのであればMicronautあたりになります。
GraalVM、これから来るのか？と感じた次第です。Javaユーザーは注目しておいていいのではないでしょうか。
私はJava、興味ないですが。
これまでの良さを取り入れつつ進化する
ティール組織とは、組織の各メンバーが自律的に行動する組織のことです。
そんな皆が勝手に大丈夫か？と思ってしまうのではないでしょうか。
ゆめみのセッションでは、それについての答えをきちんと説明していました。
まず、組織の進化段階というのを理解する必要があります。
各組織には欠点と利点があります。
ポイントとしては、前の進化段階の組織の良いところを包含するということです。
なので、時としては、経営陣の力で組織を律して短期的な改善必要であり、成果によってやりがいを得て昇給できることも必要、それに加えて、個々が自律的に行動していき成長できる。
ティール型組織という横文字混じりの言葉より、覚えて欲しいのはこれまでの良さを取り入れつつ、新しくなろうという事です。
時に、新しい言葉に胡散臭さに感じるのは、これまでのはダメだ、全部新しくしなければダメだという一元論に陥ること。
そうではなく、新しいことの良さを取り入れつつ、古くても良いものは良いという事。
エンジニアとエンジニア以外
メルペイのセッションで、言い続ける事が大事というのがありました。
メルペイのような最近の企業でも、技術的負債を返すことについてエンジニア以外が理解を示すのは難しいことのようです。
エンジニアがそうなのか、私がそうなのか、エンジニアって正しいことを言えば、わかってもらえるもの。わかってもらえないなら、相手が聞こうとしないか、理解力がないのかと、自分の説明が悪いのかと思いがちです。
そうではなく、ただ、言い続けることでやっと理解してもらえるということ。
星野リゾートの経営者にも開発なってベンダーに任せておけばいいじゃんと言われる中で、結果を出し、行動する中で、やっと理解してもらえたという話がありました。
不具合についてもエンジニアさん、あとよろしく。ではなく、サポートなどが協力していかないと解決しませんという話もありました。
エンジニア以外のサポートや経営層をいかに巻き込んでいくかということがこれから問われていくのかなと。
個人的に面白かったスピーカー
パネルディスカッションでしたが、
黒田さん「お前のWill（意志）はあるのかと言われる。いつも白紙で出している」
とか
質問「どんな組織にしたいですか？』
黒田さん「Aボタン押しっぱなし」（組織をスムーズに進める上での障害を取り除きたい）
とか
質問「辛くなったらどうしますか？」
黒田さん「ゲームしてMP回復」
などなど。端的な迷いのない発言で、伝えたいことを伝えていました。
