00:04
はい、7月19日、火曜日ですね。 地獄の朝9時を回りました。
今日の東京は、あいにく曇りで、途中ライブになるらしいですね。
はい、おはようございます。めめめのけいすことふわふわです。
では、本日も朝活を始めていきたいと思います。
えーとですね、前回4…前回か、昨日ですね。
あ、もうすいません。完全にスポーカーしました。
なので、朝活1回スキップして、 今日もまたやっていきたいと思います。
えーとですね、前回から、タイトルにある通り、
ソフトエンジニアリング・ザ・ソフトパーツというところで、
まあ、Googleの、現実のGoogleクローンか、のシニアデベロッパーの方ですね。
が、中年間の経験値の中で得てきた身につけたというか、
あのー、ソフトスキルってところですね。
をまとめた記事を今、たーっと読んでいるところです。
で、前回どこまで言ったかと言いますと、
えーと、どこだっけ。
ビルディングストロングベース…じゃなくて、
トランスファラブルスキルズ、エフィシェンシー、
ベターディフィッションズメイキングまで言ったかな。
いや、違いますね。
フォーカスゾーン・ザ・ユーザー&レストウィルフォローズですね。
ユーザーにフォーカスを当てましょう、みたいなところまでは読んだ気がしますね。
はい、じゃあ今日は続きで、
えーと、アップグレーティングやスキルズだったと思いますので、
そこから入っていきたいと思います。はい。
はい、翻訳はいつもどおりしますので。
いや、ほんと長いなぁ。今日は今日でいきましょうかね。
えーっと、
熱っ。
はい。
えー、Kさんですね。
おはようございまーす。
今日も朝霞スタッフさんからいただきありがとうございます。
タイトルにある記事をダラダラ読んでいってます。
えーと、なんだっけ。
いわゆるエンジンやのソフトスキルズについての記事ですね。
お、続きを読んでいってる感じです。
はい、じゃあ今日はアップグレーティングやスキルズですね。
このアップグレードのためにってところからやっていきたいと思います。
今月の流行ではなく、また今日の流行ではなく、
あなたのユースケースに適したものを選びましょうと。
スキルの話ですね。
ハイプトレインではなく、つまらない技術、
まあ試行錯誤されたものを使ってもいいんですよと言ってます。
まあ僕らで言うところの枯れた技術みたいな言い方ですね。
この使ったほうがいいですよと言ってます。
言語であり、フレームワーク、ライブラリーはしばしば進化しています。
最終的に優れた製品を見出すのに役立つものを選びましょう。
新しいプロジェクトを始めるときは、
よく理解されている、まあウェルノーンな、
つまらない技術から始めて、
まあ意図的にその中から問題に最適なツールを選んでいきましょうと。
新しいスキルやスキルを学ぶときは、
退屈で話題になっていないものを選ぶことを忘れないでください。
言語、フレームワーク、ライブラリーやツールなど、
技術に関してフォーモは生産的でないかもしれません。
フォーモってなんですかね。
FOMOっていうのがあるんですね。
僕はこの省略をよく分かっていなかったんですけど、
03:01
後で送りますね。
何を使うかを知ることは重要ですけども、
あなたの主な目標は優れた最終製品を生み出すことです。
自分のソリューションに付加価値があると思えない限り、
新しい技術やピッカピカの技術を追いかけないようにしてください。
同時に話題にならないからといって、
敬遠するのもやめましょう。
新しい技術を学ぶために、
新しいプロジェクトを活用してください。
同時に個人プロジェクトやハッカソンプロジェクトというのは、
新しい技術を学ぶ絶好のチャンスになります。
多くの人が多くの決定がなされた既存のコードベースに取り組むのとは対照的に、
あったか新しいことを始める機会というのは結構減ってきています。
このようなプロジェクトは新しい技術を研究し、
その長所と短所を小規模ですけど、
評価し、将来あなたにとって価値のある知識を直接的に蓄積するリスクの低い方法となります。
これ本当そうですね。
業務じゃないところでやってみてください。
別に業務でやれるならやってもいいですけど、
業務でとか実際プロジェクトとしてやるんだったら、
必要なものとか最低限のものとか、
勢いよいビジネス的視点が入りますので、
そこじゃないところのキャッチアップをハッカソンでやったりとかでやってみるのがいいんじゃないかなという話ですね。
続いて、好奇心を持って学ぶことをやめないでください。
学んだことについてどんどん書きましょう。
そうすることでトピックをより深く理解することができます。
他人に説明することで、初めて自分の知識のギャップが明らかになることもあります。
誰もあなたの書いたものを読まなくても良いのです。
自分のためにやるだけで多くのものを得ることができます。
これはでも僕もいろんな方に言ってますね。
特に学生の方に言ってます。
学んだことについて、作業のノリでいいので、
未完成でも良いですし、何なら全然作らなくてもいいので、
どんどんアウトプットで書くことを結構学生には勧めてますね。
学習は継続的なプロセスであるべきです。
ある技術について何でも知っていると主張する人は、
専門家ではないことが多いのです。
本当の専門家はその技術に精通してはいますが、
常に学習と改善の余地があることも理解しています。
好奇心が学習を後押しする。
新しいフレームワークに興味を持ったら、
ググっとドキュメントを読み、チュートリアルを試して、
そうそう読んでみてください。
学習はいわゆる教室的なところで行う必要はありません。
いつでもどこでも学習することができます。
毎日30分、教科書の一章を読んだり、
テクノロジーのポッドキャストを聞いたり、
開発ブログを読んだり、
正しいプログラミング言語を学んだりすることができるのをテスト。
いわゆるプロジェクトのリーダー。
リーダーにとって、
自分が知らないことを認めることは大きな力になります。
この自信を持つことで、
シニアエンジニアは何でも知っていなければならない
という期待を低くすることができます。
全ての答えを知る必要はありませんが、
自分が人間になることを認め、
チームと一緒に問題解決する方法を考える姿勢が大切です。
これが良いお言葉だなと思いました。
リーダーだから、
いろんなことを知っていなければならないとか、
最終的にキャッチアップしなければならないことはないんです。
06:04
人間ですし、
若い子の方がどんな新しい技術をキャッチアップしていることが多いので、
逆にそうやって教えてもらう方がいいです。
メリットとデメリットがビジネス的なインパクトのために
決定ができるかどうかというところが
リーダーの本質的な立ち位置かなと思ったりしました。
またリーダーというのは、
自分が間違いを犯したとき、それをまず認めましょう。
謙虚な姿勢と学ぶ姿勢とか、改善しようとする意欲を持って、
間違いに対処する方法をチームに教えることが重要です。
現実の世界は完璧ではありませんし、
そのためにチームに完璧でないことを示すことは全く問題ありません。
続いて、オーナーではなくて管理人になりましょうと言ってますね。
オープンソースプロジェクトの初期段階では
オーナーのように考えるのが一般的です。
あなたはしばしば価値の証明であったり、
機能への取り組みであったり、問題への回答、
アドボカシーを直接自分のものにします。
これは何かを採用する際はいい方法ですけど、
後々スタッフの配置が変わったりとか、
自分の時間が制限されたりとか、
プロジェクトを拡張するためには最適な方法ではないかもしれないですよねと言ってます。
このような場合、自分の欲張りをオーナーから管理者に変えることもできます。
管理人は自分自身をスケールアウトさせることに集中します。
これは他のメンテナーや貢献者やコミュニティと
できるだけ多くの知識を共有することで実現できます。
例えばデザインドキュメントだったり、
コードとコメントだったりとか、
その他いろんな文章がされたベストプラクティスを通じてと言ってますね。
また、あなたが関与しなくなった時に
正しい判断が行われるように
十分な文脈を持ったレビュアのプールを増やしておくこともすごく重要です。
これはプロジェクトが何年も先まで持続可能になるために
何年たびたび必要とされることですよと言ってますね。
そうですね。
いわゆる引き継ぎと言ったら
もうちょっとマイナスなイメージがあるかもしれないですけど
いろんなOSFであろうとどうなろうと
引き継ぎ的なのが結構重要だったらしいですね。
その時は管理人として持っている知識をどんどん
みんなに共有していくというところですね。
バリバリ本コミットしたりとか改善をするメインの人たちに
オーナーシップを渡していくというのは本当にいい話だなと思いました。
続いてのセクションは
スキルの深さと広さですね。
Depth and breadth of skillsですね。
いきましょう。
万能で一芸に引い出た人が自分に向いているかどうかというのを考えましょう。
そういうパーソナルというか能力的なのが
自分にマッチしているかどうかというのは一回見直してみたらいいんじゃないかという話ですね。
あなたが習得できる最大のスキルの一つは学習方法を学ぶことですと言っています。
これは本当にその通りで何も言えないですね。
学習方法というそのものがスキルの一つなんですよ。
そのスキルなんですけどこの一つがめちゃくちゃ大きくて
これをしっかり把握したりとか身につけていることで
今後の学習のスピードが全然違いますからね。
09:02
学習方法というのを真っ先に学ぶことはむしろいいかもしれないですね。
これは例えば特定のプログラミング言語やフレームワークを深く学ぶことよりも
優先されるべきことだと言っています。
完全同意です。
好奇心を持ち続けることができるんです。
このような経験を積むとスペシャリストを目指すべきか
それでもなんでもや、いわゆるジェネラリストになるべきか
みたいな疑問が湧いてくるでしょう。
私は個人的にT字型のエンジニアという考え方が好きです。
これは一つ又は少数のスキルをT字の縦棒の深い専門でありながら
製品の構築と運用に必要な他の多くのスキル
横棒のような基本的な理解を持っているエンジニアのことです。
1個専門特化しているものを持っておく。
1個または複数ですね。
2、3個ですかね、少数の尖っているものを自分の中に持っておくというところですね。
チームによっては様々な専門分野を持つメンバーをローテーションさせ
よりT字型のメンバーを育成することを好むところもあります。
中規模大規模のチームではある分野に特化したスキルを持ち
必要に応じて他の人の代わりを務めるスキルだったり
ダサさだったり協調性を備えた人材を確保することが
効果的であると私は考えていますと言ってました。
Googleの中ではそういうことをやってるんですかね。
特化した人たちの適材適所とか配置替えをどんどんして
ローテーションを回してるんですかね。
続きまして、体験することは学ぶことと言ってますね。
To experience is to learnと言ってます。
新しい言語を学ぶときはその言語を使って何か具体的なものを作り
実際に体験することに集中しましょうと。
新しい言語を学ぶ場合、良い開発者になるためにその構文であったり
ドキュメントをすべて暗記する必要は全然ありません。
それよりも問題を解決する方法を知ることの方がよっぽど重要です。
関連するコードをたくさん書いたり既存のコードから学んだりして
経験を積みましょう。
その結果、その言語で効率的なコードを書くことができるようになるはずです。
ここで述べたようにソフトウェアにおける主な価値は
生成されたコードではなく、それを生成した人々によって
蓄積された知識であるというのをおっしゃってます。
いやーいい話だな。
ソフトウェアにおける主な価値は生成されたコードではなく
それを生成した人々によって蓄積された知識の塊ですよと言ってますね。
ただし新しい技術で実験するときはもちろん生産現場で実験しないようにお願いします。
いわゆる本プロジェクトで実験しないようにという風に言ってますね。
ここは結構難しいところですね。
弊社は逆に新プロジェクトで割とエイヤーで導入してみて
みんなで挑戦しながらみんなで学習しながらっていう感じでやってるので
良し悪しはあると思いますし
僕はでもそれは悪くないやり方だと思ったりしますけどね。
もちろんベロシティだったりとか脳機とかの話があったりするので
大変だったときは本当にドツボにはまることは全然あるんですけど
ただ学習スピードは全然跳ね上がると思うんですけどね。
Googleまで行くと全世界の人が使ったりするし
12:01
その規模で物事を考えなきゃいけないと考えると
生産現場で実際のプロジェクトで使うっていうのは結構リスキーだよなっていうところで
ルール的にやらないようにしてるのかもしれないですね。
というところで一旦ソフトスケールズの大きなカテゴリー1つは終了で
次のカテゴリーはテクニカルコンプレキシティですね。
技術的な複雑度みたいなところの話だと思いますけど
の章に入っていって
でいきましょう。
次のセクションはその最初のセクションか
ジェネリックvsスペシフィックコードっていうところですね。
一般的かもしくは特別なコードかっていうところです。
でいきましょう。問題解決に特化したコードを書きつつ
少し汎用的なコードにすることができる箇所を見つけるようにしています。
多くの場合私たちはできるだけ汎用的なコードを書こうとし
結局問題の達成に役立たない事実上のコードスコープを作ってしまうことがあります。
その代わりにこの問題のために特別に構築し
ほんの少し汎用的にできることを見つけようとすることで
もしそれを考えていなかったら
あとでまたリファクタリングしなければならなかった
と思うようなことが完全になくなったと言っています。
逆に最初からスペシフィックなコードっていうのを書いておいて
それをどんどんちょっとちょっとずつジェネリック
いわゆる汎用的にできるように考えていくようにしたら
あとでリファクタリングしなきゃいけなかったみたいなことが
完全になくなったらしいですね。
Googleの中でそれができていたらしいので
ちょっと面白い話ですね。
設計の複雑さについては一般的にいくつかの原則を語られています。
エクストリームプログラミングの世界では次のようなものがありますと言っておいて
2つですね。
言われていますと。
いきなり翻訳が振っ飛んだな。
1つはヤグニ原則ですね。
You aren't gonna need it.
人の時があるまでは別にやらなくていいんじゃないのって話ですね。
もう1個はDo the simplest thing that could possibly workって言ってますね。
これしかもそれ専用の記事のリンクが貼ってますね。
これなんだ。初めて聞いた気がします。
将来的な計画を立てるよりも急速に進歩するために
うまくいきそうな最もシンプルなことをやることだと言ってます。
はいはいはい。
という原則ですね。
最初から汎用的に考えるんじゃなくて
まずはスペシフィックなところでいいんじゃないのって話。
その代わりシンプルなことをすることだって言ってますね。
ヤグニも同じことを言ってます。
必要なものを必要なときにやればいいので
今必要じゃないんだったらやらなくていいっていう話ですね。
この2つの原則っていうのは過剰なエンジニアリングを防ぐことを目的としています。
しかしこれらの原則を乱用すると
うまく統合できない単純な解決策を複数作成することにもなりかねません。
それもそうだね。
一方中小化の原則っていうのは中小化と汎用化によって
実用的であればいくつかのコードの重複構造を減らすことを目的としています。
15:00
私は極端の中小化と極端な単純化の中間を取るために
コードを少し汎用的にすることを望んでいますと。
好んでいますって言ってますね。
アハ原則。
これと似たような考え方が出てますね。
アボイド・ハスティ・アブストラクションですね。
アハ原則っていうのがあったんですよ。
僕全然知りませんでした。
一応これも今読んでる記事のリンクが載ってますので
その中から見てもらえればいいんじゃないかなと思います。
続きまして、ディープモジュールですね。
行きましょう。
ディープモジュール、そのまま。
他の開発者のために複雑な問題を解決するコードを書くが
明快なインターフェースを通して機能を公開しましょうと言っています。
もしあなたがAPIの設計者または開発者であるのであれば
あなたの責任は他の開発者のために複雑な機能を
単純化するためのインターフェースを提供することです。
もしそのインターフェースがあまりにも難解で
それを使うプログラマーに規制を強いるものであれば
その目的とはされていません。
この考えはディープモジュールという概念に反映されています。
ディープモジュールもまたそれ専用の記事のリンクが貼られてますね。
その中に言われているのは
最高のモジュールというのは最大の利益と最小の費用を持つものであります。
ローコスト、リターンというところですね。
モジュールが提供する利益はその機能性であって
そのモジュールのコストはそのインターフェースであると言っています。
なるほどですね。
なかなか素晴らしい言葉だなと思いました。
インターフェースがシンプルであることは望ましいですが
複雑な問題を解決するためには時に複雑なコードが必要とします。
これは普遍的なルールではないですけど
なんだかんだ事実だよねというふうに言っています。
この複雑さはコードに埋め込んだ方が良いと言っています。
複雑な機能が中小化されていれば
エンドユーザーやインターフェースユーザーに提供される価値ももちろん高くなります。
ある機能を包含する複数の可視関数であったり
クラスを持つAPIというのは
同じ機能より少ないパブリック関数やクラスで実装したものと比較すると
やはりより複雑で検索が困難になってしまいます。
新しい関数やクラスをメンテナンスするプログラマーや
ライブラリーユーザーにとって
インターフェースのコストを増加させてしまいますよねというふうに言っています。
難しいところですけども
複雑なところを見えるところに置かなければ
良いんじゃないかというのは極論の話かもしれないですけど
あくまでインターフェースのところはシンプルにしておいて
複雑なところはロジックの方でも
閉じてしまえれば別に良いのかなという気はしますけど
一方で全部か全部そうなるとも限りませんし
必要であれば必要なことをやるしかないのかなという感じがしますね。
ただやっぱりディープモジュールの考え方にある通りで
利益とコストというところがやはり重要なので
そこに大向きを置いてコストはモジュールにかけて
18:01
インターフェースにコストをかけていくというところがありかもしれないですね。
続きまして
ラーニングをメンテナンスプロジェクトと言っています。
メンテナンスプロジェクトにおけるラーニングですか。
星プロジェクトですね。いわゆる。での学習についてです。
古いシステムのレガシーコードに取り組む場合
残すべきコードと手放すべきコードの違いを理解するというところが重要であると言っています。
シニアエンジンなら誰でも残すべきコードと手放すべきコードの違いを理解する努力をすべきだと言っています。
残すべきコードと手放すべきコードの違いを理解することで
大規模で長期間の生産システムとかですけども
悪いコードやもう残すべき理由がないコードっていうのは絶対あるはずだよと言っています。
何かがそこにある理由ですね。
良い理由か悪い理由かわかんないですけど
何らかの理由がそこにあってそれを評価することは健全なことと言っています。
悪いコードを削除し良いコードを残していきましょうと言っています。
私は多くの会社で働いてきましたけども
人々はレガシーコードを触ることができない
あるいは時間の砂に消えた正当な理由のために
そのように設計されていると思い込んでいます。
もちろんコメントとかあれば全然いいんですけどね。
多分往々にしてないんでしょうね。
これでは変化を恐れて脆弱な基盤に
抽象的な機能を追加し続けることになりかねませんと言っています。
これも本当そうですよね。
やっぱ正当的な理由がわからなくなってしまった
その上に抽象的な機能をどんどん追加していかなきゃいけないっていうのは
割と怖いですよね。
ソフトウェア業界では多くのプロジェクトが
古いシステムやレガシーシステムのメンテナンスと
移行を行う段階に移っていたっていますと。
もしあなたがそのようなチームに所属していたとしても
イライラしないでくださいと。
古いコードを見ることでドメイン固有の知識を得ることが
できることがたくさんありますと。
古いコードやバリデーションが本番環境に存在するには
それなりの理由があるかもしれませんが
一行一行がまだ適切であると決めつけないほうが健全です。
エンジニアリング、特にソフトエンジニアですね。
ソフトエンジニアの中にはバグが発生することを恐れて
実作動しているコードに触れることに慎重な方がいますと。
そのため新しいユースケースのために条件を含めたり
いくつかのコードを繰り返したりしますと。
はい、分かります。
やっぱ分かんなかったりしたり
これいろんなところで使われたりして
影響範囲が広すぎた場合はそこを触れずに
ラップしたものを作るかもしくは新しく関数を増やしたりとか
いろんなことをやったりしますよね。
このような回避策はその場では時間を節約できるかもしれませんが
時間が経つにつれてメンテナンスの悪夢となります。
本当そうなんですよね。
既存のコードが恵まれているとか無残であると
決めつけないことが良いでしょうと。
スケーラビリティや効率性などこれまで見過ごされていた部分に
対処できることがあるかもしれませんと言っています。
ここは本当支援と言ってもいいようなお話でした。
ラーニングオンメンテナンスプロジェクトでした。
保守のプロジェクトこそ学びがあるなってところですね。
またシニアエンジニアであればこれらを見分ける能力を
21:02
身につけるべきだよと言っていましたね。
続いて、ラーニングオンはグリーンフィールドプロジェクト。
グリーンフィールドプロジェクト。
実験し、確信し、素早く失敗し、問題を解決することに
長けているよと言っています。
ゼロからシステムを構築する場合、学習の道のりは全く異なります。
プロトタイピングや機能の実装を繰り返しながら
何がうまくいき、何がうまくいかないかを学んでいきます。
アジャイルな方法論とフェイルファーストの原則というのは
より少ないリソースで、より早くアイディアを検証するのに役立ちます。
そして複雑な問題を分化して解決することができるので
ついていました。
なるほど、グリーンフィールドっていうのが
僕はあんまり伝わらなかったんですけど
とにかく早く実験して、早く挑戦をしてみていって
どんどん失敗して問題を解決することということですね。
もちろんプロタイピングができるなら
プロタイピングでどんどん失敗すればいいと思いますけどね。
アジャイルな方法だったりとか、フェイルファーストの原則とか。
もしくはより少ないリソースをとりあえず置いておいて
アイディア検証というのをどんどんやっていきましょうということですね。
では続いていきましょう。
続いて、ディフィニッションオブダンですね。
これはもうタイトル通りって感じですね。
完了の定義、ダンの定義ですね。
何が完了したのかを定義するっていうことは
必要な能力を見積もり開発計画を立て
あとで不必要な修正を避けるのを役立てるので
時間の節約になりますと。
複雑さに対処するときに便利なもう一つのアジャイルの原則っていうのは
完了の定義に合意することでもありますと。
ユーザー要件であったりとか受入れ基準であったりとかを満たすために
それに加えてコードレビューだったりテストだったり
ドキュメント課だったりとか
他の条件も含まれる可能性もありますよねって言ってます。
そんな色んなものを加味して
とりあえずダンの定義をどんどん決めていきましょうねっていう話でした。
続いてフェーズドロールアウトですね。
段階的なロールアウトというところです。
一つの大きなリリースをよりリスクの低い
より理解された一円のロールアウトに分割することができますよと言ってます。
大規模な生産システムのリリースを計画する場合
ロールアウト計画っていうのはアーキテクチャやコードと同じぐらい重要ですと。
反復開発による段階的なリリースっていうのは
大幅な変更に伴うリスクをよりよく管理するのに役立ちます。
また開発戦略であったりテスト戦略と一緒にリリース戦略を作成することで
複雑なリリースに対するエンドツーエンドの計画を立てることができますと言ってます。
リリース周りのところをしっかり分割しておくことで
リスクを小さくしたりスコープを小さくすることができるし
計画がしやすくなりますよね。
あとはロールバックすることもできたりするので。
リリースもできれば一つガーンとパイプでやるとか
パイプで結局やると思うんですけど
一つ一つのスコープをしっかり切っていくのは確かにいいはずだなと思いました。
続きましてシステマティックデバッグですね。
24:06
デバッグの際には全てのテスト条件に対応できるよう
体系的かつ厳密に問題を解決するよう心がける必要があります。
エラーメッセージとかスタックトレースっていうのは必ず読んでください。
そこには問題を切り分け解決するための貴重な情報が含まれている可能性があります。
驚くほど多くのエンジニアがデバッグの助けを求める前に
エラーメッセージが与えてくれる知見を無視していたりしますと。
そうなんや。
普通に何かエラー出たらまずエラーメッセージ読むもんだと思ってました。
小さな編集を加えたりとか常に行動を再実行することで
問題を早く解決できることと考えるのではなく
機械が何が問題か教えてくれていて
それが正しいかもしれないと仮定してみてくださいと。
例外を投げるような解決策を書いても
その例外を注意深く読んでいなければ
時間を浪費してしまうかもしれません。
多くの場合、エラーや例外のメッセージは
実際何が問題なのかを示す大きなヒントとなりますというところでした。
プログラマーとしての基本といいますか、そこをですよね。
意外と多くの人はエラーメッセージ読んでないんですね。
困ったらとりあえずエラーメッセージの英語文章を
そのままググれば何かしら出てきたりすると思うんですけど。
というところでした。
ちょっと短かったですけど、
テクニカルコンプレキシティのところのカテゴリーはこれで以上で
次のカテゴリーがデザインドックスですね。
設計書の話かな、に入っていきたいなと思います。
時間がちょっと短くなって、あと1、2分なので
あと1、2セクション読んだら終了かなというところですね。
はい、いきましょう。
一つ目ですね、Importance of Design Docs
デザインドキュメント、設計書の重要性というところですね。
設計書は後付けではなくてソフトエンジニアリングのプロセスに
不可欠な部分であるべきだと言っています。
設計書というのはシステムのアウトの部分と
インターフェースを取る必要がある同僚や他のチームから
合意を得るのに役立ちます。
どこにでもあるツールなのですよと言っていますね。
他社からのフィードバックによりギャップを特定し
設計を改良することができます。
デザインドキュメントは将来のチームに
参加するエンジニアにとって貴重な支援となります。
これは本当そうですね。
問題空間であったり解決策を設計する際に
考慮したトレードフと大体案を理解するのに役立ちます。
設計書というのは設計に関わった全ての参加者と
その貢献を記録するスペースをちゃんと提供しておいて
ドキュメント履歴の一部になってくれるよと言っていますし
これは誰が特定の決定を下したのか
さらに詳しく説明するために誰に連絡すべきなのか
他の人が理解するのにも役立ちますと言っています。
意外といろんなところの合意を得たりとか
まさしく設計ですよね。
新しくメンバーが入ってきたりとか
問題解決するために設計書というのはすごく役立つので
ぜひぜひ書いてくださいというのと
更新履歴の中に名前と日付というのを書いていくのも
他の方でもそういうことをやっているというのがすごくいい話だったなと思います。
27:01
じゃあラストですね。これだけを読みましょう。
ドキュメンテーションプロセスです。
ドキュメント作成のプロセスですね。
設計書のレビューを調整し進化する設計というのを
元のドキュメントを比較し関連する全ての制約が対処されている
ということを検証しましょうと。
一人で設計書を作成することももちろんできますけど
実際の設計プロセスというのは一連のホワイトボードとか
スラックスレッドだったりメールディスカッションで発生します。
何か書き出しておいて初めて矛盾するコミットメントが確認でき
議論していたことのあるパーツが調和しているかどうか
というのを確認することができるのです。
最初のドラフトを作成した後レビューを調整することで
関係者全員が納得していることを確認することができます。
しかし途中で何か変わったために実装された設計というのが
文書化されたものと一致しないことももちろんあるので
そういうのを確認するためにもしっかりドキュメントを作ってくださいね
というお話でした。
じゃあちょっと9時半を超えてきたので
一旦今日の朝方は以上にしたいと思います。
今日のスクロールを見ているんですけど
やっと半分くらいまで来ました。
10年間の事件をひたすらずっと書き連ねたということを考えると
このドキュメントのかかった時間もすごいし
やっぱり完成度ってめちゃめちゃ高いなと思いました。
というところで明日もこのまま引き続き読んでいきたいと思います。
やっぱりあともう2日間この記事を読むことになるなと思いますので
もちろん気になる方はご自身でも読んでみてください。
めちゃめちゃボリューミーで体力がいるんですけども
やっぱり知見の塊なのでとてもいいなと思っています。
ぜひ読んでいきたいと思いますし
僕も社内で展開してみんなにお勧めしていきたいなと思いました。
では今日も参加させていただいた多くの方ありがとうございました。
また明日もゆるーく読んでいきたいと思いますので
朝の耳の暇つぶしにでも使っていただければいいなと思います。
では今日は今週は昨日が休みだったので
今日からまた1週間、4日間頑張っていけたらなと思います。
では本日はまた以上にしたいと思います。お疲れ様でした。
