LoginSignup
5
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

@warumonogakari(warumonogakari,tumibito Kato)

最近すすめていることと、それをネタに「レガシー感謝の日」にて初登壇してみた。

Last updated at Posted at 2018-12-01

はじめに。自分にとっての "Be agile"、スクラム、そしてずっとぼんやりと考えていたこと。

　筆者は だいぶ前に 認定スクラムマスターをとったものの、実は、チームとして一度もスクラムをやったことがない。
　その理由は、筆者がいる会社がコンカレントエンジニアリングをベースにした ちょっと変わった開発スタイルをとっていて 、まずそれとの親和性がわるい。
　また、"Be agile" といっても、筆者の住む 複合機の組み込み系ソフト業界では、各プロジェクトで、スクラムが想定している ビジネスの変化への機敏性（Agility）までは そうそう要求されていない。作りたい方向性は定まっているので、スクラムが前提としている超優秀な Product Owner は必要ない。
　となると、後はエンジニアチームがどれだけビジネスロジックを理解し、品質を迅速に深化させるか（言い換えると、炎上を素早く鎮火させるか）にかかっているにすぎない。
　
　それになにより。
　スクラムを導入しようとすると、スクラムの耳慣れない単語に人々が違和感をもち、議論がえんえんと始まってしまい その時間がほんともったいない。

　強大な競争相手がある以上、少しでもよいから、貴重な時間を以下の対話にわりあてたい。

  1. 品質を迅速に深化させることはどういうことなのか？
  2. 深化させるためには 開発チームの構成をどうしておくとよいのか？
  3. 開発チームは何をどう成長するのか？
  4. 成長するにはどのようなInputを与えればよいのか？
  5. そもそもチームの成長って何？

　いずれも日々常々にふりかえり、実際に行動していきたいものである。生き抜くために。

そんなおりに。レガシー感謝の日。

　そんなおりに、レガシー感謝の日というイベントをしりあった。

　副題に「レガシーに花束を」とある。Twitterできいてみたところ有名なSF小説「アルジャーノンに花束を」が元ネタとのこと。

　場所は豊洲。前々に勤務していた会社の本社がある場所だ。
　ふと懐かしい想いと同時に、昔１年間だけやった COBOLクローンコード調査分析の苦い思い出が蘇ってきた。
　開発する会社・請負構造がかわらない以上、たとえ 一時 保守性を悪化しているコピペコードを一掃し、リファクタリングに成功しても、また元のもくあみにもどっていったとおもう。請負会社にとってみれば、コードをたくさん書いて一杯テストをすれば儲かるビジネスになっている。彼らにはコードに対する愛着はない。意識・無意識関係なく再びコピペコード爆発になっていっても不思議ではない。
　それに。
　なによりも、自分たちが築いてきたシステムに強い愛着をもっていた５０代開発メンバを COBOLべったりの世界から もう少し新しい開発スタイルへと再生・再転換できるように働きかけることはできなかったのか。
　全部が全部は無理にしても、もう少し 新しいこと・他所の世界を 知りたい・挑戦したいと 思っていた方も中にはいた。年齢が年齢だから。。という話だったが、だからといってそう簡単に割り切っていいものだったのだろうか。

　また、「アルジャーノンに花束を」といえば、知能強化・学習強化がテーマの一つだ。
　もし、学習強化モデルが図解できれば 上記 1～5 の問題は、もうすこし課題におとしこめるはずだ。うまくいけば、今自分たちのチームで これからやろうとしていることの狙いや 上記のような過去もやもやしてきたことをうまく語れるようになるかもしれない。

　ここまでぼんやりと考えていたら、ふと、昔培った機械学習モデルの絵がアイデアにうかんだ。これなら、同じフレームワークで 人間と機械の違いを語ることもできる。

　こうして人生初の登壇をやってみようと気になった。

参加決意と準備、伝えたいと思っていたこと。

　今回、以下のような「あるある」があるだろうと 想定して準備をすすめた。

  • リファクタしたいと願っても 経営層・マネージャー層になかなか許しがもらえない
  • 部下がやたらリファクタリングしたいと言ってきてるけど正直 違和感・躊躇している
  • 今いる開発チームの開発体験・習慣になんとなく疑問に感じている。もやもやしている。

　最初の２つの「あるある」にたいしは、COBOLクローンコード調査の論文をプレゼン資料におとしこむことで実現した。プログラミング言語はCOBOLだが、話の内容自体は他の言語でも充分あてはまる。また、持ち帰って現場で実際に活用できるように、昨今の主なプログラミング言語でも計測できるツールや、類似の参考文献も提示することにした。

　最後の「あるある」のもやもやを可視化するために、今回、下記のような学習モデルを考えてみた。
image.png

　上側が成果となる資産、すなわちプログラムをoutputする活動である。outputされたプログラムは計算機上で実際に動作しテストされることで 妥当か否かを評価される。outputされたプログラムには曖昧さは存在しない。
　一方、下側がプログラムをoutputするための開発チームの行動である。過去のチームの行動や行動規範、開発環境などが input され、現在のチームの行動に反映されることを表している。開発チームの行動は（フィードバックがもやもやであることふくめ）何かしらのフィードバックがあり、それがチームでの習慣化や開発体験につながっていく。

　このように図解化することで、エンジニアリングマネージャの役割、すなわち、開発チームのシステムをマネージする際のポイントがみえてくる。
　たとえば、行動の機敏性をあげようとすれば、行動の input のバリエーションを増やすように働きかけたいところだし、行動を深化させるなら、フィードバックにある強化スイッチにて 深化の内容を最大化させるように働きかける必要がある。
　また 真ん中にあたるところがエンジンリングチームとなる。この組織構造の初期値をどのようにおき、そして変化を促すアルゴリズムはどうしておくよいか。正解がない活動であるけど、その検討が必要となる。

　で、以上のことを設計することが、エンジニアリングマネージャの一番重要な役割じゃないかと考えた。
　過去・現在のチームへの inputが変化せず、強化スイッチも場当たりなら、チームの習慣はつらいままで固着、悪い意味でのレガシー開発が習慣化し、チーム自体が悪い意味でのレガシーになる。
　逆に、チームをよりよくするため 適切なinputをあたえ、強化スイッチも適切なタイミングと最適なフィードバックを制御できれば、きっとよい意味でのレガシーシステムとなる。チームをこのよい意味でのレガシーシステムとしていくのが、エンジニアリングマネージャのお仕事なのだ。

参加してみて。

　今回の勉強会で一番驚いたのは、みなさん 健康的で「若い」こと。
　もちろん運営の @dskst9 さんや @Kotanin0 さんの導きのよさもあるかもしれないけど、それをわりびいても レガシーというテーマで、表情が明るく今の境遇を楽しもうという雰囲気が強かった。
　まず、そこがよかったとおもう。

　以下、個人的に印象に残っている部分をまとめる。

レガシーとは何者か

　主催の@dskst9さんのお話。

　開始前に「全然準備していない」旨のことをおっしゃっていたが、どうして どうして 大変うまかった。 　あらゆるものがレガシーとして存在し、組織もまたそうだよねという話が印象的だった。

レガシーフロントエンド / LEGACY FRONEND BY LOHACO

　同じく主催の @Kotanin0 さんのお話。

　パブリックイベントでスピーカー初というお話だったけど、こちらもそう感じられない発表だった。でもって、スライドかっこいい。 　１年ごとのステップアップが表現され、定期的に ふりかえりをしていることがうかがえた。このくらいの、軽いが練れているロードマップの表現方法は、社内に是非持ち帰りたい。 　ちなみに、LOHACO、妻が愛用しています。

レガシーコア 不変の価値

　@k_h_sissp さんのお話。

　レガシーを生物の進化、とくに恐竜にたとえながらのお話だった。イルカの例だったかな、一度エラ呼吸をすてて陸にあがりまた海に戻った際 エラはもどらなかった話は 大変興味深く妙に心にひびいた。　

人のレガシーを笑うな

　@m_norii さんのお話。

　CVSや Subversionといったバージョン管理システム、EUC_JP・Shift_JISなど文字コードのお話とか いろいろ懐かしく聞くことができた。最後の撤退戦のスライドおもしろかったです。

本当にあった爆速でコードをレガシー化させる怖い話

　@shigeshibu44 さんのお話。

　完璧なアンチパターンはないことと、プロダクト・コードへのオーナーシップを再びもてるようになれれば、開発チームはきっと幸せなチームになれるという話は響いた。オーナーシップは日本語におきかえると愛着になりますよね。コードへの愛着、チームへの愛着。日々ふりかえることで コードやチームに愛着がふかまっていき、メンバの成長につながる気がしています。 　勇気をもらいました。 　remote worker ということでしたが、remote worker の話も一度是非きいてみたい。

レガシーインフラと向き合った三年

　@ni3shi9p さんのお話。
　レガシーインフラと向き合った三年.pdf - Google ドライブ
　分離の甘いネットワークのお話は耳が痛かった。組み込み系でもハードのデータバスの設計がまずく、まさしく「分離の甘いネットワーク」になっている場合が往々にしてあるんですよね。全体像をかくというスキルはどこにいっても持っていけるスキルだとおもいます。あと、ねこさんかわいかった。

さて、自分の発表。

　さて、自分の発表である。

　まず、会場をぐるっとながめてみて、聴衆の「若さ」をあらためて感じた。きっと、リファクタの許しがもらえんとか、リファクタしたいことに違和感をもっているという悩みはなく、自然にリファクタリングしていそうな印象をうけた。

　で、正直「はずしたな」とおもった。
　なので、おもわず会場の皆さんをみて「私の存在そのものがレガシーですね。」と思わず言ってしまった次第。
　あとは、かなり緊張しながらもたんたんとプレゼンした。くどくなったり、逆に言うことをとばしたりして かなりわかりにくくなってしまったかもしれない、すみません。
　ただ、inputが変化せず、強化スイッチも場当たりなら、チームがレガシーになるという主張は、Twitterみても結構共感してもらったみたいでよかった。余談になりますが、こういうフィードバックが可視化できるのは Twitter いいですね。

おわりに。

　以上、

  • スクラムにかわる 開発フレームワークと その要件
  • 上記要件から機械学習を参考にした開発フレームワークっぽいものを図解したこと
  • それと、過去のクローンコード分析をネタに、レガシー感謝の日というイベントでお話してきたこと
  • レガシー感謝の日というイベントで持ち帰ってきたこと

を、つらつらエッセー風にかいてきた。

　来年も同じ時期にまた開催すると聞いています。もし、来年また同じイベントがあった際には、なにかしら深化・成長した話ができるといいなと思っています。

　以上、なにかしらの参考になれば幸いです。

　ではでは、よい開発体験を。

謝辞

　今回、貴重な機会を与えてくださった ASKULの@dskst9さん、 @Kotanin0 さん、緊張しいのびびりの私の話を辛抱強く聞いてくださった参加者の皆さん、突然東京に行って一泊したいと言い出した私を気持ちよく送り出してくれた 妻と、愛する娘ニャンズに 感謝します。どうもありがとうございました！

5
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
5
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?