ソフトウェア開発における学習曲線を受け入れる by David Bernstein

Beyond Legacy Code の著者、David Bernstein (@ToBeAgile ) さんの記事を翻訳しました。ソフトウェアエンジニアは新しいことを常に学ぶ必要性がある、 それはなぜか、というお話です。

David  さんは DevOpsDays Tokyo 2019 (4/9-10) の 基調講演で来日予定です。

Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software

Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software

 

 

ソフトウェア開発における学習曲線を受け入れる

David Bernstein著 - 2018年6月20日

www.agileconnection.com

要約:ソフトウェア開発の領域では、私たちは常に必要性に迫られ、新しいスキルを習得し続けています。テクノロジーや、それに絡むベストプラクティスは絶え間なく変化してしまいますが、これは業界が急速に進化しているという意味でもあり、むしろよいことです。そしてまた、私たちが常に学習曲線の途中にいること意味します。継続的学習についてのよいマインドセットを持っていれば、ソフトウェアの世界でより遠くまで到達する手助けになるでしょう。

新しいことを学ぶときには、常に学習曲線に直面します。
まず、特定のテーマについて知らなければいけないことの全てを、あらかじめ知っているわけではないことを認めなければなりません。当たり前だと感じるかもしれませんが、人はなにかに熟達すると、しばしば、初心者のマインドセットに立ち戻るのが難しくなります。新しいスキルの習得のために、以前は役にたった古いスキルを放棄しなければならないときは特にそうです。常にもっと学ぶべきことがあり、改善の余地がある。真の達人たちが常に謙虚なのは、それを知っているからです。
きっと100年後の人たちが今の私たちのソフトウェア開発をみたら、おかしいと笑うんじゃないでしょうか。たぶん私たちが昔のまじない師を見るような感じです。もちろん仕事としてはうまくいっていたわけですが、病気の本当の原因はわからず、効果的に治療できたわけではありません。私たちも上手に仕事をこなしていますが、まだソフトウェアの本質を理解できていないのです。ソフトウェアは世界の他のすべてのものと根本的に違うため、それも不思議じゃありません。私たちは未だ、効果的な開発方法を試行錯誤しているのですから。

          *  *  *

新しいプラクティスが効果的かどうかにかかわらず、学習曲線が存在するのが普通です。あるプラクティスの適用が有益かどうかを考えるだけでも、学習曲線のなかで一層の努力が必要になります。プラクティスを取り込んで、いつもやっている活動にできたら、その努力が報われるんだと考えてみましょう。
人は生まれながらに歩く能力を持っているわけではありません。歩き方を学ぶために時間と労力をかけたのです。おそらく覚えていないでしょうけど、何度も転んだに違いありません。でもあなたは挫けませんでした。当初、歩くことはハイハイよりも大変でしたが、あきらめずに努力を続け、現在は常にこの新しいスキルの恩恵を受けている、というわけです。

          *  *  *

どんな人でも学習曲線を通過する必要があり、それが何であれ、進みながらうまくなるのです。ソフトウェア開発でも、常に新しいスキルを習得します。そうせざるを得ないからです。テクノロジーや、それに絡むベストプラクティスは絶え間なく変化してしまいますが、これは業界が急速に進化しているという意味でもあり、むしろよいことです。

このことは、私たちが常に学習曲線の中にいることも意味します。ほとんどの人は、学校から出たとたんに学ぶことをやめてしまいがちですが、ソフトウェア開発の世界では、常に学んでいくものです。私にとってこのことは、ソフトウェア分野の主な魅力の1つです。私は新しいことを学ぶのが大好きで、それに事欠きませんから。

          *  *  *

新しいものを学ぶことに慣れてくると、学ぶ困難が減っていき、より楽しめるようになります。新しいことを学んでいるなら活発な精神でいられますが、筋肉と同じように、脳も使わなければその力は衰えます。年を取ると、ソフトウェアを書くのは外国語を学ぶようなものです。神経活動を刺激し、心をシャープで機敏に保ちます。
しかし、ソフトウェア開発者というものは、仕事としてソフトウェアの生産が期待されているせいで、継続的に学ぶことが難しくなることがあります。その結果、しばしば業務時間外にも勉強しなければなりません。
20年前には、ソフトウェア開発に関する良書はあまり多くはありませんでしたが、現在は違います。開発者が読んで理解すべき、非常に重要な本がたくさんあります。フレームワークや言語に関する本もありますが、開発技法やソフトウェアでの問題解決のアプローチに関する本もあり、プロのソフトウェア開発者にとって、それらを読んでおくことは非常に重要だと思います。

          *  *  *

ソフトウェア開発分野で私の好きな本を一部あげるなら、マーチン・ファウラーのリファクタリングAlan ShallowayとJames R. Trottによるオブジェクト指向設計の第2版、マイケルC.フェザーズのレガシーコード改善ガイド、私自身の本「Beyond Legacy Code:あなたのソフトウェアの人生(そして価値)を広げるための9つのプラクティス」が挙げられます。
これらの書籍は、高品質でメンテナンス可能なコードを作成するための原則を理解するのに役立つ専門的なソフトウェア開発のコアプラクティスに焦点を当てています。残念ながら、ソフトウェア開発の分野で出版される本の大半は初心者向けです。私たちの業界は絶えず学びたいと望む専門家でいっぱいなのですが。

          *  *  *

しかし、本だけでは足りません。本からソフトウェア開発を学ぶことは、本から脳外科手術を学ぼうとするようなものです。理論的な基礎を得ることはできますが、実際に上手になるには、練習しなければなりません。
どんな科目でも達人になれる秘訣があります。初心を忘れず、常に学び、読み、練習しましょう。

 f:id:wayaguchi:20181027162228p:plain

David Bernstein (@ToBeAgile) | Twitter

 

 

本記事のレビューには松元健さん、伊藤宏幸さん、横道稔さんにご協力いただきました。

 

Netflix でガンダムを学ぶなら

おじさんの基礎知識なので今更学ばなくても...とは思いますが、ご興味ある方は Netflix で正史ともいえる宇宙世紀のシリーズはだいたい追えます。注1

 

とりあえずファーストと言われる第1作の5話大気圏突入あたりまで見る気が起きそうなら、その先も見れそうなので、まずはここからでいかがでしょう。80年代の作品なので作画のクオリティも当時の予算を反映してます。スターウォーズみたいなものです。

Netflix機動戦士ガンダム
https://www.netflix.com/title/80124040?s=i&trkid=13752289

 

もし43話付き合えたら続編はZ (7年後)。読み方はゼータです。アルファ、ベータ... の最後がゼータですね (訂正:6番目だそうです)Zガンダムは中盤から登場するのですが、単体で大気圏突入して飛行できる究極のマシンになってます。複数のメカデザイナーが参加するようになって、ガンプラがたくさん作られました。時代背景も二大国の冷戦が終わって紛争の時代に入った現実世界が反映されてます。武力行動に出資企業がいる、という。この辺りで多感な少年時代を過ごした40代のおじさん達は、Zガンダムで政治を学んでる気がします。政治演説するために議事堂占拠するとか、だいぶすごいことになってます。

Netflix機動戦士Zガンダム
https://www.netflix.com/title/80146402?s=i&trkid=13752289

 

で、アムロ/シャア編の完結が逆襲のシャアです。Zのさらに数年後です。これが名作。劇場版オリジナル作品です。お金かかってる。ちなみにビームが線じゃなくて粒子っぽい表現になりました。メガ粒子砲という設定のためです。手描きアニメなのですごく手間がかかると思います。

Netflix機動戦士ガンダム 逆襲のシャア
https://www.netflix.com/title/60024179?s=i&trkid=13752289

 

ここまでみられたら卒業といっていいのですが、ここまでみたら、むしろ色々見たくなると思いますので続きへどうぞ。

 

ファーストとZの間の話が0083。この作品はテレビじゃなくて、有料のビデオシリーズとして展開されました(お金かかってる)。優れたメカデザイナーが参加して名作モビルスーツを多く生み出しました。富野由悠季氏以外の製作で宇宙世紀ものが展開される分岐点になった作品。

Netflix機動戦士ガンダム 0083 STARDUST MEMORY」
https://www.netflix.com/title/80146416?s=i&trkid=13752289

 

逆襲のシャアのさらに数年後がUC(ユニコーン)で、福井晴敏脚本を得て宇宙世紀ものがリブートした最新作。UCは宇宙世紀(Universal Century)の略です。絵がとても綺麗。これもビデオシリーズですが後に再編集されてビデオ公開されてます。

Netflix機動戦士ガンダムユニコーン RE:0096
https://www.netflix.com/title/80186285?s=i&trkid=1375228

 

ファーストガンダムの設定に無理がある部分を手直しした「the Origin」が、キャラクターデザインの安彦良和さんによって漫画化されてます。

 

同氏監督のアニメシリーズも近年公開されてます。お金かかってて素敵。Netflixにはないですが。

http://www.gundam-the-origin.net

 

あと第08MS小隊(ファーストガンダムと同時代のサイドストーリー)も、モビルスーツがかっこよくていいですよ。

Netflix機動戦士ガンダム 第08MS小隊
https://www.netflix.com/title/80146281?s=i&trkid=13752289

 

モビルスーツのかっこよさといえば、Thunderbolt 素晴らしいですね。これはファーストガンダムの終盤くらいの時間軸です。近年の作品でビデオシリーズなのでお金かかってます。

Netflix機動戦士ガンダム サンダーボルト
https://www.netflix.com/title/80215580?s=i&trkid=13752289

 

UCのさらに未来の話がF91宇宙世紀の続編をここから始めたかったんだと思いますが、企画自体は一作で終わってしまいました。モビルスーツが小型軽量化します。UCに出てくる小型モビルスーツ「ロト」はこの作品の設定からのフィードバックです。

Netflix機動戦士ガンダムF91 完全版」
https://www.netflix.com/title/70026237?s=i&trkid=13752289

 

あと、宇宙世紀ものではあるのですが、宇宙世紀の時間軸では最後の作品とも言えるターンAガンダム。だいぶ未来の話です。黒歴史という言葉を生み出しました。

Netflix∀ガンダム I地球光 / II月光蝶
https://www.netflix.com/title/80215428?s=i&trkid=13752289

 

 

注1: Zの翌年に放映されたZZはNetfilxにないので、一部キャラクターがなんで逆シャアに出てこないかわからないかもしれないけどそれも数名なのでまあ大丈夫でしょう。

 

以上、宇宙世紀ものでした。

 

パターンを ”使う” ワークショップ

だいぶ日本語のパターンも増えてきたので、ぼちぼちパターンを使う機会を増やしていければと思っております。

パターンというのは専門家が共有知として「良さ」を書き出したものです。それをユーザーが操作して自分なりの価値や欲しいものを表現する、という使われ方をするものだと認識しています。

例えばFearless Change だと、何か組織内に普及させたいことがあった場合に使えそうな戦略がパターンになっているので、自分の状況に合わせて、一つ一つ適用し確認することで、一歩一歩前に進む手助けになることを意図しています。もちろん考えるのも試すのもユーザーですし、書いてないことをやるのも全く問題ないわけです。ただ、組織は違えど先達がすでに歩いた道であれば、真っ暗な道で絶望して立ちすくむより、わずかな光明を伝って前に進める方がだいぶいい。

というわけで、パターンを使う側のワークショップとして、Jim Coplien のスクラムパターン研修があります。=> スクラムパターン

f:id:wayaguchi:20181021140632j:image

あと、通るかどうかわかりませんが、Regional Scrum Gathering Tokyo 2018 にも笹さんと原田巌さんがプロポーザルを出しているので、応援をお願いいたします。

Regional Scrum Gathering Tokyo 2019 - 明日現場で使える!とにかく明るいScrum Patterns 活用ワークショップ | ConfEngine - Conference Management Platform

f:id:wayaguchi:20181021140650j:image

これまで Mary Lynn Mannsさんと井庭先生に来てもらってやったこともあります。英語と比べて日本語のパターンは多くないのでハードルが高いですが、一つ一つやっていければと思います。

 

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

 
組織パターン (Object Oriented SELECTION)

組織パターン (Object Oriented SELECTION)

 
パターン、Wiki、XP ~時を超えた創造の原則 (WEB+DB PRESS plusシリーズ)

パターン、Wiki、XP ~時を超えた創造の原則 (WEB+DB PRESS plusシリーズ)

 

 



 

あなたのいうウォーターフォールとアジャイルはそんなに違うものじゃないよという話

日経SYSTEMSの安藤さんの記事が、それなりに盛り上がりまして。

3分でわかる アジャイル開発 | 日経 xTECH(クロステック)

以下の記述が、企業さんなんかを訪問させていただいて意見交換していると出てくる「私たちウォーターフォールでー」というご発言の部分をうまく写し取っているのではないかと思いました。膝ポンです。

現在多くの開発現場で利用されているウォーターフォール型の開発では、要件定義工程で要件を確定させてから、設計工程や開発(製造)工程に移る。後工程になって要件定義の漏れや変更などが発覚すると、要件定義の工程まで戻って作業をやり直さなければならない。

 要件定義の漏れや変更が発生した際、アジャイル開発では次のイテレーションの始めに要件の優先度を再検討する。これにより変更リスクに備えつつ、より価値の高いソフトを提供できるようになると言われている。

この2つは実はほとんど同じことにすぎないのではないかと思ったんです。

どういうことかというと...

A->B->C->D の手順で作る必要があるんだ!だからいつまでにAを終わらせよう、と考えるわけですが、やってみて気づくこともある。なので実際は手戻りすると思うんです。(しない仕事もあるのは認める)

で、手戻りが起こるかどうかは事前にわからないので「起きてからきちんと手戻りしよう」でもよいでしょうし「手戻りするかも/しないかも、だけどチェックポイントはあらかじめ決めとこう」もよいと思います。(たぶん前者のことをウォーターフォールとみなさん言ってて、後者がスクラム/アジャイルかな。)

 

大事なのは、手戻りするということは「計画から誤差が出る」ではなく「以前は得られていなかった情報を得て意思決定をアップデートした」ということで。

その辺がアジャイルマニフェストの「計画に従うより変化への適応を(より重視)」というところかなと思いました。

アジャイルソフトウェア開発宣言

 

皆さんはどう感じたでしょう。

安藤さん、興味深い記事ありがとうございました。

 

素晴らしいセッションを自分たちで選ぶオープンプロポーザル

Regional Scrum Gathering Tokyo では、オープンプロポーザル方式を採用しています。いわゆる公募方式でプレゼンテーションやワークショップをご提案いただき、Like数上位のものや、幅広いカテゴリにマッチするもの、最新の事例、新しい発表者など、総合的に検討してプログラムを組んでいきます。

Regional Scrum Gathering® Tokyo 2019

f:id:wayaguchi:20181017065455j:image

 

10月末までが投稿および投票の期間になっていますのでぜひ投票やコメントをお願いいたします。ぜひみんなでいいギャザリング(集まり)を作っていきましょう!

 

まだLike数が少ない最新の投稿もあります。ぜひあなたの目と手で発掘してください。最新の投稿からのリストはこちら。
Regional Scrum Gathering Tokyo 2019 - 62 Invited, Accepted and Proposed Submissions | ConfEngine - Conference Management Platform

 

f:id:wayaguchi:20181017065251j:image

「へぇ、あそこでもスクラムやってるんだ!」もし共通の課題を持っていそうな人たちなら課題の解決のヒントをもらえるかも。上司や経営陣を動かすネタに使えるかもしれません。思い切って社内勉強会での講演をお願いするのもよいかもです。

「へぇ、こんなやり方があるんだ」プラクティスや考え方を大いに参考にしましょう。もし今回セッションにならなくても、共通の話題を見つければ、3日目のOST(オープンスペーステクノロジー)で議論することもできるはず。なにかを提案すれば誰かがきっと見つけてくれます。

LikeするにはConfEngineへの登録が必要です。決まったポイントが割り振られます。手持ちのポイントを使ってLikeをしていってください。自分のプロポーザルを投稿するなど、貢献に応じてポイント残高が増えるようになっています。

 

ぜひご参加を!

次回のチケット販売は公募セッション確定後の11月中ばを予定しています。

Scrum Allianceメンバーの方は、今のうちに10%ディスカウントコードの入手を(Regional Scrum Gathering Tokyo 2019 ディスカウントコード問い合わせの例文 - kawaguti’s diary)。

サイボウズさん見学

天野さんにお誘いいただいてサイボウズさんの見学に来ました。

f:id:wayaguchi:20181004203840j:image

途中から、大友さんも加わって、だいたいこんな話をしました。カッコ内は私の反応です。

 

クラウドサービスであるKintoneの1チームからスクラムを始めて、よかったのです2,3-4 と拡大して、そのあと他の部門も支援するようになったそうです(この辺はMicrosoftがBing/Azureで変わってきた話を思い起こさせます)。1チーム、2チームはゆっくり、3-4チームへの拡大はスピード早かったとのこと。(環境を整える部分も必要なので、揃ってくると早いのかも。)

 

当初はQAをどう担保するか、とかが議論になって、開発チームが出しても、QA期間は時間がかかるんで...と。でもだんだんその辺りも理解ができてきて...。(Hunterも最初のモブは5-6人くらいで、一年半シビアバグなしで信頼を得たって言ってたなぁ)

 

組織文化としてチームワークを軸に持ってきているので、スクラムの普及はスムーズ。外の会社のことはよくわからないけど、支援してる大友さんが驚いているくらいらしいです。

 

日本では受託開発の経験がない、という人が少数なので、コミュニティで話が合わないこともある(そういえば最近あんま勉強会に行ってない...)。相談できるのがRSGTくらいしかない気がする(あざーっす!)。中途採用の人が残酷物語を教えてくれた時に新卒さんが「私もう、転職できないです..」って言っていたとか。

 

受託開発だと、というか普通の業務系の開発だと、IT部門が発注者で、ベンダーが受託したりするんだけど、IT部門の人が分かってればかなり幸せな環境ができたりする。ただそのIT部門の人が長くいるかどうかはわからなくて...。なんて話を大友さんとしました。

 

その他よもやま話をしてとても楽しかったです!HunterとかRSGTとかRSGOとかBirdの話ができて楽しかったです!

 

写真撮り損ねた!この方達です。

Regional Scrum Gathering Tokyo 2019 - プロセスを良くするだけではチームはゴミを大量に作り続ける 〜より良いプロダクトに欠かせないPO支援〜 | ConfEngine - Conference Management Platform