見出し画像

弊社の企業文化に対しての圧倒的主観的見解

と、カッコよく漢字を並び立ててみたけど、今回のトピックは入社して以来フルコミットでSIerとして2年間出向し続けたエンジニアから見る弊社の企業文化について2年間を振り返りながらこう捉えると良い事ジブンゴトとして捉えられるし使えるぞというのを圧倒的な主観で書いていきたい。

長く書いたところで、結果何が言いたいのとなるので、折角定義されているMVVのValueとして弊社では3つ定義しているのでそれにに沿って書いていこうと思う。


*****


Good is good.

1つ目の行動指針がGood is good. -クライアント、ユーザー思考で価値あるものを作るだ。

スクリーンショット 2019-12-02 0.53.26

そもそも、エンジニアやデザイナー、…様々なレイヤーの人達が集まって全力で作ったところでそれが良いものかどうかを決めるのは極論クライアントでありエンドユーザーだ。

クライアントが事業戦略上「こうしたいんだ!」というドリームを実現させ、どれだけその先のエンドユーザーに「使いたい!」と思わせられるかで結果として良いものかどうかが判断される。

このバリューの定義している良いモノが履き違えられがちだが、作り手が良いと思うものが必ずしも案件に取って最適解かどうかはわからないということだ。

ただ、これを常に思考の一端に置いて実装や設計を行うにはある程度の経験値やそれなりの手札が必要になってくる。
じゃあ、エンジニアやデザイナーになりたての人はどうしたら良いのか。
行動指針にはこうも書かれている。

何より、自分自身の期待を超える

僕のエンジニア歴1年目から心がけてることでもあるけど、これが意外と肝だったりもする。

codepencodropsを見ていると、海外のエンジニアが凄いアニメーションやSPAの技術を活かした良いUIをアップしている。
これを見て常々誰かできるなら俺にだってできるはずだ。と思っていて、求められている機能の実装を妥協することなく実装することを心がけている。

このとき注意することとしては工数を圧迫しないこと。
当たり前だが、プレイヤーとしての最低限の義務は求められていることを全うし、クライアントが求める納品物を期間内にあげることにある。

その限られた環境の中でも自分自身へ挑戦し続けることは大なり小なりGood is good.だし、セカイを変える力につがるんじゃないかなと思っている。


*****


JUST HACK IT.

2つ目はJUST HACK IT. -走りながら考え、失敗を糧に、少しでも前に進めるだ。

スクリーンショット 2019-12-02 0.53.37

出てくるワードからは、何とも言えないネガティブなシーンを想起させるものばかりだが、冷静に考えてみればゲームだってボス戦までセーブポイントがない、相手モンスターに効果的なモンスターがいない、…常に何かしら障壁があって如何にやりくりするか、その思考性も楽しみのひとつとしてあったのではないかと振り返ってみると思う。

どれだけ転職しても自分に100%マッチする企業がないのと同様に、どれだけ色々な女性と交際しても100%息が合う女性と出会えないのと同じ様に、どの案件にも必ず何かしらの課題はある。

特に弊社はスタートアップ。
ありとあらゆることを自分たちで作っていかなければいけないフェーズでもある。

民族学者の梅棹忠夫の言葉にもこうある。

歩きながら本を読み、読みながら考え、考えながらあるく

よく耳にするKPTやPDCAなどがあるように、日々の業務でも小さなものから個人的な目標値を決めて1日作業し、10分だけでも良いから帰路に振り返りと翌日の目標を定義していく。

これはタスクベースではなく、〇〇を0にする。などが好ましい。
例えば、プルリクの手戻りを0にする。などである。
プロジェクトベースで出してしまうとそれはあくまでプロジェクト上のタスクにすぎないからだ。

どの業務でも、何なら精神的に心がけることでも良い。
なにか一つ、サイクルを回して日々を過ごしていくと小さなステップアップを続けていけるようになる。


*****


Making a great team.

最後は、Making a great team. -組織の成長にコミットし、役職問わず、最高のチームをつくる。である。

スクリーンショット 2019-12-02 0.53.51

これは、正直スタートアップだからこそというのもあって明示的に書かれているのではないかと個人的には感じてる。

当事者意識が、チームをつくる。

ただし、これは本当にその通りだと思っている。

今の出向先では特殊な開発手法を取っていたので、いい例だから挙げさせてもらう。
今回のプロジェクトでは、圧倒的に速度感を求められていた。
その中でできる限りの機能実装を行う必要があった為、PMの意向で恐ろしいレベルで資料を容易しなかった(プロジェクト的には問題だったと思っている。)
その分、あらゆる仕様や機能設計をすべてメンバー間のコミュニケーションで解決するという手法だった。

これはデメリットも多くあったが、メリットとしてこの当事者意識が必然的にチームメンバー全員に芽生えていたと感じている。

各々のロールは違えど、当事者意識を持って望むか望まないかでプロジェクトのスケール具合は変わるものだと感じた。

今回で言えば、サーバーサイドの人とも機能一つ、文言一つ、UI一つについて意見交換をでき限られた環境の中では悪くない選択を出来たのかなと感じている。

これも、個人レベルでGood is good.が出来、JUST HACK IT.ができるようになってくると自ずとMaking a great team.の意識や視点が芽生えてくると思っている。

しかし、大前提どのレベル感のプレイヤーにも共通して言えるMaking a great team.が一つだけある。
それは自分と同じロールのプレイヤーが開発環境を触ることを想定できるかどうかだ。
開発〜運用・保守は必ずしもひとりのエンジニア、デザイナーが行うとは限らない。
引き継ぎを行ったとき、急遽他の人間が触ることになったときのことを考えて開発を行えるか、資料を残せるか、エンジニアならコメントアウトを残せるか。
後々触るであろうメンバーへの配慮もプレイヤーとしてのスキルの一つだと考えている。


*****


まとめ

行動指針は、フレームワークではないから抽象的に定義されていて分かりづらい、意識しづらいことが少なからずあると感じている。

だからこそ、行動指針を深く考えてみて日々の自分の業務の中で使えるメソッドを切り出して使用していくと結果的に企業やチーム貢献にもつながり自身のステップアップにも繋がるのではないかと考えている。

特に弊社の行動指針は、これといって特別すぎることや高尚なことを求めているわけでもないと感じていてどの会社に所属していてどのロールだったとしてもこれを意識していく先に良い結果が待っているのではないかと考えている。

今後GIGを離れることになったとしても、この指針はきっと変わらず自分の中の指針の一つになっていくだろうなと思う。

この記事が気に入ったらサポートをしてみませんか?