00:04
はい、3月31日、金曜日ですね。遅刻は朝9時を回りました。
一通りちょっと朝バタバタしてですね、会社遅れてしまって申し訳ないです。
はい、おはようございます。mimeiのkeethこと桑原です。
ではでは、本日も朝活を始めていきたいと思います。
寝起きした朝なので喉の調子が良くないんですけども、ご容赦いただければ幸いです。
じゃあ今日はですね、ちょっと長い記事になりますけど、タイトルに入れます。
というわけで、まあ単純に言うと、技術不採って言うのをやめましょうという記事だそうですね。
なかなか面白そうだなと思ったので、読んでみようと思います。
なかなか技術不採、技術的不採とかいろんな言い方がありますけども、
これをまずそういう言い方をするのをやめようという、なかなか面白いなという視点ですね。
この記者の方もそういう問題に何度も何度も打ち当たったっていうのはあると思うんですけど、
それを根本的に解決するにはもうあれですね、
技術と向き合うとか現場と向き合うというよりも、
それを俯瞰した目線の方の視点から言うのが必要だったのかもしれないので、
ちょっとその話を読んでみようと思います。
この機能は3週間前にリリースする予定でした。
ある開発者はフレームワークのアップデートに巻き込まれ、
別の開発者は機能フラグの再編成に手間取りました。
3人目はデータベースの変更を開始するために長い間放置されていたリポジトリをスプランカーする必要がありました。
チームは水面下で動いている技術的不採から抜け出すために、
数週間ができるまで全ての機能リリースがこのような状態になるでしょうと、
ビジネスがそれを考慮するように仕向ける方法さえも私たちには見当がつきません。
こんな言葉に聞き込みはありませんでしょうか。
とてもがっかりするような会話ですね。
しかし私たちはしばしばこのような状況に陥る措置というのか予知がありますよと、
それはどんなようにというところですけれども、
私たちはビジネスパーソン、デザイナー、プロダクトマネージャー、そしてエンジニアを
技術的不採という言葉で同じページに引き込もうとしています。
しかしこの言葉は私たちは全く異なる立場に追いやるものですと。
技術職の人に技術的不採という言葉を聞いたことあるかどうか尋ねると、
まあそりゃそうだよねみたいなため息をつく人がまた多いでしょうと。
ではその意味を聞いてみましょうと。
これを10回繰り返してください。
要は10パターンいろんな人に聞いてみてくださいと。
そうすると何通りの答えが返ってくるでしょうか。
3つ4つ7つみたいな。
実は技術的不採という言葉はみんな意味するところが実は違いますよというところですね。
なるほど。
その視点からいくのか。
しかしその感情がどこからくるのか正確にはわかっていないんです。
だから自分を悩ませたり怖がらせたりする者にはこの言葉を当てはめてしまうんですよと。
まあまあわかりやすい言葉ですもんね。
わかりやすいけどタギ語的な感じですね。
デザイナーは自分たちが計画した通りのデザインにならないと言います。
製品担当者は3週間も損をして何の機能も得られないという風になります。
エンジニアは?と言いますと答えは様々ですけど悪い行動について何か言っていることが大体多いよねという話をしています。
03:00
技術的不採イコール悪い行動がなぜこれほどまでに災いをもたらすのかについてまた後ほど説明するとして
まずは同じ言葉を大勢の人が違うように定義することの影響に対処する必要がありますよね。
技術的不採という言葉を口にした途端誰もが騒ぐか誰も耳を貸さないということです。
それぞれの会話は私たちが何を言っているのかわからないと思い込んでいますがそれぞれのイメージはかなり違っています。
エンジニアが3週間機能をリリースする義務を免除してほしいと頼んでいるように企業側には聞こえます。
まあそうね。
彼らは前回その3週間を許可したときに1ヶ月以内にチームが再び水面下に沈んだことを思い出しています。
ビジネスパーソンが技術的不採習慣を認めたがらないのは
前回の技術的不採習慣でそのチームの能力が0%しか向上しなかったことを自分の目で見たからではある。
もしその過程に立つのであれば次の習慣を心よく認めることはできるでしょうかというとまあまあしないでしょうねということですね。
私たちエンジニアは自分たちの用語を吟味しなければなりません。
そして技術的不採という言葉が何を見せるのかを分析することでその用語を見つけることができます。
何か言ってしまうとコミュニケーション不足というか認識のそごが起き続けているだけの意味すぎないなという感じがしますね。
何かその根拠だったりとか何でそう例えばその習慣欲しいのかみたいなところの
本質的な理由を多分そのいろんな担当者とかいろんなキャップをかぶっている人たちに理解をしてもらっていないだけな気はしますけど
理解してもらうエネルギーとかコスト時間も取れるぐらい取れないぐらい
ひっ迫しているのであればもうどうしようもない気はしますけどね。
とはいえちゃんと説明できるようにいろんなものをドキュメンテーション起こしておくってすごく大事かなっていうふうに思いました。
これは実際でも自分が課長に入るとそうはできなかったりするんですよね。
本当に難しくてですね。
だからやっぱりプロジェクトのスタートの時点でそういうルールにするとかそういうチームにしていくとかじゃないと
習慣をしていかなきゃいけないのでやっぱりエンジニアに大事なのはコミュニケーションとドキュメンテーションの文化じゃないかっていう気はしますけどね。
その上で技術力が乗っかるのが現場としてはいいとは思ったりしますが。
続いていきましょう。
今のが一応前置き的な話でした。
続いて第一説に入りますけど
The dead is more than just bad codeだと言っています。
技術的不採とは単に悪いコードの話ではないよという話ですね。
技術的不採と悪いコードを同列に扱うと私たちは罠にはまることになります。
先代の開発者は仕事ができなかっただけだと思い込んでしまうんです。
これは無慈悲なことですけど私たちが知らなかった制約があったことに気づくまではいいんですけど実はそうじゃないよと。
この制約がこのコードの憎むべき特性を説明しまた私たちが天才的な解決策を講じることも拒むんですよと。
私はかつて顧客情報には2つの異なるテーブルから引き出すクエリが必要だと再現なく文句を言うチームで仕事をしたことがあります。
06:06
そのチームは惰性でこの構造が残っているあるいはデータベース構造を変更すると広報互換性が損なわれるからだと思い込んでいました。
大事ですね。思い込んでいましたっていうふうにちゃんと振り返られてるってことですね。
データベース設計を見直し修正する方法を考え無視できない時間を費やした後チームは自分たちの計画が違法であることを知りました。
違法と訳されてるけど本当かこれ。まあまあいいやとりあえずそういうことを表現になったんです。
この業界ではプライバシー保護の観点から個人を特定する2つのデータを同じテーブルに保存することは違法なのか。
ああそれは違法ですね。
幸いなことにエンジニアリングチームが大きく前進する前にプロダクトマネージャーがたまたま会社の弁護士にこの状況を伝えたんですけど
そうでなければコンプライアンス上の問題が露呈していたかもしれません。
たまたまだとしたら本当にやばい環境だったんですね。
技術的不採と悪い行動を同列に扱うと十分な行動をかけば技術的不採を抱えることはないと思い込んでしまいます。
だから技術的不採をなくすために時間を費やすことはないんですよと。
この行動を見直したり文書化したりテストしたりする必要もないです。
私たちはまた最初の場所に戻ってきました。
まあまあまあ一周回って帰ってくるみたいな話はよくあることですねこれは。
技術的不採と悪い行動を同列に扱うとこの行動は私の個人的な好みに合わないとかこの行動は問題だと混同してしまうことになります。
技術的不採週間では実際に何かを修正するのではなく自分の好きなリファクタリングを行うことになります。
技術的不採週間というのはエンジニアが個人的なバグを追い求めるのに適しているからです。
しかしそのようなバグが行動の最も緊急なメンテナンスの課題と交差することはほとんどありません。
そのため各エンジニアが4人一組でリファクタリングに励むと行動は以前より作業しやすくなるということもありません。
なかなかファンタスティックですねと言っています。
ちなみに注釈もありません。
3週間かけて技術的不採を返済してもその週が終わった後チームのベロシティにはほとんど何の役にも立たないことが多いのはこれが大きな原因です。
技術的不採を解消したところでベロシティ上がらないはよくある話ですね。
本質的なちゃんと不採返済になっているかというところだと思うんですけど。
とはいえそのベロシティ上げるだけが正義というのは別わけではないと思います。
本当に問題があったりとか今みたいな違法みな行動が実は組み込まれていたりとかっていうのがあるのであればやっぱり返済したほうがいいし
不採によって今やっている今後の追加開発とか改修とかいろんなやりたいことを実現のためにめちゃくちゃ工数かかってしまう。
今のアーキテクトとか設計のせいで時間がかかってしまうのであれば先に取り除いて後でそういうかかる、失う時間、使う時間を減らすっていう風に行くのだったらいいと思うんですよね。
09:02
それが今普段の業務の中でベロシティと評価されるのであればそれはやっていいと思いますので。
何を改善するかっていうのはちゃんと話した上でやったほうがいいと思いますね。
でもベロシティが出ない場合は大体大きな原因はこんなとこですよって話をしてました。
このような問題を解決するにはシステムの品質を評価するために何か測定可能なものを選びます。
私のおすすめはメンテナンス負荷だと言っています。
開発者が機能の追加や削除ではないタスクにどれだけの時間と労力を費やしているのか。
この数値についてはエンジニアリングチーム以外の人たちにも相談することができます。
もし6人の開発者がいても仕事の半分がメンテナンス作業だとしたら機能計画では3人の開発者しか想定できません。
ビジネスパーソンはエンジニアを高価なものと考えているのでこのフレームを使うことでメンテナンスの負担を減らすことに協力する気になります。
またこの数字を追跡して時間の経過とともにどれくらいのスピードで増えていくかを判断することになります。
メンテナンス負荷の増大が早ければ早いほどより多くのフラストレーションが予想されます。
ゼロ成長とはエンジニアチームの割合が同じであれば常にシステムを維持できるということを意味します。
なるほどね。
ビジネスパーソンはエンジニアを高価なものと考えているのでこのフレームを使うことでメンテナンスの負荷を減らすことに協力する気になります。
ところがここにGPDが出てきているので今後エンジニアの単価はどうなるのかは不安です。
逆にエンジニアの単価が上がるかもしれない。
超高速でかつ品質が高いのをどんどんエンジニアが出すようになったので、今までのエンジニアが急にクオリティが上がりまくってきて単価が上がるかもしれない。
要はそれで早くビジネスの展開ができて、いわゆる儲かるということですね。
儲かったのならばエンジニアの単価を上げたいよね。
次はリクライミング・ユア・タイムですね。
自分の時間を取り戻すということですね。
メンテナンス負荷の増大を最小限に抑えるにはどうすればよいでしょうか。
次はコードスチュワードシップの実践です。
本文ではグッドコードスチュワードシッププラクティスと書いています。
ちなみにこれは別の記事のリンクが貼られています。
11分くらいの長い記事なんですけど、これはちょっと面白そうなので、明日はこれを読もうかなと思います。
私たちはその機能開発スキルのようにコードスチュワードシップに報酬を与え認識し教えることはほとんどありません。
これは前提の話をしているので、僕がこれを読んでいないからちょっとわからないんですけど、ご了承いただければ。
しかし、コードスチュワードシップのスキル、いわゆるシステムを文書化し、コードからコンテキストを復元し、将来の変更に備えて計算することをコードスチュワードシップのスキルだと言っています。
12:08
10年以上にあたって順調なチームとコードの破産宣言と書き換えとか絶望を繰り返すチームの違いを生んでくれる。
これらのスキルを使うとそういうことができる。
聖杯とはメンテナンス負荷の増加を抑制することでコードのメンテナンス性を向上させることになります。
聖杯は健全な日常的なコード管理ルーチンよりもさらに多くのことをチームに要求します。
それは個々のメンテナンスタスクを見てその根源を追跡し、ソースでそれらの問題に対処することを要求します。
経験的に裏打ちされたこれらの作業は技術的夫妻に関する会議で議論するための具体的な材料を与えてくれています。
今私たちは定型的なライブラリやフレームワークのアップデートをたくさん行っているでしょうか。
そのような作業を行う時間を定期的に確保する必要があるのではないでしょうか。
これらのアップデートが積み重ねるほど異なるライブラリのリリース間の相互作用のデバッグが難しくなります。
そしてプログラマーがアップデートを行わないほど練習不足になり
アップデートが必須となる最後の瞬間にアップデートをより難しく、より苦痛なものにしてしまうということで
ちゃんと使うライブラリやメインフレームワークの更新、アップデートはちゃんと追って
自分たちの作っているシステムやアプリにも組み込みましょうという話ですね。
これは本当に良い話で、マイナーとかパッチバージョンであれば
普通にいろんなリノベートとかもありますし、いろんな自動化ツールで勝手にプルリクを出してもらって
それを回しするという流れでも全然良いと思うんですよね。
勝手にマージするのは結構ですけど、中身をちゃんとメンバーが把握しておくのはすごく大事なことですよね。
依存する限りはその依存するものの変化っていうのをちゃんと追っておかないといけないということですよね。
いやーなんか痛い言葉でした。
僕もそれあんまちゃんと癖つけられてないなっていうのはこれを読んでてちょっと反省する次第ですね。
ありがとうございます。
弊社の方にお礼を言いたい感じですね。
ではデータを続けます。
私たちは見捨てられたリポジトリに手を伸ばし、どのように変更を加えるかを考えているでしょうか。
もしかしたらそのリポジトリがどのように機能するかについて情報を取り戻すことに労力を探す必要があるかもしれません。
重要なチームメンバーが去った後、開発が難しくなるのはよくあることで、その理由は彼らが重要な情報をたくさん知っていたにも関わらず
それがどこにも書かれていなかったり、整理されていなかったりということがわかったからです。
やっぱりドキュメンテーション大事ですね。
私はこれをコンテキストロスと呼んでいますが、
このような事態を乗り越えて初めてコードベースの保守性というのがわかるんですよと。
このような事態が発生した場合、開発者はコードベースの見慣れない部分が暗くて怖いものになる前に
チームの共有知識に対するダメージを積極的に評価し修復する必要があります。
みんなが同じような知識とか、この開発プロジェクトを進める上でこの知識はみんなが持っておかないといけないよねっていう
15:02
情報の差が出てくる気がしますね。そういう意味でいくと。
そうすると見方とか感じ方、評価も変わってくるんですよね。
というのもあるのでコンテキストロスはなるべく避けたいですよね。
私たちはもはや真実ではないドメインに関する過程に基づいて、
過去に選択したアーキテクチャの周りで常に作業しているんでしょうか。
そのアーキテクチャを再構築するためのチケットを作成し優先順位をつける必要があるかもしれません。
レジリエントな行動設計というのはチームが将来どのような種類の変更を行うと予想しているかを考慮し、
その部分に柔軟性を割り当てるものです。未来を予測する作業と同様に時には間違うこともあります。
そのような場合は設計を変更する必要があるかもしれません。その場合は専用の取り組みが必要になるかもしれません。
このような雑用はどのようにして特定し優先順位をつければよいのでしょうか。
しかし技術的不採という一元的にそびえ立つ雷雲ではなく、
特定の作業という単位でメンテナンスの負荷に注目することでより良い対処を始めることができるんですよ。
この記事はすごく長いと言ったんですけど、記事自体は実はもう終わっちゃいますね。
なので、俺走り切りますね。
この後に他の記事のレイティというところと、あとはひたすらコメントですね。
41件のコメントがずわーっと連なっているから結構スクロールバーが長かったんですけど。
コメントはさすがに読まないんですけど、記事自体を走り切りたいと思います。
じゃあラストですね。
私たちは機能開発がスムーズで楽に感じられることを望んでいます。
メンテナンス作業を先延ばしにすればするほど、機能開発はスムーズで楽なものではなくなります。
このようなタスクを技術的不採という名の敷物の下で一層し、
時折まとめて対処する時間を求めるのではなく、
システムのどのような特定の要素から機能開発が長引かせているかというのも追跡し、
必要な開発者の労力の量という観点から評価をし、
開発者の能力にとって魅力ある結果を出す個々のタスクとして官僚交渉できるのです。
もはや不透明で不確実なコストとして枠にはてはめることはないのです。
その代わり、インパクトのある機能を生み出すための明確な範囲での投資という位置づけにするのです。
はいはいはい。いいですね。
この会話によって人々は同じ考えを持つようになります。
またその可能性も高まりますので3つ挙げられています。
エンジニアがメンテナンス作業に特定の時間を避けるようになります。
またエンジニアはメンテナンス作業をすることで評価されることもあります。
この補修作業は機能開発が遅くなった本当の理由の中から選ばれたものであり、
将来的に機能開発の経験を向上させるものです。
ちゃんとビジネスのことも踏まえた観点でのお話です。
そうすれば技術的負債についての会話は悲観的なものではなくなり、
希望的なものになるかもしれません。
この記事はシミュラルでおりました。
いかがだったでしょうか。ものすごく僕は共感を得た記事でしたね。
技術的負債って確かに言うのは良くないし、負債で当て込めというよりはこれ
もっと言うと問題の先送りと言ってもいいかもしれないですね。
18:00
これやらなきゃいけない。見なきゃいけないものなんだけど、
今はこっちの方が優先だったり、今はそこにやってるコースがないよっていう話ですよね。
でもそれなんか暗黙的に負債っていうか、
そういうソースコードとか設計の問題点を対処するよりも、
機能開発の方が優先だよねってなんとなくみんな思い込んでる節があると思っていて、
でもこれも今作っているシステムとして品質の話に関わったりとか、
ビジネスのインパクトに関わっているので、
どっちかというとこっちの方が優先じゃないって思う時もありますよね。
っていう考えでいくと、やっぱり負債というラベルを付けて後回しにするのではなくて、
ちゃんと日々の作業の中に組み込むように説得をするとか、
物事を進めるようなチームづくりとか、
いろんなエンジニア以外の人たちへのコミュニケーションをしっかりとっていくってすごく大事なことだと思いました。
そういうことをしていかないと、今後どのプロジェクトをやっても、
エンジニアが言う技術的要塞とかリファクタリングっていう話は、
ビジネス的にインパクト生まないじゃんっていうふうに思いはれてしまっているので、
だから後で後回しになるし、後でコースくれって言ってもくれないよねって話になると思うので、
そもそも生まないコードを書くっていうのはすごく大事なことだともちろん思います。
予防線を張るのはすごく大事なことではあるんですけど、
結果生まれてしまうのは仕方ないです。
使っているツールとか技術っていうのは、
生み出された瞬間から不細化スタートするんですよね。
どのフレームワーク、ライブラリーも一緒ですこれは。
システムも一緒ですね。
生み出したところからスタートですね。
運用スタートのところから不細化スタートということでセットになるので、
必ずこの問題と向き合わなきゃいけない。
そうなると日々そういうのと向き合っていくっていうのを、
ちゃんとチームのサイクルに組み込まないといけないんだっていうことを、
この記者の方は言ってるんじゃないかなと思いました。
とはいえ、それはエンジニア目線の視点かもしれないので、
ちゃんといろんな人たちへの説得材料として理由をしっかり言語化していく。
それをまた説明できるようにドキュメンテーションを起こすのがすごく大事だとつくづくました。
これはもう何か完全に技術者というかビジネスマンの観点ですね。
ビジネスとしての技術者としての何ですか。
知見ではないけどやることみたいなところの記事だったと思います。
でもこれは完全に技術記事でもあると僕は思いましたので、
これはぜひ全エンジニアの皆さん読んでほしいなと思いました。
とても素晴らしいと僕は思いましたけどね。
いかがだったでしょうか。
というところで時間も30分過ぎましたし、
今日の朝方はここで終了したいと思います。
金曜日プラス3月31日でごろで、
今日は月末ですね。締めというところで。
しっかりいろんなものを整理して片付けて締めていきたいなと思いますので、
今日も一日皆さん頑張っていきたいなと思います。
今日もまたwebには見えないんですけど、
おそらく参加されているだろう。スーさんですかね。
ご参加いただきありがとうございます。
じゃあこれで終了したいと思います。
お疲れ様でした。
