GlusterFS & tmpfs による分散型フォールトトレラントメモリキャッシュシステム
“GlusterFS & tmpfs による分散型フォールトトレラントメモリキャッシュシステム” の記事は下記に移転しました。
301 Moved Permanently
qiita.com
分散型フォールトトレラントファイルシステム GlusterFS による Web サーバー間の同期
“分散型フォールトトレラントファイルシステム GlusterFS による Web サーバー間の同期” の記事は下記に移転しました。
301 Moved Permanently
qiita.com
一流エンジニアになるための Off-JT #6. エンジニアの生産性
エンジニアの生産性：はじめに
今までのポストでも、“生産性”という言葉を要所で使用してきましたが、このあたりでそろそろ、“エンジニアの生産性”をテーマにしようと思います。
さて、みなさんの中で、“生産性”を理解されてるという方は、いらっしゃいますでしょうか。
そして、“生産性”を根拠に活動されている方は、いらっしゃいますでしょうか。
“一流エンジニア”と呼ばれるエンジニアさんは、この“生産性”を理解して活動されてる方は多いと思います。
なぜなら、“生産性”を理解し、“生産性”を根拠に活動できている事こそが、“一流エンジニア”と呼ばれる所以の一つだからでしょう。
では、“生産性”とはいったい何でしょうか？
そして、“生産性”を高められるエンジニアになるためにはどうすれば良いでしょうか？
このポストでは、“一流エンジニア”になるための“エンジニアの生産性”について解説します。
エンジニアの生産性：生産性とは？
そもそも、“生産性”（Productivity）とは何でしょうか？
売上や利益上げる事や、ものを作る事でしょうか？
便利な言葉のようですが、分かるようで分かりづらい言葉でもあります。
“生産性”とは、経済学上では、かけた資本、資源、労働などに対して、どれだけの付加価値をなど生み、あるいは寄与ができるかの“効率”とされています。
分かりやすく言えば、同じ時間、同じ労力などに対し、どれだけの成果や価値などが生み出せるかという事です。
“生産性”は、“アウトプット/インプット”（O/I = 生産性）の関係で表す事ができるとされています。
“インプット”が時間や労力などであり、“アウトプット”が成果や価値などということになります。
この、“インプット”の対象と、“アウトプット”の対象となるものが重要になってきます。
これは言及の範囲や、組織、あるいは状況によって変わってくるでしょう。
もし、その組織の価値となるものが、売上高や利益なら前述の通りとなります。
また、売上や利益の手前、あるいは先にあるものを組織の価値とするならば、そのための“インプット”に対する“アウトプット”の“効率”という事になります。
そして、この数値が高いほど、“生産性”が高いという事になります。
（“効率”とは、単に“アウトプット/インプット”で表わせる度合いをいい、“生産性”の上位概念となります。）
エンジニアの生産性：なぜ生産性が必要なのか？
では、なぜ“生産性”が必要とされるのでしょうか？
まずは、企業側のロジックから解説します。
エンジニアの生産性：企業側の視点
利潤追求が使命である企業においては、原資をかける事で利益が生まれ、その結果、給与、報酬、福利厚生、環境改善、人員増員や増強、設備投資、企業買収、社会貢献などに更なる原資をかける事が可能となり、それによって更なる利益を生む事が可能となり得ます。
このような循環が、“事業成長サイクル”となり、企業の成長と継続に繋がっていきます。
初めはどんな企業も、その時点においてかけられるだけのミニマムな原資から始まります。
この“事業成長サイクル”の中で、どの時点の何を価値と表現するかは、企業によって様々でしょう。
しかし、ほとんどの企業の価値の本質を意訳するならば、おそらくその骨子はほぼ似たものになるのではないでしょうか。
それは
「より利益を生むことで、関係する顧客、商品、従業員やその家族、会社、株主、社会などのより豊かな発展を目指す」
といったところでしょう。
まずはこのあたりを理解していると、会社の目的、チームの目的、個人の目的がリンクしやすく、双方にとってより良い成果が生まれやすくなるかもしれません。
（ここでいうリンクとは、同じという意味ではなく、相互に繋がるという意味です。）
新卒の方でも中途の方でも、優れたビジネスマンは、会社に所属しはじめの頃から相互理解に努めようとします。
逆にそうではない場合、“個人のより良い環境”を望む割合が強くなってしまう傾向にあると、私は今までの経営やマネージメントの経験から思います。
言い換えれば、それがマジョリティーだと言ってしまえるのかもしれません。
しかし、全従業員がそれでは、企業はたちまち立ちいかなくなるのも事実です。
そしてこの課題は、本来はマネージャーのミッションとなるわけですが。
エンジニアの生産性：福利厚生
例えば、福利厚生などを例にあげると分かりやすいでしょう。
企業が福利厚生を充実させる目的は、どこの企業の幹部に聞いても、そのほとんどは“生産性の向上”という答えが返ってくるはずです。
それは、ファシリティ部門のトップでも、人事部門のトップでも変わりはないでしょう。
しかし世の中には、テイクありきのスタンスが存在するのも事実です。
デスクの椅子を例にとってみましょう。
例えば、エンジニアのために高価な椅子を会社が用意したとします。
しかしなぜ、わざわざ高価な椅子を用意するのでしょうか？
それは、従業員の個人的な自己満足の充足だけで終わってしまうような、一方通行の関係が目的ではないはずです。
確かに安価な椅子では、我々のように座って業務をする事が多いエンジニアにとっては、致命的な腰痛を発症しまねません。
その結果、午前中に通院を余儀なくされ、作業がはかとらず、終いには心身ともに疲弊してしまうかもしれません。
ひいては、会社の利益を下げる事にも繋がりかねません。
これでは、誰も得をしない負のスパイラルの関係に陥ります。
しかし、従業員の心身を配慮して高価な椅子を用意する事は、より“生産性”の高いアウトプットを期待するという、双方向な関係を求めるからこそでしょう。
これは、椅子に限った話ではありません。
なぜ、大型ディスプレイを用意するのか？
なぜ、社食を割引や無料にするのか？
なぜ、社内保育所や社内クリーニング店、社内ヘアサロンまで完備するのか？
なぜ、綺麗で創造性の豊かなオフィスを構えるのか？
なぜ経営者は、コミュニケーションが密になるようなオフィスの導線に拘るのか？
エンジニアの生産性：会社の永続
企業は、当然ボランティア団体ではありませんので、かけるコストによって、リターンがなければ、事業継続は不可能です。
もし、事業継続不可能となれば、顧客、従業員の生活、取引先、株主など、そのネガティブな社会的影響は、規模の大きい企業であるほど大きいでしょう。
したがって、これらの目的は、まずは利益の向上による“会社の永続”のために他なりません。
まずはこれが、利潤追求が使命である企業の原理原則であるのは周知の事実といえます。
しかし、この解説の視点は、あくまで企業側から見たロジックです。
ここで終わると、企業側の都合の押し付けに聞こえかねませんが、そうではありません。
エンジニアの生産性：顧客、従業員、株主からの視点
実は、個人の生活においても、似た側面はあるのではないでしょうか。
個人においても、コストをかける事でより良いサービスを受けたい、あるいは体験をしたいなど。
経済学上では、“生産”に対してこれらの活動を“消費”と言うようですが、これはあくまで一方向性の視点といえます。
ここでは、個人の“生産活動”という視点で解説を進めると、これも顧客側の“生産性”といえるでしょう。
これは株主にとっても同様であり、投資によってより良いリターンを望むものです。
そうです、“インプット”に対して、より価値の高い“アウトプット”を求める“生産性”なのです。
そしてこれは、従業員も同じではないでしょうか。
かける労力、時間、熱意などによって、より良い対価などを望む方は多いのではないでしょうか？
その対価とは、評価、環境、処遇、報酬、給与、地位、やりがい、など、いろいろあるかもしれません。
（“内発的動機”の重要性については、“エンジニアマネージメント”のポストで言及する予定です。）
このように、顧客、従業員、会社、株主などどの立場であっても、お互いがコストに対する対価を得ている相互関係にあるということなのです。
エンジニアの生産性：生産性の本質
逆の例をあげましょう。
もしあなたが従業員として、どんなに労力と時間と熱意をもって良い成果を出しても、会社が正当な評価をしてくれなかったとすれば、あなたは会社に対する信頼が薄れていく事でしょう。
それは、企業も従業員に対して同じであり、株主も、顧客も同じなのです。
もし、あなたが顧客だとして、高額なお金を払っているにも関わらず、とても粗悪なサービスを受けたとすれば、あなたはその会社を信頼しなくなるでしょう。
この状態は、顧客の“生産性”を低めてるという、顧客にとっても会社にとってもおそらくは望ましくない状態といえます。
要するに、お互いの‘生産性”を高めあう事で、お互いのより良い相互関係を築く、これこそが“生産性”の本質ではないでしょうか。
こうして信頼関係を築き、その相互関係を発展させていくことで、社会における大きな循環関係にも、より良いサイクルが生まれていくものではないでしょうか。
ここから三つの例え話は Cig Break です。
Cig Break：贈り物の心
一つ目は、“贈り物の心”（Gift Haerts）です。
これまでの相互関係の話は、“贈り物の心”と似ています。
例えば、あなたがパートナーへ誕生日プレゼントを贈るとします。
パートナーが何を欲しがってるか、中には普段の生活から一生懸命読み取ろうとしてる方も大勢いらっしゃるかもしれません。
プレゼントを買いに行く前から買いに行った時も、いろいろ時間かけて悩んで、やっとの思いでプレゼントを購入しました。
みなさんもそんな体験をした事あるのではないでしょうか？
そして、パートナーへプレゼントを渡す。
「ありがとう！何で欲しいものが分かったの？」
と、パートナーが喜んでくれる事で、あなたは安心と嬉しさがこみ上げてくる。
そして、あなたの誕生日には、パートナーからプレゼントが贈られる。
そういうやり取りが信頼関係を強くしていく。
Cig Break：愛情貯金
もう一つは、“愛情貯金”（Love Savings）のお話です。
例えば、あなたは初めから“愛情貯金”が 10 あるとします。
そして、相手へ愛情をかけると、“愛情貯金”は等価で減っていくものとします。
ここでは、愛情 2 をかけたとすると、あなたの“愛情貯金”は 8 になります。
しかし、愛情のお返しは 1.2 倍え返さなければならないものとします。
それを近しい人間関係でやっていくと、お互いの“愛情貯金”は増えていくという単純は例え話です。
（友人の誕生日プレゼントで年々これに似た事をやって、お互いのプレゼントの額が不毛な事になったという話を聞いた事がありますが、それを推奨してるわけではありません。）
Cig Break：ギブアンドテイク
“贈り物の心”と“愛情貯金”の二つの話は、私が 20 代の頃に起業した頃から使ってきた例え話ですが、要するにこれらは、“ギブアンドテイク”による信頼関係の話です。
しかし、テイクばかりを望んでいると、本当の信頼関係は生まれないと言う事です。
ここでは、個人的な自己満足の充足だけで終わってしまうような、一方行的な利益を求めるスタンスという事になります。
ギブをして初めて双方向的な相互関係が成り立つという例え話です。
例えば、生まれてから社会人になるまで、大人の愛情を受けて育ってきた方は多いと思いますが、社会人になれば受け取ってばかりでは成り立ちません。
ネットスラングでは、これに似た事をクレクレと表現される事がありますが、若いうちは許される事も、大人になるほど通用しなくなっていくものでしょう。
エンジニアの生産性：エンジニアの視点
では、話をもう一度エンジニアの視点に戻してみましょう。
我々がやるべき事は何でしょうか？
“ソースコードの可読性”や、“開発速度の向上”、“改善速度の向上”は何のためでしょうか？
“オブジェクト志向”、“コードの再利用性”、“MVC” は何のためでしょうか？
“コーディング規約”という概念は、個人の主観、自己満足、エゴイズムが目的であるべきでしょうか？
“ナチュラルキー”が目的となってしまった“データベース設計”の議論に果たしてどれだけの価値があるというのでしょうか？
これらは、本来は“生産性の向上”が目的であるべきでしょう。
“コーディング規約”とは、個人のコーディングスタイルを貫くための、争いの場ではありません。
このようなスタンスは、福利厚生の例と同様に、個人的な自己満足の充足だけで終わってしまうような一方通行的な目的によるスタンスといえます。
更には、“コーディング規約”のための“コーディング規約”にもなるべきではないでしょう。
要するに、職務として中間目的があったとしても、それは最終目的ではないという事です。
したがって、中間目的だけでなく、最終目的も明確に理解しておくべきでしょう。
なぜなら、中間目的しか見えなければ、いずれ本来の目的からズレが生じ、やがて“生産性”の低下を招く恐れがあるからです。
例えば、エンジニアが“オーバーエンジニアリング”に目が向かいやすいように、事業の本来の方向性からズレていく可能性を高めてしまうという事です。
中間目的と最終目的の親和性が低いと感じたなら、勇気を持って中間目的を軌道修正すべきでしょう。
何のための中間目的なのか、中間目的は最終目的を達成するための手段であり、あくまでテクニックに過ぎないという事です。
エンジニアの生産性：最終目的の距離感
しかし、多くの方の職務は、会社にとってはあくまで中間目的である場合がほとんどでしょう。
そして、その目の前の目的に集中するあまり、本来の目的を見失うか、あるいは本来の目的の存在すら考えないエンジニアさんのケースをよく見聞きします。
なぜ、このような錯覚に近い状態に陥ってしまうのでしょうか？
もし、あなたが社長から、会社の目的は“会社の永続”だと聞かされて、普段の職務のタスクがピンとくるでしょうか？
そこから逆算して、目の前のミッションがはっきりイメージできるでしょうか？
もしできなければ、この“会社の永続”という大義名分は、あまりに距離感が遠すぎて現実味がないという事でしょう。
このあまりに遠すぎる最終目的と、従業員の意識の距離感を埋めるために、最終目的から中間目的をフォークしていくのが一般的なセオリーでしょう。
しかし、この親和性を管理維持していくのは本来マネージャーの任務でしょう。
もし従業員一人一人にそれを求めても、それはマネージメント意識の強い従業員でない限りなかなか困難でしょう。
しかし逆に言えば、もしこれが理解できてしまえば、会社にとっての“生産性”の高いエンジニアになり得るという事です。
エンジニアの生産性：利益という仮想通貨
エンジニアさんの中で、会社の主要な資金を直接扱ってる方はどれくらいいるでしょうか？
そう、会社の中では、会社の主要な資金を取り扱う立場の人の方が少ないはずです。
利益と言っても、多くの方にとって予算表や実績表、あるいは損益計算書や貸借対照表など、紙面の数値上の話になります。
会社の収支といっても、その全てに関わっている方は少ないでしょう。
では、個人の話に立ち返ってみましょう。
もし仮に、あなたが結婚して子供が一人いたとするならば、あなたは家族という組織に属している事になります。
あなたの職業が会社員ならお給料、経営者なら報酬、フリーランスなら受託料などをいただいている事でしょう。
それが、あなたの家族という組織の収入ということになります。
ほとんどの方は、その収入は毎月の生活のためになくてはならないものでしょう。
あなたは、その中から生活に必要な費用を払い、その余剰の中から余暇を楽しむかもしれません。
では、その家族の収支が赤字になればどうなるでしょうか？
企業の場合には、いろいろな資金調達の方法があるかもしれませんが、個人の場合ではおそらく限られてくる方も多いでしょう。
しかし、会社も家族という組織も本質的に大きな違いがないとすれば、それはどちらも組織の継続のために“生産活動”を続けているという事でしょう。
したがって、家族という組織と同じように、会社であっても利益がでなければ組織継続は困難という事です。
しかし、会社の資金を直接取り扱っていない以上、その数値に現実味がないのも事実でしょう。
よって、会社の利益は一見実体のない“仮想通貨”のようにも思えてしまいますが、しかし個人に立ち返って考える事ができれば、組織も個人も本質的にはそう大差ないという事はご理解頂けるかと思います。
エンジニアの生産性：成長サイクル
このように、会社の永続や利益向上というミッションは、従業員からすればあまりに距離が遠く現実的に聞こえないかもしれません。
しかし、それらをより身近に感じるための手段は世の中にはたくさんあります。
例えば、より親近感を感じるための“コアバリュー”経営や、組織と個人の目的をより強力にリンクするための “OKR” などのマネージメント手法など、いろいろな手段が存在します。
（“コアバリュー”や “OKR” の詳細は、“エンジニアマネージメント”のポストで言及する予定です。）
これらは、より身近な言葉で表現されたり、従業員の行動指針や意思決定の物差しとなります。
しかし、これらも“生産性の向上”が目的である事は言うまでもないでしょう。
そして、決して一方向的にならず、顧客、従業員、会社、株主、社会の相互の“生産性”を発展させ、これらを“成長サイクル”でまわして行く事で、より良い豊かな発展が生まれるのではないでしょうか。
“PDCA” や “DevOps” などのサイクル図は、プロダクト開発に限ったものではなく、個人にも、顧客にも、従業員にも、会社にも、社会にも当てはまるという事です。
このような事を、繋げて考える事だけが正しいという事ではなく、エンジニアさんのスタンスはいろいろあって良いと私は思います。
幸せの形やスタンスは、決して一つではありません。
しかし、このシリーズに冠しているような“一流エンジニア”を目指されている方には、これらが何かのきっかけになれれば幸いです。
もし、組織構築の主体者の方々がこのポストを見てくれているとするならば、是非この循環関係にこだわって欲しいと切に願います。
エンジニアの生産性：生産性と効率化の違い
最後にもう一つ、大事なポイントをお伝えしておきます。
みなさんは、“生産性”と“効率化”の違いをうまく説明できますでしょうか？
この二つの言葉の意味の違いを、うまく説明してる情報も非常に少ないようです。
ここでは、いったんこれらを“生産活動”と“効率活動”と言い換えてみます。
例えば A さんは、筋トレを始めたとします。
そのバリューは、筋力増強だとします。
しかし、その A さんが、筋トレを怠り、プロテインばかりを飲み始めたとしたら、いったいどうなるでしょうか？
もちろん、そのプロテインは筋肉ではなく、脂肪に変えてしまう可能性を高めてしまいます。
プロテインを飲む行為は、あくまで、筋トレによる筋力増強の“効果”を上げる補助的な“効率活動”としては有効ですが、バリューを生むのための直接的な“生産活動”にはなりません。
例えば、会社が“広報活動”ばかりに傾倒し“生産活動”を疎かにした場合の、価値の生まれない実態とかけはなれた“錯覚負債”を増やす活動、と酷似してるといえるかもしれません。
“生産性とは？”のセクションでも解説したように、“効率”とは単に“アウトプット/インプット”で表せる指標であって、何かの価値を表した指標という意味ではありません。
よく“業務効率化”という言葉が多用される場面を見聞きしますが、この言葉が本来意味するものは、単に業務の“効率”を“アウトプット/インプット”で表わすものでしかなく、それによって価値あるものが“生産”できるかどうかの意味とは全く別物であって、この二つの意味を混同して使用されている情報が非常に多いようです。
したがって、その“業務効率化”の施策は、本当に“生産性の向上”に寄与してるかどうか、もう一度よく検討すべきでしょう。
そして、もし“生産性の向上”に寄与していないとすれば、この状態も“生産性の向上”の目的からズレている状態といえますので、その施策の改善の余地があるかもしれません。
このズレの軌道修正も非常に大切ですが、このズレに気付く事が何より大切です。
“生産性”とは、“生産”（価値を生む活動）の“効率”を表したのものという事です。
エンジニアの生産性：まとめ
このポストでは、“一流エンジニアになるための Off-JT” シリーズのテーマとして、“エンジニアの生産性”について解説しました。
この考え方は、“一流エンジニア”になるためのみなさんの強力で有用な武器になりえます。
このポストが、みなさんの“一流エンジニア”になるための一助になれば幸いです。
“一流エンジニアになるための Off-JT” シリーズ次回のテーマは “#7. エンジニアマネージメント” の予定です。
一流エンジニアになるための Off-JT #5. 先行排他処理
先行排他処理：はじめに
みなさんは、とても行数の長い if 文やとても階層の深い if 文は目にされたことはあるでしょうか？
初学者の方は、これから目にされる機会があるかもしれません。
このポストでは C 系、Java 系、PHP 系の構文で例示します。
if (評価式) {
例：100 行 if 文ブロックなど
}
または
if (評価式) {
if (評価式) {
if (評価式) {
if (評価式) {
if (評価式) {
if (評価式) {
処理
}
}
}
}
}
}
コードを書いていると、どうしても“正常系処理”から書きたくなるエンジニアさんも多いかもしれません。
これは、とある機能実装にあたって、その目的に早く到達するためにはごく自然な行動かもしれません。
「とりあえずいったん動いた。」
これを目指すために、最短距離で実装する事自体は決して悪いことではありません。
その代わり、そのような実装手順を踏むならば、“異常系処理”のための大幅なリファクタリングが絶対条件になるでしょう。
その機能が複雑、または大きなロジックであるほどそのコストはかかるでしょう。
しかし、この“異常系処理”のアプローチを一歩誤ると、冒頭のような if 文になる可能性を多いに高めるでしょう。
このようなソースコードのことを我々は “if 文地獄” と読び、“アンチパターン”として啓蒙しています。
“一流エンジニア”は、このようなコードをほぼ書かないでしょう。
なぜなら、一流と呼ばれるエンジニアは、このようなコードは“生産性”が低下することを十分に理解しているからです。
では、このようなコードを書かないようにするためには、どうすれば良いでしょうか？
このポストでは、コードの“生産性”を高める方法の一つとして、“先行排他処理”について解説します。
先行排他処理とは？
“先行排他処理”とは、“正常系処理”よりも先に、“異常系処理”をすることを言います。
そして、我々はそれらのコーディングを“先行排他処理コーディング”と呼びます。
例えば
「ファイルの中身を取得する」
という処理の場合、
「ファイルが存在しなければ排他する」
というように、先行して“異常系処理”をする事をいいます。
ここで気をつけなければならないのは、
「ファイルが存在すれば」
という、正常な状態を期待した if 文で“正常系処理”を先行させない事です。
先行排他処理の有用性
“先行排他処理”の有用性を解説する前に、“正常系処理”を先行させるとどんなデメリットが生じやすいかを解説します。
前述のように、“正常系処理”を先行させ、“異常系処理”を後方に書くと、どうしても if 文ブロックの行数が長く、あるいは階層が深くなっていきます。
なぜならば、if 文ブロックを閉じることができない状態になりやすいからです。
if (正常系評価) {
100 行の if 文ブロック
} else {
異常系 else 文ブロック
}
または
if (正常系評価) {
if (正常系評価) {
if (正常系評価) {
if (正常系評価) {
if (正常系評価) {
正常系処理
} else {
異常系処理
}
} else {
異常系処理
}
} else {
異常系処理
}
} else {
異常系処理
}
} else {
異常系処理
}
このような状態になると、以下のようなデメリットが生まれます。
脳内の“ワーキングメモリー”の浪費
まず一つ目のデメリットは、脳内の“ワーキングメモリー”の浪費です。
if 文ブロックの行数が長く、または階層が深いということは、そのコードをキャッチアップするにあたり、そのロジックを脳内の“ワーキングメモリー”に記憶させていかなければなりません。
これは、作業のためにとても長い文章を一時的に記憶していく状態に非常によく似ています。
では、その脳内のワーキングメモリーを使い果たしてしまったら、どうなるでしょうか？
もう一度、同じ文章を読み直すことになります。
これにより、ロジックのキャッチアップに余計な時間がかかり、“生産性”を低める事になります。“視認性”の低下
二つ目のデメリットは、“視認性”の低下です。
これは、if 文の階層や if 文のブロッックを単に見間違える可能性を高めるという事です。“ロジックの矛盾”
三つ目のデメリットは、“ロジックの矛盾”が生じやすいということです。
これは、一つの文章を接続詞で延々と繋げていく作業に非常に似ています。
その結果、次第に論点がずれていくという状態を生じやすくしてしまいます。“スパゲティコード”の誘発
四つ目のデメリットは、ロジックが複雑になりやくす、“スパゲティコード”を誘発しやすいということです。
これは、接続詞で延々と繋げた一つの文章に対して、強引にその整合性をとろうとすると、どうしても複雑な文章構造になり、ロジックの I/O も分かりづらくなってきます。
書く方も、読む方も、要点が掴みにくい“スパゲティコード”になりやすいということです。“未知のバグ”
五つ目のデメリットは、“未知のバグ”を生みやすくなるということです。
巨大なロジックブロックになるほど、評価の重複や抜けも生じやすくなることから、未知のバグを生みやすくしてしまいます。
しかし、“先行排他処理”では、このような“正常系処理”を先行させた場合のデメリットが、そのままメリットになります。
なぜなら、異常系を先行して排他処理すると、その処理はその時点で完了し、if 文ブロックを閉じる事が可能となるからです。
そして、残る正常系の処理には、if 文を使わなくて済むようになります。
したがって、冒頭のような “if 文地獄”が起きにくくなります。
もちろん、知っていながら“異常系処理”を面倒がって省く行為は議論の対象外となります。
例）正常系処理が先行した場合
// ファイルが存在すれば
if (評価式) {
// ファイル読込権限があれば
if (評価式) {
// ファイル形式であれば
if (評価式) {
// ファイルの中身が取得できれば
if (評価式) {
正常系処理
// ファイルの中身が取得できなければ
} else {
排他処理
}
// ファイル形式じゃなければ
} else {
排他処理
}
// ファイル読込権限がなければ
} else {
排他処理
}
// ファイルが存在しなければ
} else {
排他処理
}
例）先行排他処理の場合
// ファイルが存在しなければ
if (評価式) {
排他処理
}
// ファイル読込権限がなければ
if (評価式) {
排他処理
}
// ファイル形式じゃなければ
if (評価式) {
排他処理
}
// ファイルの中身を取得できなければ
if (評価式) {
排他処理
}
// 最後に正常系処理：if 文は必要ない
正常系処理
これは、“正常系処理”を先行させた場合が、接続詞で延々と繋げた一つの長い複雑な文章のようなものであるのに対し、“先行排他処理”は箇条書き処理のようなものです。
どちらが、“生産性”が向上するかは自明でしょう。
例えば、「東京大学大学院 人文社会系研究科」の研究でも明らかになったように、これに似た状態だといえるしょう。
newswitch.jp
開発速度が落ちる？
「“先行排他処理コーディング”では、開発速度を遅くなる？」
という意見が出た事があります。
“開発速度と品質”の両立については、別のポストで言及する予定ですが、これは正しくも誤りでもあります。
まず、正しい側面で解説すると、個人開発においては、エンジニアさんによっては確かにその通りかもしれません。
個人開発においては、どのコードがどの意図によって書かれたものかは、既に本人が一番わかっているわけですから、可読性やロジックのキャッチアップ速度という話はほぼ出てこないでしょう。
次に、誤りの側面で解説すると、趣味ではなくビジネスやオープンソースコミュニティの現場においては、ほとんどの場合が複数人によるチーム開発となるでしょう。
いくら一人の開発速度が早くても、複数人のキャッチアップ速度や開発速度が遅くなれば、チーム全体の開発速度は遅くなります。
したがって、この開発速度が遅くなるという主張は、個人開発の域の話であり、チーム開発の話としては誤りであるのは明白です。
パフォーマンスが落ちる？
「“正常系処理”のパフォーマンスが下がる？」
という意見もありましたのでついでに解説します。
大丈夫です。そんなことはありません。
もし、仮に影響したとしても、今の時代その影響はマイクロ秒単位でしょう。
逆に複雑な if 文の方が処理パフォーマンスが下がるのは自明でしょう。
否定形表現を使うな？
“先行排他処理”では、if 文の評価式が否定形であったり、戻り値が false のメソッドや関数などを多用するケースが増えます。
例）
if (! 否定形評価式) {
処理
}
あるいは
if (a != b) {
処理
}
「if 文で否定形表現をあまり使うな？」
という情報を、たまにお見かけすることがあります。
彼らのこれらの主張には、きとんと意図があるはずです。
語弊を覚悟でこれを解説するとするならば、
「単に肯定系表現ができるところを、わざわざ分かりづらい否定形表現をすることもだいだろう。」
というものです。
きとんと、目的と意図がある“先行排他処理”については、これらをあてはめなくても大丈夫です。
先行排他処理：まとめ
このポストでは、“一流エンジニアになるための Off-JT” シリーズのテーマとして、“先行排他処理”について解説しました。
このスキルは、“一流エンジニア”になるためのみなさんの“強力で有用な武器”になりえます。
このポストが、みなさんの“一流エンジニア”になるための一助になれば幸いです。
“一流エンジニアになるための Off-JT” シリーズ次回のテーマは “#6. エンジニアの生産性” の予定です。
一流エンジニアになるための Off-JT #4. フッキングメモ
フッキングメモ：はじめに
前回のポスト“一流エンジニアになるための Off-JT #3. ワーキングメモ”では、“長期記憶”と“短期記憶”について軽く触れました。
ではみなさん、“中期記憶”はご存知でしょうか？
- 短期記憶より長く、長期記憶より短い一ヶ月ほどの記憶
- 記憶容量は短期記憶より大きく、長期記憶より小さい
- インプットとアウトプットは短期記憶より遅く、長期記憶より早い
- HW で例えれば、SSD（ソリッドステートドライブ）のようなもの（この例えは正確性に欠けます）
- SW で例えれば、KVS のようなデータリソース
- 海馬
- 短期記憶に興味を持つことで大脳前頭野から海馬に転送され中期記憶化する
- 中期記憶を反復することで海馬から大脳皮質に転送され長期記憶化する
- 使われないと判断されると忘却される
- etc...
“ワーキングメモ”は“短期記憶”の補助ツール、“テクニカルメモ”は“長期記憶”の補助ツールという考え方でした。
このポストでは、“中期記憶”の補助ツールとして、“フッキングメモ”について解説します。
注記
このポストの以降の表現の一部は、私の仮説、検証、結果と数人の体験に基づく内容に留まり、一般的な知見や科学的根拠に基づくものではないものが含まれます。
この根拠については、現在科学的なアプローチを検討中です。
記憶フッキングについて
“フッキングメモ”を解説する前に、まず“記憶フッキング”という、私の考え方から解説します。
私は知らない技術を見聞きした時、興味に引っ掛かったものは、記憶の片隅のフックにかかります。
そのフックは、洋服をかける壁掛けフックのようなイメージです。
私は、そのフックのことを“記憶フック”、そしてその“記憶フック”に引っ掛ける行為を“記憶フッキング”と呼んでいます。
そして、私が再度その技術を見聞きした時、そのワードが“記憶フック”にかかってることを認識する事ができます。
また、その技術の関連ワードを耳にした時には、頭の中を通り過ぎずに、“記憶フック”に関連ワードが無造作にフッキングされていきます。
そして必要なタイミングが来た時、フッキングされてきたそれらのワードを“記憶フック”から取り外して深堀りをはじめていきます。
いわば、この“記憶フッキング”という行為は、深堀りするための前準備のようなものといえるかもしれません。
そして、深堀りすることで“長期記憶”化されていきます。
この“記憶フッキング”という行為は、“中期記憶”にあたるのではないかと私は考えています。
要するに、見聞きしたことで“短期記憶”化された情報の中から、興味を引いたものが“中期記憶”としてフッキングされ、ある一定期間までの間に深堀りした“中期記憶”は“長期記憶”化され、その一定期間までに深掘りされなかった“中期記憶”については、一般的な概念では忘却されるとされています。
しかし私は、“中期記憶”から例え忘却されたとしても、“長期記憶”である“エピソード記憶”などから間接的に、再び呼び起こす事が可能だと考えています。
たまに私は、その時に発信してた相手や、その時の出来事、その時の状況などと関連づけて、過去に“中期記憶”化したであろうワードを探しにいく事があります。
例えば、その時の状況を思い浮かべるかもしれませんし、そのワードを思い出そうと一生懸命記憶を辿るかもしれませんし、検索サイトで探しにいくかもしれませんし、再びそのワードを見聞きした時かもしれません。
その結果、記憶として再度フッキングされ、“長期記憶”化して記憶が安定した体験を数多くしてきました。
このように、“中期記憶”に残る期間や、忘却されるとされる頃には、そこまで本人が必要としていなくても、再び呼び起こすタイミングというのは、実は深掘りして“長期記憶”化が必要なタイミングということなのかもしれません。
みなさんも、似たような状況に遭遇したことがあるのではないでしょうか。
したがって、‘記憶フッキング”という考え方は、忘却前・後の“中期記憶”が“長期記憶”化した自身の数多くの体験から、技術を身につけるにあたり、非常に有効な手段の一つではないか、という考えから生まれました。
他者への記憶フッキング
そして、“記憶フッキング”という行為を更に有効活用するするため、私はいくつかの手法を試みてきました。
そのうちの一つに、他者への“記憶フッキング”というものがあるのですが、このセクションではその一例をご紹介します。
私の場合の他者とは、OJT のトレーニー（研修者）や、講義の受講者を指す場合が多いのですが、そのトレーニー（研修者）たちに、意図的にこの“記憶フッキング”を用いたトレーニング方法を取り入れた事があります。
特に初学者のトレーニー（研修者）には、いま関係する全ての技術を深堀りして教えることは現実的ではありませんし、合理的ではありません。
「こういう技術がありますが、今は覚えなくていいので、そういう技術があるくらいに聞いておいてください。」
と話しながらも、ホワイトボードでは二重にも三重にも赤丸で囲って、語気を強めてそのワードを強調しておきます。
この場面においては、強調するという事が重要です。
なぜなら、そのワードに興味を引いてもらうためです。
これは、何を意味してるかというと、そのトレーニー（研修生）の頭の中に“記憶フック”をつくってもらうのが狙いという事です。
あるいはトレーニー（研修者）によっては、テキストに栞を挟む感覚の方もいるかもしれません。
こうしてトレーニー（研修生）に、その情報が“記憶フッキング”されていく可能性を高めることができると私は考えています。
そして、OJT でタイミングがあるとすれば、その時に深堀りする事もありますし、OJT では、二度と出てこなくても、トレーニー（研修者）自身が必要なタイミングがきた時に、“記憶フック”に残ってれば、そこから深掘りしていくでしょうし、
「あの講義で言ってた、ほら、あの技術なんだっけ？」
と、“長期記憶”である“エピソード記憶”などから間接的に呼び起こし、再フッキングしてから、深掘りされる場合もあるでしょう。
そして、“記憶フッキング”を働きかける側も、“記憶フッキング”をする側も、意図的に意識するということで、“記憶フッキング”効果がより発揮されるのではないかという結論に至りました。
これらの根拠は、“記憶フッキング”について、私が立てた仮説を、いくつかの OJT や 講義で検証し、多数のトレーニー（研修者）や受講者から得たフィードバックを基にした考え方となりますが、一般的な知見や科学的根拠に基づくものではありません。
記憶フッキングの有用性
なぜ、このような短期的とも長期的ともいえない、中途半端な感じの“記憶用法”を使うのか？
これを、まずは OJT に例えて解説します。
OJT の例で前述したように、特に初学者のトレーニー（研修者）には、いま関わる技術を、全てを深堀りして教えることは現実的ではありませんし、合理的ではないではないのは明白です。
特に OJT では、時間は無限ではありませんし、その現場で即戦力になってもらうために、その組織で必要とされる技術領域を身につける事が最優先課題となります。
例えば、アプリケーション開発エンジニアの初学者に、3 日目で OSI 参照モデルのネットワーク知識を身につけさせたところで、現場投入時にはほぼ役に立たないでしょう。
では、ネットワーク技術には一切触れないやり方の方が、より良い選択肢だと言えるでしょうか？
まずは、最優先課題の領域の技術を習得する場合においても、直近のまわりの技術の存在を知らなければ、その領域における質の高い技術を習得することはまず不可能でしょう。
また、ネットワークという存在を無視すれば、体系的な技術の理解が進むこともまずあり得ないでしょう。
そして、そのトレーニー（研修者）が現場に入った後、一生本人にその技術だけしか求めないということも、ほぼあり得ないでしょう。
次のステップというものも必ず存在するはずです。
例えば、OJT の中でこのステップが何段階かある場合、次のステップをより効率よく進めるためには、この“記憶フッキング”はとても有用な手段となりえます。
なぜなら、新しい技術を学ぶ前に、そのワードをリハーサルすることで、次のステップでその技術を習得する際のハードルを下げる効果があると考えられるからです。
このように、OJT においては、局所効率化だけでなく、カリキュラムの全体効率化の要素も取り入れながらバランスを維持し、しかし状況によりキャリブレーションしていくことも大切な要素ではないでしょうか。
特に OJT 初期段階では、
「どこまで深堀りして、理解を進めればいいかわからない。」
という質問を受けることがあります。
「心配しなくても大丈夫。そういう時は“記憶フッキング”しておくか、“フッキングメモ”（後述します）で、留めておいてください。」
と答えます。
そして、私は脳内の“記憶フック”の多さにも価値があると考えます。
ですので、OJT 初期段階では、
「特にいまは“記憶フック”をどんどん増やしていってください。それがもうすぐに役立ちますので。」
と必ず伝えておきます。
そうすることで、彼らのそのような不安による、学習進捗の停滞も低減できると考えられます。
特に OJT においては、知識学習と実践学習を併用することで学習の効率化をはかることも大切ですので尚更です。
ここまでは OJT を例にあげ、他者に対する“記憶フッキング”の有用性という視点で解説してきました。
しかし他者に対してだけでなく、自己に対しても有用なのは、もはやご理解いただけたことと思います。
フッキングメモとは？
この“記憶フッキング”に似た行為は、脳の働き以外でも可能だと私は考えます。
例えば、アイディアメモや、ネタ張、あるいはミュージシャンの方ならボイスレコーダーかもしれません。
必要になったとき、そのタイミングでアイディアを深堀りしたり、ネタの記事を書く方もたくさんいると思います。
このような“中期記憶”的なものを更に補助するツールとして、エンジニアさんには“フッキングメモ”を私はオススメします。
見聞きして興味のある技術をリストしておくようなメモのことです。
中には、“ワーキングメモ（短期記憶）”からその中で興味のあるものが“フッキングメモ（中期記憶）”へ転載されるパターンもあるかもしれませんし、“フッキングメモ（中期記憶）”からより必要となるものが“テクニカルメモ（長期記憶）”へ転載されるというパターンもあるかもしれません。
一般的に脳内では、
“短期記憶 -> 中期記憶 -> 長期記憶”
のような流れが起きてると言われていますが、このような形式に捉われ過ぎることで、本来の目的を見失って欲しくないとも私は思います。
フッキングメモの有用性
“記憶フッキング”の有用性と同様のため、これは割愛します。
フッキングメモの使い方
では、“フッキングメモ”はどのように使えばいいでしょうか？
下記では、一例をあげてご紹介します。
フッキングメモの目的例
次のステップに進むための布石、あるいは新しい興味のある技術を“長期記憶”化するための前準備をしておくことで、自身の“生産性”を更に上げること。
フッキングメモの要件例
- クロスプラットフォームで操作可能なこと。
- マルチデバイスで操作可能なこと。
- オンライン・オフライン環境で操作可能なこと。
- ソフトウェアに多くを依存しないこと。
（開発やサポート終了の影響を受けないようにするため）
- etc...
フッキングメモのポイント例
- 中期記憶の補助。
- すぐに書き込んで引き出すのはワーキングメモに任せる。
- ワーキングメモの中で興味のあるものを抽出して転載する。
- または見聞きしたものをダイレクトに書き込む。
- テーマによってファイルを分けるかどうかは使い方次第。
- どんどん箇条書きできるようにする。
- 自分が見てちゃんとわかるものにする。
- 他人が見る用に清書しない。
- フォーマットにあまりこだわりすぎない。
- あまり濃い内容にせずそれが必要な場合にはテクニカルメモに転載する。
（フッキングメモを濃い内容にすると、テクニカルメモとの役割があいまいになる。） - etc...
フッキングメモのツール例
- 普通のテキストファイルエディタ
（アウトライン機能があれば尚可） - Markdown 可能なエディタ
- Google Drive
- OneDrive
- Dropbox
- BoostNote
- GistBox
- etc...
これらは、あくまで一例ですので、ご自身にあった用法をオススメします。
情報のフック：まとめ
このポストでは、“一流エンジニアになるための Off-JT” シリーズのテーマとして、“フッキングメモ”について解説しました。
このスキルは、“一流エンジニア”になるための“強力で有用な武器”になりえることでしょう。
このポストが、みなさんの“一流エンジニア”になるための一助になれば幸いです。
“一流エンジニアになるための Off-JT” シリーズ次回のテーマは “#5. 先行排他処理” の予定です。
一流エンジニアになるための Off-JT #3. ワーキングメモ
ワーキングメモ：はじめに
みなさんは、人間の“長期記憶”（Long-Term Memory / LTM）のことをご存知でしょうか？
- 恒久的な記憶
- 記憶容量は大きい
- インプットとアウトプットは低速
- HW で例えれば、HDD（ハードディスクドライブ）のようなもの
- SW で例えれば、RDB のようなデータリソースのようなもの
- 大脳皮質
- 忘却されない（諸説あり）
- etc...
では、“短期記憶”（Short-Term Memory / STM）はいかがでしょうか？
- 一時的に記憶しておく短期的な記憶
- 記憶容量は小さい
- インプットとアウトプットは高速
- HW で例えれば、RAM（メモリー）
- SW で例えれば、キャッシュのようなデータリソース
- 大脳前頭野
- 忘却される
- 作業記憶やワーキングメモリとも呼ばれる
- etc...
このように、同じ記憶でも、性質と役割が違うということが分かります。
“一流エンジニアになるための Off-JT #1. テクニカルメモ” で“テクニカルメモ”について解説しましたが、これは“長期記憶”の補助ツールという考え方でした。
このポストでは、“短期記憶”の補助ツールとして、“ワーキングメモ”について解説します。
ワーキングメモとは？
“長期記憶”を“テクニカルメモ”というツールで一部補助ができるように、“短期記憶”の補助ツールとして、私は“ワークングメモ”を使っています。
場面としては、例えば作業のために、計算結果を一時的に記録しておきたいとか、メールアドレスを一時的に記録しておきたいなどの用途に有用です。
よく、手にメモをとる方がいますが、これも用途が同じならここでいう“ワーキングメモ”と同義でしょう。
昨日の記録や、半日前、3 時間前、1 時間前などの記録で、必要ないものはどんどん消し去ることができる、一時的な記憶を記録しておくためのものです。
みなさんも、業務中などで似たようなことをされているのではないでしょうか。
また、似たようなことをしてる“一流エンジニア”さんを私は何人か知っています。
フォーマット、スタイル、内容についてはそれぞれでしょう。
ワーキングメモの目的
“ワーキングメモ”の目的は、“すぐ書き込む”、“すぐ引き出す”、“すぐ忘れる”ための“短期記憶”を、ツールによって一部補助することです。
これにより、情報の“インプット”と“アウトプット”の最大化をはかり、自身の“生産性”を高めること。
そして、重要なポイントは、“長期記憶”と混同させないという事です。
言い換えれば私の場合は、業務の生産性向上はもちろんですが、“テクニカルメモ”の効果を減じないために、“ワーキングメモ”を分離しているという側面もあります。
このように、私は“ワーキングメモ”を、“テクニカルノート”とは別に常備し、記憶の性質によって補助ツールを使い分けています。
ワーキングメモの使い方
では、“ワーキングメモ”はどのように使えばいいでしょうか？
下記では、一例をあげてご紹介します。
ワーキングメモの要件例
- クロスプラットフォームで操作可能なこと。
- マルチデバイスで操作可能なこと。
- オンライン・オフライン環境で操作可能なこと。
- ソフトウェアに多くを依存しないこと。
（開発やサポート終了の影響を受けないようにするため） - etc...
ワーキングメモのポイント例
- 短期記憶の補助なので一時的なメモ扱いに限定する。
- すぐに書き込み、引き出せるように常に開いておく。
- 検索する時間を省くためできるだけ一箇所に集約する。
- 自分が見てちゃんとわかるものにする。
- 他人が見る用に清書しない。
- フォーマットにあまりこだわりすぎない。
- etc...
ワーキングメモのツール例
- 普通のテキストファイルエディタ
（アウトライン機能があれば尚可） - Markdown 可能なエディタ
- Google Drive
- OneDrive
- Dropbox
- BoostNote
- GistBox
- etc...
人間の“短期記憶”の性質がそうであるように、“ワーキングメモ”もインプットとアウトプットの“スピード”が非常に大切です。
そのため、私は常に“ワーキングメモ”ファイルを常時開きっぱなしにしたり、テーマを検索する手間を省くために 1 ファイルに集約してます。
その中で、“長期記憶化”が必要なものは、“テクニカルメモ”に転載します。
これらは、あくまで一例ですので、ご自身にあった用法をオススメします。
ワーキングメモ：まとめ
このポストでは、“一流エンジニアになるための Off-JT” シリーズのテーマとして、“ワーキングメモ”について解説しました。
業務の効率化や、“長期記憶”との分離、検索の手間を省くなど、“ワーキングメモ”を適切に活用することで、自身の“生産性“が向上され、“一流エンジニア”への道に繋がっていきます。
このスキルは、“ワーキングメモ”の目的からズレずに継続していくことで、“一流エンジニア”になるための“強力で有用な武器”になりえます。
このポストが、みなさんの“一流エンジニア”になるための一助になれば幸いです。
“一流エンジニアになるための Off-JT” シリーズ次回のテーマは “#4. フッキングメモ” の予定です。
一流エンジニアになるための Off-JT #2. 情報の精査
情報の精査：はじめに
みなさんは、“ある機能の実現方法を調べたいとき”、あるいは“新しい技術を習得するとき”、何から情報を仕入れることが多いですか？
あるコミュニティで、このようなアンケートを実施したところ、その多くの回答が“インターネット”というものでした。
近年では、インターネットと技術の進化に伴い、“課題解決のスピード”が以前とは比べ物にならないほどの高速化が進んでいます。
言い換えれば、現場で課題解決に“求められるスピード”が早くなってきたことと、課題解決に“かけられる時間”が短くなってきたということでしょう。
それらが十数年前より可能になってきたというともいえます。
情報の精査：工程の違い
下記では、“課題解決のスピード”が高速化してきた事例として、“ある機能の実現方法を調べたいとき”の十数年前と近年の工程の違いを比較してみました。
例：数十年前
- 課題発生
- 社内の有識者に尋ねる
- 未回答
- 本屋へ行く
- それっぽい本を物色する
- 立ち読みして整合性をとる
- 4 と 5 を何回か繰り返す
- 購入する本を何冊か決めてから一旦帰社する
- 書籍購入の稟議および決済
- 再び本屋へ行く
- 何冊か買う
- 帰社
- 熟読する
- 実装
- テスト
- 解決
例：近年
- 課題発生
- ググる、またはSNS やコミュニケーションツールでメンションする。
- 横断する、または返答がくる
（未解決なら有識者に尋ねる、あるいは書籍購入の流れも） - 重要箇所をピックアップする
- 実装
- テスト
- 解決
これらはあくまで、工程の一例でしかありませんが、このように一覧しただけでも、計 9 工程省略されているのが分かります。
このように、明らかに“情報の取得方法とスピード”に大きな変化があります。
以前を知ってる私たちからすると、便利になった反面ちょっと酷に思うこともあります。
私は購入した書籍を、会社の近くの砂浜で、先輩と一緒にビールを飲みながら読んでたので（笑
もちろん今でも、書籍購入はとても有効な手段でしょう。
しかしそれでさえ、Amazon などにおいては、電子版の購入までに何分とかかりません。
有料書籍の場合、金銭が発生するためでしょう、ほとんどの場合は“情報の精度”は高めに維持されていることでしょう。
その昔、書籍に誤った情報が記述されていた際には、私の上司や先輩方はその出版社に連絡をしていたものです。
それらの行為は、おそらく“情報の精度”の維持に役立っていたものと思われます。
しかし、いまやそれらの情報媒体の多くはインターネットが担っているのかもしれません。
情報の精査：ある出来事
ここで、ある現場で起きた極端な出来事を例示します。
あるエンジニアさんに、“ある機能の実現化”に向けて、“調査から実装まで”のアサインがされました。
その結果、結合テストで不具合が生じました。
コードレビューを担当した私は、ロジックが破綻した不具合箇所を見つけ
「なぜ、このようなロジックになったか？」
そのロジックの“意図”だけを確認するつもりでした。
そうすると、彼は
「このサイトにこう書いてあったからです。」
と答えるので、そのサイトを見せてもらいました。
そのサイトは、いわゆる“やってみた系“の情報サイトでした。
「でもこのサイトの情報は、そもそもバージョンが古くありませんか？」
と私が尋ねると、彼は
「でもそう書いてあったので。」
おそらく彼が言いたかったのは「特に自分の意思はない」ということだったのでしょう。
そう、この例の問題の本質は、実装ミスというよりは意識の問題です。
しかし、一つの“勝手サイト”の情報だけを鵜呑みした結果でもあります。
では、テクニカルマネージャーは、その“勝手サイト”の管理者に連絡をとって文句を言えばよいでしょうか？
仮に指摘はできたとしても、金銭の授受がない以上、ほとんどの場合はオープンソースの決まり文句のように、「自己責任でお願いします」というのが通例でしょう。
この事例では、無償で情報を得る側の立場として、自己責任になっていませんでした。
インターネット上の情報は、精度が担保されていない情報も多いのが現状であり、強く認識しておくべきです。
初学者は、その情報サイトに書いてある内容に、完全依存状態になってしまうものです。
これは当然の原理です。
しかし、よくある脱初級者クラスの例として、少しずつ応用が効くようになってきた頃、インターネット上の情報が誤っていることが分かると、必要以上に憤慨しているエンジニアさんをお見かけすることがあります。
私はこの事象を、“成長期”と呼んでいますが、必ずしもネガティブな事象ではありません。
なぜならこのような事象は、初級者の完全依存状態から抜け出しはじめた状態だと私は思うからです。
情報の精査：一流エンジニアの場合
一流エンジニアは、前回の記事の“テクニカルメモ”の例と同様に、“課題解決の調査から実装まで”の“生産性”が非常に高いものです。
“情報の精査”についても、ほんの短時間で見極めるエンジニアさんもたくさんいます。
これは、特に基礎技術をきちんと身につけてきたエンジニアさんほど、この傾向が強いように思います。
また、これは“エラー調査”の生産性においても如実に表れてきます。
では、彼らは一体どのようにしているのでしょうか？
情報の精査：スキル
この簡単な解決例は、およそ以下のようなものが考えられます。
- “オフィシャルサイト”は最低限マークしておく。
- 一つの“勝手サイト”の情報だけを鵜呑みにしない。
- 同じ条件下の情報を横断的に複数調査し、共通してる箇所を抜き出し、その情報を繋げてまとめて行く。
- “テクニカルメモ”を有効活用する。
インターネットで取得した“情報の精度”を上げるとするならば、オフィシャルコミュニティがある場合には、まずは必ず“オフィシャルサイト”は抑えておくべきでしょう。
ブックマークなり、Pocket なりしておけば良い話です。
これは、最終的な“情報の精度”の担保に非常に役にたちます。
しかし、“オフィシャルサイト”は、仕様を羅もうしなければならない任務からか、必ずしもユースケースにマッチする“分かりやすい情報”が載ってるとは限りません。
キャッチアップスピードを高めるためには、よりユースケースに近い“勝手サイト”の情報を参考にするケースもあるでしょう。
しかし、もし仮に検索結果の表示順位が一番目にあるからといって、その全てを鵜呑みにする行為は、“情報の精度”を上げる作業を怠っていると言ってもいいでしょう。
そこで、同じ条件下（OS 、バージョン、連携ツールなどが同じ条件）の情報を横断的に複数調査し、共通してる箇所を抜き出し、その情報を繋げてまとめ、“情報の精度”を上げていきます。
もし仮に、同じバージョンの情報がなければ、旧バージョンの情報を参考に、解決に向き合うことも必要になってくるでしょう。
まとめる作業は、“テクニカルメモ”を有効活用していくことをオススメします。
このようにして、“情報の精度”と“情報の分かりやすさ”を維持し、必要に応じてブラッシュアップして“情報の鮮度”と“情報の量”を確保していきます。
そして次回、似たようなユースケースでも、“テクニカルメモ”からすぐ引き出して応用できるようにしておく。
まずはシンプルにこれだけで、“課題解決の調査から実装まで”の“生産性”が一気に向上していくでしょう。
そして、違うユースケースでも、これを繰り返していくだけで、“情報の精度・分かりやすさ・鮮度・量”という、“情報の基礎力”も上がっていることでしょう。
そしていつしか、“情報の精査”スキルも身についていくことでしょう。
前述した、ある現場では
「もう少しだけ横断的に調べて、まずは共通点を抜き出し、正確な情報をまとめてみてはどうでしょう？」
ということで、解決に向かいました。
情報の精査：OJT において
私は OJT にトレーナーとして入る際、全てをテキストとして用意はしません。
例えば“サーバーの仮想化技術”や“ネットワークの OSI 参照モデル”について
「5 つくらいググって目を通しておいてください。」
という手法をよくとることがあります。
この際、必ずはじめに伝えてるのは、一つの情報サイトのみを鵜呑みにせずに、複数の情報サイトを横断的に調べるようアドバイスしておきます。
（これは、次回ポスト予定の“情報のフック”にも大きく関わってくるのですが。）
こうすることの目的は、以下のような効果が期待できるからです。
- その技術に関する知識の習得
- “情報の調査”スキルの向上
- “情報の精査”スキルの向上
- “テクニカルメモ”のインプットスキルの向上
- 技術に関する“多角的な視点”の向上
- 自ら情報をまとめることによる技術への“主体性”の向上
情報の精査：まとめ
このポストでは、“一流エンジニアになるための Off-JT”シリーズのテーマとして、“情報の精査”について解説しました。
インターネットから情報を得る以上、“情報の精度”を確保する作業は多くの場合は自己責任となります。
最終的な“情報の精度”の担保のために“オフィシャルサイト”をマークし、“勝手サイト”の情報を鵜呑みにせず、情報を横断的に複数調査し、共通してる箇所を抜き出し、その情報を繋げて“テクニカルメモ”にまとめ、“情報の精度”と“情報の分かりやすさ”を維持し、必要に応じてブラッシュアップして“情報の鮮度”と“情報の量”を確保していく。
次回、似たようなユースケースでも、“テクニカルメモ”からすぐ引き出して応用できるようにしておくだけで、“課題解決の調査から実装まで”の“生産性”が一気に向上していき、違うユースケースでもこれを繰り返していくだけで、“情報の精度・分かりやすさ・鮮度・量”という“情報の基礎力”も上がり、“情報の精査”スキルも身についていく。
このスキルは、“一流エンジニア”になるための“強力で有用な武器”になりえます。
このポストが、みなさんの“一流エンジニア”になるための一助になれば幸いです。
“一流エンジニアになるための Off-JT” シリーズ次回のテーマは “#3. ワーキングメモ” の予定です。
一流エンジニアになるための Off-JT #1. テクニカルメモ
テクニカルメモ：はじめに
特に IT 業界は、“技術の進化が早く”、また“技術の種類が豊富”で、さらに“情報量が膨大”です。
また市場では、シリコンバレーを起点に“プロダクトの開発と改善の速度競争”が激化しています。
世界では、これらの需要を満たす技術が日々誕生し、検証され、実用化されています。
したがって、これらの市場競争に参加する以上、現場では“プロダクトの開発と改善”のスキーム（例えば、アジャイル開発、DevOps、Growth Marketing など）や、“技術の進化”に対応していかなければ、組織も個人もいずれ時代に取り残されてしまう事になるでしょう。
このように特に近年は、そのトレンドの移り変わりの速さを実感されているエンジニアさんも多いのではないでしょうか。
ある分野に特化してるエンジニアさんであっても、技術に関わる以上少なからずこの影響は受けてることでしょう。
しかしそんな熾烈な技術進化の中にあっても、優れたエンジニアさんの中には、“技術のインプット”と“応用のアウトプット”が早く、そして多くの“引き出し”を持っているエンジニアさんがいます。
そして時として彼らは、これらの“生産性の高さ”から“一流エンジニア”と評される事があります。
（“エンジニアの生産性” については、別のポストで言及します。）
では、彼らのようなエンジニアは、これらの課題にどのように対応してるのでしょうか？
彼らの多くに共通していることの一つに、“テクニカルメモ”を適切に活用している、ということがあげられるでしょう。
実はこれは、初級エンジニアさんにとっては、ファーストステップともいえるスキルです。
また、初級段階でこのスキルを身につける機会のあったエンジニアさんは幸運だと私は思います。
しかし、中級エンジニアさんでも、今から取り組んでもぜんぜん遅くはないはずです。
なぜなら、このスキルはそれだけ価値のあるものといえるからです。
“一流エンジニア”になるための“強力で有用な武器”となりえるからです。
テクニカルメモとは？
“テクニカルメモ”とは、後で自分が見てわかりやすい“技術の記憶メモ”のようなものです。
新しく取り掛かる技術、知識、手順などを“素早く記録”し、必要に応じて“素早く引き出して”活用していくためのものです。
フォーマット、スタイル、内容はエンジニアさんによってそれぞれでしょう。
その一例は、この後記述します。
“一流エンジニア”の中には、このように“記憶用法”をうまく使い分けている方がたくさんいます。
手続き記憶（考えてもなかなか引き出せないが、タイピングすれば引き出せる等）、セマンティック記憶、エピソディック記憶、補助記憶など・・・（“記憶の用法”ついては、別ポストで言及します。）
そして、私の経験則からも“テクニカルメモ”をうまく活用してるエンジニアさんの多くは“成長スピード”が早いと感じています。
（もちろん、“一流のエンジニア”になるために必要な要素はこれだけではありませんが。）
なぜテクニカルメモは有用か？
いろいろな現場に入ってて感じるのは、検索サイトが進化したおかげで、良くも悪くも“全てを検索サイトに依存する”スタイルのエンジニアさんが増えたということです。
ここで問題となりうるのは“全てを依存”という箇所です。
例えば、必要に迫られて一度調べたはずの情報を、何度も検索サイトで検索して調べる方を、あらゆる現場でお見かけする事があります。
このような場合「あの記事が見たいんだけど、どこだ？」というように、検索結果の表示順位が変わってたり、一時的なサーバーダウンならまだしも、記事の削除、アカウントの削除、サイトの削除など、二度とその情報が出てこない場合もあります。
また、中には鵜呑みにすべきではない情報もあります。
（“情報の精査”については、別ポストで言及します。）
これはあくまで、ある現場での一例ですが、
「あれ？なんだったかな」「ないぞ？」「どこいった？」「これだったかな？」
という声が聞こえ漏れてくることもありました。
このように、同じ情報を何度も検索サイトで調べては時間を費やしてしまう行為は、“生産性”を上げるどころか、ほぼ“インプット”にもなっていない状態をつくり出してしまっている、といってもいいでしょう。
要するに検索サイトを、記憶装置化してるということでしょうか。
それであれば、まだ Pocket などを使うほうがマシといえるでしょう。
（“テクニカルメモ”としては疑問ですが。）
このようなスタイルで、且つ伸び悩んでいたエンジニアさん達に、“テクニカルメモ”の活用法をアドバイスしたところ、明らかに伸びていったのを今でも鮮明に覚えています。
もちろん、情報の量が多くて質が高い、どのサイトも内容がほぼ一定の情報については、それでも良いかもしれません。
（例えば cd コマンドのオプションなど）
また、“テクニカルメモ”にまとめること自体が不毛なケースもあります。
このへんは、極論ではなく程度感ともいえます。
“テクニカルメモ”の有用性は、このように全てを頭で記憶するには情報量があまりに多すぎる煩雑な状況に対して、“すぐ書き込み”、“すぐ引き出す”ための“長期記憶”の補助ツールとして利用できる点にあります。
その結果、“技術のインプット”と“応用へのアウトプット”の効率化と“引き出し”の増加により、“生産性が向上”するという大きなベネフィットが生まれます。
更に、“テクニカルメモ”の有用性を最大化するためには、“全てを記憶する必要はない”という明確な意識と、“記憶の補助として適切に活用する”という明確な意識が鍵になる、といっても良いでしょう。
単なるメモと何が違うのか？
単なるメモとは何が違うのか？
前述のように、“すぐ書き込み”、“すぐ引き出す”ための、“長期記憶の補助”という“明確な目的”の有無がその違いとなります。
これらの目的があれば、そのメモはおそらく“テクニカルメモ”とニアリーイコールでしょう。
しかし、雑記が目的のメモとは、明らかにその目的に違いがあります。
（ちなみに、私は雑記メモなどは、“短期記憶”（すぐに忘れてもよい記憶）目的として、“テクニカルメモ”とは別に“ワーキングメモ”を常備しています。）
テクニカルメモの使い方は？
では、“テクニカルメモ”はどのように使えばいいでしょうか？
下記では、一例をあげてご紹介します。
テクニカルメモの目的
“テクニカルメモ”を“すぐ書き込み”、“すぐ引き出す”ための“長期記憶の補助ツール”として活用することで、“技術のインプット”と“応用のアウトプット”の効率化と“引き出し”の増加をはかり、自身の“生産性”を高めること。
テクニカルメモの要件例
- クロスプラットフォームで操作可能なこと。
- マルチデバイスで操作可能なこと。
- オンライン・オフライン環境で操作可能なこと。
- ソフトウェアに多くを依存しないこと。
（開発やサポート終了の影響を受けないようにするため） - etc...
テクニカルメモのポイント例
- 一時的なメモ扱いにしない。
- 自分が見てちゃんとわかるものにする。
- 他人が見る用に清書しない。
- チームドキュメントに依存しない。
（組織の情報セキュリティ上難しい場合があるかもしれません） - 手順や情報をあまり省かない。
- 全てを記述するも必要もない。
- フォーマットにあまりこだわりすぎない。
- 追加情報がある場合は、都度ブラッシュアップする。
- 項目、技術内容によってファイルを分ける。
- etc...
テクニカルメモの配置例
テキストファイルの場合
テクニカルメモのツール例
- 普通のテキストファイルエディタ
（アウトライン機能があれば尚可） - Markdown 可能なエディタ
- Google Drive
- OneDrive
- Dropbox
- BoostNote
- GistBox
- etc...
これらは、あくまで一例です。
中には、自己表現やポートフォリオのアウトプット目的で、ブログなどでオンライン化されてるエンジニアさんもいっらしゃいますね。
このへんはご自身にあった活用法をオススメします。
テクニカルメモ：まとめ
このポストでは、“一流エンジニアになるための Off-JT” シリーズのテーマとして、“テクニカルメモ”について解説しました。
情報量があまりに多すぎる煩雑な状況に対して、“テクニカルメモ”を適切に活用し、“技術のインプット”と“応用のアウトプット”の効率化と“引き出し”の増加をはかり、自身の“生産性を向上していく事で、“一流エンジニア”への道に繋がっていきます。
他人に見せるアウトプット用ではありませんので、フォーマットやレイアウトにこだわりすぎると、本来の目的を見失いかねません。
また、せっかく“テクニカルメモ”を活用していても、インプットを忘れてしまったり、時として面倒になってしまうケースもあります。
したがって、ご自身が面倒にならない内容に留めておくことも秘訣の一つです。
新しく調べた技術は、必要なことは都度インプットしておくようにしましょう。
そのうちインプットの仕方にも慣れ、“テクニカルメモ”のスキルも向上していくでしょう。
このスキルは、“テクニカルメモ”の目的からズレずに継続していくことで、“一流エンジニア”になるための“強力で有用な武器”になりえます。
このポストが、みなさんの“一流エンジニア”になるための一助になれば幸いです。
“一流エンジニアになるための Off-JT” シリーズ次回のテーマは “#2. 情報の精査”の予定です。
一流エンジニアになるための Off-JT
> for English Pages kyowg.blogspot.com
一流エンジニアになるための Off-JT について
「どうしたら一流のエンジニアになれますか？」
IT 関連の講義やセミナーなど、このような質問を多く受ける機会があります。
（ここでは「一流」の定義は言及しません。）
私はこのような質問に答える際、質疑応答の時間が限られてる場合は、端的に答えられる代表的なことしかお伝えしません。
しかし、実際にはそのためのコツはいろいろとあります。
例えば、私が OJT にトレーナーとして入るようなご縁があるエンジニアさんには、状況に応じていろいろとお伝えしています。
しかし、このような解を求められる全てのエンジニアさんと一緒に OJT に入れるわけではありません。
そこでこの記事では、少しでもそのお手伝いができればと、そのためのコツを“一流エンジニアになるための Off-JT”というシリーズで、次回以降テーマごとにお伝えできればと思います。
一流エンジニアになるための Off-JT シリーズの対象
このシリーズ記事の対象となる方は、下記を想定しています。
- エンジニアを目指してる方
- 初級・中級エンジニアの方
- 伸び悩んでいるエンジニアの方
- テクニカルマネージャー、ディレクターを目指してる方
- CTO, CIO を目指してる方
- etc...
一流エンジニアになるための Off-JT シリーズの注記
「一流」について
このシリーズでは「一流エンジニア」の「一流」について、定義する予定はありません。
「一流」とはあくまで抽象的概念が強く、一流のエンジニア像は各々でイメージが違うはずだからです。
トップエンジニア、リードエンジニア、シニアエンジニア、チーフエンジニア、優れたエンジニア、できるエンジニア...
必要があれば、適宜読み替えてください。
「スタイル」について
エンジニアとしてのスタイルはそれぞれ違うもので、決して一つではありません。
また、私とみなさんは、同じ組織に属した関係ではない以上、バリューや方向性に違いがあるかもしれません。
ですので、ご自身が必要だと思う該当箇所や、参考になると思う該当箇所を抜き出し、ご自身のスタイルに変えてご活用頂ければと思います。
“一流エンジニアになるための Off-JT”シリーズ初回のテーマは、“#1. テクニカルメモ” の予定です。
お蔵入りした NoSQL プロジェクトの話
お蔵入りした NoSQL プロジェクトの話
> for English Pages kyowg.blogspot.com
Introduction
「NoSQL」 このキーワードが世にはじめて出たのは 1998 年とのこと。 だが、当時はほとんど浸透しなかったらしい。 そして、2009 年初頭に、ある人物によって再提唱されてから NoSQL は徐々に普及しはじめる。
つい先日、自分のソースコードを整理していたら、最終更新日が 2004 年 11 月のソースコードに目が止まった。 そのソースコードは、近年では「ドキュメント指向 DB」と呼ばれる NoSQL のスクラッチソースコードだ。 NoSQL の初提唱が 1998 年で、我々が、NoSQL らしきプロジェクトを開発していたのは 2003 〜 2004 年。 NoSQL が世の中へ普及し始めたのは 2009 年で、世の中へ普及したのはそのもっと後だろう。 要するに NoSQL が普及しはじめる 5 年以上も前のプロジェクトの話である。 いまからもう 15 年以上前の話である。
このソースコードを見て改めて感じたことは「こういう技術的イノベーションのアプローチは決して間違ってない」ということだ。 そして、その時に私たちが発明した技術が、私がいま携わっている AI 研究にも役立っている。 イノベーティブな技術者たちには、あきらめないで欲しい。 そして、いまの NoSQL 技術に尽力した技術者たちに感謝をしたい。
IfDB
少しだけこのプロジェクトの概要を紹介する。 このプロジェクト名は、下記のように何回か遷移した。
FileDB -> IniDB -> IfDB
当時、我々は NoSQL という言葉を全く意識していなかった。 それどころか、おそらく我々はそのような言葉を知らなかったはずだ。 データの CRUD 処理は以下のような流れだ。
配列 -> クエリコマンド -> Ini File -> 結果セットの配列
そして、我々は SQL ライクな構文まで実装した。 そして我々が重視したことの一つは、コマンド経由ではなく Ini File の直接編集も可能にすることだった。 なぜなら、当時 Json は汎用的じゃなかったからだ。 この技術は、今でも用途によっては有用ではあるが、私は他のプロジェクトで忙しくなりこの 10 数年間忘れていた。 しかし、この技術によって、当時の私のプロジェクトの開発速度と改善サイクルが非常に向上したという記憶がある。
Why was the IfDB developed?
15 年前の我々は、なぜこんなものを作り始めたか？ 私は、このプロジェクトのソースコードを久しぶりに見たが、コンセプトは今のドキュメント指向 DB とたいして変わらない。 15 年前の私は、関係モデルの設計が非常に面倒だったが、ウォーターフォール的なデータモデル設計やスキーマの制約に疑問をもっていた。 なぜなら、関係モデルとスキーマが静的化されることにより、プロジェクトのスケーラビリティが損なわれるからである。 当時、DBA たちはみんな口を揃えてこう言った。
「それはデータモデルの設計が悪いからだ。」
「データモデルをもっと勉強しなさい。」
しかし、データモデルを勉強するほどその違和感は大きくなっていった。 おそらく 15 年前の私は、アジャイル開発による改善サイクルを向上したかったのだろうと、今になると思う。 おそらく当時の私は、アジャイル開発という言葉でさえ知らなかったはずだ。 アジャイル開発も 1990 年代が提唱時期である。
Conclusion
技術のデファクトスタンダードは、事業においてとても重要な要素である。 そして今、「なぜデファクトスタンダードが重要なのか？」という、目的に対する優先順位や、根拠を持てないエンジニアが増えている。 そしてこう極論する。
「非デファクト = 悪」
「スクラッチ開発 = 無駄」
私たちはあなたも含め、非デファクトだったそのスクラッチ開発の上に乗っかっている。 目的によって、持続的イノベーションも、破壊的イノベーションも重要である。 それは時代が常に証明している。 イノベーティブな技術者には、是非あきらめないで欲しい。
スペースキャメルコメントスタイル & レイヤーコメントスタイル
スペースキャメルコメントスタイル & レイヤーコメントスタイル
> for English Pages kyowg.blogspot.com
1. Overview
プロジェクトにコメントスタンダードがない場合、ソースコード上のコメントスタイルは、プログラマーのスタイルによって様々だろう。 このポストでは、プログラミングのコメントスタイルとして、スペースキャメルコメントスタイルと、レイヤーコメントスタイルを示す。
2. Introduction
プログラマーからよくこのような声を聞く。
「コメントに何を書いていいか分からない。」
「コメントの粒度が分からない。」
このポストでは、これらの解決方法の一つとして、スペースキャメルコメントスタイルと、レイヤーコメントスタイルを提示する。 尚、以下についてはこの投稿では特に触れない。
3. コメントスタイル
3-1. スペースキャメルコメントスタイル
一般的な定義が見当たらなかったため、ここでは「スペースキャメルコメントスタイル」として定義する。 このコメントスタイルは、オブジェクト指向のメソッド名のような、キャメル記法にスペースを挟んだコメントスタイルである。
# set Controllers and View Resources
このスペースキャメルコメントスタイルがなぜ有用か。 このコメントスタイルは、ロジックをメソッド化する場合の命名アプローチに似ている。 どこからどこまでの処理を「一つの振る舞い」として考えるかで、コメントの範囲が決められる。 その「振る舞い」に対して、メソッドを命名をするかのようにコメントを記述する。 こうすることで、コメントの粒度やスタイルが明確になっていく。 粒度のコツは、処理の流れを振る舞い単位で考えることだ。 可読性向上のために、シンプルな命名に慣れたトッププログラマーなら、この記法でもおそらく違和感はないだろう。 また、コメントはメソッド名のように再利用性や衝突などの影響を受けないため、メソッド名よりもはるかに柔軟に書けるはずだ。 もちろん、コメントで多くを説明しなければならない場合にはこれにあたらない。
3-2. レイヤーコメントスタイル
一般的な定義が見つからなかったため、ここでは「レイヤーコメントスタイル」として定義する。 このコメントスタイルは、マークダウンのヘッドの階層のようなコメントスタイルである。
# set Controllers and View Resources processing… ## for Controllers processing… ## for View Resources processing…
このレイヤーコメントスタイルがなぜ有用か。 プログラムソースコードは、同じレベルのインデントであっても、処理の階層が異なる場合がある。 このような場合において、コメントを多階層に考えることによって、処理の視認性やコードの可読性をあげられるかもしれない。
4. Conclusion
このポストでは、スペースキャメルコメントスタイルと、レイヤーコメントスタイルの 2 つのプログラミングのコメントスタイルを提示した。 スペースキャメルコメントスタイルについては、デプロイ時のコミット文にも応用可能かもしれない（詳細文は別）。 また、プログラミングスタイルが、オブジェクト指向でも手続き指向でも、低レイヤーの処理は必ずどこかに書かなければならない。 これらのコメントスタイルは、そういった低レイヤーの処理の記述には特に有用かもしれない。
