今回は紅と白。花にまつわる禅語をチョイスしてみました。
自然を愛でながら「その先にある自らを考える」先人の心持ちを少しでもお届けできるとよいのですが。
禅語「柳緑花紅真面目」
ランク：上級 カテゴリ：現場スキル
柳緑花紅真面目。この禅語を一言で片付けると「あるがまま」という意味合いです。
では。何がどう「あるがまま」で、それは技術の現場でどのように役立つのでしょうか？
例えば。
サービスを作成するのに、どのOSを用いるべきなのか。どんなプロトコルが適切なのか。どんな言語が、どんなクラス設計が、テーブルの切り方が、開発手法が、その他諸々。
様々に、決定しなくてはいけない事項が、プロジェクトには多々含まれています。
そんなときに、あなたはどんな基準でその決定をくだしているのでしょうか？
いったん少々話を散らかして、最後で一気にまとめてみます。
少々話があちこちに飛びますが、のんびりついてきてください。
「“可能である”と“適切である”との間には深い溝がある」という話を、技術の現場で私はするのですが、正直なところ、大抵の「要求に対する実装」は、少々ひねた手順も考慮しますと「不可能である」というのはあまりないのが実際です。
少々古い話にはなりますが……今からン年ほど前。「CGIといえばPerl」というのが割合にポピュラーな選択肢だったころがあるのですが。筆者の友人で「bashで組んでた」なんていう猛者もいました。……などという筆者も、特段注文がなければC言語でCGIを組んでましたからあまり人様のことを言えた義理ではありません（苦笑
つまり。大抵の実装方法で、要求の実現は「可能」ではあるんですね。
ただ……「可能である」というだけでチョイスをしてしまうと、特にビジネスの現場において困ることが発生することが少なからずあります。
手前味噌な話が続いて恐縮ですが。
私は現在、まず滅多にC言語でCGIを組みません（皆無ではないのですが）。
確かに、C言語でちゃんと組むと「軽くて早い」ものは作れるのですが、例えば「ほかの人に引き継ぐ」ということがほとんど出来ません。
そのために。「C言語でCGI(Webアプリケーション)を作成する」という選択肢は「可能」ではあるのですが、後々の運用などを考慮に入れると適切ではないという判断になるのですね。
現状であれば、PHPなりJavaなりPerlなり。昨今ですとRubyも選択肢に入りつつあると思うのですが、おそらく現状においてはそのあたりが「エンジニアを調達しやすい」という観点からは「適切な」言語チョイスであるように思います（無論それ以外の観点も多々あるのですが）。
面白いもので。
技術の世界……に限らないのですが、「最適な手段」というのは大抵において「最短距離かつシンプル」です。
言い方を変えると「必要十分にして最低限」。MECEとかKISS原則とかを想起させる感じですね。
ちなみに。ここで注意していただきたいのですが、「普通＊＊だから」という発想は大変に危険です。
靴の世界の職人さんに曰く「“普通の足”というものは存在しない」とは素晴らしい名言ですが、システムも同様で「普通のシステム」なんていうものは存在しません。存在するのは「お客様が欲しいと切望しているシステム」だけです。
ですので。考慮した上で「一般的に＊＊であることが多く、今回のシステムにおいてもその利点を享受することができるから」という理由はよろしいですが「普通＊＊であれば○○だから」と、無考察に何かをチョイスするのは、それはそれでよろしくない、ということになります。
そのあたりは十分に留意しておきたいところです。
さて。
話を戻し、まとめてみましょう。
様々にある、プロジェクトにおける「決定しなくてはいけない」選択肢を、あなたはどんな基準で決定していますか？
必要なのは、たくさんの選択肢の中から「お客様の今回の要求」に対して「もっとも適している」ものを選ぶことです。
つまり「あるがまま」。
無理のないところに無理のない技術を当てはめれば、それは自然なチョイスになります。
自然なチョイスであれば、変に迂回路をつくる必要もなければ奇妙なTipsに頼る必要もなく、シンプルで真っ直ぐなシステムになります。
ものごとには、それは自然であろうが技術であろうが変わらず、あらゆるものには「個性」が備わっています。
柳緑花紅真面目。
柳は緑。花は紅。当たり前のあるがままを真っ直ぐに捉えよう、という意味が、この禅語には込められています。
- 柳が緑であるように。花が紅であるように。
- お客様の要求を、OSの性質をプロトコルを諸々の技術を開発手法をその他を。
- 「自分が知っているから」「普通はこうだから」という色眼鏡で見るのではなくて。
- ただひたすら真っ直ぐに「あるがまま」を見る事ができたら。「何が適切なのか」を考える事が出来たら。
きっと。素晴らしい設計に、プロジェクトに、なるのではないでしょうか？
禅語「白馬入蘆花」
ランク：新人 カテゴリ：コミュニケーション
半年一年と経験を積むにつれて。
何となく「あぁこないだやったのと一緒だ」という状況が、大なり小なり出てくるのではないかと思います。
運良く大きいところに行ければプロジェクト単位で。大抵の人が経験するのは、ちょっとしたプログラムのロジックとかサーバ／ネットワークの設計とか。
それは素晴らしい成長のサインであると同時に、ぽっかりと口を開けてある「大いなる落とし穴」でもあります。
その落とし穴には、どんな罠が潜んでいるのか。それを少し紐解いてみましょう。
白馬入蘆花、という禅語を今回選びました。
「はくばろかにいる」、と読みます。
絵としては「秋口。一面に咲き誇る真っ白い蘆の花の中に佇む白馬」という感じです（ちなみに。蘆花（あしのはな）というのは、水辺に自生するイネ科の多年草です）。
遠目には「白馬の白と蘆の花の白が混ざって見分けが付かない」ほどに純白な風景だそうです。
そこに「夕日のクリムゾン」なんかが入ってきたら……心の琴線に触れるというか鷲掴みな感じの、浪漫溢れる風景になりそうなのですが。
さて。「見た目が双方ともに白くて見分けが付かない」花と馬は、果たして「同じもの」でしょうか？
当然ですが、「違うもの」です。
例えば。同じ「ECサイト」というプロジェクトが、「Webサーバを立てて」という要求があったとして。
あちこちから来る要求は「まったく同じモノ」でしょうか？
その中身が、要求が「完全に同じ」ことは、当然ながら有り得ないわけです。
そうして……特にプログラミングをやっている新人さんに顕著なのが「共通化」です。
昔は共通ルーチン、共通ファンクション。最近はclass化とかになる事も多いですかね。
はじめは「同じ処理を毎回書いていた」からstartして「コピペ」を覚えて叱られて……共通化することを覚える、まではよいのですが。
その次によくやりがちなミスが「表面上同じ処理に見えるものを全て共通化してしまう」こと。
「白いから馬も花も一緒」と言っているようなものです。
どんなに同じように見えたとしても。かたや動物、かたや植物では、これを一緒くたにしたら「どこかで厄介ごとが起きる」のは、むしろ当然です。
「見た目」にまどわされずに。その本質を見る目を持たなければいけません。
共通化の場合。必要なのは「本質が同じものをまとめる」ことです。
例えば、同じ「元値に+5%を足す」処理だからといって必ず同じ処理にしてよいとは限りません。もしかすると、片や「消費税」で、片や「＊＊社向け手数料」であるかもしれないからです。この二つを1つの共通にまとめてしまうと大抵後で問題がおきます。
白馬入蘆花。
同じように白く見えるそれが、もしかすると片や馬、かたや植物、かもしれません。
「同じように見える」のは確かに一つの成長の証です。でもそこで慢心することなく「さらなる目」を持つ努力をして、もう一歩先に進んでみませんか？
