91
33

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

フロムスクラッチAdvent Calendar 2016

Day 21

[俺的]エンジニアにとって、必須な3つのベース思考

Last updated at Posted at 2016-12-21

この記事はフロムスクラッチ Advent Calendar 2016の21日目の記事です。

はじめに

新卒2年目のエンジニア。(主にインフラ)
大学院時代も特にプログラミング等を
やっていたわけではないのですが

そんな私でも
開発、保守・運用のリーダーをやらせていただいて
その中で

「これは、エンジニアにとって、大事なんじゃないか!」

と感じた3つのベース思考(俺的)に関して
私の「口癖」と共にご紹介したいなと思います。

エンジニアにとって、必須な3つのベース思考

それは

  1. 経験主義
  2. KISSの原則
  3. 引き算思考

の3つです。以下、順番に説明します。

1.経験主義

経験.png

経験主義とは。

認識の源泉をもっぱら経験に求める哲学説。
代表的なものは17〜18世紀のイギリス経験論であり
一切の観念は感覚的経験から生じるとして、生得観念を否定した考え方。(広辞苑)

つまり
経験主義とは、「人間の考え方・認識は、経験から生まれる」という考え方。

もちろんこれは、いろんな場面で言えることだと思うのですが
特にエンジニアの業務は
「知ってる」よりも「やったことがある」
という「経験」の方が、すごく尊重される傾向にあると感じています。
(アンチパターンとかって結構勉強になったりするのは、そういうところかなと。)

私の中では、「経験」というのは
2種類のサイクルがあると思っています。

1.1 経験の「個人の」サイクル
1.2 経験の「組織の」サイクル

この切り口で、以下少し掘り下げてみました。

1.1 経験の「個人的な」サイクル

よく教育論の中で挙げられる
代表的な考え方として
アメリカ合衆国の哲学者デューイの『経験と教育』というものがあり
その中で、以下のようなサイクルが大切だと言われています。

 1. 経験に基づいて仮説を立てる
 2. 結果によって仮説を検証する
 3. 検証結果を反省して次の経験に備える

過去の経験をinput(経験)として、output(経験)して
それをさらに次のinputする的なサイクルです。

つまり
いつまでも「同じoutput(経験)」していていたら
そりゃあ「同じoutput(経験)」しか出せないでしょ!
みたいなイメージ。
だって、「新しいinput(経験)」がないから。

そんな時の口癖は

###口癖:「まずやってみよ!」

ありきたりかもしれませんが、自分自身にそう言い聞かせて
食わず嫌いはせず、失敗してもいいから
とにかく今までやったことないことを、経験してみて
上記の1~3のサイクルを、如何に早く回していくことが
特に現代のエンジニア、「個人として」は、大事かなと日々感じています。

1.2 経験の「組織的な」サイクル

一方で、
「組織」に焦点を当てて考えてみました。

組織の中で色んなタスクがあるかと思うのですが
ふと思うと
「経験したことのある人」のところに
「経験の機会が回ってくる」ことが多いなーと
感じることが多々あります。

これは、エンジニアだけではないかもしれませんが
「経験」が尊重されるエンジニア業務だからこそ
より一層その傾向が強い気がします。

ただそれでは
組織的に・長期的にみた時に
同じ人に業務が属人化してしまい
それは
組織としてリスクであり、生産性の最大化できないのではないか
と考えています。

そんな時の口癖は

###口癖:「経験したことがある人がやるのは、簡単。」

まぁ本当、簡単なんですよね笑
やったことある人が、やるのは笑

もちろん仕事なので、リスク(期日、品質の程度 etc...)
とのトレードオフだったりするのですが
本当に、そこに価値があるかどうかというのを
都度問い直してみると
私の場合は、今までには無かった見方が出てきたりします。

2. KISSの原則

シンプル.png

"Keep it simple, stupid"

設計の単純性(簡潔性)は成功への鍵だということ
不必要な複雑性は避けるべきだということの考え方。

直訳すると
「シンプルにしておけ!この間抜け」
ちょっと口が悪いですが、まぁ言いたいことはわかります。笑

この言葉は、色々な技術系の本とかでもよくでているので
知っている方も多いのではないでしょうか。

日頃
要件を固めたり、設計をしたり、コーディングしたりしていると

「いや、、、それはどうしようかな。。。」
「おっと、、、これはきついな、、、」

みたいなことって結構あるんじゃないかなと思います。

そんな時の口癖は、

###口癖:「いや、"普通に"考えて〇〇でしょ。」

ここでいう"普通に"は、
私的には、"シンプルに"とニアリーイコール。

結構「普通に」考えることで
大したことないことで悩んでることに気付けたりします。
あえて口に出すことで
思考・視点を上げる効果もあるので、オススメです。笑
少しでも違和感を感じた時は、いつもこの口癖を言っています。

3. 引き算の思考

引き算.png

「このコードもうたぶん使ってないけど、テストしないといけないし、あとで削除しよう。」
「ちょっとすぐ決めれないから、とりあえず、持ち帰って検討しよう。」

一概に言えませんが
「たぶん」「あとで」「とりあえず」「検討する」
という言葉を、違和感なく、口癖にしちゃいけないなと
いつも私は、心がけています。

結局、そうやって後回しにしているものは
解決できる課題もダラダラと解決できないで、負の遺産として
残り続けてしまうことがしばしば。。。。

しかも、いつまでも解決されない課題が残っていると
精神的にもあまりよくない、かつ、色々なリスクがあるなと思っています。

例えば
もう今は使っていないコードを放置した場合
を、例に挙げて考えてみると

1. 後任者が改修するときに、わからないコードが残っている。
2. わからないコードのおかげで、無駄な考慮点が増え、テストしなければならないことも増える
3. そうやっていると、本当に大事なところの要件が漏れる。
4. "品質が上がらない"と言われ、管理しないといけなくなる。

ちなみに
私個人的には、正直「管理されたくない」人間なので
できれば、管理されずに高い品質のものを開発したいと考える人間です。

だいたいこうなると
"品質を担保するのは管理側の仕事"という意識が開発側に現れて
組織に対して、溝ができて
色々な組織的な課題が出てきて、"品質が低下"しがちになったり
することってよくあるんじゃないかなと感じています。

うーん。そうなると、悪循環ですよね。。。
開発側も管理側も

「プロダクトの品質を上げたい」

その想いは、みんな一緒のはず。
だけど、"現実"と"理想"に大きなギャップが生まれてしまっている。
どうしてでしょうか・・・?

オーストリアの心理学者アドラーの言葉でこんな言葉があります。

「変われない」のではない。「変わらない」という決断を自分でしているだけだ。

これをエンジニア的に言い換えると

「管理されたくない」のではない。「管理されたい」という決断を自分でしているだけだ。

[結果]
管理されている

[原因]
「管理されたいと思っている」もしくは「管理されたいと思われる」ような行動を自分が決断している

という因果関係があるはずというのが、アドラー的考え方。(当事者の意識の有無に関わらず)

そんな時は、

###口癖:「これ、本当に必要ですか?」

そう口に出して、改めて考えてみると
案外、重要じゃなかったりすることって結構あったりします。
重要じゃないものを増やさない無駄に増やさず
もっと重要なものに目を向けるためにも
この"引き算の思考"は、すごく意識するように心がけています。

まとめ

また、「2年目の若造が何をわかった口を!!!」
と思われる方もいるかもしれませんが、本当失礼いたしました。
実際見返すと、
正直、全然シンプルじゃなかったかも・・・みたいなところあります。笑
若造の独り言だと思って、ご容赦くださいm(._.)m

まぁでも私個人的に、堅苦しくせず
「普通に」・「シンプルに」考えて
エンジニアにとってベースにあるべきものを一つあげるとしたら

###子供のような"遊び心"

じゃないかなー。あー本当遊びたい!笑

その気持ちを忘れずに

###Keep it "Smile", stupid.

でがんばってまいります!

推して参る!!!ミ(`●∀・)彡キリッ

91
33
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
91
33

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?