makotan _at_ gmail dot com

認知範囲

人にはそれぞれ認知してる範囲があって

その範囲外のことは知る事が出来ない

でもその範囲外からの影響を受けることが多々あって

それの反応は

無視する

拒絶する

受け入れる

の3つ、それぞれメリット・デメリットはあるけど

 

 

ただ、人が他人の能力を見る時は自分の認知範囲に他人の認知範囲を重ねるので、案外低く見がちになる。

特に自己評価の高い人は認知範囲が広いと思い込んでる場合があるので面倒なことになる

 

 

極まれに認知範囲のめっちゃ広い人とか、そもそも認知範囲が存在しないような動きの人がいる。

この二つの人を識別するのは難しい

 

 

認知範囲を広げる方法は唯一、範囲外からの影響を受け入れて興味を持つことだなぁ〜って思った

 

要はバランスなんですよ・・・っていう意味

あるときに「そのバランスをどう取るのかが難しいんだよ!」って聞こえてきて、そうなんだ・・・なんでだろ・・・って思っててしばらくしてお風呂で理解した

 

 

バランスを取るには

周囲の力関係の理解が必要で

周囲の力関係の中で良い塩梅に設定することを

要はバランスなんですよ〜の一言で片付けてた

まずは周囲の力関係の理解を先にしないと意味がなかった

 

 

ということで、周りのライトサイドとダークサイドの力関係を理解しつつ

フォースのバランスをとることが大事って事で

シスにならないように頑張る

ってことですね

(↑これを書きたかっただけ

 

設計とか...

気になったって話でそれ以上のオチは無い

色んな人と話をしていると、プログラミングは出来る。 しかしテーブル設計が出来ないとか、設計技法はあまり知らないって人が一定数居ることに気がついた (居ること自体は個人的にはどうでも良いんだけど...知らない事があるなら勉強すれば良いのでは?って思ってるだけなので)

プログラムには必ず裏にデータモデルがあって、どっちが重要って事もないし プログラムを楽に作るには必ずデータモデルの設計があって データモデルの設計の一つにテーブル設計があって それらを手順化して組み合わせたのが設計技法だったりするわけで...

プログラムが出来るのに設計が出来ないってどういうことだろう・・・というか出来るってなに?って思ったw

最近の設計・実装のながれ

随分前とだいぶ変わったのでメモ代わりに

 

# 原則

  • 処理で2次元を超えるのデータは可能な限り設計段階で避ける
  • 処理で2次元を超えるのデータは可能な限り実装段階でも避ける
  • 次元数は可能な限りあげないように設計段階で避ける
  • どう頑張っても2次元を超えるなら漏れないルールを作る

# メモ

1次元のデータを扱う実装は簡単に作れてあんまりミスが起きない

2次元までは人が頑張れば作れる

3次元以上は能力的に圧倒的な差が生まれる

なので、1次元〜2次元のデータを扱うようにすると・・・一部がだいぶ多次元にならざるを得ないので、そこをルールでがんばって押さえ込む

 

「なに」と「どう」

何を作るのか

どう仕組みを作るのか

何で作るのか

どういう手順で作るのか

何で運用するのか

どう運用するのか

 

っていうのがバラバラに存在してて、個別に議論されてて

でも、議論してる人達がみんなそれぞれ別の「なに」と「どう」を抱えてるのがうっすら透けて見えてて、それを認識できてなさそうな人達がいろんな形で絡んだりしてて

世の中はなかなか難しいな

って思ったお昼のひと時

 

手法とか技術力とかの差異をぼんやり考えてたら...

前提として

ある人が可能なことと、他の人が可能なことは一致しない

ただし、色々と学習や経験をしていくと可能になったりする

 

何を考えたか

作るべきソフトウェアは実際には形状の決まってない 何か である

それを各自の持つフィルターを通してみることで形状が見える

フィルターの形と大きさと透明度は各自に差がある

この各自の差が能力的な差に繋がる

 

あるエンジニアJは

ABCっていうフィルターを使えるエンジニアは

ABCっていうフィルターでソフトウェアを理解しようとする

その結果、ABCっていうフィルターを通した形ソフトウェアが完成する

 

あるエンジニアIはABCとCDEっていうフィルターを直感的に適切に使い分けている

ただし、通常はABCっていうフィルターが好きなのでABCを使おうってみんなに言う

ABCしか使えないエンジニアJは、エンジニアIの言うことに従えば同じ事が出来ると思い込んで、CDEのフィルターを学習せずにやってみる

結果的に上手くいったり、上手くいかなかったりする

これはABCっていうフィルターの問題ではなく、フィルターは複数を使い分けるべき事があるって事を指してる

 

エンジニアの初期の頃はフィルターの大きさは小さく透明度も低い

それが経験を通して大きく、透明度が上がる

結果的に作るべきソフトウェアがよく見えるようになる

これが容易に超えられない経験の差として見えるようになる

単なる経験年数を積み重ねたところでフィルターの大きさとか透明度は上がらないので、フィルターを大きくして透明度を上げる努力が必要になる

 

そもそもの作るべきソフトウェアは形状の決まってなく観測したフィルターによって見える形が変わるのなら、単独のフィルターの優劣はそこまで影響はなくて

いくつのフィルターを使えるのか、それぞれの大きさと透明度はどのくらいなのかが実はエンジニアとチームの優秀さの決定ポイントなのでは?って思った

 

要件を考えるときにぼんやりやってること

発生元の分析

発生元(要件を言ってる人)が何を考えて、どのレベルのことを言っているのかを把握する

大体発生元から流れてくる情報はこの3つ(とその組み合わせ)に分類される

  • 目的を言っている
  • 解決策を言っている(目的は言ってない)
  • 現状の問題点を言っている

目的だけを言ってる場合

頻度は高くないけど、目的だけを提示してくる場合がある

目的だけなので、そこから解決策の決定とか色々検討が必要になる

ただ、自由度は非常に高いけど自由度が高いから難しい

この場合は現状の調査と目的との差を探って解決策を練るっていう理想的な工程を踏めるので、個人的には楽しい

解決策を言ってくる(目的は言ってない)

このパターンは楽そうに見えて結構面倒なので要注意

発生元がちゃんと目的を持って検討した上で解決策を提示しているのか、それとも思いつきのように解決策を提示したのかの判断が必要

場合によっては目的の再構成から始める方が良い

ここをミスると無駄な作業が増える

現状の問題点を言っている

現状が問題だということをひたすら言ってくるパターン

そもそもの目的がないので理想的には問題解決をするために目的を作る所からスタートして、解決策を練るのが良い。

このパターンしか言わない人も多いので慣れるしかない

発生元の分析の後の作業

発生元の分析の結果はこの4つを作る事

  • 現状
  • 目的
  • 課題(目的と現状の差)
  • 解決案(課題をクリアするための方策)

解決案で目的が達成できるならその解決案を実現するという工程に入る

解決案の実現の時の判断基準として必要なので、目的を常に認識しておくこと

 

 

 

自分は普通にやってたけど、意外と知らない人も多いみたいなのでメモとして...