なので、私自身は、今よりも知識を増やすために色々と勉強しています。新しい知識を増やしたり、実際に増やした知識に対して手を動かしてみたり。
あくまで忙しくないから出来ることでもあります。
自分流の順序
ぶっちゃけると、私のやり方はあまり良くないと思いますが書こうと思います。多分…頭が悪いと思っている人向けだと思いますwまず環境構築から
システムエンジニアの仕事をしていると、何事にも仕様書というものがついてまわります。これこれはこういうものですよ~とか、どれそれはここに書いてますよ~とか、いわゆる製品の仕組みなどが記載されたものです。
「これに対応するのは〇〇で△△は〇〇と連携しない部分があってXXはそれに限らず…」とかかなり意味不明な文章で書いてある時もありますw
仮にこのように記載してあり、出てくる用語がわかるものばかりであれば理解も出来るのですが、そこによくわからない用語が出てきた時にはもうちんぷんかんぷんになりますw
なので私の場合、まず動く環境を作ることを最優先としてます。
理由はただ一つ。
仕様書を読んで理解できる人は天才
と思っているからです。周りにそういう人種が数人いますが、頭の中でどんな環境かが想像できているんです。
そして、決まって頭のいい人w
いわゆる、「教科書を読むだけで問題が解けてしまうタイプの人」です。身の回りにそんな人いませんでしたか? 今考えると凄いと思います。というか羨ましいw
仕事に置き換えると、「仕様書を読むだけで製品の仕組みがわかるタイプの人」ってなとこでしょうか。
私には無理ですw
なので、実際に環境を構築して、動かしてみて、動かなかったら仕様書を読んで――ってな感じで仕様書を理解していくタイプなのです。
私のようなタイプのメリットは、実際に環境を構築する上で躓く箇所やわからない箇所がある程度判断がつくようになることです。
私の場合は躓いたら都度調べて解決してきたので、今では躓いてもある程度どこが原因かわかるようになってきました。
勘が良くなったってことですね。ある程度、原因に基づいて解決方法を模索するので勘とは言えませんがw
例えば「DNSサーバー構築しておいて」と頼まれたとします。
というか、最初、ネットワークのネの字も知らない頃に言われたものですw
ここで、頭のいい人は、有名な解説本、オライリー・ジャパンが出版しているDNSの書籍を読んである程度どんなものか理解したうえで構築していきます。 しかし私の場合は、いわゆるおすすめと呼ばれる書籍を読んでも全くわからないのです。
そのため、まずgoogleで「DNSとは」と検索することから始めます。
すると、IPアドレス、サブネットマスク、デフォルトゲートウエイなどまたしてもわからない言葉が出てくるのでそれぞれを調べて行き、自分の中で噛み砕いて理解していきます。
最終的にはある程度理解出来たところで、先ほどのオライリー・ジャパンの解説書を読むと理解が出来るといった感じです。
そして知識を得ながら構築していくのでところどころ躓くのですが、トライアンドエラーで進めていくのでうまくいった時の記憶が自分の中に刻まれます。 ってな感じです。
今までそうやってやってきた結果、様々な環境構築を経験してきたので躓く箇所や、躓く原因、というものが自分の知識として付いてきました。
先に書いたオライリー・ジャパンから出版されている書籍はとても読みやすいので私はよく使っています。特にこの2冊はいつも手元に置いています。
ある仕事でのこと
もう何年も様々な環境構築をしてきたのである程度は身についています。ここからちょびっとだけ技術的な用語が出てきます…もしシステムエンジニアの人が読んでいるならば…わからない単語はバッチリ知識として身に付けて置いてくれると嬉しいですw
さて、私が暇そうにしているのを上司が見つけて(見つかってw?)、別のプロジェクトの環境構築を手伝うことになりました。そのプロジェクトでは、セキュリティ系の業務をやってるチームです。
ソフトウェアのセキュリティ機能がしっかりと動作するかのチェックです。TLS(SSL)系の証明書に関する業務や、httpsのパケットを見たりなどでしょうか。
私自身は、windows環境やLinux環境でCA構築したり、様々なタイプの証明書を作った(イレギュラー系や脆弱性をもった証明書)りした経験があったからです。また、暗号化されたパケットの復号も経験済みです。
プラスα、ある程度仕組みも理解しているため、問題が発生しても自力で解決することが出来ます。
そのプロジェクトのヘルプとして入って驚きました。なんと作業は全部コピペでやっていたのです。
そのコピペはLinuxのコマンドでした。
コピペの内容を読む限り、正しいコマンドです。
私
このコマンドって誰が調べたんですか?全部まとめてあって便利ですね。
同僚
前任者が調べて残していったメモです。後は請負先にやり方を聞いたりとか。
そのコピペする元のメモを見て私がわからないコマンドがあったので聞いてみました。
私
このコマンドの後にある○○ってどんな意味でつけているんですか?
同僚
さぁ…?でも動くのでこれでいいんじゃないですか?
とりあえずanz-mさんには、○○の環境に必要なコマンドを調べて欲しいのでお願いします。
とりあえずanz-mさんには、○○の環境に必要なコマンドを調べて欲しいのでお願いします。
仕組み知らなくてもいいの?
ちなみに、そのわからなかったコマンドはあとで調べて理解しました。が、、、意味や仕組みを知らないまま使っていることに驚きました。
それ客先に説明出来ないんじゃないかと思ったりもしました。
その後1時間くらいで頼まれたことが解決出来たので言いに行くことにしました。
少しお節介だと思いつつコマンドの意味も添えて教えようと思っていました。
私
さっき頼まれたのなんですけど、解決できそうです。そっちの環境で試してみていいですか?
同僚
はい、お願いします。
私
ここがこれで、いつもはこうなっているところをこうすればいけます。追加情報をその時に入れてあげてください。
同僚
…あ! 出来ました! ありがとうございます。
私
あの…一応仕組みも説明しますけど…
同僚
あー…動いたので大丈夫です。聞いてもわからない(理解できない)ので、動かなくなったらまたそのときに聞きます。
仕組み知らないまま、コピペでコマンド打っちゃうんですか…。仕組み知っておけば、修正するコマンドの場所も絞れると思うのですが…。
と思いながら、
私
わかりました、動かなくなったらまた言ってください。
考え方の違い
これは、根本として考え方が違うために起こったことだと思います。私のとしては、できればコマンドの意味も理解してもらって、理解したうえで使って欲しかったのですが、私に仕事を頼んだ同僚としては、
難しい説明をされてもわからないから、今動く物が欲しいといった感じでした。
実際、動けば仕事は進みますから、無駄を省いて行っていることになります。わからないことがあれば誰かに聞くことで都度解決していくかもしれません。
どちらが正解、不正解ということは実際にはないと思います。私自身は、自分が正しいと思っていますがw
私自身は、システムエンジニアとして作業効率化するためのコピペはかなり推奨したいのですが、意味もわからずコピペするのはちょっと問題な気がします。
見た目は動作していても、中身が違っていた場合、コピペの意味がわかっていなければ解決の糸口が全く見えない時があります。
なので、聞いてるふりでもいいから、「仕組みはどんなのですか?」と聞いてくれたほうが救われますw
ただ、仮に自分が以前に教えたコマンドが動作しなくなったらまた聞きに来るとは思うので、その時なんで動かないかなどを自分の知識にしていけたらと思っています。
まとめ
私は、今のチームがかなり優秀な人が多く、また仕組みから理解していくタイプの人が多いチームに所属しているためこのような考え持つように影響されたのかもしれません。実際、仕組みから理解していくと、躓いた時にどこで躓いたかというのがわかることが業務をしてきて多いと感じます。
仕組みを考えるのが苦手な人を前にも取り上げました。
職場にいる同じチームの人のスペックが低い…。 教えてるけどなかなか感触が得られない。
私は小さな会社の小さなプロジェクトのリーダーとして働いています。 主に、プロジェクトの計画をたてたり、客先とのやりとりを主に行っています。 実作業は主にチームメンバーに任せきりでいます。 なのでぶっちゃけ暇ですw ただ、他のプロジェクトを...
自分の強みとしてネットワーク関係やセキュリティ関係の知識なのでこれからも磨きをかけていこうと思っています。
以上、自分のストレスを発散するためのエントリー(愚痴w)でしたw