00:00
株式会社株区スタイルの後藤秀典です。この番組では、エンジニアリングチームで起きている問題について、技術、組織、ビジネスといった複数の観点で深掘りし、問題の正体へアプローチしていきます。
テーマの紹介
今回のテーマは、物事の始め方ときっかけについてです。
今日は実はゲストをお呼びしておりまして、その方と色々なことに取り組んでいらっしゃる方なんですけれども、どういう風にそれが始まったのかとか、そういうところを色々エピソードを伺えればなと思っています。
エンジニアリングマネージャーの問題集。
では本日のゲストを紹介します。Webエンジニアのフォルテさんです。フォルテさん、簡単に自己紹介お願いします。
Webエンジニアをやっておりますフォルテと申します。
基本的にはバックエンドが経験多いんですけども、フロントエンドもインフラも色々やってる感じのWebエンジニアになります。よろしくお願いします。
今日はよろしくお願いします。
Twitterでお声掛けいただいて、フォルテさんの方もポッドキャストだったり色々やられてるんですけれども、ちょっとこちらの方に出てみませんかというか、一回やってみましょうという感じで今回ゲストとして来ていただいております。
今日はマネジメントを中心にいくつかのお話をさせていただきたいと思ってるんですけれども、まず結構色々なことをやってらっしゃる中で、どうして今のフォルテさんになったのかというか、フォルテさんってどんな人なんやみたいなところを聞いてる方も知りたいのかなと思いますので、
何でしょう、社会人になってからのどんな会社でどんな感じのことをされてきたのかって、フォルテさんの方からお話いただいてもいいですか。
そうですね、私新卒でこのIT業界に入ったのが2007年の時でちょうど20歳の頃だったんですけども、なので今大体17年目ぐらいこの業界にいるんですけども、最初の会社がいわゆる中小のSIRと呼ばれている大手結構有名な会社のグループ会社みたいなところでして、
そこで9年間同じ会社にずっといて、主に受託受け負いの開発をやっておりました。で、それもウェブサービスですね、一般にインターネット上に公開されるっていうよりはその会社さんの業務システムをイントラ内に作るみたいな案件が多かったんですけども、
そういった案件を半年ごとに受託で繰り返した案件をやっていく中で、毎回デスマーチと言いますか、炎上するということが多かった。多かったというか、ほぼ炎上してたんですけど。
なのでなんか、大体その半年なんで、3月末年度末とあと9月かな、10月かとかに農期を迎えるっていうパターンが多かったんですけど、その3月9月になると残業給出が増えるっていう典型的な辛い開発と言われているやつでして、
大体そんな開発の仕方が6、7年続いた時に、当時私テレビゲームが好きで、ネットゲームも好きなんですけど、当時発売されたぐらいのファイナルファンタジー14というネットゲームMMOがありまして、
でちょっとそのゲームが色々あって作り直すだったりですとか、一度サービス開始したものを畳んで新しくもう一回サービスインするみたいなことをちょっとやった、結構世にも珍しいと言いますか、おそらくこんな例は一つしかないと思うんですけど、
確かに。
っていう例があるというか実績があるゲームだったので、結構それに関するカンファレンスじゃないですけど、こういう知見がありましたよみたいなのがゲーム開発業界内で発表とかがされてまして、
ちょうどそのタイミングでゲーム開発プロジェクトマネジメント講座っていうそのファイナルファンタジー14をどうプロジェクトマネジメントしたかという講座があったんですけども、その資料を読む機会があったんですね。
これ資料を読んだ時にすごく本当に良いことが書いてある。マネジメントとしては当たり前のことなんですけど、その当たり前すら知らない私にとっては非常に目から鱗が落ちると言いますか、世界が広がる感じがしまして、そこからアジャイルだったりとかスクラムだったりとか、
プロジェクトマネジメントですよね。そのマネジメントをする管理というよりはうまく回していくっていうところに非常に興味を持ったっていうところがまずきっかけであります。
なるほど。今の話だけですごいストーリー性があると言いますか。めちゃめちゃ面白いですね。最初のSIRさんのところって、ちょっと脇道の話かもしれないですけども、言語だったりどんな業種のどんなシステムを作ってらっしゃったのかって言える範囲で伺うことできます?
はい。言語としては基本的にJavaが多かったんですけども、ウェブ開発をすごく得意と言いますか、経験があるエンジニア、ベテランエンジニアみたいなのがいなくてですね。
もともとそのロボット制御みたいな、いわゆる組み込みって言うんですかね。メインのところに新しい案件、これからはインターネットだみたいなところでウェブを始めたみたいな会社だったので。
そうなんですね。
なのでなんか当時もうスプリング、フレームワーク、スプリングとかあったと思うんですけど、フレームワークっていう存在すら知らないみたいな。
なるほど。
あとMVCなにそれみたいな感じの。本当にそういう今で言えば本当お決まりというか基本みたいなことがわかってない人たちがなんとなくネットや書籍で拾ってきたハローワールドみたいなものをベースに書き始めたコードが綿々と受け継がれているみたいなことが多くてですね。
なのでちょっと専門的なというか言語に依存した話をすると、Javaを基本的に使っていたんですけども、いわゆる生のサーブレットっていう表現になるんですけど、本当にサーブレットに対してリクエストレスポンスを書いていくみたいな形で。
フレームワークとかそういうMVCみたいなのもわからないので、1個の.javaファイルにメイン関数じゃないんですけど入り口と出口があるみたいな感じでリクエストを受け取って中身見てSQL投げて結果を加工して。
当時はJSPっていうテンプレートみたいなのがありましたね。あれに埋め込んでとか、あとはもう何ならサーブレット側でHTMLをテキストで起こしたものをベースに送るみたいなことをやっているような感じでして。
なるほど。
業界的には受託受け負いだったので、お客様の案件によるというか、お客様の業種によるというところが多かったんですけども、グループ会社っていうのもあったので、親会社といいますか、元の会社の仕事を受けたりっていうのと、
あとは配達とか郵便とかそういう運送業っていうんですかね、の業界とか、あとは小売業みたいなところでバーコードをピッと読み取るようなハンディーにちょっと組み込むようなプログラム。これはちょっとwebではないんですけど。
あと私が直接関わってない部分であったのは、太陽光、ソーラープレイ。まだちょっとスマートメーカーとかが普及しきる前ではあったんですけど、その太陽光の発電状況とかをリアルタイムにwebで見れるようにしようみたいなプログラム、プロジェクトがあったりとか、そういった感じでいろいろやってたって感じですね。
いやー、なるほどなるほど。その辺の話、もうちょっとしたいなぁ感はありまして。何でかっていうと、何ですかね、やっぱり今2020年ってwebの作り方とかって、もういろいろ研究されていてというか、ベストプラクティスみたいなのが豊富にあって多分多くの人はそこからスタートしてると思うんですけど、
僕多分ホルディさんよりさらに一回りというか何というかちょっと前の感じではあるんですが、やっぱりwebでシステム作るっていうのが、何かそのベストプラクティスも何もないというか、何かそういう時代でしたよね。
エンジニアリングマネージャーの問題
そのスプリングみたいなのが一部では出てきていたにせよ、何かもうそれが当たり前みたいな感じには全然なっていなくて、まあそのもちろんキャッチアップできてないとかいろんなところもあるでしょうけど、とはいえ何か割ともう自分たちで何かどうやって作るのかなって、結構ゼロベースみたいなところから何か勉強しながらというか、
そんな感じで作ってた気はしますね。
いやーそうですよね、あと特殊な制限というか環境だったということ一つを付け加えると業務システムが多かったので、
社内だけみたいな。
なのでいわゆるその当時2007年ぐらいだとまだi6、インターネットエクスプローラー6がバリバリ使われていて、かつそのイントラでしか使わないから複数ブラウザ対応みたいなのも必要ない感じなので、もう本当にi6でしか動かないJavaScriptをひたすら書く。
そうですよね、それでいいというかむしろそれじゃない。
当時だとプロトタイプJSとかでしたっけ?
ありましたね。
多分JQueryの1個前ぐらいだと思うんですけど、ようやくブラウザ感の溝を埋めるみたいなところが。
そうでしたね。
始めた頃は多分それぐらいだったんですけど、さっき言った通りi6しかなかったので、そういったものを入れようみたいな動きにもならず、ひたすらいわゆるバニラJSを書いていたって。
そうですよね。その辺の作法もクソもない頃から僕やってたんで。
ゲットで送信するのか、ポストで送信するのかとかもう何もないんですよ。
ない、ないですね。
好きにやるというか。
当時はAJAXが、AJAXって言葉が出てきたぐらい?
ぐらいですかね、2000年ちょっとみたいなところで。
なので、今みたいに通信周りのライブラリーっていうんですかね。
全然なかったですね。
あったとしてもメジャーではない感じではありましたね。
いやぁ懐かしいですね。時代は進化しましたね。
そうですね。
そんな中で、最終的にスクウェア・エニックスのところに辿り着かれるんですけれども、
プロジェクトがことごとく炎上みたいな。
いやいや、そんなもんだよなと思いつつ、表現としてはなかなか面白いと言いますか。
っていうところでやってらっしゃって。
なんでしょう、そこも技術的にというかノウハウがなかなか持ってらっしゃらなかったみたいなところもあると思うんですが、
その後から振り返ってみたときに、それ以外にも何かプロジェクトマネジメントなのか、何かのところで要因があったっぽいんですかね。
なんか本当に、ただ一つこれが原因みたいなのは今パッと思いつかないくて、複合的なものだとは思うんですけど、
業界的にあるあるなのが、営業が取ってきた案件が無茶だったみたいなところも多分あったとは思うんですよね。
それで始まったときに、結局そのマネージャー層と言いますか、マネジメント層がその無茶をまず正せないというか、言い出せないみたいな、契約なんでみたいなところですよね。
なんとなく当時はウォーターホールだったので、最初に当然選票と言いますか、スケジュールを立てて、当然その時点で終わるスケジュールを立てるんです。
最初から終わらないスケジュール立てる人はいないので。
で、大体1週間か2週間ごとにお客様に進捗報告とか、社内に報告とかするんですけど、稲妻選って言って分かる方がどれくらいいるか分からないですけど。
今言うのかな。
言わないですよね、きっとね。選票と呼ばれる、横に倒した棒グラフみたいので設計が例えば1ヶ月とか、
実装が1ヶ月、テストが1ヶ月、リリース2週間みたいな感じで、工程ごとにスケジュールを引いていくんですけど、
それに対して横軸の棒グラフに対して縦線の点線で進捗を表すっていうのがありまして、
で、進んでいるところは山になると言いますか、右側に振れて。
遅れているところは左側に凹む谷になるので、ギザギザした線になるんですけど、これを稲妻選と当時、現場じゃ呼んでいたんですけど。
これがどんどん凹んでいく。基本的に凹んでいくんですけど、毎打押しってあんまりないので。
で、じゃあなぜそうなったかっていうと、要は仕様が決めきれなかったりですとか、あとはもう不確実性ですよね。
これやるならあれやらなきゃダメじゃんとか、これやったことないんだけどどうやるのみたいなところでどんどん想定外の。
それはその契約だったりとか、一番最初に仕様を決めるときですね、見積もりで要求仕様を定義するときに決めきれなかった部分がまずそこで歪みとして出てきて、遅れ出すっていう感じですね。
で、結局それもまたマネジメント層がそこを立たせないまま、残業でカバーしますとか、QCDじゃないんですけどテスト省略しますみたいなことなんか。
できないんですけどテスト省略なんて。
マネジメントへの興味と触発されたプロジェクト
っていうので、要は悪臭っていうんですかね、悪い見本みたいなマネジメントを続けた結果、当然後工程に行けば行くほどその幸せが全て後工程に被ってくるので、
さっき言ったようなデスマーチっていうのは実装、テスト、リリースみたいなところがそういったところの幸せを食らってっていう感じですね。
いやー、まあ今話せばなんか笑い話なんですけど、本当になんかそうなんですよね、なんかうまくいかないんですよね、いろいろ。
そうですね、まあそういったところでやってこられて、そういったご経験ご苦労されながらの、どっかの時点でファイナルファンタジーのところ出てくるんですけれども、
これ、まあそのプライベートの方っていうんですかね、ファイナルファンタジーを突然始めたっていうことではないと思うんですが、
ゲームとかはまあ並行してずっとこうやられていたっていう感じなんですかね。
そうですね、子供の頃からテレビゲーム、いわゆるファミコン、スーパーファミコンみたいな時代からゲームが好きで、
ずっとゲームをやってきた中で、当然ファイナルファンタジーやドラクエ、ドラゴンクエストみたいなメジャーというか有名どころなゲームも好きでやっていて、
2006年、7年ぐらいにそのファイナルファンタジーの新作がネットゲームで出るぞというのが話題になって、
しかもものすごいグラフィックであったりとか、システムが盛りだくさんで、もうなんか夢のようなネットゲームが出るみたいな話題になって、
で、蓋を開けてみたら、先ほどもちょっと言ったように、もうぶっちゃけ忖度なしで言えばバグだらけ。
で、どれぐらいのバグかというと、RPG、ゲームなのでメニューを開いたりするんですよね。道具を選ぶとか装備を変えるみたいな。
で、そのメニューを開くボタンをポチって押すと、メニュー開くのに3秒から5秒かかるんですよ。
もう基本がまずできてないっていうところで。
で、ゲーム自体も確かにハイクオリティというか、グラフィックが非常に綺麗だったんですけど、綺麗すぎて重たすぎるっていう問題があって、
これはまぁ後の世でも言われてはいるんですけど、RPG、ネットゲームで人間のキャラクター、プレイヤーキャラクターですね、プレイヤーキャラクターが出てきて会話したり冒険したりするっていうゲームなのにも関わらず、
その他のキャラクターがほぼほぼ表示されないっていう状態になってまして、それは何でかっていうと、
本当は優先すべきは他のキャラクターを表示してコミュニケーションを取れるようにすべきっていうのがネットゲームMMOの基本なんですけど、
その時点でのFF14は他のオブジェクト、例えばその辺に置いてある火壇ってあったりとか、
街のライトみたいな、電灯みたいなものの方がプレイヤーキャラクターよりポリゴンと呼ばれる、要はリソースですよね。
グラフィックリソースを割いていて、一説にはその火壇がプレイヤーキャラクターの4倍だか8倍ぐらい重たかったらしくて、
当然火壇なんで、道に火壇が1個置いてあるなんてことはないわけで、それが道に点々といくつも置いてあるんですよ。
もうそれだけでリソースを食い潰しちゃってて、キャラクターが表示されないとか、
例えば街に入る時、フィールドから街に入る時のロードで、その火壇のロードに時間かかっちゃうみたいな。
っていうのでも、ほんと基本ができてないみたいな状態で、ボロクソに叩かれるというか、大炎上をしたっていう感じで。
で、そこから3年ぐらいかけて作り直したっていうのがさっきの話ですね。
僕もゲームはそこそこやってるんで、その話も舌触りますけれども。
でもそれでFFのプロジェクトのカンファレンスがあった発表の話にたどり着くっていうことなんですけれども、
これなんかでもどうなんでしょう。単にゲームをやってたから、そこにカンファレンスを覗いてみたとか、
そういう単純な話でもなかったりするんですかね。どうきっかけでそれを見ようってなったんですかね。
多分本当に私がゲームだけをやっている人だったら、このカンファレンスの存在を知っても資料まで見ようとか、
中身まで見ようって思わなかったと思うんです。
で、じゃあなぜそれを見ようと思ったのかというと、やはり私がIT業界といいますか、
コンピューター、パソコン、プログラムを使って開発をやっているっていうところと、
当時のゲーム開発もWindowsの、WindowsかMacかどうかなんですけど、パソコンで開発をする、
特にネットゲームMMOなので、いわゆるコンソールとかコンシューマーハードと呼ばれる、
ファミコンとかプレイステーションみたいな、専用のチップに対して最適化されたプログラムを書くというよりは、
もうちょっと一般的な開発をするっていうところになってきたというのもあって、
自分がやっている業務システムの開発と、そのゲーム業界の開発っていうのが、
2012、2013年当時の私からすると、神話性があるというか、何か良いものが見られるんじゃないか、
知れることがあるんじゃないか。で、自分が好きなゲームだしっていうのもあって、
その2つの両輪というかきっかけで、覗いた、覗いてみたっていう感じですね。
確かにそうですよね。自分が業界にいて、かつプロジェクト的な話っていうのが、
ご自身でもそこのつらみというか、持ってたでしょうから、
よりその話には反応するっていうのは必然だったのかもしれないですね。
そうですね。あと1つこれも付け加えると、当時、その当時の私自身としては、
そのマネジメントっていうことを意識していたわけではなかったと思います。
なぜこんなにデスマが続くのか、つらいのかっていうの認識はあったんですけど、
じゃあどうしたらいいのかっていう答えがなくて、
何かもう諦めの境地みたいな、システム開発ってこういうもんだよなぐらいの勢いでいたところだったので、
あ、これならうまくいくかもみたいなビット来たと言いますか、ひらめきがあったというよりは、
ああ、こういうのもあるんだなぐらいのFFってこういうのもあるんだなぐらいの感じで覗き込んだので、
何かそこでマネジメントだってなったっていうよりは、それを見た後の話に
マネジメントっていうものに気づいたり興味を持ったりって感じですね。
そうですね、このスクエア・エニックスさんの何ていうタイトルでしたっけ。
ゲーム開発プロジェクトマネジメント講座っていうタイトルですね。
このスライドあれですよね、今でも見れますからね。
セカンドライフのオープンソース的な運営と学び
見れますよ見れます。
僕も先ほど少しちらっと、これまで知らなかったものでちらっと見たんですけれども、
今読んでも全然役に立つというか、
むしろこのレベルをまだちゃんとみんなできてないんじゃないかっていう感じすらする、
すごくいいスライドですよね、これ。
いわゆるアジャイルってもう20年以上、22、23年ですかね、経ってて、
なおアジャイルって言われてるじゃないですか。
なんか我々は当時のケント・ベックだったりとか、
そのアジャイルを提唱した人たちに追いつけてさえいないみたいな状況がある中で、
その10年後ぐらいにこういった資料が出てきて、やっぱり今でも通用するというか、
今だからこそ見てほしい話が出てくるっていうのは、
本当になかなか現場って変わらないじゃないですか。
そうですね。
同じような悩みはどこにもあるんだなっていうのは私も思います。
まあなんかいろんなことが書かれていて、
なんかそのウォーターフォールとアジャイルとどっちでもないというか、
掛け合わせてやるんだよみたいな話とか、
いやもう現場の人からする、現場でそこそこの難易度の物事を推進して苦労してきた人からすると、
まあそうだよねって思うんですよね。
なんか全部ピュアにアジャイルみたいなのでもやっぱりできないし、
全部ウォーターフォールではちょっとやっぱり不便なところもあるので、
っていうのでそのアジャイルみたいな不確実なものにどう対処していくのかっていう要素をうまく取り入れてやっていきましょうみたいな話が書いてあって、
もうなんか普通に現実味があるし、
正しく何ですかね、いろいろな苦労、ご経験をもとにそのウォーターフォールやアジャイルっていう手法をちゃんと現場で使えるものとして落とし込まれて、
それを何か説明されてるなっていうふうに感じたんですよね。
はい。
本当に素晴らしいですね、これ。
この資料を書かれた方が、当時スクエアエニックスに在籍されていた橋本さんって方なんですけど、
この橋本さんって方がファイナルファンタジー14を作り直すってなった時の、
オンラインゲームの開発経験とミーティング
いわゆるプロジェクトマネジメントと言いますか、プロジェクトマネージャーの最高責任者的な立場。
CTOって書かれてますからね。
そうですね、当時CTOだったのかなと思うんですけど、
要はこれから作り直すっていうプロジェクトをうまく活かせるためにそのプロジェクトに参加していたっていう方で、
実際やってみてどうだったかっていう資料がこれなので、
本当におっしゃる通り実体験に即したと言いますか、
そういったものから来ている説得力のあるものっていうのはおっしゃる通り、私もそう思いますね。
もうこの時点でその域に到達してらっしゃるっていうか、
現場でやってる人からしたら当たり前なのかもしれないんですけども、
でもすごいことをちゃんとされてるなっていう感じはしましたね。
この資料を今回教えてくださってありがとうございますっていう感じで。
ちなみになんですが、このゲームみたいなところをさっきも少し触れたんですけれども、
ちょっと余談になってしまうんですが、なんか僕の方も若干話したいことがあって、
ちょっと織り交ぜさせていただくんですけれども。
僕はFFは、ハイノファンタジーはあんまりオンラインではやってなくて、
それとは別にもうちょっと年で言うと、これいつぐらいだったかな。
でも2011年とかそれぐらいだった記憶があるんですけど、
これまたMMO的なやつで、セカンドライフっていうやつが流行ったんですよね。
なんていうんだろう、オープンワールド的なMMOで、
その中で特に目的はなくって、何か物を作ったり、いろんなことができるっていうタイプのやつですと。
マーケティング的なところの絡みで、いろいろ怪しいとか言われたりもしたやつではあるんですが、
僕は純粋に楽しんだんですよ、このゲームを。
そこで一つ、二つかな、僕がこのゲームから学んだというか、
すごく面白かったなって思うのが、オープンソース的な運営の仕方をしてたんですよ。
これって他のゲームではどうなのかなっていうのを後ほどフォルテさんに聞きたいんですけど、
セカンドライフっていう、ある種その中でいろんな人たちがあれこれの活動をしてるものを、
リンデンラボっていう会社が運営してるっていうタイプ。
その構図は他のオンラインゲームとかも一緒だと思うんですよね。
そのリンデンラボの人たちが、まずビューワーっていうサーバーとクライアントサイドの2つソフトウェアがあって、
そのクライアントサイドのソフトウェアをビューワーって呼んでいて、ビューワーはオープンソースだったんですよ。
なんとって面白くて、誰でもソース読めると。僕らエンジニアだから読むじゃないですか。
こここういう処理してるんだ、みたいなのを読めたり。
そのビューワーのバグ管理とか機能開発の管理をジラーでやっていて、そのジラーもオープンなんですよ。
僕らがバグ見つけると、そのジラーにバグレポートできるみたいな感じなんです。
バグが溜まっていくじゃないですか。
それに対して、これは1週間に1回か2週間に1回かな。
開発メンバーのCTO的な人とあと何人かとかがオープンにミーティングをするんですね。
トリアージするミーティングっていうのをやってて、それをセカンドライフの中でやるんですよ。
MMOの中でその人たちのオフィスっていうかスペースが…
みんな家持ってるんですよね、その家とかで。
アウトプットの始まり
その人たちのバグトリアージアワーとか行って、何月何日何曜日何時かでやりますって言って。
そこに僕のアバターとかみんなのアバターとかで参加していって、
これはこういう風でこういうバグだから何とか直してほしいみたいなのを訴えると優先注意を上げてくれたりだとか。
そういうことをやってましたね。
オープンソースとして作られていたし、オープンソース的な運営っていうんですかね。
その当時他にもオープンソースで作られているソフトウェアって当然あったんですけれども、
僕自身がっつり貢献したことがなかったし、
ネットワーク上のそういうスペースであたかも現実に一緒に会話しているような感じで
オープンソースに取り組むみたいな経験にもなったんで、
それはめちゃくちゃ面白かったな、学べたなみたいな感じだったんですよね。
っていうのがエンジニア視点ではすごく面白かったところで、
そういうのって他のMMOとかではどうだったのかなみたいなのをチラッと聞いてみたかったりしますけど。
基本的には先ほどのセカンドライフの言葉で言うと、
ビュワー的なものをオープンソースでっていうのは基本的にはないと思います。
ないですね。
特に最近はそうなんですけど、
セキュリティの面がどうしてもいろいろある、
データの改ざんとかを含めたセキュリティもそうですし、
キャラクターの改造みたいなところで見た目はあまりよろしくないと言いますか、
感じにしてしまうみたいな危険性を運営側がどうしても管理できない、
コントロールできないって話になっちゃうので、
基本的にそこまで自由度が高いものはないというか聞かないですね。
ただ取って変わったってわけではないんですけど、
プレイヤー側が自由に改造するだったり追加するみたいな文化として、
今でも残っているのはいわゆるモッドって呼ばれる。
モッドありますね。普通になってますよね。
なってますよね。あれがよくある話なのかな。
と思ってまして、特に海外製のゲームはモッド推奨というか、
公式がモッドに対応しているみたいなところがありますので、
有名どころだとマインクラフト、
マインクラフトは厳密にはネットゲームというかオンラインゲームというよりは、
オンラインでもできるゲームではあるんですけど、
マインクラフトのモッドって星の数ほど出ていると思いますし、
先ほどセカンドライフの美話でいうところで言うと、
マインクラフトってJavaで作られているゲームなので、
Javaのコードが読めればコードが読めるんですよね。
当時のマインクラフトが出たときの驚きとして、
Javaでこんな3Dのゲームができるんだっていうところが非常に驚きで、
制作者の名前をどうせ言っちゃったんですけど、
優秀なJavaエンジニアの方で、
ゴフっていうんですかね、デザインパターンをめちゃくちゃ使ってたりとか、
結構勉強になるコードだったようで、
そういう部分でモッドだったりとか、
ゲーム自体のコードを読むみたいなところの文化っていうのは今でもあるし、
続いているっていうのはあると思います。
なるほど、なるほど。
ちょっとこの辺の話が尽きなくなりそうなんですけど、
趣味というか遊びというか、そういうところのものきっかけで、
意図せず仕事の役に立つというか、
役に立つことを意図してやってるわけじゃないんだけれども、
なんか面白いし、結果的に役に立ったかなみたいなことってあったりするんですよね。
ありますね、なんか本当に何もしないで家で閉じこもっているだけだと、
そういったきっかけがどんどん少なっていくと思うんですけど、
何かに期待してというよりはとにかく動いていると、
本当に偶然、さっきのFF14のカンファレンスの話も本当に偶然知った話で、
かつそれが効果があると思って見たわけでもないので、
本当にそこのきっかけは偶然だと思いますし、
人によって様々といいますか再現性がないと思うので、
現場現場によって悩みもやっぱ違いますから、
なんかそこはそのIT業界、コンピューター、プログラムみたいなところに関わらず、
興味があるものはとにかく見て触ってもらって、
そこから何か得られるものがあれば、知的好奇心ではないんですけど、
何でだろうみたいなところを大事にして深掘りとか広げていくとかっていう方向に
いってほしいなとは思いますね。
なるほどなるほど。ありがとうございます。
なんかもうポルテさんのことを色々聞きながら話が色々展開しているんですけれども、
それで最近の活動として、例えば芸術書店に本を出されたりだとか、
あとそのポッドキャストもやられたりみたいなことで、
なんていうのかな、ある種結構アウトプットというか、
色々な活動をされてらっしゃるなというふうにも思ったりするんですけれども、
なんかこの辺りも何でしょう、ポルテさんの原点というか、
何きっかけでそれを始められたんですかみたいなところを、
僕なんか個人的にそのきっかけというか、オリジンみたいな話を聞くのが好きなので、
その意味でも聞いてみたいっていうのがあるんですが、
なんかここで教えていただけますか。
はい、明確にそのアウトプットを始めたきっかけみたいなのは、
先ほど名前出していただいた技術書店のちょっと絡みで思い出す機会がありまして、
2018年の夏ぐらいですね。
はい。
多分それよりちょっと前に出たんだと思うんですけど、
改善ジャーニーっていう。
はい、市谷さんの。
そうですそうです、市谷さんの。
多分最初の本だと思うんですけど、
アジャイルスクラム、どっちかというとスクラムですかね。
初めてやる人向けの結構手引き書じゃないんですけど、
実体験になぞられたドラマっぽい感じの技術書みたいなのがありまして、
その本の中ですごく刺さった一言、言葉が、
それであなたは何をする人なんですか?っていう質問があったんですね。
ほう。
それはその改善ジャーニー内の主人公だったりとか、
キャラクターに向けて言われた言葉ではあるんですけど、
自分に対してそれを投げかけられた時に、
あなたは何をする人なんですか?って言われた時に、
答えられないなって思ったのがきっかけで、
なるほど。
じゃあ何かそれを答えられるようにするにはどうしたらいいのかっていうので、
すごく抽象的にはあるんですけど、
自己特定とアウトプット
例えばスキル、技術力を高める必要があるとか、
もっと経験を積まなきゃいけないみたいなことを考えた時に、
周りでインターネット上でやられてることって、
例えばブログを書くですとか、
LT、ライトニングトークとかで登壇をするとか、
カンファレンスなどに参加して知見を得るみたいな、
要はそういったよく言われるIT業界、
ITエンジニアのインプットアウトプットっていうのが、
自分はやってきていなかった、
本を読むぐらいだったので、
そこの質問がきっかけでアウトプット、
当時はブログとポッドキャストと登壇と、
あと技術同人誌の合同誌の機構からだったんですけど、
始めたのもそれぐらいで、
何か答えを求めて一気にワーッと始めた感じではありましたね。
なるほど。
考え方の変化と挑戦の加速
本がきっかけっていうところもなかなか面白いといいますが、
本の中の確かに何らかのワードが、
たまにめちゃくちゃグサッと刺さるときってあるんですよね。
ありますね。
なるほど。
何をする人なんですかっていうのは確かに、
究極の問いの一つのような感じがしますね。
そこからあれなんですか?
どれか一つとかではなくて、
同人誌みたいな書く方もだし、
ポッドキャストもっていうふうに、
複数同時にやられたんですか?
そうですね。全く同時にではなくて、
数ヶ月範囲で間は行ってるんですけど、
とりあえずブログ始めてみて、
登壇始めてみて、
執筆してポッドキャストもって感じで、
順番にやっていったって感じですね。
なるほど、なるほど。
そこは結構勢いがすごいなと言いますか、
なかなか何でしょうね、
万人が一気にできるわけではないなっていうのは、
聞いてらっしゃる方も思うのかなと思うんですけど、
何かコツなり何かあったんですか?
それだけ一気にやっていったっていうのは。
そうですね。
私、技術同人誌でそういう始める技術みたいな本を
書いたことがあるんですけど、
要はハードルが高いって、
まさかりを投げられるじゃないですけど、
なんか批判されるんじゃないか、
言われるんじゃないかとか、
あとは単純に自己評価が低いじゃないですけど、
自分程度が、例えばブログに記事書いたり、
ポッドキャストで喋っても何の価値もないんじゃないかみたいな
部分があるのかなって思っていまして、
ただ先ほどきっかけとしてあげた、
何をする人なんですかっていう回答が
やっぱり答えられないんですよね。
何かしらして自分の中に
確固たるものを得ないと答えられないので、
自分の中に確固たるものを得ないと
答えられないので、
じゃあどうしようってなった時に、
きっかけというよりはそれを加速させる言葉で一つ、
また別の本でいい話がありまして、
本の話ばっかりしたら申し訳ないですけど、
嫌われる勇気っていう、
IT系ではなくて心理学の本なんですけど、
アドラー心理学っていう心理学の体系がありまして、
そこで書いてあったのが
アドラー心理学っていう
体系がありまして、
なぜ変われないのか、
それはあなたが変わらないことを望んでいるからっていう
一言がありまして、
望んじゃってるんですよ。
まさかりが怖いとか自分の知識なんて意味がないっていうのは、
結局理由づけでしかなくて、
だからやらないっていう、
やらない理由を探してるだけなんですよね。
やらないことを自分が選択し、
その結果、例えば傷つくことを恐れているだったりとか、
ある種変わることを恐れて落効しようとしているみたいな、
これはそうだと決めつけているわけではなくて、
そういう考え方もできるっていう話なんですけど、
っていう観点がありまして、
それを考えたときに、
ポッドキャストもブログも執筆も登壇も、
別にやって失敗したところで、
命まで取られるわけでもないですし、
また再挑戦できるものではあると、
切り替えるじゃないですけど、
考え方を、見方を変えられたっていうのが一つあったなと思っていて、
何をする人なんですかって質問に答えるためには、
やはり自分を変えるしかないなっていうところに
たどり着いたっていうのがあって、
いったようなところにどんどん挑戦が加速していったというか、
っていうのはあったと思いますね。
なるほどな。いい話ですね、これね。
ありがとうございます。
僕自身も、やっぱり当初ありましたよ。
ブログを書くにしても、
こういうポッドキャストで喋るにしても、
何か登壇するにしても、
まさかりみたいなものだったり、
自分の話す内容がこれで正しいんだろうかみたいなやつとか、
いろいろそういうふうに思ってやめようかなだったりだとか、
いうことはあるんですけれども、
どっかの時点で、
ある種の境地に達したというか、
これは僕自身の個人的な趣向なのかもしれないんですけれども、
誰かが発明したというか、
提唱した理論だったり、
エンジニアリングマネージメントのスキル
手法だったり、
っていうのを説明するっていうスタイルで、
自分はいたなって気づいたんですよ。
それはあんまり価値がないかもしれないって、
僕はどっかで気づいたんですよ。
そうじゃなくて、
そういう手法とかそういうものが役に立たないとかいうことではなくて、
それはそれでありがたい時もあるんですけれども、
それをどう個々の人がいる現場というか、
取り組んでる問題、状況みたいなところで、
どういうふうに考えてどういうふうにしたのかっていう、
個々のエピソードの方が価値があるなって、
僕自身は感じるようになったんですよね。
それってもう人間の数だけあるというか、
全く同一の状況ってほぼないと思うんですよ。
っていった時に、
同じ手法を使う話であっても、
やっぱり状況が違えば聞き方が違ったりだとか、
いくらでもバリエーションが出てきて、
その個々の状況の違いだとか、
そういうことこそに価値があるというか、
より道具を理解するために大事だっていう側面もあるし、
みたいなふうに考え方が変わってきたんですよね。
ってなった時に、
同じオブジェクト思考の話でも、
違う人が違う場面での使い方というか、
それぞれのエピソードで話すことって、
それはそれで意味があるし、
いろんな理解度というのかな、
あんまりそういう尺度は好きじゃないですけれども、
方々がそういうものに対して、
どういう状況で、どんな感じで使って、
どういうことだったのかっていう、
やっぱり個々のエピソードっていうのが、
僕自身は聞くのがすごく、
どんどんスキンになっていったっていうのもあるんですよね。
僕はそういう感じで、
ハードルを乗り越えたというか、
ある種、境地に達した的な感じはありますね。
フォルテさんとは違う感じなのかもしれませんけど。
私も他の現場の話を聞くっていうのは本当に大好きで、
そのためにカンファレンスに行ってるぐらいの、
ところはあるなと思ってるところはありますね。
登壇された発表内容を聞くのももちろんそうなんですけど、
その後に登壇者の方と会話したりとか、
あとはランチの時間とかに、
他の参加者の方と発表内容とか、
自分の現場とか、その人の現場について話すみたいなことは、
よくやるし好きなので、
それはすごくよく分かります。
それが醍醐味ですよね。
そうなんですよね。
分かりますね。
それで今どうなのっていうところからお話したいなと思ってまして、
事前に伺ってるところでは、
このポッドキャストも一応
エンジニアリングマネージャーっていうのがタイトルに入ってますし、
フォルテさんとしてもプロジェクトのマネージメントだったり、
いろんなところには携わられてきたんですが、
これはエンジニアリングマネージメント的なところに
少し関わられるようになってきたっていうことなんでしたっけ?
そうですね。一応EMTF役職を明確に与えられているわけではないんですけど、
そんなようなことをやってるって感じです。
そこでの学び方だったりだとか、
エンジニアリングマネージャーというものに関して、
多少ちょっと意見交換というか、
みたいなところもしておこうかなというふうに、
僕の方からもぜひと思ってまして、
そこの話をしたいなと思うんですけれども、
実際どうなんでしょう?
フォルテさんとして今イメージされてる
エンジニアリングマネージャーに必要な知識だったり、
逆にこの辺はまだやったことないから
勉強しなきゃいけないみたいなものが
今の時点で思い浮かんでるとかってあったりするんですか?
そうですね。私は何か銀の弾丸とか、
モデルケースというか理想とするEM像みたいなものが
あるかと言われるとないですっていうのが正直なところです。
でもおそらくある方の方が珍しいと思うんですけど。
なのでいろいろ手をかえしなおかえ
勉強したり試したりしているっていう
その中ではあるっていう前提にはなるんですけども。
最近やってて思うのはやっぱりその
なんていうんですかね。
目の前の問題をどう解決するかっていう問題解決力だったりですとか。
あとはそれに対してそのコミュニケーションだったり
自分がそういった問題やチームメンバーやお客様といった
他の方々とどう見き合っていくかっていう
マインドセットみたいな部分だったりとか
なんかそういった部分が結構本を読んだり
経験したりした結果重要なんじゃないかなって
思うようになってきたっていうのが今現在って感じですね。
なんかすごく面白いって言いますか。
僕自身もなんかいろいろ何週かした結果
マネージャーに必要なのって問題解決力ですよねっていうのを
このポッドキャストの前で話してたりもするので
なんか不思議な一致というか
問題解決力の重要性とエピソード
不思議でもないのかもしれませんけれども
すごく面白いですね。
ポルテさんの方で何でしょう
問題解決力、課題解決力みたいなところに
たどり着いたのって
今日このキーワードばっか出すんですけど
何かきっかけがあったんですか。
そうですね。なんて言うんですかね。
なんかこれは問題解決力だなって思ったというよりも
なんかしばらく経って振り返ってみると
あれこれ問題解決力じゃねって思ったっていう感じなんですけど
日々現場なり会社なりチームなりで
システム開発をやっていると
全く同じ日ってないんですよね。
チケットが降ってきてそれをこなしてっていうのは
同じなんですけど
微妙にやっぱり違う内容だったりとか
例えば納期が違うとか担当が違うとか
関わっているシステムが違うので依存関係が違うとかっていう
微妙な不確実性みたいなものがあって
それに対して
分からない部分を明確にしていくっていうのが
結局何が分からないのかっていう問題を定義して
それを明確にする解決していくっていうことなのかなって思った時に
これは問題解決力だなって思ったことがありまして
それはさっき言ったコミュニケーションとか
そういった部分も同じで
この言い方は良くないんだなとか上手く伝わらないんだなみたいなところが
自覚できると要は問題として自覚できて
じゃあこう変えてみようかとかやってみようかとかっていう
解決方法に動いていくので
そういった部分がきっかけなのかなと今振り返って思いますね
なるほどな
でもそうですね
言ってあれなのかな
問題解決っていう抽象的なレイヤーの活動自体は
どこかでは引き出しというか概念というか
としては何か知る必要はあるのかなっていう気もするんですけどね
そうですね
何て言うんですかね
問題解決なので何か公式じゃないですけど
何かありそうな感じを申し上げるんですけど
実際には本当に現場の数ほど問題はあるし
何なら人の数ほどあると思うので
何か定義公式として決まったものはないかもしれないですが
問題解決力自体はやっぱ必要なのかなとは思いますね
エンジニアリングマネージャーの役割と課題
そうなんですよね
だからエンジニアとしてシステムを作る
それってある種のお客さんの問題を解決する行為だったりしていて
何か問題解決的なことをずっとやってきているんだけれども
でもその活動の中に発生する別の次元の問題というか
一緒なのかもしれないんだけれども
それ自体をどうやって捉えて良くしていくのかみたいなところって
システムを作るのとは別の視点で見なきゃいけないし
その活動自体も別のスキルなのか何かっていうのがないと
上手く進められないみたいな感じだったりしますもんね この辺って
そうなんですよね
我々やっぱITエンジニア ソフトウェアエンジニアとしてやっていると
どうしても目の前のシステムに気を取られがちなんですけど
後藤さんがおっしゃる通り
その根本ってお客様のビジネス課題であったりとか
ビジネス上の問題の解決が原点だったりするので
ドメイン知識って言い方をしようとあれなのかもしれないですけど
それに対する知識だったり理解だったり解決策の提示っていうのも
一定数必要なのかなっていうのはやっぱりありまして
具体的に例を挙げると
我々ってついコードをプログラムを書きがちになっちゃうんですけど
本当に1回しか使わないような機能だったら
開発するよりも言い方悪いですけど
運用デカバーと言いますか
動いてバグを生み出すかもしれない
メンテしなきゃいけない行動を生み出してしまうよりも
たった1回の運用で回避して
なんか補修用意でちょっとお金をもらうみたいな
ちょっとビジネスチックな話であれなんですけど
みたいな方法解決論もあるわけで
それって問題を解決してること自体には
お客様の課題を解決しているってことには変わりはないので
どっちが良い悪いではないんですけど
その場に応じて適切な提案ができる
する必要があるっていうのはあるなと思います
今の話もなんか深いですよねと僕は思うんですよ
なんかそういうところも含めて
エンジニアのスキルというか
エンジニアの仕事だと思うんですよね僕は
コードを書かないことも
どうやってお客さんの問題をちょうどいい塩梅で
解決してあげるのかっていう時に
コードを書かない選択も持てないと
僕としてはダメだぐらいには思うんですよね
わかります 私も言葉はさっき選びましたけど
同じ気持ちですねあれ
そうですよね ここはここで深いな結構
ありがとうございます
だからマネージメント的なことを
エンジニアリングマネージャーとしてやるにしても
やっぱり何か課題解決みたいなところに行き着く
って僕は思ってて
フォルテさんもそこにはもう
何だろうな考えが至っているので
そこから先は問題として上がってきたところ
じゃあどういう風に潰していくのかっていう
個々の格論的な話になるので
当然格論には収まらないような
人との問題みたいなところは結構難しかったかもしれませんけれども
まあでも何かいいところはもう
最初に抑えられてるんだなっていう風には思いましたね
そうですね何か
さっき銀の弾丸はないって言いましたけど
結局その根本というか原理不通か
根っこは同じなのかもしれないですね
そうですね
そういう意味では課題解決力というスキルに関しては
銀の弾丸とは言いたくないですけれども
かなり汎用性は高いですよね
はいありがとうございます
もう結構長い時間一気に話しちゃったんですけれども
無限にいろんな話ができそうなんですが
ちょっと今回はこれぐらいで
一旦区切りたいなというところでして
最後にそうですね
今日はこんな感じで話させていただいて
ちょっとお互いの感想的なものを
一言二言程度話して終わりにできればと思うんですけれども
ポルテさんの方からいかがですか
そうですね
やはりそのきっかけ原点
あと後藤さんの言葉でいえばオリリンみたいなところって
本当に重要なんだなっていうところは
改めて再認識したと同時に
このエンジニアリングマネージャーに限った話ではないと思うんですけど
ITエンジニア引いてはサラリーマンといいますか
社会人の方々も
そういったオリジンや原点を大事にしてほしいというか
初心に帰るじゃないですけど
そういった意味でその部分を
改めて見つめ直していただいて
でまた目の前の現実といいますか
課題に向けてどう定義して解決していくのかっていうのを
やっていただけると
今回この会話をした回といいますか
会話で学べ取れることってその辺り
もっといろいろあったと思うんですけど
なのかなとは思いますので
ぜひぜひ参考にしていただきたいし
私も同じようにまた現場でやっていきたいなという
勇気をいただけたと思っております
ありがとうございます
ありがとうございます
私の方からは個別の話でいうと
やっぱりFFだとか
僕の本のセカンドライフの話をしたんですけども
やっぱりああいうゲーム自体を
なんていうのかな
ある種真面目に捉える側面というか
そういう視点で物を見て
会話ができるということ自体
面白かったりするなと思うので
そういう話をまた別途させていただきたいな
みたいに思ったりしました
ということで今日はポルテさんと
いろんなお話をさせていただいたんですけれども
ポルテさんの方から
簡単な告知といいますか
ご尋問にやられていることなど
ちょっとご紹介いただけるといいなと思っておりまして
ポルテさんお願いできますか
ポルテさんの告知とエンジニアリングポッドキャスト
ありがとうございます
私もポッドキャストをやっていまして
エンジニアリングマネージャー専門というか
限定のというわけではないんですけども
雑多にいろいろやっているっていうのと
あとゲストに
基本ゲストを呼んでやっているんですけども
ゲストに呼んだ方がITエンジニアの方が多くて
結構テック系の話
中にはマネジメントの話もしていますので
興味があれば
私の青空FMというポッドキャストの方も
ちょっと聞いていただけると
ありがたいです
あとでURLと共有させていただきますので
そちらからぜひぜひ興味があるエピソードを
聞いてみてください お願いします
お便りフォームとレビューの案内
さて この番組では
感想や質問 お悩み相談をお待ちしております
エンジニアリングの現場で遭遇するあらゆるトピックについて
番組詳細欄にあるお便りフォームより
お気軽にご投稿ください
Twitterではハッシュタグ
EM問題集をつけてツイートしてください
EMはアルファベット
問題集は漢字でお願いします
そしてAppleポッドキャストやSpotifyのポッドキャストでは
レビューもできますので
こちらにも感想を書いてもらえると嬉しいです
お相手は株式会社株式スタイル
COO兼CTOの後藤英二でした
