大石 良 氏
「未来予測はあんまり意味がない」 予想は大概外れる
予想するより、むしろ変化にすぐ対応できるようにすること
大塚 弘記 氏
アジャイルが当たり前になって、その次
須藤 功平 氏
リーダブルコード
安達 輝雄 氏
何を解決したかったのかを明確する
変化が激しい時代において、自分たちのスキルセットも変化しないといけない
これからの時代、アプリケーションの開発を下請けに丸投げせずに、自分で開発してってる
クラウドサービスについて
クラウドサービスを知ったのはいつごろ？
おおいし 2007年にamazonのやつが出てきてから、社内サーバー購入禁止令(中身を見てこれ自分で作れんじゃね？って思ったけど、無理だった)
あだち AWS IaaS系
hirocaster AWSはクラウドなのか？ disaster recovery
すとう あんまり覚えていない
クラウドサービスを知った前後で何かの意識の変化があったか？
おおいし コピーしようと思ったけど出来が良すぎて車輪の再発明や劣化コピーではなく、使う側に回る
あだち 今まではサーバーを使い倒してきたが、これからはサーバーは使い捨てになっていった
hirocaster お金かけていたのをやめた
すとう なし
業務システムのOSS活用に抵抗なくなったのはいつ頃？
ターニングポイント
おおいし 2007年(2005にMySQLを使おうとして拒否られたが、リーマン以降、やたら高いものを使えなくなった)
あだち 2007年入社時点で、tomcatとかmysqlとか当たり前の時代になっていたので、最初から抵抗なし
hirocaster
すとう
2013年以降の展望に関連してSIの今後
おおいし
コミュニケーション < 技術が鮮明になっておりSIerの人材バッファとしての役割は終わった。
ボタン一発で大幅なスケーリング可能になってきているので、人手も必要なく、分業モデルが崩壊してきてる
客が「喉乾いた」つったら、ボタン1つですぐに水をデリバリーできる。
故に巨大なピラミッド構造とそれに伴うコミュニケーションが必要なくなる
アメリカのエンジニアの募集要項には、「AWSが触れること」と書いてある
おおいし SIerの変化→ピラミッドの下の下は本当に要らなくなる
あだち 周りを見てるとそんな感じでその通り
hirocaster なるほどー
すとう この前脱出した
SIのビジネスモデル変化で今後意識したほうがよいことは？
おおいし インフラチーム(リリース)とアプリチーム(開発)の分担は必須だった
あだち デプロイもすぐに出来るので、開発からリリースまでほとんど一人で出来るようになった
hirocaster
すとう 昔から自分で開発して自分でデプロイして…「こうしないと死ぬ」昔のビジネスモデルはあんまり意識ない
ストレッサーについて
ストレッサー ストレス反応を引き起こす原因
ストレス反応 ストレッサーによって引き起こされた結果
外部環境変化がストレッサーにならなかった？
おおいし 耐えられないほど変化がストレスになる人はいるっちゃいるだろう でもストレス耐性の高い人は概ねパフォーマンスが高い
あだち 自分としては保守派だけど、危機感のほうが強かったので、それほどストレスは感じてない
hirocaster ストレスそのものが変化の原因(SIerがストレスになって、インフラがストレスになって、そもそもソフトウェア開発がストレス…)
すとう 技術的なものはストレッサーにはならなかったが、経営がストレス やっぱり、好き嫌いがストッサーになるかどうかを左右してれぅ
おおいし プレゼンは緊張するけど、そもそも誰も聞いていないし覚えていないことが分かると緊張しなくなる
昔から機械を弄っているため、年を取った人間のほうがストレス耐性は高くなる→クラウド？タイムシェアのことでしょ？みたいな
ご自身なりのキャリア戦略を持っているか
おやまだ コードの書けるコンサルタント Qiita GitHub (エンジニアと話するときに、開発できるほうが話が早くなる)
おおいし あんまりキャリア戦略を信用していないが、マルチタレントは必要。聞こえはいいけど、「今現在何が出来るか」のほうが圧倒的に重要。
医者がキャリア戦略云々言ってても、「いいから患者を治せよ」って気分であるのと一緒。
あだち 「皆と被らない」 あまりブログは書かない 差別化すると、被っている人が少なくなると、途端に注目されはじめる
hirocaster 特に意識していないが、「自分が何が出来るか」を意識している (ブログはあんまり仕事と関係ない)
すとう あんまり重視していない
採用者始点からエンジニアのキャリア戦略を考察
おおいし
あだち 変化に対応できなきゃああ
hirocaster
すとう むしろペアプロしたりして「一緒に開発出来るかどうか」のほうが重要。突っ走るのはいいけど、チームプレイが出来るようにならないと…というか採用側がそれを判断しないと…
リーダブルなコードのビジネス上の利点
リーダブルじゃないコードを見るのがしんどい
ビジネス的にどんな利点があるの？
おおいし ベーマガのコードを打つことによって、覚える。メモリ最適化>>>>>リーダブルの時代だったので…きれいなコードを写経させたほうがいいんじゃないか？
あだち 非開発者に汚いコードを見せつづければいいんじゃないの？
hirocaster コードを書く時間より読む時間のほうが長くなるから。そして、リーダブルコードを書ける人は重要である
すとう
コード書けないエンジニアの立場をどう思うか
おおいし ある程度プログラミング能力を持っている人間が求められている
あだち 料理の作れない料理人と同じで、コーディング出来ないエンジニアは不要になってくだろう。
hirocaster データセンターなど、ネットワーク系インフラエンジニアは、コード一行も書けなくても生きていけるけど、まあそういうエンジニアってあんまりいないよね
すとう
コード書けないという気持ちを持ったエンジニアになにかヒントを
いいからコードを書けよ。写経でもしてさ。
おやまだ 英語はボキャブラリーが多ければよい…そんなふうに考えていた時期が俺にもありました
おおいし 今まではドキュメントを書いてコードを書かない人は必要だったけど、今後はそういう仕事減っていくよね でも日本語がロジカルな人は例外なくコードもロジカル
あだち
hirocaster TDDはコードを書く人間にしてみたら避けては通れない道。自分の常識を変えなければならない。徹底して自分のルールを確立出来るかが重要。プライベートで実践できなければ職場で実行できるわけねえだろ 一人でどうこうすんのはしんどいから、仲間を作ることが重要
すとう
強制的にテストを書く仕組みって重要じゃなイカ？
フレームワークのパターンを見つけて、写経していく
アジャイルに必要なこと
- 計画
- 定期的なレトロスペクティブ(振り返り) 反省会かねて飲み会やっちゃうのは完璧なアンチパターンです
アプリケーションのコードを書ける人がインフラを学ぶにはどうしたらよいの？
→サーバー内部でも何かしらのスクリプトで動いており、それを好きな言語に統一するといいだろう。
→会社を巻き込むのがいい。日本の会社で何かの技術を導入するときは、上の承認が必要なので、「この技術は絶対いるんだああ」っていうのを経営陣に納得させる
