P81 問題解決のステップと合意形成のステップ

【問題解決のステップ】
問題解決のステップには様々な考え方があるが、
あらゆる領域で活用可能な「What→Where→Why→How」の4つのステップを紹介する。

●What:何が問題なのか?(問題意識の明確化)
●Where:どこが問題なのか?(問題箇所の特定)
●Why:問題が生じる原因は何か?(真因の追及)
●How:どうするのか?(対策の立案・実行)

こうした考え方が必要なのは、決め打ちやしらみ潰しなどに陥らない様にするためである。
また、上記考え方を思考の癖にすることは重要である。
人は多くの場合、どうしたらよいのか(How)から考えてしまう、
もしくは、なぜそうなっているのか(Why)から考え始める傾向が強い。
一時的には状況が改善できても、しばらくすると同様の問題が再発する事が往々にしてある。
これは、本質的な原因に対処できていないためである。
また、事前に何が問題なのかを正しく課題設定しておかないと、
別に重要ではないこと、そもそも問題ではない事を考える無駄が発生してしまう。

【合意形成のステップ】
合意形成のステップの中に問題解決のステップが組み込まれている。
以下の合意形成のステップの内、アクションの理由の共有・合意を取る際の手法が問題解決のステップである。

●場の目的共有
問題解決のステップの前段
 ・議論の場の目的自体は何か?
 ・合意のための手続きは妥当か?
 ・参加者への期待役割は何か?

●アクション理由の共有・合意
問題解決ステップのWhat、Where、Whyの3つのステップを含む
 ・問題意識の明確化(What)
  あるべき姿の要件を洗い出す
  具体化して議論するプロセスを通じて問題意識を共有する
 ・問題箇所の特定(Where)
  広げて、絞る
  Whyに飛ばず、Whereに留まることが問題解決の肝
  共通点・相違点に着目して問題の構造をあぶりだす
 ・真因の追及(Why)
  原因の把握にこそ、多くの意見が必要
  広げる→絞り込む→深める
  MECEだけでなく、状況の映像化、イメージアップすることによる状況整理、把握

●アクションの選択と合意、実行プラン・コミットの確認・共有
上記2つは問題解決のステップのHowに当たる
 [アクションの選択と合意]
 ・取りうる選択肢は何か
 ・どのような基準で選択するか
 ・選択した場合の想定されるリスクや対応策は何か
 [実行プラン・コミットの確認・共有]
 ・実行プランをどうするか
 ・各自の役割は何か
 ・実行時に生じる判断や意思決定をどの様に行うか

書籍には上記内容が図解で分かりやすく解説がされている。

SSMS[SQL Server Management Studio]のポート番号の指定方法

指定方法

ホスト名, ポート番号
ポート番号を省略すると1433に自動接続
補記事項
ホスト名\インスタンス名, ポート番号

その他

ログイン時にデータベースを指定したい場合

接続プロパティでデータベース名を指定
(但し、別に指定しなくてもつながるし、後から選べる)

通常は編集しなくても問題無
インスタンス名などの確認方法
確認対象 確認方法
インスタンス select ** @@SERVERNAME
データベース名 SELECT DB_NAME()
データベース名一覧 SELECT name, database_id, create_date FROM sys.databases;
スキーマ SELECT SCHEMA_NAME()
スキーマ名一覧 select * from sys.schemas order by schema_id;
テーブル名一覧 select * from sys.tables order by schema_id, name;

補記事項

インスタンス

・サーバー名と記載する場合有
・名前が設定されていない場合がある(これを既定のインスタンスと呼ぶ)
 一方名前が付与されている場合は、名前付きインスタンスと呼ぶ

ユーザー周りの関連性

●キーワード
・ログイン:ログイン時に利用するID
・ユーザー:データベースにアクセスする際のID
スキーマ:データベースのデータを格納する領域

●ログインとユーザーが分かれている理由
ログインした際にデータベースにアクセスするユーザーを切替できる
そのため、ログイン名はuser1でログインを行った際、
データベースAはuserA、データベースBはuserBとすることができる
データベースが複数ある場合は便利、一つだけの場合はややこしい
また、データベース毎にユーザーを作成する必要有(※1)
※1 あまりSQL Server使いこなせてないので、共用する方法あるかもしれないが

●ユーザーとスキーマの関連性
デフォルトロールという設定は行う必要はある
しかし、Oracleの様にユーザー=スキーマという関係性はない
MySQLの様にユーザーとスキーマは個別管理という関係性である

サクラエディタでキーマクロを保存しようとするとエラー

事象

サクラエディタでキーマクロを実行して保存しようとすると、
 マクロファイルを作成できませんでした。
 c:\Program Files (x86)\sakura\RecKey.mac
というエラーが発生して保存できない。

対応方法

いくつか手段はあると思うが、面倒なのでフォルダを
 c:\ProgramData\sakura
とProgram Files以外に移動させた。

Unicodeと日本語関連の文字種規格

イメージ図

なお、図中の幅にあまり意味は無いです
(あくまでも覚えやすさを重視した概念図です)

図中の線の間隔幅に漢字登録数などの意味は無いです(覚えさすさ重視)

補足説明

  • Unicodeは、JIS第一~四水準漢字や、IBM拡張文字等に加え、外字も含め全てサポートする。
  • JIS第三~四水準漢字はUnicodeで表現できるが、それがサロゲートペア文字である場合もある。
  • JISの漢字規格もいくつか種類があるので、ややこしさの原因の一因である。
  • JIS第一~四水準漢字に含まれない漢字(例:𠮷[つちよし、牛丼屋の吉])も存在する。JIS規格外漢字がサロゲートペアである場合もあれば、そうでない場合もある。
  • IBM拡張文字も第三水準や第四水準と被る部分も存在する。しかし、被らない(JIS規格外)漢字(例:髙[はしごだか])も存在する。但し、サロゲートペア文字の範囲には現れない。
  • 外字は私用領域で登録する必要があり、どの規格とも被らない。(被るのであれば、わざわざ外字登録する必要がないため)

リアルタイム文字コード解析ツール

本当にこんなサイトが昔から欲しかった
www.natade.net

P211 バリューストリームマッピングとECRS

●バリューストリームマッピング
ものや情報の流れを洗い出してから、ボトルネックや手戻り箇所を特定し、改善を実施する。
結果、顧客が成果を手に入れるまでの時間削減を狙う。
DevOps プロセス: バリュー ストリームでの作業の可視性  |  Google Cloud

●ECRS
Eliminate(排除)、Combine(結合)、Rearrange(交換)、Simplify(簡素化)の略語である。
効果が疑わしい形骸化した工程自体を全面削除したり(E)、
工程を結合させて待ち時間を減らしたり(C)、
チェック工程を先に持ってきて品質を作り込んでから後工程に流したり(R)、
ツールを使ったいたものを統一して簡素化させたりして(S)、
全体最適化を図ること。
ECRSの4原則で始める、引き算の改善|ものづくりの現場トピックス | キーエンス

Tomcat7のmanagerにアクセスすると403エラーが返ってくる

【事象】
Tomcat7のバージョンを7.0.107.0にバージョンアップを行った。
すると今までアクセスできていたと思われる(※1)Tomcatマネージャーにアクセスできなくなった。
結果、アクセスしても403エラーが返ってくる

※1 自分で管理しておらず、野ざらし鯖の対応をしたので
 以下の痕跡があったので、以前はアクセスできていたと考えている

(${CATANILA_HOME}/conf/tomcat-user.xml)

(中略)
<role rolename="manager-gui" />
<user username="hoge" password="hogehoge" roles="manager-gui" />

【原因】
Tomcatマネージャーに対するアクセス制御設定が足りていなかったため

【対応方法】
${CATALINA_HOME}/webapps/manager/META-INF/context.xml を修正する。
具体的には、コメントアウト対応するか、addressの値をアクセスしてくるIPを追加する。

(中略)
<Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1" />

なお、host-manager側にも同様のファイルが存在するが、こちらは編集しなくても良さげである。
(デフォルトでコメントアウトされているため、制約がかかっていない)

【補記事項】
なお、${CATALINA_HOME/conf/}server.xmlにも以下の記載が必要である。(※3, 4)

(中略)
<Connector protocol "AJP/1.3" secretRequired="false" address="::1" port="8009" redirectPort="8443" />

※3 Apaceh HTTP ServerがsecretRequired=trueに対応しているバージョンであれば変更しておくべき
※4 上記addressの値はガバガバ設定なので、きちんとアクセス制御する値に設定変更する必要有

【注意事項】
どうもmanager配下のcontext.xmlのallowは、ブラウザ側のIPを評価している模様である。
一方、conf配下のserver.xmlのaddressは、AJP通信元(当例ではhttpd)を評価している模様である。
そのため、どちらもローカルのIPアドレスを抜かす設定にしていたらTomcatマネージャーにアクセスできず、
context.xml側だけブラウザ側のIPアドレスを追加するとTomcatマネージャーにアクセスできる様になった。
(もしかしたら、自分のserver.xmlの設定が間違えているだけかもしれないが…)

詳解 Tomcat

詳解 Tomcat

なお、Tomcat7は2021/3/31で修正パッチが出なくなります。。。
yoneyore.hatenablog.com

Apache / Tomcat のバージョン情報を隠す方法

Tomcatのバージョン情報を隠す方法

レスポンスヘッダ:Apache HTTP Server)

httpd.confにServerTokens Prodを追加する
weblabo.oscasierra.net

レスポンスヘッダ:Tomcat

server.xmlのConnectorのserver情報を加工する(※1)
dev.classmethod.jp

エラーページ[※2]

server.xmlにErrorReportValveを追加する
なお、HostタグにもerrorReportValveClass定義が存在する(自身では試した事がない)

意外と知られていない、Tomcatのエラーページのバージョン番号の簡単な隠し方
t246osslab.wordpress.com
Tomcatがバージョン情報参照している箇所や、それの修正方法についても言及してくれています。

※1 ConnectorがHTTPの場合は指定可能であるが、AJPの場合は指定不可能(=Tomcatの情報自体返却されない)
Apache Tomcat 9 Configuration Reference (9.0.87) - The HTTP Connector
Apache Tomcat 9 Configuration Reference (9.0.87) - The AJP Connector
※2 そもそもエラーページは別途作成しておいた方がとか

TomEEを利用する際の注意点

  • どうもTomEEがserver.infoのバージョン情報まで確認しているっぽいので、server.infoは修正できなさそう

 (挙動レベルできちんとした確認まではしていない)

  • server.infoを少し加工して記載しても、TomEEのバージョン情報は出力されてしまう
バージョン情報をコンソールで取得する方法

(Apache HTTP Server)

httpd -V

(Tomcat)

${CATALINA_HOME}/bin/version.sh

(TomEE)
今のところtomeeのjarの命名規則にバージョン番号が付与されている