DB技術者として伝えるべき技術について考える [コミュニティ]
先日、図書館でふと目に止まったのが畑村洋太郎氏の「組織を強くする技術の伝え方」という本であった。失敗学のすすめなどで有名な先生である。比較的薄い本でさらりと読めてしまったので、印象に残ったこと、考えたことを簡単にメモしておく。
伝える上で大切なこととしてまず言っていることは、受け入れの素地を作ること。これは知識の吸収は、伝えられる側の知識を吸収しようとする意欲に大きく関係するため、そのような状況を作りだすことが大切ということである。そのためには、本人が自発的に動くような状況を作ったり、また、脳の要求を利用し、マズローによる人間の５段階の欲求にある自己実現の欲求をうまく利用することも良いらしい。その上で、技術を伝える方法について以下の５つのポイントを紹介している。
・まず体験させろ
・はじめに全体を見せろ
・やらせたことの結果を確認しろ
・一度に全部を伝える必要はない
・個はそれぞれ違うことを認めろ
これはその通りだなと思ったのだが、これ以上に１つ面白いと思ったのは、著者がここでいう「技術」の定義である。技術は、「知識やシステムを使い他の人と関係しながら全体を作り上げていくやり方」と定義している。つまり、個人に閉じた世界でのやり方ではなく、組織あるいはチームである製品開発をしたりするためのやり方が技術である、と言っているのである。技術が伝わらないと、組織として競争力のある製品を世に送り続けることが難しくなったり、（品質の問題から）望まぬ事故を引き起こしたりすることに繋がったりする、という訳である。
上記定義に照らし合わせれば、これは製品開発に限った話ではなく、SIの中にも伝えていくべき多くの技術があるのではないかと考えさせられた。要するに、「全体」というのを、「ITシステム」あるいは「ITサービス」と言い換えるとわかりやすいかもしれない。例えばデータベース技術者として、知識やシステム（ベンダ製品）を使い他の人と関係しながらITシステムを作り上げていくやり方、には具体的に何があるだろうか。ぱっと思いつくことだけでもいくつか挙げられる。
・APの動作に必要なデータベースの環境要件を適切に捉え設計・構築するDB基盤構築技術
・APに必要なデータを格納するテーブル（パーティション）・索引を設計・実装するモデリング技術
・試験に必要なテーブルを作成したり、データをロードしたり、バックアップ・リストアするデータ管理技術
・データベース製品のアーキテクチャを踏まえ、効果的なAPの処理方式を決定する処理方式設計技術
・APの性能を担保するための性能確保技術、性能遅延に伴う性能（SQL、インスタンス）チューニング技術
・データベースの障害（結果不正、データ破壊、インスタンスダウン等）に伴う解析やトラブル対応技術
これらに関して言えば、テクノロジーは変われどSIの中での必要性は今も昔も変わっていないと思う。もちろん、時代によって製品機能や利用できるサービスは変わるので、蓄積する技術の重要性は変遷するだろう。例えばクラウド時代においては、環境構築やバックアップはボタン１つでできるので、技術の蓄積の重要度が下がるだろう。一方、面が簡単に増やせるだけに、より多数の面を管理しなければならないため、データ管理技術の方がより重要性が増すだろう。OracleのautonomouseやAP透過なIn-memoryが功を奏せば、チューニングの重要性は減っていくかもしれない。しかし、よりクラウドというサービスでブラックボックス化された中でトラブルが発生した場合は、より高度なトラシュー力が求められるかもしれない。自動パッチでしょうもない不具合に悩まされることは減っても、設計に起因するトラブルは避けられないので、設計・サイジングは変わらず重要、といった具合である。
私がよくノウハウとして残すドキュメントは、Oracleに関する以下のようなものである。
・致命的不具合など、同じバージョンで他のPJでも発生するようなクリティカルなもの
・製品の基本的なアーキテクチャ
・新機能のユースケースとして役立つ利用技術
これらは、かなりOracle製品に特化したノウハウであり、上記の定義からは技術と呼ぶには難しいかもしれない。特に不具合情報などは長期的に見れば一過性のものであり、いずれPSUに取り込まれるからである。しかし、例えば、運用中にOracleの12.2である不具合に遭遇したとする。発生事象から、問題を切り分け、本質的な問題（不具合）を特定し、運用中の暫定対処（隠しパラメータの変更等）、本格対処（パッチ適用）という一連の流れを他者とかかわりあいながら実施することとなる。もしトラシュー技術なるものがあるとすれば、不具合情報を伝えるというより、一段メタな対処のプロセスや考え方なのではないか。
また、アーキテクチャについては、これがアーキテクチャの説明にとどまらず、APの処理方式や運用に関する何らかの規約（べし・べからず集）になるものであれば、これは他の人と関係しながら作り上げるやり方（技術）と呼べるのではないか。例えば、APはバインド変数を使うこと、DDLは業務繁忙時間帯の実行は避けること、等である。また、新機能についても、例えばマルチテナントにより、面の展開がクローンコピーで楽にできるようになるといった、データ管理のユースケースに紐づけば、これも技術と言ってよいかもしれない。
Oracle技術者として5年10年経てば、多かれ少なかれ若手を指導する機会が出てくるだろうし、何から始めようと悩むこともあるだろう。そこで伝えていくべき技術とは、構築ならrunInstallerでDB構築する方法だったり、運用ならAWRのtop10の待機イベントの読み方だったり、様々であろう。しかし、それらの知識は単体で存在するわけではなく、上記のような様々な場面（ユースケース）において多かれ少なかれ他者とかかわりあいながら物事を進めていくために存在しており、その位置づけを理解することが、「受け入れの素地づくり」に決定的に重要なのかもしれない。体験させて、全体を見せることにより、受け入れの素地が作られれば、おのずと吸収の環境ができる。そうすればより効率よく本質的な技術を伝えていけるのかもしれない、と考えるのである。そういう伝え方ができていたか、振り返る良い機会になった。
なお、本Blogで記載している多くの記事は自分のための備忘（将来の自分への思考の記録）と、もしかすると他システムへの共有で役立つことがあるかもしれない、という期待が少しある。不具合事象の共有は賞味期限は短い（ただ、インパクトが大きければ価値はあるだろうが）が、上記技術に対する考え方やアプローチは、抽象度は上がるものの、時代や組織を超えて長く使えるものとなるに違いない。そういう記事を残していければよりDBAの世界平和にわずかながらでも貢献できるのかもしれない。
以上
◆参考文献
伝える上で大切なこととしてまず言っていることは、受け入れの素地を作ること。これは知識の吸収は、伝えられる側の知識を吸収しようとする意欲に大きく関係するため、そのような状況を作りだすことが大切ということである。そのためには、本人が自発的に動くような状況を作ったり、また、脳の要求を利用し、マズローによる人間の５段階の欲求にある自己実現の欲求をうまく利用することも良いらしい。その上で、技術を伝える方法について以下の５つのポイントを紹介している。
・まず体験させろ
・はじめに全体を見せろ
・やらせたことの結果を確認しろ
・一度に全部を伝える必要はない
・個はそれぞれ違うことを認めろ
これはその通りだなと思ったのだが、これ以上に１つ面白いと思ったのは、著者がここでいう「技術」の定義である。技術は、「知識やシステムを使い他の人と関係しながら全体を作り上げていくやり方」と定義している。つまり、個人に閉じた世界でのやり方ではなく、組織あるいはチームである製品開発をしたりするためのやり方が技術である、と言っているのである。技術が伝わらないと、組織として競争力のある製品を世に送り続けることが難しくなったり、（品質の問題から）望まぬ事故を引き起こしたりすることに繋がったりする、という訳である。
上記定義に照らし合わせれば、これは製品開発に限った話ではなく、SIの中にも伝えていくべき多くの技術があるのではないかと考えさせられた。要するに、「全体」というのを、「ITシステム」あるいは「ITサービス」と言い換えるとわかりやすいかもしれない。例えばデータベース技術者として、知識やシステム（ベンダ製品）を使い他の人と関係しながらITシステムを作り上げていくやり方、には具体的に何があるだろうか。ぱっと思いつくことだけでもいくつか挙げられる。
・APの動作に必要なデータベースの環境要件を適切に捉え設計・構築するDB基盤構築技術
・APに必要なデータを格納するテーブル（パーティション）・索引を設計・実装するモデリング技術
・試験に必要なテーブルを作成したり、データをロードしたり、バックアップ・リストアするデータ管理技術
・データベース製品のアーキテクチャを踏まえ、効果的なAPの処理方式を決定する処理方式設計技術
・APの性能を担保するための性能確保技術、性能遅延に伴う性能（SQL、インスタンス）チューニング技術
・データベースの障害（結果不正、データ破壊、インスタンスダウン等）に伴う解析やトラブル対応技術
これらに関して言えば、テクノロジーは変われどSIの中での必要性は今も昔も変わっていないと思う。もちろん、時代によって製品機能や利用できるサービスは変わるので、蓄積する技術の重要性は変遷するだろう。例えばクラウド時代においては、環境構築やバックアップはボタン１つでできるので、技術の蓄積の重要度が下がるだろう。一方、面が簡単に増やせるだけに、より多数の面を管理しなければならないため、データ管理技術の方がより重要性が増すだろう。OracleのautonomouseやAP透過なIn-memoryが功を奏せば、チューニングの重要性は減っていくかもしれない。しかし、よりクラウドというサービスでブラックボックス化された中でトラブルが発生した場合は、より高度なトラシュー力が求められるかもしれない。自動パッチでしょうもない不具合に悩まされることは減っても、設計に起因するトラブルは避けられないので、設計・サイジングは変わらず重要、といった具合である。
私がよくノウハウとして残すドキュメントは、Oracleに関する以下のようなものである。
・致命的不具合など、同じバージョンで他のPJでも発生するようなクリティカルなもの
・製品の基本的なアーキテクチャ
・新機能のユースケースとして役立つ利用技術
これらは、かなりOracle製品に特化したノウハウであり、上記の定義からは技術と呼ぶには難しいかもしれない。特に不具合情報などは長期的に見れば一過性のものであり、いずれPSUに取り込まれるからである。しかし、例えば、運用中にOracleの12.2である不具合に遭遇したとする。発生事象から、問題を切り分け、本質的な問題（不具合）を特定し、運用中の暫定対処（隠しパラメータの変更等）、本格対処（パッチ適用）という一連の流れを他者とかかわりあいながら実施することとなる。もしトラシュー技術なるものがあるとすれば、不具合情報を伝えるというより、一段メタな対処のプロセスや考え方なのではないか。
また、アーキテクチャについては、これがアーキテクチャの説明にとどまらず、APの処理方式や運用に関する何らかの規約（べし・べからず集）になるものであれば、これは他の人と関係しながら作り上げるやり方（技術）と呼べるのではないか。例えば、APはバインド変数を使うこと、DDLは業務繁忙時間帯の実行は避けること、等である。また、新機能についても、例えばマルチテナントにより、面の展開がクローンコピーで楽にできるようになるといった、データ管理のユースケースに紐づけば、これも技術と言ってよいかもしれない。
Oracle技術者として5年10年経てば、多かれ少なかれ若手を指導する機会が出てくるだろうし、何から始めようと悩むこともあるだろう。そこで伝えていくべき技術とは、構築ならrunInstallerでDB構築する方法だったり、運用ならAWRのtop10の待機イベントの読み方だったり、様々であろう。しかし、それらの知識は単体で存在するわけではなく、上記のような様々な場面（ユースケース）において多かれ少なかれ他者とかかわりあいながら物事を進めていくために存在しており、その位置づけを理解することが、「受け入れの素地づくり」に決定的に重要なのかもしれない。体験させて、全体を見せることにより、受け入れの素地が作られれば、おのずと吸収の環境ができる。そうすればより効率よく本質的な技術を伝えていけるのかもしれない、と考えるのである。そういう伝え方ができていたか、振り返る良い機会になった。
なお、本Blogで記載している多くの記事は自分のための備忘（将来の自分への思考の記録）と、もしかすると他システムへの共有で役立つことがあるかもしれない、という期待が少しある。不具合事象の共有は賞味期限は短い（ただ、インパクトが大きければ価値はあるだろうが）が、上記技術に対する考え方やアプローチは、抽象度は上がるものの、時代や組織を超えて長く使えるものとなるに違いない。そういう記事を残していければよりDBAの世界平和にわずかながらでも貢献できるのかもしれない。
以上
◆参考文献
- 作者: 畑村 洋太郎
- 出版社/メーカー: 講談社
- 発売日: 2006/12/19
- メディア: 新書
