無駄を省く その１
前回の「技術に振り回されない為に」
その１
その２
その３
その４
より続きます。
今回から、以前上げた９つ其々のテーマに関連した話を少しずつ記事にしていきます。
Unixの哲学
１．小さいものは美しい。
２．各プログラムが一つのことをうまくやるようにせよ。
３．できる限り原型（プロトタイプ）を作れ。
４．効率よりも移植しやすさを選べ。
５．単純なテキストファイルにデータを格納せよ。
６．ソフトウェアの効率をきみの優位さとして利用せよ。
７．効率と移植性を高めるためにシェルスクリプトを利用せよ。
８．束縛するインターフェースは作るな。
９．全てのプログラムはフィルタとして振る舞うようにせよ。
まずその１「小さいものは美しい」という考え方について
この考え方自体はそれほど難しいものではないとおもいます。
「無駄を省き必要な事だけをやる」という事に集中しましょうという事です。
どういったものかといえば、必要となるのは副作用に期待せずに何が起っているか分かり易く見通しのよいものを作れということです。
規模の大きなものを作ろうとするのではなく、小さなパーツ達を丁寧に作っていくという事です。
昔のアメ車とビートルを引き合いに本書では取りあげられていますね。
その例で考えるよりも、日本であれば茶道や武道などの道のものイメージした方が分かりやすいかもしれません。
この考え方自体は僕はとても日本人的だと思うのですが、どうも大きな問題や目標が提示されてしまうとどうも頭の中から吹っ飛んでしまい。
大きく無駄の多い問題解決方法をとる道を選んでしまう人達は多いように感じます。
本来は一つ一つ確実にやる事に集中すれば良いので、問題に対して対処方法はそんなに変わらないのですね。
システムの話でも、手法はいくつかありますが本当にとれる対応策は多くないと思います。
また、複雑に問題を解決してしまうと後で修正が大変になるので、パッチをあてる度に変更点やデバックが大変になってきますので、DRYやKISSの原則は護って作る方がシステムの改修は行い易く出来ます。
あくまで状況に応じてにはなってしまいますけどね。
ちなみにDRYは
「Don't Repeat Yourself：繰り返しを避けること」
でKISSは「Keep it simple, stupid：（シンプルにしておけ！この間抜け）」
もしくは「Keep it short and simple（簡潔に単純にしておけ）」
の略となります。KISSの原則は個人的にKeep it simple, stupidくらいの感覚で良いと思います。
これを護っていれば、保守しやすいコードが作れるようになっていくと思います。
今回はここまでです。
最後まで読んで頂いて有り難うございました。
技術に振り回されない為に その４
実際にこういった哲学を利用しながらシステムを考えていく事で指針を立てる事が出来ますので、その現場の設計がどういった所に問題があるか逆算する事が出来るようになります。
方向性さえ押さえていけば、道に外れても修正はしやすいですからね。
こういった方向性を持たずに漫然と仕事をしていると、いつの間にか周囲の環境に振り回されていつの間にか望まない結果を押し付けられてしまう、という状況に追いやられるケースも有ります。
むやみやたらにピチクパーチク喚き散らすのも問題ですが、状況に流されるままというのも宜しくないですよね。
その為に、確度の高い情報をもっておくのは手だと思います。
始めは自分のもので無いので、中々なじまないかもしれませんが、しっかりとしたポリシーを持って物事に望めるようになると状況に流されにくくなったり、更には状況を創りだす事もできるようになります。
人と話す時にも、しっかりと芯をもって学んでいると複数の視点で突っ込まれても合気道の達人のように全て往なす事が出来るようになるのをイメージしてもらえると、どんな状況か分かりやすいでしょうか？
その為には、地味ではありますが基礎鍛錬が必要になります。
先人の考えを学び実際にどうやって今の環境が出来上がったか理解を深める事によって、世の中のキャッチーな技術に踊らされる事無く本当に必要なものだけをクライアントに提供する。
そんなエンジニアになる事も出来ますので、昔から現在まで残っている技術や考え方については自分の血肉に出来るだけする事は必要です。
Unixの哲学だけでなく他にも多くの先人達の知恵はあるので、自身で色々と調べて身にあった考え方を取り入れるようにしていく事は追々プラスに働くと思います。
では、次回からは、「小さいものは美しい」を議題に記事にさせて頂きます。
今回はここまでです。
最後まで読んで頂いて有り難うございました。
技術に振り回されない為に その３
こういった考え方が必要な理由について、僕なりの考え方になりますが一番分かり易いところで、これは既に成功事例なのですね。
失敗から学ぶという人はたまにいますが、統計的にみると「成功した人が成功する確率」と「失敗した後に成功する人の確率」は、前者の方が多いそうです。
まぁ、「成功」を知らない人が知っている人より成功しやすいという事は現実問題考えにくいですね。
これは逆に考えてみれば、成功している、ちゃんと目標達成している考え方を用いる事で失敗のリスクを回避出来る事にもつながります。
そのため、僕はこういった哲学を学んで実践する事で、誤った方向性に行きにくいようにしています。
哲学というと仰々しいですが、要は最初の決めを何処に持ってくるかという話なので、その指針には便利だと僕は考えています。
こういった指針を元にサーバ構築するにもプログラミングするにも極力無駄となりそうな所は省いて、自分の作りたいものに最短で近づけるように意識を向けやすいように僕は感じます。
あと、人に説明するポイントも絞りやすくなってきます。
ポリシーがしっかりしている人の話って聞き易いですよね？
僕は、この根幹となる部分を大事にしながら人と話したり、技術系の情報を探索するのに利用しています。
基点を持って色々な情報をみる事が出来れば、本当に相手が困っている事を見つける事が出来ます。
ただし、相手が気づかない場合や「そんな（根本の）話はどうでもいいんだよ！」という人には通じないので注意しましょう。
世の中にはそんな人もいます。
そんな人は説法よりも目先の金なんですよ（苦笑）
そういう方を相手にすると疲れるので、適当にあしらって自分の事に集中する時間を持つ方が良いと思います。
今回はここまでです。
最後まで読んで頂いて有り難うございました。
技術に振り回されない為に その2
その１より
ここで紹介をした考え方は現在でも「５番の単純なテキストファイルにデータを格納せよ。」以外は通用すると僕は考えています。
５番だけは特殊な事例が発生すると出来ないですからね。
これについては今後取り扱いますが、ここでお伝えしたいのは基礎的な考え方は時代が変化しても通用するという事です。
前回紹介した考え方以外にこういった考え方はあります。
その一部を転用します
これがUNIXの哲学である。
一つのことを行い、またそれをうまくやるプログラムを書け。
協調して動くプログラムを書け。
標準入出力（テキスト・ストリーム）を扱うプログラムを書け。標準入出力は普遍的インターフェースなのだ。
— M. D. マキルロイ, UNIXの四半世紀
これなんて、別にUnixとか開発とか関係ないと思います。
要は、「一つ一つの事を確実にやる事」これが最短なんですね。
おざなりに事を進めて、問題を置き去りにしながら次のテーマを解決に向かっても、そこに解決策を見いだすのは難しいです。
根源的な部分で誤摩化していては、結局最初からやり直しをしなくてはいけないのですね。
僕がいた職場で、この根本的な問題に突っ込んでしまいどうしようもなくなっている状況の職場もありました。
こうなってしまっては、最初から作り直すしかないです。
大切な事というのは実はそれほど多くありません。
ただ、あまりにも簡単すぎて上手くいかない時、きっとやり方が悪いんだと複雑に考えてしまう場合があります。
ここで、難しく考え始めるとあとは泥沼にはまるようにシステムの肥大化が進んできます。
本来簡単であった問題は、非常に困難な問題へとすり替わる事があります。
こうならない為に、先人の考え方というのを利用するのはおおいに有りだと思います。
人に説明する時に結果を出している言葉を使うと勝手に納得してくれる場合あるので、クライアントを説得するのにカードとしても使えたりします。
あと、昔気質のエンジニアと話を合わせるのにも役に立ったりしますね（笑）
この他にも大切な所で役に立ちますがその話はまた次回にします。
今回はここまでです。
最後まで読んで頂いて有り難うございました。
技術に振り回されない為に その１
エンジニアを職にしていると、「そんなのツールにしなくてもシェルで良いんじゃないのかな？」とか「わざわざ仰々しくパッケージにしなくても良いんでないか？」といった事を考える機会が多くあります。
多分ツール化とか仰々しく看板立てておけばお金にしやすいからだと思います。
ただ、こういったものは問題をより複雑化してしまい本来欲しいものから遠ざかってしまうケースがあります。
そのため、僕自身も為に何度も心に唱える戒律があります。
Unixの哲学
１．小さいものは美しい。
２．各プログラムが一つのことをうまくやるようにせよ。
３．できる限り原型（プロトタイプ）を作れ。
４．効率よりも移植しやすさを選べ。
５．単純なテキストファイルにデータを格納せよ。
６．ソフトウェアの効率をきみの優位さとして利用せよ。
７．効率と移植性を高めるためにシェルスクリプトを利用せよ。
８．束縛するインターフェースは作るな。
９．全てのプログラムはフィルタとして振る舞うようにせよ。
全部で９つのこの戒律に従って道を外れないように緊張して作る事を考えます。
モノを単純に作るのはありなのですが、作った後の運用や保守をないがしろにした設計の場合、その後酷い未来が待っています。
プログラマの人に大した変更でないと思って提案したのに、パッチを作るまでに４ヶ月とか半年の開発が見積もられたときはありませんか？
一概に言えませんが、この状況は「何処を治せば良いか分からない」もしくは「治すべき所は分かっていても変更箇所が多い」という状況など考えられます。
大した事をやっていなくても無意味やたらに巨大で複雑なソースで開発してしまうと、このアップデートを進めていくにつれて困難になり、次回のアップデートから１から作り直した製品を出すという事もあります。
それを護るためには、色々とルール作りが必要になってくるのですが、そのルール作りの大本を担う部分がこの９の戒律だと僕は考えます。
また、これは最新の技術ではなく、旧く枯れた考え方です。
こういったものにも目を向ける事が出来るようになれば、自分が苦労している部分を楽にする事は簡単だったりします。
この他にもUnixの在り方を学ぶ事で色々と先人の方の至言を学ぶ事が出来ます。
そういった今も活きる言葉を胸に実践から学ぶ事は大切な事だと思います。
まずは、エンジニア初心者なんですと思っているかたは、新しい技術を学ぶのではなく今もなお変化の少ない分野を学ぶと一生食べていけるエンジニアになれると思います。
今後この話を続けて掲載しますが、元となる本は記事の最下部に紹介させて頂きます。
今回はここまでです。
最後まで読んで頂いて有り難うございました。
実践する事
僕は昔は別々の学び方を使っていて、今にして思うと非効率だったなと反省する時があります。
一つ目は、知りたい事を書籍を読んだり、人の話を聞いたりする事で学ぶ
二つ目は、実行する事を念頭に置いて学ぶ
この二種類の学び方をしていたのですが、結局自分の地肉となっているものは二つ目の実行までした事の方が多いような気がします。
実際に色々な情報を得てみたもののなかなか活動する事は出来ない事って多くないですか？
また、一度やったけど疲れてしまって一旦停止して、その後に再スタートしたいのだけどなかなか始める事が出来ない事ってないですか？
何となく、昨日の話を書いた後に、その実行する時のエネルギーを最小限にする心境ってどういう状況だろうと僕なりに考えてみました。
座禅、黙想をしている時これが僕の感覚では一番スタートするのに適しているのかなと感じます。
ただ座ってるだけじゃないかと思われるかもしれませんが、実際にただ座るという事は結構しんどい事だと思います。
座禅については、また後日改めて書くかもしれませんので、ここで扱うのはその時の心です。
僕が通っている道場では黙想中は、ただ呼吸を整え数を数えます。
これは数息観というのですが、ゆっくり呼吸に合わせて「いーち、にー、さーん・・・」と頭の中で数えていきます。
この時、数を中心に思考はフラットな状態になっていきます。
本来、数字に雑念なんて湧きようがないですからね。
このフラットな状態を座禅の時だけでなく、斬る時にも用いる事を稽古の間は師範より指導されます。
といっても出来ていない時に２言３言言われるくらいですけどね。
ただ、事を始める場合、このフラットな心境を作れると、実行に移す時に変な期待感や不安感を和らげる事ができるので、実生活でもわりと役に立つのではと思います。
人と話す時ってかなり緊張してしまうのですが、このような腹積もりを決めた後であれば実行するだけになりますからね。
やってしまえばこっちのモノだったりするのですよね。
ただ、実行に移すまでに色々と考えちゃって動く事が出来なくなってしまうのですけど、そこをクリアしてしまえば後で振り返ってみると簡単な事だったんだなと気づく事が多かったりします。
この最初のステップって結構大事なんだなと最近を振り返ってみて改めて感じました。
今回はここまでです。
最後まで読んで頂いて有り難うございました。
学ぶ事
普段の社会生活だと、上司や客先の方にあーだこーだ言われてそれが間違っていていも堪える必要がある事は少なくはないと思う。
何かを進める為に面倒でもルールを決めてやっていくのはそれほど悪くない方法だと思う。
そうでないと、誰に何をお願いするか有耶無耶になる現場もありますから、ある程度は仕方ないと感じる。
ただ、そのルールに縛られて肝心な所が疎かになるのであればどうなんだろうと最近考える事が多くなりました。
ここで、僕が通っている道場稽古を例に僕なりの学びについて書いていきたいと思います。
道場稽古について
僕が通っている道場では入りたて時期は、摸擬刀を持つ事になり最初は座礼や立礼から刀の持ち方や振り方、納め方を習います。
礼法については稽古の時間は普段の出し切れていない自分の力を全力で出すための儀礼みたいななものです。
その間は普段の社会生活を一旦洗い流して、ただその場の自分の全力を出す。
そういったイメージですね。
近い所で食事の「いただきます」「ごちそうさま」をする気持ちに近いと感じます。
あと、基礎的な所を教えたあとは出来るだけ自分で考えて稽古をするように行われています。
最初の方に書いた礼法は、日常と道場の区切りをつける事
あと、刀の持ち方、振り方、納め方は実際に真剣を持った時に怪我をしないようにするためという所が重要な所ですね。
実際、真剣がどれほど人体を斬るのに適しているか斬れた所を見た人しか分からないですからね。
扱いを間違えればあっさり指程度であれば落ちます。
これは納刀は時におきやすい怪我です。
行動を発するより納める時の方が人は油断し易いようです。
そうならない為に、最初はきちんと教えるのですね。
基礎的なところを教えたあとは、個人で鏡前で刀を振り稽古をしています。
基本的に一から十まで伝える事はしていません。
そうしてしまうと、折角の学ぶ機会を奪ってしまう事に繋がるからだと思います。
最初のとっかかりさえ伝えてしまえば、本来人は動けるものです。
１から１０まで一々教えていては何れその方は考える事を放棄してしまうでしょう。
それに、その人の体格や筋力によって微妙に癖が変わります。
そのため、必ずしも先輩が言った事「正しい」とは限らないのですね。
本来「学ぶ」という言葉は「真似る」事から始める事でもあります。
そのため、人から受けた情報を自分なりに咀嚼し実践する、その経験自体を「学び」という言葉に繋がっていくのですね。
こういった感覚を養うように毎日生活していきたいものです。
今回はここまでです。
最後までよんでいただいてありがとうございました。
