青空な日々

ITエンジニア関連で興味あることをアウトプットして共有したいブログ

【後編】ソフトウェアレビューシンポジウム JaSST Review'18の感想

はじめに

2018年12月14日(金)にJaSSTが開催するJaSST Review'18に参加してきました!
この記事はその感想の後編になります。

まだ前編をみていない方はこちらからどうぞ。

【前編】ソフトウェアレビューシンポジウム JaSST Review'18の感想 - 青空な日々


前提条件

シンポジウム中にメモした内容と、
ここがよかったなぁと思ったことを書いています。
結構な量をメモしたので長いです…。
目次から気になるところだけどうぞ。

目次

感想

アーキテクチャのレビューについて 鈴木雄介さん

アーキテクチャ設計におけるレビューのについて。
資料はこちら。

www.slideshare.net


アーキテクチャとは

ISOにも定義がある。
コンポーネントの連携の指針。
システム構成とも言い換えられる。
クラスやメソッド分割もアーキテクチャの一範囲。
レベルが違うだけ。
将来性も含めて考える必要がある。

アーキテクチャの役割

現代はさまざまなライブラリや既存製品がある。
それらを組み合わせてシステムを構築する時代。
その分割や統合の方針が重要となる。
さらにそこにライフサイクルの話も入ってくる。

そこでアーキテクチャが(さらに)重要になる!

良いアーキテクチャとは何か?
機能ではなく非機能で考える。

非機能(セキュリティや可用性)をアーキテクチャで保証する。
切り替えや入れ替えなど。

アーキテクチャ設計中のレビューについて。

アーキテクチャの良し悪し判断は工程の後半では間に合わない。
すでにシステムが組み上がってからアーキテクチャの入れ替えなどは土台無理な話。

だから、アーキテクチャの設計中、
具体的には非機能要件の定義と、システム構成の評価時に行う。

非機能要件の定義。
経産省IPAにテンプレートがある。

非機能要件の注意点。
要件定義にあいまいな表現で非機能要件が書かれている場合がある。
「すぐに」「早く」「確実に」など。

  • すぐに=1時間いない?もっと早く?
  • 早く=ホットスタンバイして障害時は切り替える?
  • 確実に=どこまでなら確実?

など。

アーキテクチャ設計レビューの難しさ

  • アーキテクチャ設計は常に事前的
  • リスクと戦う(技術的リスク、システムの成長リスクなど詳しくは資料にて)

この事前的にという難しさは痛いほどよくわかる。
プログラマとしてはいわゆる「技術的負債」としてのしかかってくるので。
これは事前の作りが悪い場合もあれば、
上記にあるようにシステムの成長によって負債になってしまう場合もあると思う。

いま業務でもスマホアプリのアーキテクチャ改善に取り組んでいるので、
非常にわかりみが深いなぁと思って聞いていました。

まとめ

リスクと戦う際には信念がいる。
「〇〇さんが言っていたから」とか、
「仕様がこうなのでこうしました」とかじゃないよね、ということ。

非機能要件をすべて満たすことは難しい。
それぞれの非機能要件に矛盾がないことなどあり得ないので。
落としどころかが大事。
技術的オーバーキルではないのか。
いわゆるオーバースペックではないのか?ということ。

感想

組織によってはすでにあるアーキテクチャに従って開発することがある。
自分もそんな現場が多かったので、
あまりアーキテクチャについて考えことがありませんでした。
そのため、非常に刺激があって持ち帰りたいことが多いセッションとなりました。

具体的にはシステムの成長や事前ということの難しさ、非機能要件など。
ぜひチーム内で新しいアーキテクチャを考える際にこれらを念頭に置いて検討したいです。

パネルディスカッション

それぞれの登壇者のセッション後、
全員と風間さんの4人でパネルディスカッションが行われました。
各発表の共通点、相違点を話し合いたい。
また会場からの質問にも答えたい。

欠陥を見つける以外で重要だと思っているレビューの目的。

  • 白水さん
    リリース後に大きな問題にならないようにしたい。
    やはり現地に行くといろいろ大変なので、
    問題が起こっても影響範囲が最小限あるとか、
    マニュアルやリモートで対応できるような工夫をしていきたい。

  • 及部さん
    そのレビューがわくわくするかどうか
    レビューの後、メンバーがスッキリしているかどうか?

  • 鈴木さん
    参加者が成長できるようにしたい

  • 風間さん
    コミュニケーション
    教育

発表内容について

お互いの発表内容についての議論。
同じようなことをしている、私の場合は違う、という観点で。
(ほとんど発言者をメモし忘れました…)

  • 白水さんの発表にて、レビューの出席者が決まっていることについて(及部さん)
     お客さんや社長相手でもメンバーが適当なので、
     話を聞いて形式的に決めた方が良い気がしてきた。

  • モブプロでのリアルタイムでのフィードバック
     非常に良いと思う。

  • 遠慮や忖度しないで意見をいうことについて
     みんなの共通意見。

  • リスクに気づくのは経験に寄るところが多い
     経験や知識に依存する部分が多いのかなぁと思う
     暗黙知や属人化はある程度は仕方ないのではないか?
     100%なくせると思ってしまうのも、思い込みなのかも。

  • レビューやチェックリストなどの手段が目的になってしまうのはどうすれば?
     手段の活用の仕方が大事でいろいろ工夫している。
     (確か意識づけなどのだった気がする…)

レビュー観点と思考

レビューで発言したり、今後に生かす時の思考の流れを知りたい。

  • 白水さん

    • ひらめきや気付きで指摘するまで
      思いつきなので思考はあまりしてない
    • ユーザーから開発に持って帰る思考
      意識してやるということが大事、発表は理想論にしてみた
      最近起こったことをレビューで指摘することでフィードバックしている
  • 及部さん

    • 安心しない仕組み
      仕組みを利用してしまうと安心してしまって逆に品質が下がる場合がある
      もちろん仕組みも利用するが、アンチテーゼとして考える必要がある。
      上手くいかなかったメンバーに対して聞く、
      余裕でした!というメンバーに対して聞くということを気をつけている。
      人にフォーカスしたレビューは効果的かも。
      レビュイーが考えていないことを考えさせてあげる。
  • 白水さん ドキュメントというアウトプットで品質を確認する。
    記述が細かすぎるところ、大まかなところは怪しいので突っ込んでいく。

人かドキュメントかは違うけど改善点を探っていくのが大事。
モンキーテストのような形のレビュー、モンキーレビューみたいなのが効果ありそう。

指摘事項の優先順位

複数ある指摘事項の中で、暗黙の優先順位があるのではないか?
ですます調やタイポなどは後回し、不具合や致命的な欠陥などが優先のようなイメージ。

  • 鈴木さん
    レベルを決めて伝える。
    理想と落とし所と現在みたいな。
    理想ではこうだけどさすがにそこまでは厳しいからこの辺までにしようか。
    それに対して現実ではいまこうだよね〜の様な論調。
     
  • 白水さん
     基本的に全部伝えている。
     間違い(不具合など)は指摘だが、質問形式にした方が威圧的にならず良いのかなとも思う。
     そうやってよくしていくのがいいのかなと。

  • 及部さん
     全てチームに計って、チームで決めるようにしたい。
     経験が多い人が引っ張ることはあっても、
     経験が浅い人がそれに巻き込まれて成長できるようにしたい。
     チームの判断が個人の判断になるようになったら良いと思う。

レビューの正しい教育の仕方

この辺りから質問に答えていたはずです。
(記録していなかったので曖昧ですいません)

  • 及部さん
     やってみて学ぶしかないかなぁ

  • 白水さん
     体系だったレビューの仕方は本とかいろいろある。
     個人のスキルとしてはやってみるしかないのかなぁ。

  • 鈴木さん
     やるしかないのかなぁ。

みなさん同じ様な回答ですが、私も同意見でした。
まさに暗黙知暗黙知として渡すということだと思いますが、
レビューって対象や出席者などの環境に左右されるので一元的な解はないと思っています。

レビューの目的の達成度の確認方法

ここも発言者がメモ取れていなくてすいません…。

  • わかる範囲でやるしかないんじゃないか?
    無理に無意味な数字をとっても意味がないし…。

  • 安心感を得られればいいのではないか?
    チームでやって納得するとか、全員がある程度見たからOKなのだろうとか。

  • 定量的な数値でのレビュー評価に意味があるのか。
    やはり安心かなぁ。
    不安を共有するという安心感もあるかも。

レビューで偉い人がかき乱す

  • 及部さん
     レビューに参加させないように努力する。
     メリデメを比較してデメリットが大ければ黙らせる(参加させない)。

  • 鈴木さん
     根回ししておく。
     喋らせて満足させて終わりにする。

  • 白水さん
     事前に聞いておく。

最後に一言。

  • 白水さん
    今日は喋り過ぎてしまいました。
    喋りすぎたのは、最近社内でレビューに呼ばれてないからなのでは?w
    今後はもっと部下などの教育面に注力していきたい。
    QAとして、開発とも協力してやっていきたい。

  • 及部さん
    今日ここで得られたことで現場がよくなると良いな。
    なかなかレビューに関してがっつり考えたことないし、
    良い機会になったと思う。

  • 鈴木さん
    レビューって外から考えることだと思うので、
    レビューをみんなでレビューする機会になってよかったと思う。
    本当にこれで皆さんの現場がよくなれば良いなと思います。

感想

というわけで、遅くなった上にめっちゃ長くなりましたが、JaSST Reviewの感想でした。

参加する前はレビューという形式や方式を考える場だと思っていました。
しかし、参加してみると形式や方式ではなく、
人やチームにもフォーカスして考えていく必要があるのだと思いました。
例えば声音や表情からいろいろ探っていく、
暗黙知暗黙知として伝える、
レビュースキルの継承など。

これまでのレビューは、すれば良い、
なんとなく対象をみんなでチェックして、
いくつか指摘が出ればOK、品質が上がって良かったねという感じでいました。

これからは「レビューごとに本当にこれで大丈夫か?」ということを意識したり、
このレビューではどこまで品質を考えるのか?
目的はレビュー参加者に共有できているのか?(情報共有?品質向上?教育?リリース判定?)
レビュー参加者は全員納得しているか?モヤっとした部分はチーム内で共有できているか?
と、そういったあたりも気を配っていきたいと思います。

また、これだけやればOK!というものではないと思うので、
ここに上げたことに安心せず、より楽しくできるやり方、
チームでスッキリ終わるレビュー方法を模索していきたいと思います。

最後に宣伝を…。
note.mu


今年の冬コミ親方さんが主催した合同誌、
「ワンストップ見積もり」本に寄稿させていただきました!
私は第4章「2点見積もりと振り返りのススメ」を書きました。
他にも上流工程のいわゆる工数・金額的な見積もりから、
タスクレベルの見積もり、
そして見積もりに関する様々な人の事例やコラムが掲載されています!
必見です!!!

電子版もありますので、冬コミ行けない人も是非是非!
ごめんなさい、電子版は未定でした…。
よろしくお願いします〜!