"意識的に意思決定されたことでなくても、そこに設計が有るんだ、暗黙知として。"
結果的に、たまたまできあがった、明文化されていない仕様は仕様と言えるのか、それは設計と言えるのか、と言えるけど、それがユーザーに見えている挙動である以上は仕様であり、設計なんだ。
でもそれがいつも可視化されているとは限らず、たまたま言われたら、確かにそうかもという話になってしまうんだけど、案外そういうところに大事な要素が詰まっている。
"意識的に意思決定されたことでなくても、そこに設計が有るんだ、暗黙知として。"
結果的に、たまたまできあがった、明文化されていない仕様は仕様と言えるのか、それは設計と言えるのか、と言えるけど、それがユーザーに見えている挙動である以上は仕様であり、設計なんだ。
でもそれがいつも可視化されているとは限らず、たまたま言われたら、確かにそうかもという話になってしまうんだけど、案外そういうところに大事な要素が詰まっている。
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方眼紙的な設計書があれこれ言われるけれど、それ以上に必要なコミュニケーションが取れないことが一番問題なので、設計書の様式や記載内容は常に「これで必要なコミュニケーションは取れるのか?」という視点を持ち続けたいですね。
noteからの転載
プログラミングが上達するコツ
— magnoliak🍧 (@magnolia_k_) 2019年11月19日
・いろいろな種類のコードを読む
・たくさんコードを書く
・テストを少しでも書く
・エラーメッセージをちゃんと読む
・公式ドキュメントをちゃんと読む
・ペアプロする
・途中でTwitterしない
最後も、独習する上では、割とシリアスな問題ですが…とりあえず本だけ読んでいても全然上達しないですよね。
最初は写経でもいいと思うんですけど、写経する時に絶対にタイプミスとかでエラーメッセージが出ると思います。
その時に、エラーメッセージをちゃんと読んで、意味を調べて…っていう行為を最初の時点でしっかりやると、その後の上達が全然違うんじゃないかなって思います。
本当に全然意味不明なエラーメッセージも多いですけどね
明らかにやり過ぎた。1ヶ月で1年分のエントリ数を書いてしまった。これは明らかにペースを間違えている。
2月からはもっとゆっくりめのペースでやっていきます。
でも先日「書評ブロガーとしてついにブレイク」と言ってもらったので、それはそれで調子に乗ってしまうかもしれない。
書いたエントリをいくつか振り返ってみる。
はてブが500を超えると、けっこう読まれた、と思うのだけど、『理科系の作文技術』のエントリは1000近いブクマがされて、それなりに読まれたと言える。たぶんだけど、タイトルに全部書き切ったのがよかったのかも。この本、古い本だからそれなりに持っている人も多いと思うけど、案外ちゃんと読み切った人はそんな多くないのかも……と思って、せめてここだけは読んで欲しい、と言い切り、読み方を提示できたのが注目されるポイントだったのかも。
しばゆーさんのエントリに触発されて書いたエントリ。自分が考えたこと、行動したことを、ものすごく細かく分割して、書き出してみると面白いな、といつも思っていて、自分が技術書とかをじっくり読んでいるとき、どんな読み方をしているんだっけ?っていうのを極限まで分解してみた。解像度が変わってくると、意味が変わってくる……という発見がある。
これはずっと言い続けていることの本質というか、要はこれだ、という気持ちの濃縮版。どこかでもう少しまとめたいと思っていて完結編的なものを書きたい。
これはけっこういいキーワードを引っ張れた気がする。「自動化」と「見える化」の二つがいつも嫌な言葉だなって。
noteに書き散らしていたことを転載してみたエントリ。ものごとを視点を変えてみるとどうなるんだろう?という話ばかりしている気がする。
この辺も普段考えたことを書き出してみたエントリ。
雑に書いてしまったので、まだあまりまとまっていないんだけど、これはほかの人が書かないことをかけたなーって思っている。
これはなかなか書けたぞ!というエントリが必ずしもブクマを集めるとは限らない所も悩ましいし、面白い。
これなんかかなりの渾身のエントリだったんだけどなーと思ったり。
面白い。その通りとも思うし、量だけでなく関心を処理する能力もあるはずで、後者は鍛えられるんじゃないかとも思う。ただ、鍛えられるはずと思うことにも関心量が必要そう。https://t.co/BB5bzOjex7
— 栗林健太郎 (@kentaro) January 5, 2021
まぁでも、栗林健太郎さんに拾ってもらえたので、5000兆点でいいかな、とも言える。