フラット表示 | 前のトピック | 次のトピック |
投稿者 | スレッド |
---|---|
webadm | 投稿日時: 2021-8-6 4:59 |
Webmaster 登録日: 2004-11-7 居住地: 投稿: 3107 |
ソフトウェア開発とクラッシックピアノ練習との共通点 以前の投稿でソフトウェア開発とクラッシックピアノ練習との間の共通点があることを紹介すると記憶が残っていたので、それをお伝えすることに。
・IEEEソフトウェア技術者憲章とクラッシック音楽演奏の共通点 あまり知られていないものの、米国の様々な電気電子およびソフトウェア技術標準を制定している米国IEEEではソフトウェア技術者憲章というのも制定し公開しています。 IEEEソフトウェア技術者憲章はIEEEが推奨するところのソフトウェア技術者の行動規範を定めたもので、個人的には若い時に読んで感銘を受けたので記憶にあります。その中で、ピアノの練習を始めてからクラシック音楽演奏家に共通する行動規範と共通点があることに気づきました。 使われている用語はソフトウェア開発現場の視点からですが、クラシック音楽演奏家の視点で言い換えることができます。 (1) 公共の利益を優先する ソフトウェア開発者は企業に雇われている社員や契約社員であっても、また独立した個人事業主としてのソフトウェア開発者であって、その業務は公共の利益を優先すべきと定められています。 これに反する行動とは、企業や個人の利益を優先することで、結果的に公共に不利益な行為を行うことを意味します。 クラシック音楽家の視点では、演奏はすべからく聴衆のために行われるべきであることと共通します。 まあ、クラシック音楽の練習中は演奏者自身が聴衆でもあるわけで、聴衆のために研鑽することは問題ないわけです( ´∀`) クラシック音楽の場合は、誰か他の人に聞いてもらって感銘を与えたり作曲者の思いを伝えることが重要で、自分だけのためだけに演奏するのは利己的で公共の利益からはかなり離れてしまうかもしれません。 また、プロのクラシック演奏家の場合は、有名になるとレコード会社や音楽事務所と契約を結んで収入が約束されますが、その代償としてフリーの時のように自由に人前で演奏が出来なくなり、商業的なコンサートやリサイタルや録音の配布でしか演奏を披露できなくなります。プロモーションのために無償で試聴できるビデオを作成されるときも、全曲演奏ではなく一部分だけ披露するのにとどまるのは普通です。それは公共の利益ではなく会社や事務所および演奏家の利益を優先するがため仕方がないことです。 (1) ペアプログラミング 近代になってソフトウェア開発需要が増大し、一方で開発手法そのものは旧態依然でコンピューターが登場した頃から基本的にあまり変わっていないというのが実態です。 そんな中でも、少しづつ効果的で実用的なソフトウェア開発手法が提案され、普及してきています。 その中の代表的なものが、ペアプログラミングというもので、ひとつのソフトウェア開発テーマや課題に関して、常に二人で役割分担して互いの不備を補って高品質な成果を得るというものです。 効率的な面から見ると一つの課題は一人に任せたほうが良いように見えますが、人間は完璧ではないので、ポカミスはするし期限が迫っているとプレッシャーで思考が狭くなって問題の解決のためのアイデアが枯渇することがあります。 二人を同じ課題に割り当てて、片方はプログラムの作成の役割をもう一人は片方の成果物をチェックする役割を担うようにするのがペアプログラミンの基本です。これによって、片方は作成に専念し、もう片方は成果物に欠陥が紛れ込むのを未然に防ぎます。 これはクラシック音楽の視点からは、生徒と先生のレッスンと同じです。生徒は演奏し、先生はそれを聞いて不備や改良点をアドバイスして、生徒の演奏をより良いものにします。 (3) 基本的に承認されたドキュメントに基づき作業する 現代において要求されるソフトウェアの機能や要件は日に日に複雑となり、完成すると利用者から更なる改善点が追加要求されたりすることは当たり前です。 これは求められるソフトウェアの理想的な挙動や仕様を最初の時点で詳細に定義した仕様書なりドキュメントを作成できないことに起因します。 とは言え、最初の時点ではっきりしている重要な要件に関しては、口頭や思い付きや思い込みに委ねるのではなく、ソフトウェアを最終的に受領し利用もしくは販売する発注者と正式に合意した事項を記載した承認ドキュメントに基づいて作業すべきなのです。 口頭で伝えても聞き間違いや思い込みなど聞き手の勝手な解釈によって意図したものとは異なるソフトウェアが作られる可能性が大きいのです。 ソフトウェアの場合には、出来上がってから発注者のレビューを経て、要件が一部変更される可能性があります。その場合も承認ドキュメントを改訂してそれに基づいてソフトウェアの変更やテストが行われるべきなのです。 クラシック音楽演奏家の視点では、これは作曲者の出版した楽譜に基づいて練習し、演奏することと同じです。 耳コピーや誰かが過去の演奏を聴いて採譜したもので練習して演奏しても、作曲者が意図したものと同じである保証は皆無です。 ポピュラー音楽とかでは作曲者が存在しても、楽譜そのものが存在しない(シンガーソングライターとかでは当たり前)もしくは原曲の楽譜があっても、レコーディング用に別の編曲者がアレンジしたもので演奏されたり、ライブもアルバムに収録した時とは異なるライブ用のアレンジで演奏され、演奏された時期でも演奏家が同じでも中身は同じではないというのが当たり前です。 ポピュラー音楽で作曲者が存命しているか、死後まだ著作権保護期間である場合には、作曲者や著作権を管理者の承諾なしに勝手に採譜して出版することは許されません。よほどヒットして需要のある曲でもない限り作曲者が譜面を出版することはないので、人気のある曲は大抵は第三者が採譜して原作曲者の許諾を出版社が得ていることになります(その際にロイヤリティが作曲者に支払われる)。 誰かの演奏した曲を耳で聞いて譜面化するのは個人目的利用に限り自由です。個人的には若い頃、弾けるようになりたくて仕方がないギター演奏家のレコードに遭遇して、演奏をコピーすべき練習を始めた結果、最終的には採譜してそれを見て練習するようになりました。そのために記譜法を楽典の教科書を読んで勉強しました。譜面を読む目的ではなく譜面を書くために必要不可欠だったのです。その甲斐あってクラシックピアノの練習のために譜面を読むことは苦ではないのが幸いです。 クラシック音楽では、演奏家が同じ楽譜に基づいて演奏しても細部のテンポや強弱法やアーティキュレーションについて原曲に潜在するいくつもの聞かせどころを際立たせることが可能であるものの、原曲の良さを損なわせるような変更や追加はご法度です。 もちろんクラシック音楽でも過去の名曲もしくは曲の中でこれからの時代の人も聞いて価値のある聞かせどころ部分を際立たせて新しい曲に編曲された名曲も数多くあります。これらは元となった原曲と聞き比べてみると、いかに後世の編曲者が原曲の聞かせどころを理解していたかわかります。 (4) デバッグサイクル ソフトウェアプログラムは書いたものがそのまま100%意図した通り動作することは滅多にありません。それは意図していた動作の一部を失念していてそれに関するプログラムを考えるのをすっかり忘れていたり、ちゃんと考えて作ったつもりでも考え違いや考慮不足ですべての状況で意図した通り動作しないためです。 ソフトウェア開発では、最終的に利用者が満足できる水準に達するか、開発予算や期間が尽きるまで、プログラムを書いてー>テストしてー>意図した通り動かない点を洗い出してその原因を調査して(デバッグ)ー>それを解決するためにプログラムを書き直して(サイクルの最初に戻る)を繰り返すことになります。 加えて、不具合が見つかった箇所を修正して、当該部分の単体テストを実施して不具合が再現しなくなったとしても、再度すべてのテストをやり直す必要があります。これは、不具合修正によってそれまで正常に動作していた部分に悪影響が生じる可能性があるためです。 これは、ソフトウェア開発やクラシック音楽に限らず、演奏の練習すべてに同じ事が言えて、成果物(演奏)の質の評価と改善すべき点や改善できる点を洗い出して、それぞれ各個撃破する対策を考えて実施する制御されたサイクルが無い限り、オープンコントロール(やりっぱなし)では品質の向上は得られないというプラグマティズムの考え方そのものです。 ソフトウェア開発の単体テストは、不具合が見つかったテスト項目だけを不具合が修正して解消するまで繰り返し実施することを意味し、クラシック演奏の練習では部分練習に相当します。部分練習がうまくできるようになったとしても、再度全体を通して弾くチェックを行う必要があるのも、ソフトウェア開発と同じです。 なのでピアノの練習は先生に習った方が良いと言われるのは、上記のデバッグサイクルがレッスンと練習の繰り返しによって得られるからです。もちろん、自分で自分の演奏を評価して問題点を見いだせて、解決方法も提案できるのであれば独学も可能なわけです。先生から卒業を言い渡される時がくれば、自分でそのサイクルができなければそこで演奏家としての成長は止まってしまいます。プロの演奏家でも、時々は優れた人に「私の演奏を聴いて頂けないでしょうか」とお願いして、演奏後のフィードバックに対してレッスン代をお支払いするというのは普通にあります。 ちなみに個人的には若い頃に、自分で書いたプログラムは自分で念入りに微々微細にチェックリストを作って評価していました。その過程で、実際にはその条件が発生しないけど、プログラム上はその条件が成立した時の処理を用意することが出来るというのが多々あり、そこに意図的に誤った処理を書いて完璧な物を作らないように心がけていました、人間は完璧であってはいけないのです( ´∀`) (5) 構成管理とリバースエンジニアリング 現在のコンピュータソフトウェアはどれも初期の頃と比べて膨大で複雑になってきているのと、ソフトウェア開発者がゼロからすべて書き上げるということは少なく、誰もが必要とするものはオープンソースやサードパーティが既に開発したものを流用し、二重の開発を避けることが当たり前になってきています。 その際にオープンソースソフトウェアやサードパーティソフトウェアを利用して目的のシステムを構築する際にシステム固有の部分だけを新規に開発する際に、その他の第三者が作成した部分についの機能や制限事項や設計思想を予め学習する必要があります。 オープンソースやサードパーティのソフトウェアには開発者が提供するソースコードやドキュメントがあったとしても、それらから必要な知識を取得するのはそれを利用する者の責任になります。 サードパーティソフトウェアは商業上の機密目的でそのソースコードを開示せずに、実行可能なバイナリコードのみを提供している場合が多いです。その場合には、足らない知識や情報は、実際にそれらを試用して確認する必要があります。例外的に明らかにサードパーティソフトウェア内に欠陥がある場合には、不具合の再現方法を絞り込み提供者に解決を求めるためにクレームをつける必要があります。ソースコードがあっても、どこに問題があるか、それを書いた本人以外が見つけ出すためにはリバースエンジニアリングと称する作業が不可欠です。 これはクラシック音楽でも同じで、例え楽曲のソースコードに相当する作曲者から提供された楽譜があったとしても、作曲者が意図した聞かせどころを意図した通りに演奏するためには、ソフトウェア開発でのリバースエンジニアリングに相当する解析作業が必要です。 楽曲の場合には、複数の異なる演奏部位から成り、大曲になればなるほど複雑な構成を伴ってきます。ソフトウェア開発でも沢山の人の手によるソフトウェアモジュールが組み合わさって動作するため、それらの一つ一つについてその本来意図する挙動を理解する必要があります。 大規模なソフトウェア開発では、数千や数万の小さなソフトウェアモジュールによって構成され(担当した開発者の総数は少なく見積もってもモジュール数以上になる)、全体が良好に機能するには、それぞれのモジュールの品質が保たれている必要があります。現在ではそうしたモジュール構成と依存関係を明確に認識し、個々に品質を管理する作業をソフトウェア構成管理と呼んでいます。 クラシック音楽でも、大曲を演奏する際には、全体を構成する沢山の部位についてその役割と依存関係を理解した上で、どのように演奏すべきか演奏者自身がテンポや強弱法、アーティキュレーションを適切にコントロールする必要があるのと似ています。 (6) ソースコードから伝わる作者の心理 小説や詩、短歌とかを読むと作者の思いが読む側の心に映るように思えることがあります。 それと同様に、第三者が書いたソフトウェアのソースコードを読み進めると、それを書いていた時の作者の思いが読む側に以心伝心します。 ソフトウェアのソースコードには作者自身が書き添えたコメント文があるので、それの効果もありますが、コメントが一切なくても読む側は同じ機能のものを自分で書くとしたらと常に批判的な目で見るため、自分と作者の思想の違いを感じ取りことになります。 優れたソフトウェア作者のソースコードを読むと、その考え方が優れていることが感じ取られ読む側のレベルアップにもつながります。 一方で、レベルの低いソフトウェア作者のソースコードを読むと、吐き気がする思いをすることがあります。 それでも職業プログラマの常として、第三者がやり残した仕事を引き継いで完成させなければならない時もあります。 その際には、前任者が書いた部分で気に入らないあっても、不具合につながっていない場合は、作業量を増やさないように温存するので結果、完成させても満足感は得られないものです。 個人的には前任者がやり残した部分を仕上げて欲しいと依頼された時に、前任者が書き残したソースコードを読み進めるうちに、次第に気分が滅入り、鬱状態になっていくのを感じました。原因は、顧客の相反する要件を無理やり実現しようと努力したことによることが分析の結果判明しました。後で聞いた話では、前任者は自殺したそうです。 クラシック音楽でも良い演奏では作者の思いが聴き手に伝わるように、譜面を読むことでも作者の作曲時の意図を細かく読み取ることができます。特に直筆譜では、最終形に至るまでの葛藤を知ることもできます。 譜面を分析して作者が意図した楽想を読み取ることができるのはクラシック音楽の伝統でもあります。 (7) クライアントに過剰な期待を抱かせない これも IEEE ソフトウェア技術者憲章の中にあったと思うのですが、技術的に専門家であるソフトウェア技術者は技術的に素人であるクライアント(顧客)に過剰な期待を抱かせないようにコントロールすべきというものです。 これは公共の利益を優先するという行動規範にも関係しますが、商業上の契約や受注の獲得を優先するために技術的に素人の営業担当はなにかと顧客に過剰な期待を持たせたがります。そのままにすると購買者危険を増大するリスクがあります。結果的に過剰に期待された仕様が技術的に実現不能と後に判明した場合、顧客は心理的に損失感を感じることは避けられないです。 このため専門的な知識を持つソフトウェア技術者が、実現性にリスクがある要件についてはその理由を説明して、顧客の過剰な期待を抑制する必要があります。 同じことがクラシック音楽の練習の際にも言えます。そこでは顧客は練習する本人であり、弾けたらいいなという名曲を練習し始める際に過剰な期待を持たないように注意する必要があります。 例えば演奏時間が数十分の大曲を一日で全体を通して弾けるように目指そうとか素人は期待しがちです。けど現実にはほんの一部しか初見では弾けないという現実に遭遇し過剰な期待を抱いていた場合には落胆と喪失感は半端ではありません。 練習に慣れてきて、練習の進み具合のペースとかが判ってくると一日の達成目標がどれくらいが実現可能性かというのが見えてきます。その程度に期待度を押さえて、過剰な期待を自分にかけないようにする必要があります。 個人的には毎日30分練習するうち、曲の練習は後半の15分だけなので、前日の15分よりも少しましに弾けるようになったという確証が得られたらその日の練習は終了し、十分睡眠を取るようにしています。睡眠を取ることで、運動領野との間で記憶の最適化が行われ、前日にはぎこちなかった演奏も翌日にはスムーズに弾けるようになるという不思議を毎日体験することができます。 プロのピアニストで人気が出てくると、レコード会社からレパートリーにない作曲家の大曲や名曲を録音したいというオファーが来るようになりますが、必ずしも期待に応える演奏や納得できる演奏が約束できない場合にはオファーを断るという話を聞いたことがあります。これも専門家ならではの行動規範の一例だと思います。 (8) 車輪の最発明はしない 馬車や車を製作する際に、車輪は既にあるものを真似て作れば良く、ゼロから自分で考えて作る必要はないし、時間の無駄だし、上手く行く保証はない。 新規にソフトウェアを開発する際に毎回技術者は0から新規に作るわけではないのです。 大抵の技術的な課題は既に過去に解決方法が知られているため、ゼロ知識から解決方法を探す必要がないためです。 既に過去に解決方法が実装されているライブライやパッケージがあればそれを利用することで開発期間を短縮でき、本当にゼロから始めないといけない課題にだけ注力できるからです。 同じようにピアノでも、独学だと楽譜通りに音を鳴らすのが精いっぱいで、楽譜通り弾いてもプロのピアニストが弾くように上手くは聞こえず、下手くそな演奏にしかなりません。これが独学の壁というものです。 プロのピアニストは小さい頃からプロのピアニストの先生に弟子入りして、レッスンで楽譜通り弾けるようになったのを確認したら、楽譜には書かれていない上手い演奏方法(楽譜通りではない弾き方)を伝授してくれます。先生が実際に弾いてみせて、生徒自身の演奏とまるで違うのをわかってもらうか、口頭でコツを伝えて生徒がコツを理解するまで繰り返し教えるというロイヤルゼリーみたいな形で口移しで上手い演奏ができる栄養素を与えてくれます。 多分に独学でゼロから自分で上手い演奏(解釈)を発見することができる人も居るでしょうが、ほとんどはそうでななく、誰かの演奏から耳コピーして試行錯誤しながらそれに近い演奏方法を探り当てるというのが精いっぱいだと思います。 なので独学でなく先生のレッスンを受ける場合には、最低限は楽譜通り(自分の解釈で)演奏できるようになったらレッスンに持ち込んで上手い演奏のコツを教えてもらうというのが効率が良いことは確かです。 でも先生によっては、結局生徒に車輪の最発明を強いるような指導方法をとる方も居るので要注意。生徒がよっぽど天才でないと無理。 (9) 1文字も間違えると失敗 コンピュータプログラムは、人間が読み書きできるプログラミング言語で記述したソースコードをコンパイラというプログラムに食わせてコンピュータが直接実行できる機械語コード列に変換する必要があるのですが、ソースコードの重要な記述の1文字でも間違えるとコンパイルが通らなかったり、コンパイルが通っても生成される機械語コード列が意図したものと異なってしまって意図した動作をしない結果を生みます。 コンピュータソフトウェアの開発過程でソースコード記述のタイプミスは、typoと呼ばれタイプライターで文章を打つ時の時代と同じ打ち間違いの用語で呼ばれます。 たかが一文字の間違いなら人間が読む限り、前後の関係から間違いだと気づく場合がありますが、数値や演算記号(+、ー等)はそうではありません。 昔人工衛星の打ち上げに失敗した原因が、制御プログラムで一文字の間違いだったというエピソードがあります。 ピアノ演奏でも音の列の中で1音間違えると致命的な箇所があるのと同様に、間違えても致命的にはならない箇所も存在します。 ソフトウェアでも一文字間違えても影響が少ない部分と致命的な部分があり共通します。 (10)構造化プログラミング コンピュータが生まれた当初は実行できるプログラムの規模も小さかったので、最初に実行されるステップから順番に考えてくみたてるればよかったけど、次第に規模の大きいプログラムが組めるようになると、大きなプログラムを組む難しさが露見してきます。 人間が普段の会話で話す短い内容であれば即興で出てくるものの、3分間みんなの前で何かスピーチしなさいと言われると、即興でそれを行うのは難しいのと同じです。 コンピュータが最初に実行する部分では、最初にやっておかないと行けないことだけをやって、難しい処理や重要な処理はそれだけを切り出して不備の無いように設計し、それらを必要なタイミングで随時呼び出す沢山の枝を持つメインフローを幹としてしっかりとした安定した大樹を作る必要があります。 演説とかも、ちゃんと全体構成を考えて、出だしはキャッチングな触りで視聴者の注意を惹きつけておいて、中盤は飽きさせないように緩急に富んだ話題を繰り出し、最後に締めとなる印象的で感動を与える結末で終わります。 ピアノ芸術も同様に、作曲者が予め念入りに構成した序盤と中盤それに最後のコーダと終結部を視聴者が飽きないように忠実にメリハリのある演奏することが求められます。それには作曲者が曲を構成する各部位に何を意図していたのか読み取る必要があります。それは作曲の知識も必要になります。 今のところ思いついたのは上記の10だけですが、また何か気づいたらお便りします。 |
フラット表示 | 前のトピック | 次のトピック |
題名 | 投稿者 | 日時 |
---|---|---|
» ソフトウェア開発とクラッシックピアノ練習との共通点 | webadm | 2021-8-6 4:59 |