noteからの転載
アイキャッチが作りたいと思ったので、作ってみた。
コードの共通化と、コードの再利用、コード書かない人とコード書く人の間で全く違う捉え方をするよねって思ってる
— magnoliak🍧 (@magnolia_k_) 2021年2月11日
共通なコードが一つにまとまる 二つのコードが有れば、共通化で総量は半分になる
共通なコードと、それぞれの個別機能が渾然一体となる 二つのコードが有れば、共通化で総量は2割くらい減って、密結合により複雑度は5割増しになる また、未来の機能追加で個別コードが増え続ける
元の品質が担保されたコードをそのまま使うので、工数はほぼゼロ
そもそも再利用の可否を調査するのに工数がかかる 再利用した後の品質保証ポイントが爆発し、工数がかかる 再利用時に、本来は不要なコードが残り、未来の機能追加の足枷となる
最初からそう設計されていればいいけど、あとから共通化や、再利用といったキーワードが出てきたら、たいてい危ないことが多い。
この手のミドルウェア・プログラミング言語の入門・解説書、ひたすら語り口を優しくしているだけだったり、単にリファレンスをなぞっているかのどちらかで、教科書的な硬さとかが鼻につくんだけど、この『Webで使えるmrubyシステムプログラミング入門』は全然違う。次元が違う。
明らかに、”現場で経験値の高い先輩から指導を受けている”ような錯覚を感じさせる内容、流れになっている。
今後、この手の入門書は全部こんな感じでお願いします（あとは公式リファレンス読むんで！）と言いたくなるくらいの良書。マジで良い。
つまり、mrubyとだけタイトルに書かれているのに、C言語を使ったシステムプログラミングも学べ、実用的なツール類も学べ、結果的に適材適所としてのmrubyの使い方が学べるようになっている。
マジでこれ実践的な教育の流れに沿っていて、凄い。マジで凄い！！
著者の近藤宇智郎さんに直接指導してもらえる幸せな人はいいけど、そうじゃない人はマジですぐ買って、読んで、コードを動かし、自分のコードを書いた方がいいです。
近藤パイセン、マジぱねぇッス！！
これで学んだら、システムコールを使ったプログラミングを解説する本はいくつか出ているので、そちらに進めばいいと思います。
"意識的に意思決定されたことでなくても、そこに設計が有るんだ、暗黙知として。"
結果的に、たまたまできあがった、明文化されていない仕様は仕様と言えるのか、それは設計と言えるのか、と言えるけど、それがユーザーに見えている挙動である以上は仕様であり、設計なんだ。
でもそれがいつも可視化されているとは限らず、たまたま言われたら、確かにそうかもという話になってしまうんだけど、案外そういうところに大事な要素が詰まっている。
noteからの転載
技術書を初めて読み始めた頃、ビジネス書とかマネジメント論みたいな本と違って、書いてある通りにやれば動く、凄い！って思ったけど、すぐに「書いてある範囲のことしか動かない…何も分からない…」という所に行くんだよね…
— magnoliak🍧 (@magnolia_k_) December 6, 2020
一人で技術書を読むときに陥りがちなんだけど、そのソフトウェアの持つ独特の箱庭感みたいなのが有ると思っていて、技術書に書かれていることは（前提のバージョンとかが変わっていない限り）、まぁ動いてしまう。
そして、動いて、「やったー」と思った先に、「で、次に何をやるの？やりたいことってあるの？こんな面倒くさいをことを続けるの？」というフェーズがやってきて、なかなか先に進まない、ということが有って。
特に職業プログラマーであれば、職務上やるしかないけど、将来のための勉強などでやっていると、なかなかその先に進むモチベーションが湧かないことが有るように思える。
その先を一歩越えるのに、コミュニティだったり、OSSへのコントリビュートみたいな行為が有効だったりするんだけど、そこもやはり一人で到達するのは難しかったり。
技術書を読んだ、その先で何をするのか、考えてみよう。
技術書、一度読むだけでなく、しばらく経ってから読むことで新しい発見があるので、分からなくてもいいからまずはざっと読むと良い、という話をしました
— magnoliak🍧 (@magnolia_k_) November 6, 2020
特に設計思想的な話は、自分の経験によってどんどん見え方が変わるから同じ本でも何度も読み直した方がいい。
本を理解するのではなく、本をきっかけに自分の考えを整理するのが目的だからね。
と、以前noteに投稿した。
そして、そのあとに、「一冊の本をじっくり読み込み、知識を吸収するためにはどうすればいいのか」というエントリを書いた。
非常にコメント付きのブクマが多く集まり、色々な知見が得られた(ちなみに、私も全部あんなディープな読み方をしているわけではないです、念のため）。
その中で、古い本だけど今でも読み継がれている本の読み方の本として、タイトルもそのままですが、『本を読む本』をご紹介いただいた。
読書の目的を知識を得るための読書と、理解のための読書に分解して、読むという行為は決して受動的な行為ではなく、積極性のある行為だと説いている。
また、読書のやり方を4段階に分けて、「初級読書」「点検読書」「分析読書」、そして同一主題について2冊以上の本を読む「シントピカル読書」の解説へ続く。
おそらくそもそもの出版点数の爆発的な増加や、Kindleなどの電子書籍プラットフォームの普及などにより、この本が書かれている当時よりも圧倒的にこの読み方がやり易い環境になっていると思われる。
本の読み方は人それぞれだし、千差万別だけど、わずか数千円で著者が長年にわたって蓄積してきたことが凝縮されて得られるのだから効率が良いのは間違いない。
ただ、本の内容は変わらないけど、読み手側はどんどん変わっていく。最初はまったく分からなかった本が、あとで手にとるように分かるようになった経験は一度や二度ではないはずだ。
なので、技術書のように、読み手の経験値に深く根ざす書物は、一度読んで理解できずとも、しばらく寝かせて、自身の経験を積み上げ、「読むべき時」が来たときに読むといいのではないか、「理解のための読書」という概念を知って、改めてそう思うわけです。
Clean Agile 基本に立ち戻れ (アスキードワンゴ)
原著は2019年に出版されていて、日本でも2020年に翻訳されている。
「アジャイルソフトウェア開発宣言」が2001年に発表されて、約20年。アジャイル開発の歴史や、考え方、プラクティスなどがコンパクトにまとめられている良書。
ちょうど、そろそろもう一回アジャイルについて、自分の中の考え方を整理してみたいと思っていたところだったので、ちょうど良いタイミング、内容だった。
ただちょっと気になったのは、全体としてウォータフォールとの対立軸をものすごく強調しているところ。
『Clean Agile』を読んでいるんだけど、「みんな頑張ってやってたんやで、そんな悪う言わんでも……」みたいな気持ち
— magnoliak🍧 (@magnolia_k_) 2021年2月5日
ウォーターフォールでも上手くいくためにいろんな工夫がされたけど、そこに名前がつかなかっただけじゃないかなーって
対立軸を煽るのは良くないし、そこじゃない感がある
冒頭はひたすらウォータフォールではプロジェクトが上手くいかず、アジャイルにより上手くいくようになった、みたいなことが書かれているが、本当にそうなのだろうか？
そもそも「正しいウォーターフォール」などというものがどこかに定義されているのだろうか？工程を区切り、順番に進めていき、最後にリリースする…本書ではウォータフォールについてはそれ以上のことは何も言っていない。ただ上手くいかない方法だと書かれている。
進捗について書かれているところも、ウォータフォールでは上手くいかない例ではなく、「進捗で嘘をつくと上手くいかない例」に過ぎない。そりゃそうだ。
中間管理職の価値観の話も、開発方法論となんら関係ない。ウォータフォールだったら、中間管理職はこんな振る舞いをしなさい、なんてどこにも規定されていない。
一方でアジャイルについては、その考え方、プラクティスなど、さまざまな角度からいかに有効であるか論じられている（当たり前だけど）。
因果が逆で、ウォーターフォールだったから上手くいかなかったんじゃなくて、上手くいかなかったことにウォーターフォールだったから、というラベルを付けてないですか？って
— magnoliak🍧 (@magnolia_k_) 2021年2月5日
ちゃんとしたウォーターフォールの入門書って無いんですか
— magnoliak🍧 (@magnolia_k_) 2021年2月5日
いつも対立軸の中でしか語られない、架空の手法だったりしませんか
いろいろな方法論を作り出す人たち、おそらく過去にただ一人たりとも、”プロジェクトが上手くいかないことを願って”作業をした人はいないのでは？（ステークホルダーへの説明責任を過剰に意識し過ぎ、そもそもの成果をおろそかにした方法論はひょっとしたら有ったかもしれない）また、アジャイルを採用していないソフトウェアプロジェクトが全部失敗に終わったわけでもない。色々な創意工夫の上に成り立っている。
なので、その辺りは割り引いて読んでいった方が良いのかも。現実の問題に合わせた対応をしないと、結局ソフトウェアは完成しないのだから。
「アジャイルソフトウェア開発宣言」で語られる4つの宣言…”包括的なドキュメントより動くソフトウェアを”を除くと、アジャイルではないプロセスを採用したプロジェクトでも上手く行っているプロジェクトでは当たり前にやってませんか？個人や顧客を無視したプロジェクトはどんな手法を使っても失敗するし、上手く行っているプロジェクトは現実の変化に対応しているのでは？
ただ、経営層や顧客など、取り巻くステークホルダーの価値観や、視点を変えるために、あえて強く主張するのは、きっと有効。ほんとうにこの本を読むべきなのはアジャイルで開発を行うチームの外にいる人たちではないか、とも言える。成果物をすべて最初にコミットする方法ではなく、ある範囲において柔軟に対応することが求められる価値観を浸透させるための、キーワードとしての、「アジャイル」。
ただ、一方でシステムを要求する側は、大抵は、必要にして最小限と思っている機能を要求している。無駄と思って要求する人はいない、要求した以上はどれも必要な要素だ。
既存のシステムの更改など、最初から既に要求仕様が決まっている、一定以上の規模のソフトウェアを作らなければいけないシチュエーションも存在する。
このギャップをどう埋めるかは、この本には書かれていない。本書は2021年現在でも読む価値は十分にある本だけど、実はもっとも大事なのはここに書かれていないことなのかもしれない。
どうすれば、ここに書かれている方法論が機能する環境を作り出すか？それが実はアジャイルを導入する上で一番大事なポイントなのではないか。
本書を読んでアジャイルのすべてが分かるわけではないし、結局何度も実践していく中で自分たちのやり方を見つけていくしかない。プラクティスは揃っているが、それはあくまでプラクティスであり、自分たちの代わりに何かを生み出してくれるわけでもない。
冒頭でアジャイルは軽量なプロセスと書かれている。でも、それはソフトウェア開発に関わる人たちが実際にやることが少ないことを示しているわけでない。
やることはたくさんある。それをいちいち規定しないと言っているに過ぎない。
結局は自分たちが置かれている環境、課題と真摯に向き合い、柔軟にやり方を変え、最終的なゴールに向けてソフトウェアの点から価値を提供できるか？を実行し続けるしかない。それは逆に言えば、アジャイル以外の方法論でも何も変わらないのだけど、ソフトウェア開発プロセスや、ツールチェーン、クラウドの普及・進化などがアジャイルという方法論の効果をより増大させているのは間違いないので、この流れに乗るのが一つの生存戦略だよね、と言われればそれはそう。
「正しいウォータフォール」「きちんと機能するアジャイル以外の方法論」については、この本を読んでもわからないのだけど、この本に書かれていることを誤った方に読み込んで、”目の前の上手くいかない状況はアジャイルじゃないからだ”というラベリングするのだけはよくないなーと思った次第です。
あと、組織をスケールさせる方法はついに分からなかった……。
だれか教えてください
Noteからの転載
—-
設計書は、現在、または過去、未来をつなぐコミュニケーションツールなので、そのコミュニケーション設計をどうするか？って話を抜きに、どう書くべきか？そもそも書くべきか？みたいな議論を始めてしまうと、会話が成立しないことが多いですよね
— magnoliak🍧 (@magnolia_k_) 2021年2月6日
必要な抽象度だって全然違ってくるし
これが設計書です！と言われて見せられたものが、あからさまに個人的なメモを超えるものでない場合、「この文書は誰とのコミュニケーションを目的としましたか？」と聞くと良いのではないかっていう
— magnoliak🍧 (@magnolia_k_) 2021年2月6日
みんなオレオレ正しい設計書理論があるので
設計書になにが書かれているべきか、コードの世界と違ってあまりコンセンサスが得られた回答を見たことが無い気がする。
かなり大きめの書店に行っても、「リーダブルコード」に代表される”良いコードの書き方”はかなりプラクティスとしてまとまってきている一方で、”良い設計書の書き方”みたいな本はほとんど見かけない(ごくたまに見かけるけど…それほど印象に残るものは…無かった気がする)。
なぜだろう…と思ったのだけど、結局冒頭のツイートに有るような、「設計書はコミュニケーションツールである」という視点が抜けたまま議論されることが多く、「割と多くの人に納得感が得られる」ところまで到達していないのではないかな。
つまりコンテキスト依存が大きいにも関わらず、オレオレベストプラクティスがその場その場で語られすぎた結果、誰もそれを組織を超えて積極的に流通させていないのではないか？みたいなことを考えていたら🍺飲みたくなってきた。
Excel方眼紙的な設計書があれこれ言われるけれど、それ以上に必要なコミュニケーションが取れないことが一番問題なので、設計書の様式や記載内容は常に「これで必要なコミュニケーションは取れるのか？」という視点を持ち続けたいですね。
