開発環境
エンジニア
新人プログラマ応援
働きかた

システムエンジニアの弱点を武器にする方法

システムエンジニア、プログラマというのは面白い仕事である。

たとえば「記憶力の低さ」が有利に働く場合がある。


  • 自分が書いたコードは3日も覚えてられない

  • だからこそ、覚えておかなくても良いコードを書く

これが有効に働く。

なぜなら「覚えておかなければいけないコード」よりも「覚えておかなくて良い」コードの方が優れているからだ。


弱点が武器になる

僕の場合は、


  • 変数名やクラス名などで、名前付けがすごく気になる。

  • 名前と実体やイメージがズレていると、いつまで経ってもコードをよく理解できない。

  • テストの説明 ( rspec だと it "diplays user accounts" みたいな部分 ) が曖昧だと、テストが仕様書として読めずに、混乱する。

という弱点がある。

だがこれは、


  • そもそも実体と乖離しない、理解しやすい名前をつける。

  • 仕様書として読めるテストを書く。

という長所に置き換えられる。

(少なくとも、それを意識してコードを書くことは出来る)


理解力の低さを武器にする

これは「理解力が高い人」には出来ない芸当だ。

なぜなら、ある特定の領域を「すんなり理解できる人」はそもそも「理解しづらい部分」がどこか分からないからだ。

なので「理解しづらいと思った人」が声を挙げて、真っ先に改善を施すことによって、コードや開発環境はより良いものにすることが出来る。

ちなみに「理解力の高さ」は領域によって変わる。ある領域では理解力が低い人が、ある領域では高かったりする。

あくまでも特定のコンテキストにおける話だと考えてほしい。


分かりづらいことは分かりづらいと言ってみよう

開発環境やコーディング方法の改善のきっかけとなるのは、「これは分かりにくい」「これはやりづらい」という個人的感覚である。

だから「分かりづらいこと」を「分かりづらい」と言ったり、「やりづらいこと」を「やりづらい」と言うことは意外に重要だ。

これは決して、コードやプロジェクトを理解する努力を放棄しろという意味ではない。

何百回理解しようと努力しても、何百回でも自分が突き当たる「ネック」には、何か落とし穴が隠れているはずという話だ。

それをメンバーにシェアした結果


  • 他の人にも、実は分かりづらかった。

  • 自分だけが、分かりづらかった。

という2種類の、どちらかのフィードバックを得ることが出来るだろう。


初心者向け注意


  1. 自分が理解できていない部分

  2. 実装的に分かりづらい部分

この違いを区別するには、


  • プロジェクトの内容が理解できている

  • 技術的な事柄が理解できている

ということが前提となる。

もしプロジェクトや技術領域がよく理解できていないなら、まずは理解する努力をしてみよう。


熟練者向け注意

逆にプロジェクトや技術分野に慣れた熟練者の場合、状態化している問題は、特に意識にのぼらなくなる。

関わっている年数が長ければ長いほど、自分自身が問題に最適化してしまって、問題自体が見えにくくなるからだ。

なので、


  • 意識的に開発の死角を見つけ出す。

  • プロジェクトに慣れていない人の声に耳を傾ける。

ということが重要になってくるだろう。


具体例

自分の場合。


  • API エラーを起こした時に Slackに飛んでくる通知の情報量が少なく、毎回調査コストが発生していたのを、詳細なエラーが表示されるようにした。

  • Github のレビューで何個の + が付いているかを一覧するために、Approve機能を使うようにした。(それ以前は +1 を表現するために、Convesations にコメントを付けていた)

  • Github で レビュー中の状態を分かりやすく示すために、レビューリクエスト機能を使ってはどうかと提案した。(この提案はウケが悪かったので)


    • たとえ提案が却下されても、チームとして失うものは何もない。



  • Wikiの情報が腐っているのに気付いたら、すぐに更新する。

というようなことを実践した。

上記は非常に些細な事ではあるが、誰かが最初に声を上げなければ改善されなかった部分ではある。

そしてこういった小さな改善を積み重ねることによって、僕たちがコアなストーリーに使える時間は少しずつ増えて行くのである。

エンジニアにもっとも重要なのは、開発における幸福度だと僕は考える。


まとめ


  • システムエンジニアは、特定の能力の低さを武器に出来る

  • 自分の欠点をカバーするための改善は、全体にも寄与する可能性がある。


関連記事


4年勤めたNTTを退職して1年が経ちました - Qiita


技術力なんて持っていなかった

我々がドキュメントの体裁を整えているとき、彼らはずっとプログラムを書いています。

マネジメント能力で戦える

一方で彼らは綺麗なV字モデルでの開発経験はありません。

システムの仕様に関してお客様と揉めた経験もありません。