読者です 読者をやめる 読者になる 読者になる

何でも屋エンジニアのブログ

当分はRails中級者向け勉強会Step-to-Rails-Expert.rb関連になると思います

レポート:AWS Summit Tokyo 2015 デベロッパーが切り拓く、次の時代

AWS Summit Tokyo 2015に参加し、DevConの14:20~15:00の枠である
【パネルディスカッション】デベロッパーが切り拓く、次の時代
のメモを取ったので取り急ぎまとめます。

www.awssummit.tokyo

以下、伊藤様の発言は「伊:」大場様の発言は「大:」で表記します。特に表記がない場合(テーマ1など)はまとめている場合です。
また、発言者についてはまとめてしまっている部分もあり、100%ご本人の発言でない場合があります。

テーマ1 変わったこと、変わらないこと

技術的には、かつて技術はBtoBからBtoCへ流れていた。大手のベンダーから技術提案があり、それにキャッチアップすることが重要だった。ベンダーからロードマップが提示され、それにどう対応するかを考える部署すらあった。今は誰もロードマップを提示してくれない。 ロードマップが提示されないのは技術だけでなく、ビジネスも同様である。

テーマ2 技術を取捨選択した際の大原則・考え方はあるか?(個人として)

伊:オープンな方を選択してきたが、それが正解かは分からない。これはBtoCの業界にいたことに由来しているだけ。そもそも、技術を選択してキャリアを作り上げていくという考え方が良くないのでは。

大:技術を選択してこれでいこう!というのは怖い。今までの傾向としては、目的のものが7割8割しかできない、メインストリームからはおもちゃのような技術を選択してきた。おもちゃで遊ぶ感覚。

テーマ2-1 技術を選択するうえで、興味が先か、課題が先か

伊:課題が先。自分の場合、興味は課題から発生する。技術者が今使えるものを使用すると失敗する。この技術はここまでしかできないからという先入観が邪魔する。

大:課題の中で技術を楽しむ。やはり(ある程度は)背伸びはした方が良い。

テーマ3 これからの外部環境の変化をどう迎え撃つか

伊:マネジメント面、先に話に出たが、技術だけでなくリソース・スケジュール全ての面で曖昧になっている。Saasとかになってくると、様々な要素が不透明な状態で進めなければいけない。エンジニアはこの曖昧さに耐性がなければならない。曖昧な中で仕事の中で進まなければならない。

大:マネジメント面、環境は変化するということを受け入れられることが大事。決められた枠組みで粛々と進めたい人だと厳しい。
また、開発部として開発しかしないような枠組みにしてしまうと「開発だけしてれば良い」という考えを生むため失敗してしまった。事業部ごとに分割すると責任は曖昧になって個人にかかる負担が増えて大変だが、それは耐えなければいけない。また、フルスタック指向があるエンジニアでも、その時興味がある技術にロックインされるし、やりたいことがあっても不慣れな分野だと他に自分よりレベルの高いエンジニアがいたら遠慮したりする場合があるので、組織的にある程度ローテーションさせて新しい技術に触れさせる枠組みを作ることが大事。

以上です。

感想

特に印象に残ったのが「曖昧なまま進む強さ」が必要だとお二人ともに同意していた点です。これは私がSier系の下請けからWebサービス(BtoB)分野への転職した際に大変だと感じたことだからです。
当たり前ですが、サービスの場合はそもそも作るものやニーズが確定していません。もちろん、顧客対象となりうる方々からのヒアリング等を実施し可能な限り調査しますが、たとえその場合でも、サンプル数は不足しており無作為抽出ではないので、統計的なことは言えず、「このような分野・機能にニーズがあるという意見がある」としか言えません。そのような状態から、ユーザー目線で試行錯誤し何を作るか決めなければならないのです。
このように、サービスのケースでは不特定多数がお客様であり、ニーズや流れを捉えきれないとサービスを継続することは困難である一方、受託の場合はまず相手が決まっていて、話合いを重ねた上で何を作るか確定させることができます。仕様変更があったとしても(特定の)お客様の要望であるので、考えるべきリスクは仕様変更の影響で生じる工数追加などのコストが主です。これは、サービスの機能追加が必ずしもユーザーからの要望のみで行われるわけではなく、ニーズを生むために先手を打って機能追加を実施するのとは対照的です。当然、この場合はそもそも当該機能が必要とされる100%の根拠はなく、ユーザーの反応によっては徒労に終わるリスクがあります。 ビジネスモデルの差異はエンジニアの意識の違いにも反映されます。前職の場合は機能追加などの指示があっても「何を」作るのかは上から降ってくるので「どの位の期間で」「どのように」作ることだけを報告し考えれば良かったのですが、現職で同様の指示があった場合「それが本当に必要か」「具体的にどのような機能を作るのか」まで一エンジニアが考える必要があるのです。
これは私の経験に基づいた話で、お二人の話す「曖昧さ」が全て上記に合致しているのかを判断することはできませんが、大きくは外れていないのではと思います。 自分でも強く意識していた不確実性への対応が必要という点を、お二人のような方からの口からも聞けて良かったです。色々曖昧なまま進むことが良いのか、判断を先延ばしにしてももう少し不確実性を排除した方がいいのか、転職してからずっと悶々としていて、やはり決まらないことはあるので進みながら試行錯誤しその都度対応していくのが良いんだろうなぁと思いました。

追記 : 誤記を修正しました。感想を追加しました。