パネルディスカッション テーマ

「プログラミングにおけるより良い選択とは〜『ソフトウェア設計のトレードオフと誤り』から紐解く設計方法〜」に参加してきました

プログラミングにおけるより良い選択とは〜『ソフトウェア設計のトレードオフと誤り』から紐解く設計方法〜

https://findy.connpass.com/event/300004/

に参加してきたので、聴講メモです。

イントロダクション:書籍『ソフトウェア設計のトレードオフと誤り』について 渋川さん

資料

https://docs.google.com/presentation/d/e/2PACX-1vSsESeR_qEqudzabbZSiUT9qIoowCJt_kH5xMDwLMNd3CFRHY0Zn5pdGLJUSiBPhqyaeP3zQnGWCLuU/pub?start=false&loop=false&delayms=3000&slide=id.p

本の概要紹介

全部で13章あり

  • プログラミングな話
  • 分散システム系な話(分散システムに詳しい人が書いた部分)
  • 日付と時刻の話(この章は結構他と毛色が違う)

のようなことが書いてある

どんな本?

プログラムは書いた通りにもちろん動くが、メンテナンス性や性能や拡張性などの部分は考える必要がある。
様々な業務経験から議論が深掘りされているため、渋川さん自身も発見が多かった。

逆にどんな本ではない?

  • 手っ取り早くコードを読みやすくするとかではない
    • リーダブルコードみたいな感じではない
    • ある程度コードを読みやすくする心得みたいなのは知ってる前提の、初心者を突破した人レベルが対象
  • 正解を求める向け人ではない
    • クリーンアーキテクチャの本とかでもそうだけど、「こうすればいい」を求めてる人向けではない
    • おそらく正解を求める思想の人は、現実ではそんなことはないと感じると思う
  • 現在多く使われているフレームワークを網羅しているわけではない

トレードオフとは?

トレードオフは判断基準によって変わるし、
トレードオフから決断をするときには、更に別な基準が入ってきたりする。

トレードオフは面白い

  • 採用しなかったアーキテクチャも残したらいいのではないか。
    • 他案でどんなものがあったのか。
  • 状況が変わったら採用しなかった他案が参考になるのではないか。
  • 初心者が読んだら参考にもなるのではないか。

パネルディスカッション「渋川さん・松岡さんならどちらを選ぶ?」

トレードオフがある複数の選択肢のうち、お二人なら何を選ぶのかをお話いただきます!

パネルディスカッション テーマ
パネルディスカッション テーマ

コードの重複vsコードの柔軟性

渋川さん

重複は気にしない
DRYの法則でも、3回以上重複するなら改善しようとなっていて、逆に3回までなら良いかなと思う。
最初から重複を排除しようとすると必要以上に複雑になったりもする。

松岡さん

テーマが 〇〇 vs 〇〇 となっているが、スタンスは違うものではないと思う。
重複というより、知識や責務で分けるのが良いと思う。
たまたま同じプロパティだったとしても、
たまたま同じだったユースケースが違うものだったりもする。
それを一緒の扱うようにしちゃうと難しくなる。
クリーンアーキテクチャは難しくて認知負荷も高いが、
社内でも責務を分けるのが大切というのを繰り返し発信するようにしている。

渋川さん

フレームワークによっては、
バリデーションはここに書くと決まってると、自然と責務を分けられるようになったりもする。

Q1

コードの重複について、各クラスに分散してしまっているものはどのように検知していらっしゃいますか?
静的解析で賄える部分もありますが、気付かぬうちに重複が増えてしまっていたケースのコントロールに苦戦してます。。

A1

松岡さん

自動検知はそんなにできなそうとは思っている。
自分たちはパッケージに分けるとかのルールがあって、リファクタをしやすくするようにしている。
みつけたら改善するというようにしている

渋川さん

そもそも重複を排除したほうがいいのかを考えるのもいいかもしれない。

例外 vs 他のエラーハンドリングパターン

渋川さん

このフレームワークや言語ならこういうやり方だよねというのがあるので
それから離れないほうがいいかもしれない。
例えば関数型を学んだからモナド使ってみようかなみたいなのは
他の人からしたらノイズになったりする。

例外の仕方というよりは、例外は最終的に誰が処理するのかを考えたほうがいいかもしれない。
ユーザーにどう対応するのか、社内の誰かがどう例外に対応するのか等を考えて
そこから、最終的にどうするために例外こうしようということを考えたほうがいいかも。

松岡さん

渋川さんに同意。
言語によっては、例外の投げ方をどうするかとかの議論はあると思う。
TypeScript や Kotlin などで、例外を投げるのかエラーを return するのかとか
そういう話が出てくるときはある。

Q2

個別具体の例外ルールが積み重なって負債のようになっており、別管理になっているのですが、例外処理を作りすぎない方がいいなどの目安はありますか?

A2

渋川さん
例外処理を作りすぎというのは、例外の型を作りすぎという意味だとして、
最終的に例外を処理する人が運営の人なのかサポートの人なのかとかだと思うが
その人たちが対応できるように、リストを作っておくといいのかなと思う。
例外はシステム外で対応するという話なので。

流行を追いかけ続けること vs コードのメンテナンスコスト

渋川さん

仕事で選ぶことが多いのは、ある程度歴史がある言語やフレームワーク。
Rust ももう10年くらいたってるので、安心して使えるかもしれない。
ただ、フロントエンドは最新を追いかけてる。
フロントエンドの新しいものは革新的で自分たちの利益になると大きい。

松岡さん

渋川さんに同意。
追いかけるというより、学んでいくといいことがあると思っていて
新しいトレンドを知っていくと、よりよい書き方とかが学べて今後取り込んでいく選択肢になるので
学んでいくのが良いと思う。

Q3

最近の言語は例外がないものが増えてきているのですが、例外を使うメリットは何でしょうか。個人的には解析性やマイクロサービス化が進むことでデメリットのほうが多い気がしています

A3

渋川さん

例外が発生したら一箇所で処理できるのでいいというのが、例外が発明されたときはあったかもしれない。
ただ、いろいろ意見があって例外は例外で扱いづらいところとかはあるかも。

松岡さん

さっきの Go の panic の話もあったが、本当にシステムとしてどうしようもないみたいなときは
例外を投げてまとめて処理できるともしかしたら良いのかも知れない。
そうじゃないときは分岐させてみたいな使い分けができるといいかもしれない。

Q4

現在プロダクトに残っている例外処理のいくつかが実装当時の意思決定が残っておらず、惰性でそのままなのですが、改善すべきでしょうか?
当時の思想がわからない例外処理の取り扱いのご意見を伺いたいです

A4

状況によるかもしれない。
握り潰しているのかもしれないが、それで困っているなら改善したほうがいいかもしれない。

Q5

コードのメンテナンスにかかるコストを計測されていたりしますか?
属人化されており、現在は良いのですがその方が異動等でいなくなった場合の対処法に悩んでおります。

A5

松岡さん

ここがこのくらいぐちゃぐちゃだと、こう困るよというのを言語化するために計測するとかのほうがいいかもしれない。

渋川さん

コストを計算したものを一概に判断はできないかも。
AさんがやるのとBさんがやるのでかかる時間も違うので。

Q6

昨今のLLMの隆盛から開発に取り入れるべきか悩んでいるのですが、流行に乗ってどんどん取り入れるべきなのでしょうか?
生産性向上の反面、これまでの標準から外れることやメンテナンスコストに見合うか否かの判断はどうお考えでしょうか?

A6

松岡さん

入れるというのも、開発プロセスに入れるのか、プロダクトに入れるのかで大分話が変わる。
プロダクトには合う合わないがあるので、そこを考えるしかないかも。
開発プロセスは、copilot 入れたらアシストしてくれるので、いれてみたらいいんじゃないかなと思う。

渋川さん

プロセスだという前提で、
生成されるコードもレビューをしたりするので、全部おまかせで生成にはならないとおもう。
Javaでも歴史の中で流行りの書き方とかがあって、古い書き方を生成されたりもするので、そういうのは改善するし。
生成が得意なものもあったりするので、熟したものを使うとかはあるかもしれない。

Q7

少人数で開発していた初期フェーズから組織がグロースしていく中で、チーム毎に開発が多様化してコードの重複や書き方が複雑化していくと思っています。
保守コストの高さを許容してでも共通ロジック化を進めるべきタイミングはいつ頃と考えられてますか?

渋川さん

先手先手でやるしかないと思う。

松岡さん

共通化の責務を誰が見るのかが大事かも。
全員自分のコードしかみてないとかだと良くなくて、横串で誰がが責務を持ちますというのがあると良いかも。

クロージング

渋川さん

実は、会社のテックブログを年間200記事近く投稿とかしてます
よかったら見てね
Future Tech Blog好評配信中
https://future-architect.github.io/

松岡さん

社内で、毎週絶対記事出す、更新が止まったらそこで終了というイベントをしている(現在13週目)
https://zenn.dev/p/loglass
質問箱もやってます
https://querie.me/user/little_hand_s?ts=1701151680883

togetter まとめ

https://togetter.com/li/2267188

参加しての感想

渋川さんがおっしゃっていた、採用しなかった設計もドキュメントに残すと良いのではないかというのは自分もそう思っていて基本的に残すようにしている。

採用しなかった設計というよりは、「なぜいまこの設計や選択肢を取ったのか」を記載するようにしていて、その意思決定の材料として「背景として他にこういう選択肢もあったが、こういう比較検討をした結果こちらを採用した」を残すようにしている。

理由は渋川さんがおっしゃっている通りで、将来状況が変わったときに「既存のようになっている理由がそれであるのなら、こういう変更をするのは問題ないだろう」という、将来の変更の助けになるためにしている。

また、イベント開催前にパネルディスカッションテーマを見ていたときに、「vs と書いてあるが、これはどちらが良い悪いとか、排反しているとかではなく、ソフトウェアを変更を容易にするための手段であって、目指してるところは同じの認識」と思っていたが、松岡さんも近しいことをおっしゃっていたように思えて、自分の認識が違ってなさそうで安心した。(イベントのタイトルが「トレードオフと誤り」なので、あえてのディスカッションテーマだったのかも)

「例外はシステム外で対応するという話なので、最終的に誰がどう処理するのかを考えるのが大事」という点で、確かに自分も例外を投げるときは、その後の人での対応はどうするを考えているが、言われてみて「たしかに」と改めて思うところだった。

他の参加者の方からの質問で、静的解析ツールや LLM を使うケースもよくあったなぁと感じた。

自分はその辺りにはまだ疎いので、勉強していきたい。

今回テーマになってる本の存在は知ってたのだけど読んでないので、読みたくなった
「ソフトウェア設計のトレードオフと誤り―プログラミングの際により良い選択をするには」https://www.oreilly.co.jp/books/9784814400317/

「コード品質向上のいろは – 先達に学ぶ実践例 Lunch LT」に参加してきました

コード品質向上のいろは – 先達に学ぶ実践例 Lunch LT

https://findy.connpass.com/event/300912/

に参加した聴講メモです。

LT①『「コードがむずかしい」からの脱却』 株式会社メルカリ 濱村甚平(@jinpeih )

資料

https://speakerdeck.com/jimpei/kodogamuzukasii-karanotuo-que

途中から参加したので、メモは途中から

「コードが難しいから改善したいので時間ください」だけだと、相手には伝わらない。

そのため

  • それはどのくらい悪くて
  • 改善するとどのくらい効果があって
  • どのくらいの時間が必要なのか

などの指標が必要。

複雑度の指標

SonarQube 等のツールがあるのでそういうのを活用した

ただ、だからといって数値が悪いイコール絶対改善!というわけでもない

複雑度が高いからといって、そのコードを滅多に変更しないなら改善してもあまり嬉しくない

また、複雑度はやり方によっては回避できる。

例えばネストさせない代わりに関数を分割させまくると複雑度の数値は下がるが、

それは複雑度の低い複雑なコードなだけである。

指標を下げることが目的ではないので、あくまで補助的な使い方。

ひとりで書くのは難しい

ペアプロで意図を共有しながらコードを書くと、少なくとも二人の間では意図が通じてる

Q&A

Q1

他の人や他のチームの数値が見えすぎると、良い部分はある反面少し競争のような形になってしまうなとも感じています。

どこまでの人と数値を共有するかなど、意識されたりしていますか?

A1

比較するものではないので、競争とかにならないように数字数字という扱いにしていない。

共有は広く共有したほうが、参考になるのでいいと思う。

Q2

認知的複雑度を数値化してからは、やはり不具合は減ったのでしょうか?

A2

これは簡潔に yes/no かは言えない。というのも、数値化した後にチームを離れることもあるし、

まだ数値化したあとに不具合の数がそれによってどうなったかを追っていないというのもある。

不具合が減った要素はいろいろあるので、そこまで追うのも難しいかも。

ただ、将来的には、不具合を減らしたいから数値化しているというのも目的の1つにはある。

LT②『なぜリアーキテクティング専任チームを作ったのか』 株式会社アンドパッド 白土慧(@kei_s)

資料

https://speakerdeck.com/kei_s/naze-riakitekuteinguzhuan-ren-timuwozuo-tutanoka

現状のアーキテクチャ

中心となる Rails に付随する形で各プロダクトが存在

Rails は8年選手

Rails のライブラリアップデートが滞っていた

  • ライブラリの開発が停止してたりしたが、そのままだった
  • アップデートしようにも、そのライブラリは複数のチームに跨っているので、1つのチームで責務を持ちにくい

これによって、古いライブラリに依存したコードを書かなければならなく、メンテナンス性が低下。

OSSのメリットもあまり受けられない状態に。

リアーキチームの発足

  • 特定のサービス等には責任は持たない。そこは既存のチームが担当する
    • その代わり、チーム目線だと難しい全体目線で考える部分を担当
  • 共通利用されているところとか担当
    • 逆に、特定のチームでのみ使っている部分とかは対応しない

さじ加減

「ライブラリアップデートは、リアーキチームの仕事」としない。

特定の人の仕事ではなく、改善意識は全員が持つべき

Q&A

Q1

お話であったように、エンジニア全員で改善をするというマインドが失われないようにするための取り組みはありますか?

専任チームを作ることで、各自から課題が出てこなくなるリスクもあるなーと

A1

わいわいと「ここ改善したいよね」みたいな話をしたり

リアーキチームに限らず、改善活動するのは良いことである、みたいなのを浸透させるようにしている

Q2

ライブラリアップデート時の影響範囲調査の進め方など、専任だからできるメリットをもう少し聞きたいです

A2

専任チームのいい例は、専門でそこの領域に調査の時間とかとれたり知見がたまるのが良いと思う。

逆にプロダクトチームほど知見がないので、「この挙動ってどうなってる」「こういうテストを考えてるけど抜け漏れないかな?」

みたいなコミュニケーションを取るようにしている。

LT③『10年モノのAndroidアプリのコード品質を改善していく、3つの取り組み』 Chatwork株式会社 奥澤 俊樹(@okuzawats)

資料

https://speakerdeck.com/okuzawats/4de89f92-6dff-4d77-8701-10882ff27be7

なんでコード品質を改善したいのか

  • メンバーやチームが増えた
  • コード品質が開発速度に直結
  • 改善したい

コードレビュー

「自分がコード品質について誰よりも考えレビューすればよい」と思っていた。

が、自分が門番になってしまうと開発速度が落ちると思ったので、そうはしなかった。

自動レビュー

静的解析ツール

  • danger
  • ktlint
  • android lit
  • sonarcloud(今日の話はこれに着目)

メリット

  • コードが怪しいところ(Code Smells)の検出
  • 複雑度を出してくれる
  • 閾値を満たさないと CI が落ちる

勉強会をするようにした

https://creators-note.chatwork.com/entry/code-readability

ガイドラインの作成

Kotlin のスタイルガイドみたいなのを参考にした

できれば Lint がスタイルガイド通りに反応してくれたら嬉しいので、検討中

Q&A

Q1

SonarCloud検討しているのですが、他に検討したツールや自作していたものなどありますか?

また、どういう観点で使う判断をしたか参考に聞きたいです

A1

もともとある程度SonarCloudの知見があったから使った

Q2

ストリームアラインドチームメンバーをどうアサインしたか気になります

A2

それぞれのエンジニアがどういう仕事やキャリアにしたいか等で検討した

LT④『DMMプラットフォームにおけるコード品質を改善する取り組みの理想と現実』 合同会社DMM.com pospome(@pospome)

資料

https://speakerdeck.com/pospome/dmmpuratutohuomuniokerukodopin-zhi-wogai-shan-suruqu-rizu-minoli-xiang-toxian-shi

レガシーシステムのリプレイスをするよ

コードの品質を高く保って、開発速度を改善したい。

品質を高く保つための持論

リファクタリングや静的解析ができても、設計スキルが高くないと品質は上がらない

が、設計スキルが高いエンジニアを雇うのも育てるのも難しい

そこで、レビューシステムの導入

各チームのコードを設計スキルの高いエンジニアがチーム外レビューする取り組み

うまくいく自信があった

が、それだけだとうまくいかなかった

なぜなら、チームによって課題が様々だから

  • リファクタリングの時間確保
  • 良し悪しの判断が難しい
  • 意思決定権持ってる人への、品質に対する理解

まとめ

組織が大きいとコード品質改善は大変。

特に意思決定の部分が大変なので、戦略を持ってやらなければ。

Q&A

Q1

pospomeさんの考える「設計スキルが高いエンジニア」の基準をお伺いしたいです!

業務知識に詳しく、アーキテクチャ図を描ける人、静的解析に詳しい、など

A1

SOLID 原則とか分かってたり、もちろん業務知識も必要

図を書くためのスキルみたいなのはあまり必要ないかも。

Q2

専任チームを作る話が本日多数ありましたが、

最初にチームを組成した時に、他のチームへどのように介入したか、より失敗談や工夫した点などがあれば聞きたいです。

A2

まずはレビューやらせてくれという姿勢で入った。

失敗談の話になるが、結局チームのテックリードや意思決定者を巻き込まないといけないので難しかった。

参加しての感想

各社、ある種似たような悩みを抱えていて、それに対して社内の状況に合わせたアプローチを試行錯誤しているんだなぁと感じた。

そういう意味でも、今回のような会は各社の知見を共有して自社に活かすことに繋がるので良いなぁと感じた。

各社概ね共通していることは

  • 現在の状態を整理
    • 課題は何か
    • 必要であれば静的解析ツール等を使って数値化、見える化
  • 対策を検討
    • どこまで対応するか
    • 専門チームの立ち上げ
    • コードレビュー
    • 品質意識の浸透
  • 対策を実行したり、更にブラッシュアップしたり
    • 指標に対する考え方
    • やること・やらないことを明確に
    • より活用にするためにどうするのが良いか
    • チームの課題に合わせて動くように

などがあるなぁと思った。

当たり前かもだが「これが最近流行ってるやり方!」「とりあえずこれやっとけ!」みたいなのがある訳ではなく

課題が何で、どういうゴールを想定していて、理想の状態にするために何をすればよいかを考え、改善し続けるという、課題解決の基本的な考え方と同じだよなぁと思った。

その中で、テクニカルな部分や参考になる手段として静的解析ツールの導入や、専門チームの設立などがあるなぁと思った。

 

SonarCloudは触ったことないけど、コードの怪しそうな部分(Code Smells)を教えてくれるのが気になった。

デジアンシステムとは何か?

「デザインシステムからはじめない、デザインシステムの考え方」に参加してきました

デザインシステムからはじめない、デザインシステムの考え方
https://flexy.connpass.com/event/289496/
に参加してきたので、そのときのレポートです。

登壇者

  • 小木曽 槙一さん|株式会社SmartHR プロダクトデザイングループ プロダクトデザイナー @kgsi
  • 金森 悠さん|株式会社SmartHR プロダクトデザイングループ プロダクトデザイナー @uknmr
  • sakitoさん|サイボウズ株式会社 Design Technologist @__sakito__

デザインシステムとは何か?

デザインシステムとは何か?
デザインシステムとは何か?
  • デザインシステムは変数的なもの。プログラミングでいう箱で、そこに何をいれるか。
  • 会社によって、スタイルガイドをデザインシステムと言ってたり、コンポーネントをデザインシステムと言っていたりする。
  • デザインもシステムも言葉が大きい。
    仕組み化までしてシステムなのかなと思っている。
  • デザインシステムって楽な単語だと思う。すべて説明するよりは、大きな「デザインシステム」というラベルを使うと会話が楽。
    言うのは楽なんだけど、作りますってなるとちゃんと会話しないといけない。
    個々人の考えているデザインシステムは、コンポーネントのことだったり、デザイン原則だったりすることがある。
スタイルガイド
スタイルガイド

SmartHR

  • デザインシステムを作ることが目的で始まったわけではない。
  • コンポーネントライブラリやUIガイドラインが当時あったが、内部ではドメインが20個くらいに分かれていてデザインの違いがあり、ユーザーを混乱させてしまうことがあったのでその課題解決で始めた。
  • 社内でもデザインのドキュメントが散らばっており、「ここを見れば分かるよ」という状態にしたかった。

サイボウズ

  • デザインの歴史の継承をしたくて始めた。
    歴史の継承をしていない(デザインの移り変わりの背景を知らない)ために、同じ繰り返しをしてしまうことがあった。
  • そこで、10年溜まった知見を活かすことができるようにしたいと思った。
    当時、ドキュメント自体は残ってたが、まとまっていなかった。
    データがなくなることもあるが、人もいなくなると更に難しくなる。経緯を誰も知らない状態になる。

質問:「受託制作はデザインシステムをどう作るのが最適か?」

  • 何を解決したいデザインシステムなのか。
    仮にスタイルガイドを用意してそれが機能するのであれば、それはシステムだといえるのだと思う。
  • 何をしたいのかが大事で、丸投げしたらうまくいかないし、伴走してくれたらいいかもしれないし。
  • どう作るのが最適かと言われたら、現場によるかも。
    現場の人はデザインシステムが欲しいわけではないと思うので、デザインシステムを作ることを目的にしないほうがいい

質問:「サイボウズ社ではデザイン変更の履歴を現在どのような仕組みで残されているのでしょうか。」

  • まだ TRY 中だが、ストーリーブックに全部まとめてる。
  • ので、ブランチの履歴を見ればわかるようにしている。Figma に変更履歴のリンクを残したり。

デザインシステムの立ち上げ方

目的・課題を明確にする

目的・課題を明確にする
目的・課題を明確にする

課題

SmartHR

  • 20個くらいのプロダクトのUIのばらつきがユーザーの混乱の原因になってる。
  • 横串でレビュー会もやってるけど、対処しきれず難しかった。
  • コミュニケーションコスト増大。例えば、エンジニアからしたら「この余白の違いは意図してるのかどうか」などの質問への対応とか。

サイボウズ

  • 歴史の継承ができていない。
  • デザイナーしかデザインに関わらない。
  • ボタンの色や配置を変えて終わりならPMでもできるので、デザイナーはもっと難しいことに注力したほうがいい。

課題対処へのことはじめ

SmartHR

  • 歴史があったため、当時スペースがずれてるところとか気になっていて、パターンを統一したいと思っていた。その課題を解決するためにやるという姿勢だった。
  • 明確にデザインシステムを作ろうぜという感じで始めた訳ではなく、レガシーなものを整理したいという課題から始まった。

サイボウズ

  • デザインを言語化するチームを立ち上げ、アクセシビリティ、エンジニア、デザインを変えたい方、等デザイナーだけではなく色んな方面に強い人が集まったチームで始めた。
  • 過去を直すのは制約が大きいから、新しいところから始めようとなった。
  • デザイン室で、デザインとは外部にアウトプットするもの全てをデザインと定義。

便利なコンテンツから作る

便利なコンテンツの3つのポイント
便利なコンテンツの3つのポイント

SmartHR

  • デザイントークンの定義
  • 地道にタイポグラフィを考えたり。

サイボウズ

  • ボタンのコンポーネントを1つ用意するだけという、一番ミニマムなところからやった。これから増やしていくが、まずは既存のボタンのコピペだけ。
  • だんだん、それを使ってプロダクトを作ることで、こことここは共通だとなっていったりした。
  • 少しずつ移行していく。

まとめ

  • 便利なものを作る。作っても使ってもらわないと意味がない。
  • 最初は読み物だけでもいいかもしれない。
  • プロダクト立ち上げ当初だとデザインシステム作るの難しいと思うから、当初どうしてこのデザインにしたかを残しておけると、後から役に立つかもしれない。

デザインシステムをみんなが使えるようになるために

「みんなのもの」にするための3ステップ
「みんなのもの」にするための3ステップ

最初は地道な草の根活動

  • SmartHRもサイボウズも、最初は草根の根活動
  • 日本だとデザイン原則という言葉を使っていて、それはよくないかもしれない。英語だとフィロソフィーやファンダメンタルと言っているが、日本では直訳して原則と言っている。
  • デザイン原則をやると永遠に時間がかかるので、それより先に浸透していくことをしている。
  • 未だに浸透のための草の根活動は続けている。
  • だんだん、ファンがついてきてドキュメントを読み込んでくれたりしてくれる。

組織浸透時に課題

SmartHR

  • デザインシステムがデザイナーだけのものになってしまう。

サイボウズ

  • デザインシステムが浸透することで、やることが増え、開発の妨げになってしまう恐れ。これは現在進行形で起こっている。
  • 組織は大きくなっていくので、それを追いかけるように浸透させていかないといけない。

課題に対するアクション

SmartHR

  • エンジニアがデザインシステムを知らないので説明したり啓蒙したり

サイボウズ

  • 機能追加やリリースするものがあれば早く察知するようにする。デザインシステムが原因でリリースを遅らせるわけには行かない。
  • 最初は中央集権的にチームを立ち上げたが、分散的なチームに移行
  • 今はコアメンバーは、本当に大事なところだけやりますとか。

質疑応答

質問:デザイン素養のない開発者だけでは手詰まりを感じている。
デザインシステムについて見識があるパートナーを得たい。どこで見つければよいのでしょうか。

  • 自分がこの会社いいなって会社に話を聞きにいくのがいいかもしれない。

質問:プロダクトの開発を始めてからどのくらいのフェーズの時にデザインシステムを作り始めるのがいいのでしょうか?

  • デザインシステムというよりはドキュメント(さっきも話したけど)に、なぜこのデザインにしているのかというのを書いていくところから始めた。
  • デザインシステムを作ることが目的じゃないよって話。

質問:サイボウズ社ではstorybookがsingle source of truthになっていて、デザイナーもstorybookを参照して都度figmaにパーツを取り込みながらデザインを作成しているということでしょうか?

  • Yes

質問:社内的にデザインシステム化をする工数が承認されてない場合の「ことはじめ」は
結局ゲリラ的(時間外作業とか)にやるのが良いのでしょうか?

  • デザインやってる人は、なぜこのデザインにしたのかを説明する責任がある。なので、そのゲリラ的な作業でことを為せられたらよいけど、それで失敗したら…とかある。
  • エンジニアのリファクタリングと同じで、業務時間でしれっとやるのもありかもしれない。
  • ドキュメントから始めていって、作業効率が良くなったら「実はデザインシステムがあるんですよ」とかで広めていくとか。

質問:SmartHRさんが基本的にFontAwesome(Free)を使うことにしたのはどういう理由でしょうか。

  • 入ったときからそうだった。また、いまそれが課題になっていないので、課題になったらまた考えていこうという話になっている。

質問:ドキュメントが苦手とか、忙しくて実務の中でちゃんと読んできてくれない人はいましたか?
地道に普及活動やるしかないんでしょうか?

  • 基本読まないと思ったほうがいい。
  • 読まれなくてもあるのが大事で、何かあったときにスッと出すことができる。そこでの共通認識を持つのが早い。
  • 課題になってないから読まないだけだと思う。

質問:細かすぎるフィードバックや要望に対する、対応方針などは決めてますか?

  • 場合によるが、優先度で考えると思う。
  • 他にも、何度も同じ話をしてたら対応コストもあるから言語化しようとかある。
  • ただ、意見をくれたことに大してはめちゃめちゃ感謝している。

参加して個人的な感想とかまとめ

  • デザインシステムはあくまでツールであって作ることが目的ではなく、デザインシステムを使って課題を解決するのが目的
  • デザインシステムという言葉は人によって色んな解釈があるので、場面によっては具体的に何を指してるかを話すようにしたほうが良い
    • 「システム」と言われるので、具体的な物や行動というよりは、仕組みという解釈のほうが近いかもしれない。
  • デザインシステムを取り入れるとなった場合には、小さく部分的に始めると比較的やりやすいかも。かつ、周囲の人がメリットを感じる(これあると便利だな)ことも並行して進めると受け入れられやすいかも。
    • この辺りはデザインシステムによらず、システムリプレイスとか業務刷新とかする場合と似たような考え方だなと思った。
  • 登壇者の方は、事例を交えながらフランクな雰囲気で対談をしていただけたので、聞いていてとても分かりやすく、内容や現場感のイメージもしやすかったです。また、一貫してデザインシステムを作ることが目的ではなく課題解決の手段だというのもおっしゃっていて、改めてそうだよなと思いました。とても良いイベントでした。

「クラウドの作り方 (使い方じゃないよ) – NTT Com Open TechLunch #2」に参加してきました

クラウドの作り方 (使い方じゃないよ) – NTT Com Open TechLunch #2
https://nttcom.connpass.com/event/263134/
に参加してきたので、そのときのレポート

クラウドの作り方

DC NW x ソフトウェア

Data Center を作る。ラックとか空調管理とか。

物理装置を扱う

  • ハードウェアがちゃんと動くかとか
  • 100G bps のテストに耐えられるかとか

ネットワーク試験を自動化
大量のテストがある
テストログだけで7000万行くらい出てくる
そのログの解析も自動でやる

 

物理配線の切り替えロボットの導入

 

そのように

  • ネットワーク x ソフトウェア
  • ハードウェア x ソフトウェア

を意識して開発している

SDN/NFV x ソフトウェア

SDN とは?簡単に

ネットワークを切り替えるソフトウェア

SDN コントローラーの経路計算遅延解消

この辺はよく分からなかった
冗長な実装があって、アルゴリズムを改善したら、かなり早くなった、という内容っぽい

ディスカッション・質疑応答

Q1

このクラウドはどうすれば使えますか?

A1

法人向けのサービスなので、法人向けの営業の方から連絡とってもらって、となる

Q2

社内(今回説明していただいた事業)での内製と委託の割合は?

A2

ちゃんと測っているわけではないが、内政がまだ半分いってないくらいかも?

Q3

配線ロボットは何者?

A3

実際の配線を物理的に切り替えてつないでくれるもの。
配線ロボットは探せば売ってるものがある。
いま使っているものが面白くて、大量の線を扱うが、線がからまることがないという特許を取っている。

Q4

人材は取ってくるんですか?育てるんですか?

A4

もともと育てることが多く、いまでもそうしているが、昨今人材不足もあるので、とってくることもしている

Q5

長期インターンシップとかやっていますか?

A5

なんらかの形で今後そういう場が作れていければと思っている

Q6

どういう言語で開発されてるんですか?

A6

それぞれのチームで決めているが、自分のチームでは Python, Go, C++ が多い。
Ruby を使っているチームもあるし、Rust とか流行ってきていたりもする。

Q7

クラウド基盤の開発や検証を担当しているのですが、クラウド基盤ソフトウエアベンダのパッケージソフトを使っていて、さらに各工程ごとに分業で実施しています。社員はほとんど管理業務しておらず、システム更改の開発規模もおおきく、重くて、新しいことにほとん度取り組みできていないです。どのようにしたら飛岡さんの発表のように開発が回せるでしょうか?アドバイスいただければと思います。

A7

どういうことを自動化していけるか考えていく。
内製していかないと自動化も難しい。
業務委託をきるというよりは、いまの作業を少しでも自動化していけないかを検討したりしている。

Q8

クラウドを提供していて大変だったこと、言えるポストモーテムはありますか?

A8

一番低いレイヤーまで自分たちでチューニングできるのは醍醐味だと思う。

Q9

物理的な作業のドキュメンテーションはどのようにされていますか?作業手順など、写真を取ったりとかなのでしょうか?

A9

配線など、大量の作業をしている。数%のミスだとしても何本か間違ってしまうことがある。
そういうのは実際に現地に行って写真を撮って確かめたりする。

Q10

NTTグループ間でのエンジニアの交流とか気になっています。

A10

交流はあって、今日のテックランチとかも社内でもともとやっていたこと。
t_wada さんの読書会とかも。
割とボトムアップで交流会が生まれたりする。
なので交流はチームを跨いでできるかと思う。

Q11

コードは書けないけどインフラ構築経験はある、みたいな人に席はありますか?

A11

自分にできないことをしてくれている人はとても重要で、多種多様な内容を専門にしている人がおり、他の作業をやっている人をリスペクトしている
他の作業に関して全く知りたくないとかだと良くないかもしれないが、一緒に協力しながら仕事をしている。

クロージング

次回も乞うご期待!

参加して個人的感想

日頃あまり触れないレイヤーの話だったので、とても新鮮で面白かったです。(こなみかん)

物理的な配線作業はなんとなくのイメージで、手作業でやるのかなり神経使いそうだなと思っていたのですが、ロボットがいることは初耳でした。(線が絡まない特許すごい)

社内チャットのスクショをみせてもらいましたが、コードの改善についてわいわいやりとりをしていて、おっしゃっていたように周囲の方をリスペクトしながら働いていらっしゃるという感じがしました。

また、大量の作業やテストを行うので、ロボットの導入をしたりテストを自動化したりなど、話にもあったように自動化が思っていたよりも重要だということも分かりました。

 

「リアーキテクチャことはじめ~事業成長を最大化するための技術選定と登り方~」に参加してきました

リアーキテクチャことはじめ~事業成長を最大化するための技術選定と登り方~

https://flexy.connpass.com/event/259853/

に参加してきたので、そのときのレポートです。

 

レガシーの定義とは?

今回のレガシーの定義では

今回のレガシーの定義
今回のレガシーの定義

と定義します

ここで大事なのが4で、簡単な機能追加に時間がかかってしまうことがある。
そこで、リアーキテクチャが必要になってくるが、
単に「このシステムは今ここがよくないのでこうすべき」というのは誰でも言えるが
将来の事業成長や拡張性を見据えてどうするか、ということも考えられるのが必要になる。


そこで、今日はリアーキテクチャをどのようにやってきたとかの話を事例を交えてする。

各社サービスの背景からみるリプレイスの事例

事例1

事例1
事例1

バージョンアップしたいが、なかなか難しく、負債が高まっていっていたため、リプレイスを検討した。

リプレイスを検討していると
現状のシステムを分析した結果、複数の境界線を跨っていることがわかった
そこで、記載しているような設計にした。
稼働年数10年とあるが、システムをリプレイスするのは稼働年数と同じくらいかかる。
今1.5年ほどリプレイスを進めているが、まだ序の口。

とある業務フローがあり、
伝統的なシステムだと、とあるデータを同じデータとして扱いたいが
業務フローを精査してみると、違うデータとして扱う必要がある。
例えば、セブンイレブンにあるお弁当とかは、全部同じものではなく、店舗によって近い工場で造られている
お弁当の申請をするとそれはパートナーが登録したデータだが、申請されたデータを承認するのは別の工程で行う。
それを処理するには、申請されたイベントから派生させて行うのが良いとなり、そうしている。

事例2

事例2
事例2

最古の commit が 2012 年だが、それ以前にも何かあったらしい。
一番社歴が長い人でも5年前で、その人に歴史を確認しながら進めることもある。
中身を見ていると、名前がおかしなものもちょいちょいある。
改修の際に調査が長引いてしまいデリバリーが遅くなることがあり、リプレイスを検討した

1日30分くらいつかって地道にLaravel に載せ替えることもしていたが、長続きせず頓挫することもあった

現在は本腰をいれてリプレイスを進めている。
いま進めているリプレイスも何年かかるか分からないが、進めている状態

リプレイスする際に、ちゃんと技術選定していかなければならない。
Rust を採用した理由は?と聞かれて「流行ってたからです」となると
未来で困る人がその理由は聞きたくないだろう。

事例3

事例3
事例3

読み取りと書き込みは別要件なので、それぞれ別個に最適化したような設計をした

事例4

事例4
事例4

内部事情を知らないといけないので、入った人が戦力になるまで時間がかかる

コードベースでモジュラーモノリス化した

事例5

事例5
事例5

マイクロサービスアーキテクチャ化をすすめている

マイクロサービスアーキテクチャにするとビジネスが推進されますよという見出しの記事がよくあるが
それを行うには何年単位という時間が必要になる
ドメインを分析したり、業務フローを精査したりなんなら業務フローを変えたりする必要もある
もろもろ全部考えた上で、決断する必要がある。
なんのためにマイクロサービス化するのか、技術ファーストではなく、ビジネスのためにどうするのか、というのを考える必要がある。

Q&A

Q1

リプレイス後のアーキテクチャはどのように決められましたか?トップダウン、ボトムアップなど。また、ボトムアップの場合で、メンバー間で意見があわない場合はどのようにアーキテクチャを決定されましたか?

A1

あらたまさん

トップダウンだった
現場で、どうすればいいか分からないという状態だったので、トップダウンで行った
また、リプレイスというのは向こう数年にわたって投資をしていくという判断なので、経営判断が必要になる
のでボトムアップだけだとうまくいかないと思う。
経営的に、いまここに投資するべきか、という判断をしている

ytakeさん

トップダウンだけでいくというのはあまりやっていない
メンバー間で意見が合わないばあい
スキルセットが合わない人ももちろんいるので、ディスカッションはする。
が、技術レベルを下げることはあまりしない。そこを下げてしまうと、周りが面倒をみる必要が出てくるし、会社の技術レベルが下がってしまう。
ので、習得してもらうようにしている

Q2

言語やフレームワークを大きく変更したとき、メンバーに対するキャッチアップはどのように実施されていますか?(ex. 週1で学習時間を設けているなど)

A2

あらたまさん

輪読回をしたりしている

ytakeさん

技術習得が難しい人もいるし、本だけだとわかりづらいところもあるので、質問があれば自分が噛み砕いて答える、ということをやっている
エンジニアだけに限った話じゃないが、技術習得のアップデートというのは当たり前ではあるので、そういうのを自主的にやっていけると良い

Q3

リプレイス中に仕様変更がある場合、どのように取り込んで開発していますか?

A3

あらたまさん

リプレイス中の使用変更はブロックするようにする

ytakeさん

やらないといけないことあやるようにしている

Q4

退職者が多いことによる辛み=技術的負債とした時に、リプレイスに時間が数年かかるとなると今作っているものを以下に負債にしづらくするかというのが大事だと思っています。そこに対する取り組みとかありますか?(ドキュメントは工数がかかりすぎたり、陳腐化する懸念がありどう考えているか伺いたいです)

A4

あらたまさん

ドキュメントはコンフルエンスとかにたくさん書くだけではなくて、コードコメントとかも大事なドキュメント
細かくドキュメントを残していけるかが、システムの寿命にもなると思う

ytakeさん

陳腐化するのか防げないので、定期的に確認する必要がある。
書いた人の考えていることの一部を読んだ人が得られるので、劣化した情報が伝わっていくので陳腐化は防げない
ので、定期的にメンテナンスする必要がある。

まとめ

ytakeさん

作るものだけを考えるのではなく、技術ファーストではなくビジネスのことも考えよう

あらたまさん

サービスや事業に対する理解を社内の人とたくさん話をして解像度を上げていく必要がある
自分の考えた最強のシステムを作りたくなる気持ちもあるが、そこを抑えて考えていく必要がある

参加しての感想

イベントの中でも出てきましたが、リプレイスはしなくて良いのであればしないほうがよく

日頃の業務の一部をリプレイスに投資するという判断をしなければならないので

ある程度ストレスがかかることもあると思います。

また、リプレイスをするというのは現状の負債と立ち向かうものなので、作業自体にも結構な負荷がかかると思います。

全体的にですが、そんな話を笑いも交えながら話をしてくれてとても安心しながら聞けました。

また、リプレイスは単発で終わるものではなく、数年かけて行うこともあるので

何をどうするということをしっかり決めたり、どういうプロセスでやっていくのかという計画を立てたりすることが重要だとあらためて感じました。

何度か出てきましたが、技術ファーストで考えるのではなくビジネスのことも考えていこうというのはとてもうなづけました。

いまのレガシーなシステムでつらいことを感じることもありますが、それだけの理由でリプレイスしたいというのは目線が自分に向いているので、ビジネス目線でどうなのか、ユーザー目線でどうなのか、ということまで考える必要があると、改めて感じました。(つらいのを許容するべきという意味ではない)

 

「10X Tech Talk〜カジュアル面談、なに話してる?エンジニア同士で話してみた!〜」に参加してきました

10X Tech Talk〜カジュアル面談、なに話してる?エンジニア同士で話してみた!〜

https://10x.connpass.com/event/263170/

に参加してきたので、そのレポートです

カジュアル面談何話してる?

台本(プレイブック)がある
その話で何を確認するか、という意図も書いてある

台本があることで、他の人がやっても再現性を持たせることができる

いくつかのプレイブックを用意してある
職種別(ML向けなど)や、1次面接向けなど

会社のフェーズを伝えることもある

事前に 10x について調べてきてくれている人がいるが
人によって小さい会社が好きとか大きい会社が好きとかある
なので、いまの雰囲気はこんな感じですとか伝えたりしている

Q&A

エンジニア向けのカジュアル面談でどんな話をしたら喜んでもらえるか?

喜んでもらえる話について
喜んでもらえる話について

開発の進め方とか盛り上がることが多い。
10x よりもフェーズが進んでいる会社とかだと、どういう課題があったんですか?とか聞いたりする

アーキテクチャの話をすると盛り上がる
エンジニアなので、なんでこうしたの?とかが気になる人が多い
ただ、こういう話は面接に近くなってしまうが、評価のようなことはしないようにしている

カルチャーフィット・ヒューマンスキルフィットはどんな観点でどのくらい重要視している?

10x の中でガイドラインのようなものがある
カジュアル面談ではそれを満たしているかはみないが、面接だとみるようにしている

面接のような判定はしないが、話をしていてマッチしそうだな、盛り上がるなと思ったりはする。

ただマッチするなと思ったら、次はこの人と話してほしいので時間くださいとか、おし気味になったりはする

流入経路は?

Findy さんが多い
meety やリファラルもある

実施する上で心掛けていることは?

お互いの目的が合致しているか確認すること。
10x を好きになってほしい。
いいことばっかりじゃないけど、自分たちはこうしていきたいということを伝えるようにしている

話す割合は7:3くらいにしましょうとプレイブックにもあって、相手も話も聞くようにしようと気を付けている

説明資料の更新頻度や、面談の質向上はどうしてる?

社内の組織で大きな変更があったりしたときなど、デザイナーの方が気付いてやってくれている

失敗経験やアンチパターンは?

たまに盛り上がらないカジュ面がある
終わったら振り返りメモを残すようにしている。
メモを書いているときに失敗したなと思うが、そのあと応募してくれたりするので、実は失敗してなかったりする。
そのときその人がそういう雰囲気だっただけとかなので、あまり失敗したとか思わないようにしている

逆に盛り上がりすぎるときがある
10x の話をあまりしてなくて、仲良くなっただけみたいな。

カジュ面と面接で意識的に変えているところは?

絶対にカジュアル面談では評価をしない
面接のときは、こういう回答がくるかもとか想定をたてたりしているが
カジュアル面談ではあまり準備はしていない。

カジュアル面談によって志望度があがったパターンはどんなものだった?

正直受けた人に聞いてみなと分からないので、今後カジュアル面談を受けた人に聞いたほうがいいなと思った
人事の方が最初にコンタクト取るが、相手にあわせたカジュアル面談を組み立てるようにしたりはしている(職種やロールがあった人が話すとか)

社内でカジュアル面談を受けて入社した方がいるが、bizdev の方と話をして、他部署からの期待値のようなものがわかってモチベーションが上がったことがった。
なのでエンジニアだけじゃなく、他部署の人と話すといい場合があるかもしれない。

人事の方に技術的な内容を事前に話しておいてほしいとかありますか?

特になくて、先行フローとか、制度のこととか話しておいてほしいと思っている

技術的な話はエンジニアがしたほうがいいと思っている。

(運営より)技術的な話はしない(中途半端なことは言わない)ようにしている

カジュアル面談では年収や福利厚生についてどこまで話せますか?

なんでも話せます。
入社したときのグレードがどれになるとかは分からないので話せないが、社内のグレードのルールとかあるのでそれは話せる。

鉄板ネタは?

現地行くとかの話は、「へぇそうなんですね」という反応をもらえたりする
出身のスーパーの話とか盛り上がったりする

相手から「うわ、カジュ面で面接的なことされてる」って思われないように工夫していることはありますか?

事前にここは評価の場ではないですよと伝えるようにしている

テンションとかでカジュアルな雰囲気を出すようにしている

カジュアル面談前に面談者の情報をどこまで確認していますか?

面談者の情報をどこまで確認しているか
面談者の情報をどこまで確認しているか

結構みている
findy からきたら findy に書いてる経歴とか見たりしている

見れるものは一通り目を通すようにしている

自分がどのように働いているか想像できるようなカジュアル面談よさそう?

良さそう
10x では選考の最後にトライアルっていうフローがあって、1日一緒に働いてみるというのをやっている

他には、現在の社内の課題とか話すといいかもしれない。

感想

個人的に、カジュアル面談はなんとなくこういうもの、というイメージはあり

良い意味で具体的な決まりはないという自由度はあるものの

逆に各社ではどのようにやっているのか(自分の認識と違う部分があったり、工夫していることなどあるのか)と思い今回参加してみました。

思っているものと大きな認識の違いはなく

  • 面接ではない(評価は行わない)
  • お互いの認識に相違がないかの確認の場

という点は、カジュアル面談の共通認識なのだろうと思いました。

また

  • 盛り上がりすぎて会社のことを話す時間が短くなってしまった
  • 話す割合は 7:3 くらいにして相手の話も聞くようにする

などは活かせそうな tips だなと思いました。

 

イベント全体的に、登壇者の方がフランクな雰囲気で話をしてくれて、とても楽しいイベントでした。

 

TEST Study #2「ソフトウェアテストにおける自動化」に参加してきました

TEST Study #2「ソフトウェアテストにおける自動化」

https://forkwell.connpass.com/event/249851/

に参加してきたので、そのときのレポート

資料を見ながら口頭で説明していただいた部分のメモ

基調講演「ソフトウェアテスト自動化、一歩前へ」

オープニング
オープニング

ソフトウェアテストの自動化

ソフトウェアテストの自動化は広い意味を持っている
日頃どんな部分で関わっているかで、イメージするものが人によって違う
自分が認識している以外の部分も、色々な側面から見るのが大事

テストは領域に分けられて、自動化が適している領域がある

  • チェックの意味
    • 正しい結果を知っていて、その通りになること
  • テストの意味
    • 想定外のことを発見する

自動化が向いているのはチェック

テストピラミッド

ピラミッドでいうところの領域を確認し、その領域に適したツールで領域を絞ってテストすることで、効率よくテストができる

アイスクリームコーンのテスト

画像

効率が悪いので、なるべく避けるべきだと言われている。

他にもモデルはいくつかある

バグフィルター

画像

網目がバグのありかを表している。
Unit テストは網目が細かいが、まかないきれない範囲がある。
逆に下の層に行くほど、網目が大きいが、範囲が広くなる

学び

Unit テストどうしようか、E2E テストどうしようか。ということを考えてしまいがちだが、

全体を通してどうテストしていくかを考えることも大事。

一歩前に進める現実的なやり方

段階的に進める図
段階的に進める図

理想的には自動化したいが、現実的に整備されてなくて、進められない現実がある。

その場合は段階的に進めていくのが良い、という提案をすることがある。

今ある手動実行前提のテストをそのまま自動化しない

人が読む前提で書かれたケースがあるので、そういうのは機械に解釈させるのが難しい場合がある

視聴者Q&A / パネルトーク

Q1. テスト仕様書のようなものを書いた上でテスコードを書いているのですが、テストコードを書くならテスト仕様をドキュメントとして残すのは無駄に感じてしまいます。

テストコードを書く場合でもテスト仕様書は必要なものなのでしょうか?

A1. テスト仕様書を E2E でやっている前提だと捉えると、一概には言えないが、必要だと思う派。

テスト仕様書を残すと、全体としてどんなテストをしてどんな結果だったかを整理してみたい、という目的があったとして、それをするにはテストコードだけでは難しいところがある。
例えばテストコードが、バグのパターンを正しいと思って書いている場合がある。
そうするとプロダクトオーナーに仕様を聞くことになる。
テスト仕様書を書くとプロダクトオーナーの頭の中にある仕様書を表現することになる。


Q2. エンジニアが頑張りテストを充実化させていくことに限界を感じています。

組織を巻き込んでテストを根付かせる方法論をお聞きしてみたいです。

A2. 後半の組織の話になると、実はそれは私も知りたい。

これをやると組織に根付く、というものはない。
まずは、いま苦労しているものが楽になるイメージを持ってもらって、じゃあどうしようかみたいな建設的な会話ができたりする。
そういうソフトスキル面が大事かもしれない。


Q3. E2Eテストの自動化を一定進めたとして、テストピラミッドの形に移行するためにとるべき重要なアクション紹介いただけますでしょうか?

A3. アイスクリームコーンの上の部分を自動化したとして、その後の話だと思うが、その前提で話すと。

E2EテストでテストがNGだったものを洗い出し、それはE2Eテストじゃないといけないのか?ということを考える。
それはUnitテストだよねとか、見つけていったりする。


Q4. 自動テストが少ない既存のプロダクトに対して、自動テストを増やしていく際の人的リソースの配分におすすめの方法はありますか?

例えば専門のチームを組む(開発チーム全体に知識を共有するのが難しそう) or 既存の開発チームが〇%時間を割く(なかなか進まなさそう)など

A4. 難しい問題だと思います。

質問に答えている様子
質問に答えている様子

日頃自分は専門チームで自動化をするチームを組むことが多い。
テストのノウハウを教えるということはあまりない。
自分たちにテストを依頼する現場は切羽詰まっていることが多い。
なのでノウハウを伝える時間はないことが多い。
専門のチームを組むのが難しい場合があるが、専門者がいると進めやすいなと思うことは多い。
兼任でやると中途半端になることが多い。


Q5. 単体テスト、E2Eテストについてはある程度どういったテストを書けば良いのかはわかりやすいのですが、 結合テストについて、どういったテストケースを書けばいいのか悩んでしまいます

どういったテストケースが向いている、こういった観点で書いていけば良いなどありますでしょうか?

A5. まず結合テストとは?

会社によって結合テストでやっていることがバラバラな状態。
自分の中では、サブシステム間のテストと捉えている。
マイクロサービスなアーキテクチャだと、責務が分離されているので分かりやすいが、
結合テストをやりたい部分で何をテストすべきか?が分かりづらいから結合テストが難しいのだと思う。
テストを書く前にリファクタリングできると良いかもしれない。


Q6.協力会社がテストを書かない、かつ自分のチームにテストを書く文化がない状態で、何から始めるのが良いでしょうか…?

A6. ちゃんと契約書に書くとかになってくるが、この問題がある状態というのが、納品されたものに問題がある状態だと思う。

なので、テストを用意してそれがパスしたものだけ納品する、という形もあるとは思う。(幸せになりづらいが)
協力会社に書いてと言って失敗したことがあって、現状テストできるように設計していないので設計しなおす料金はどうするという話になってしまった。
テストがない状態というのは、テストのメリットを分かっていないのかもしれない。


Q7. 自動化の過渡期について チーム内の単体テストを一部ツールで自動化し始めました。

しかし、そのツールの範囲外の部分は従来通りの手法(Excel)で実施することになってしまい、負担が増えてしまいます。 どんどんツールを使ってもらいたい一方で、負担はあまりかけられない、この過渡期を乗り切るポイントが知りたいです。

A7. 現場を度外視した外側からの意見だけでいうと、ツールに問題があるかもしれない。

ツールを変える選択肢もあるが、現実的に変えられないこともある。
過渡期を超える上で、あとどのくらいで過渡期を超えられるというゴールをチームで持って、そこまで頑張るとかかもしれない。


Q8. 自動化によるコストをどう回収できるか、どう判断したら良いでしょうか?

A8. 開発費を含めた経費を計算することだと思う。

また、インシデントをどう防ぐかという話をすると、コストとかじゃなくてやるしかないという話になる。

クロージング
クロージング

参加して個人的感想

  • テストの自動化は、サービスの規模が大きくなってくると途中からやるのはとても大変なので、最初からある程度設計していたほうが良さそう。
    • そうもいかないのが世の常かもしれないが。。
  • 途中から自動化する際は、最初から全部を理想系にするのではなく、部分的かつ段階的に進めていくのが良いのというのは、テストもそうだし、いろいろなことに当てはまりそう。
  • チェックとテストの意味の違いは、なるほどと思った
    • 言葉の定義がどうというよりは、そういうふうに分けて考えるとイメージしやすいよなと思った。
  • テスト自動化を当たり前のように取り入れている環境もあれば、そうではなくまず受け入れられなけばならない環境もあり、組織や文化も関係している。
  • 経営目線の人にテストについて理解してもらう際は、開発が楽になるという話よりは、コストを減らすことができますという会話のほうが、相手にも理解してもらいやすそう。

WordPressのパーマリンク設定

WordPress のパーマリンクを

https://example.com/sample-post/

という形にしたときに上手くいかなかった原因を解消したので、そのメモです。

ちなみに上記のような形を “Pretty パーマリンク” と呼び、

https://example.com/?p=N のような形を “Ugly” と呼びます。

 

解消方法の答えは公式ドキュメントに記載されています

パーマリンクの使い方

FollowSymLinksとAllowOverrideを設定しなければいけない

  • Options FollowSymLinks

  • AllowOverride All

この 2 つが設定されていなければいけません。

apache の .conf ファイルか、Wordpress がインストールされているディレクトリの .htaccess 等に上記を記載しなければなりません。

.conf ファイルを編集する際は、80 番ポートや 443 番ポートを間違えないように。

また、.conf ファイルを編集したら、apache の restart か reload を忘れないように。

.htaccess を編集する際は、後述しますが WordPress が書き込みを行う範囲外に記載しなければいけません。

.htaccess ファイルが存在しなければならない

WordPress の管理画面で Pretty パーマリンクを選択して保存すると

WordPress は .htaccess に書き込みを行います。

そのため、.htaccess が存在していなければなりません。

存在しない場合は WordPress が作成を試みるようですが、うまく行かない場合は自分で作成しましょう。

.htaccess の書き込み権限を WordPress が持っていなければならない

.htaccess に WordPress が書き込みを行うので、権限を持たなければなりません。

WordPress が書き込みを正しく行えなかった場合には下記のような内容が表示がされます。

chown apache:apache .htaccess
chmod 644 .htaccess

としてあげれば良さそうです。

FollowSymLinksとAllowOverrideを.htaccessに記載する際は、上書きされない場所に記載する

上記で説明したように、Wordpress は .htaccess に書き込みを行います。

.htaccess に記載を行う場合は

# BEGIN WordPress
・・・
# END WordPress

の外側に記載しましょう。

内側に記載してしまうと、上書きされて記載した内容が消えてしまいます。

生活習慣はメリハリと切り替えが大事

コロナ禍で基本家で過ごすようになり

なんだか単調な生活にマンネリしてしまっているということはないでしょうか。

 

私も平日と休日の区別があまりつかなくなり

毎日家で過ごしていてもスッキリしない感が強くなってきました。

そんな中、ふと生活習慣を見直して工夫してみたら、少し改善できたのでその話です。

仕事とプライベートを切り替えるときに何か行動を挟む

私は、在宅ワークになり

朝起きて、そのまま家で仕事をして、仕事が終わったら家で過ごして、、、

という状態で、何か気持ちの切り替えができず

仕事が終わっても何かスッキリしないということがありました。

 

通勤していたときはあまりこのようなことはなかったのですが、

在宅ワークになってからこのようなことがよく起こっていました。

 

何が違うのかと考えたのですが、

おそらく「特定の行動をすることによって気持ちを切り替える」という機会がなくなってしまったのかもしれないと思いました。

通勤していたときは

  • 朝家を出て電車に乗って通勤して、仕事をする気持ちに切り替える
  • 仕事が終わったら帰る準備をして、電車に乗って帰り、プライベートな気持ちに切り替える

ということが自然にできていた気がしますが

在宅ワークになってシームレスに仕事とプライベートが切り替わるので

気持ちの切り替えが追いついていないと感じました。

 

そこで、私は生活に

  • 仕事に取り掛かる前に、朝散歩をして、帰ってきたら仕事の気持ちに切り替える
  • 仕事が終わったらジョギングをして、熱い湯につかり、その後プライベートなことをする

という「気持ちを切り替えるタイミング」を取り入れました。

 

案外これがうまくいっていて、気持ちの切り替えができています。

「気持ちを切り替えるタイミングでとる行動」は「何も考えないこと」

が良いようにも感じています。

ネットの記事を見ましたが、瞑想もよさそうですね。

平日と休日でやることを変える

平日も休日も家で過ごしていて、代わり映えのない単調な生活に

なかなかリフレッシュできていない人はいるのではないでしょうか。

さきほどは「1日の間の気持ちの切り替え」の話をしましたが

「1週間の間の気持ちの切り替え」も大事だと思います。

休みの日は休みの気持ちでゆっくり過ごす・楽しめる必要が私にはありました。

 

休みの気持ちに切り替えるには、「1日の行動パターン」や環境を

平日と休日で変えると良いかもしれません。

例えば私は

  • 休日は朝に近くのカフェにコーヒーをテイクアウトしにいく
  • 休日は部屋で音楽を大きめの音量で流しながら過ごす
  • 休日のご飯は近くの店にテイクアウトしに行く
  • 平日は夜にジョギングをするが、休日は昼にジョギングをする

など、平日ではやらない行動を休日は取るようにしています。

 

こうすることで、「今日は休日なんだ」と強く実感できている気がします。

 

他にも、コロナ禍でリフレッシュする個人的方法まとめを書きましたので

そちらもご覧いただけると嬉しいです。

コロナ禍でリフレッシュする個人的方法まとめ

Laravel-adminのformでリレーションデータをdisplayする方法

Laravel-admin の form メソッド内で、リレーションした Model のデータを表示する方法です。

今回のケースでは、記事編集者の情報は admin_users テーブルに

記事の情報は articles テーブルにあり、articles テーブルに admin_user_id カラムがある状態です。

そこで、form メソッドで記事編集者の名前を表示したいという想定です。

まずは、Article モデルと AdminUser モデルを作成します。

次に、Article モデルにリレーションを定義します。

public function admin_user()
{
    return $this->hasOne(AdminUser::class, 'id', admin_user_id');
}

form では、Article クラスを引数に form インスタンスを生成し、

display メソッドの第一引数に、リレーションのメソッドとドットでカラムをつなぎます

protected function form()
{
    $form = new Form(new Article());

    $form->display('admin_user.username', __('記事編集者'));

    return $form;
}

これで、記事の編集画面に記事編集者の表示ができます。