Photoruction工事中!

Photoructionの開発ブログです!

木工(家具)職人とAIエンジニアの共通するところ

目次

  1. はじめに
  2. 物作り
    1. 早いということ
    2. 綺麗だということ
    3. 正確だということ
  3. 木工職人と工場長、エンジニアとPMの関係性
  4. 共通しないこと
  5. 最後に

1.はじめに

2021年も早いもので残すところ2週間くらいとなり、「今年も一年早かったね」なんて言葉を言ってみたり聞いたりすることが多くなってきました。今冬は寒くなるんでしょうか、雪は降るのかな、来年の干支ってなんだっけなどと考えたりしてます。

さて、私はというともうすぐAIエンジニアとなってまる2年が経とうとしています。

社会人になってから飽きることなく繰り返してきたこの「今年も一年早かったね」とともにこの2年間を振り返りつつ、16年ほど携わった前職の木工(家具)職人と現在のAIエンジニアの共通することってなんだろうを考えてみたいと思います。


2.物作り

「段取り八分」

職人をしているとよくこの言葉を聞きます。

段取り(準備)さえしっかり出来ていれば仕事の8割は出来たようなもの、みたいな意味です。

8割は言い過ぎだろという思いが頭を掠めまくっていましたが、経験を重ねれば重ねるほどこの言葉の意味を意識することは多かったように思います。

木工職人にとって**「早くて綺麗で正確に」**という絶対的に正しい結果を追求する上で「段取り八分」(いかに効率的なプロセスを辿るか)はもっとも重要な考えの一つだと思ってました。

AIエンジニアと木工職人の間には、アナログとデジタルの違いはあるものの「モノを作る」という大きな共通点があります。

木工職人にとって大切だと思っていたことを半ば無理やりAIエンジニアにとって大切だと思うことに結びつけてみたいと思います。

木工は作り手が図面をもらった時点で何を作るかは明確に決まってます。(まれに途中で変更があったり、一部決まっていない中進めることもありますが、、、)

製作スタートと同時に数時間は図面と睨めっこしながら、部分的な詳細図を描き(組み立て説明書を自分で考え思考を整理し書き起こすみたいな作業)、完成形や製作工程を頭に叩き込み、最短距離でゴール(完成)するにはどうすべきかを考えます。

1つの家具・什器(店舗やオフィスの家具)でも作り方は何通りかあり、製作物の大きさや難易度によって、どの手法をとるかで手間と時間が大きく変わります。この辺りは経験と知識が大きくモノをいいます。(ゴールを「目的」に置き換えるとその時考えてたことはphotoructionのvalueである「目的逆算」に近い気がします)

早いということ

そこで家具や什器をコードに、鉋(カンナ)・ノコギリ・電動工具等をPCに置き換えてみると、この「早くて綺麗で正確に」という価値観は職人からエンジニア業務への延長線上にしっかり乗っかってきます。

IT業界でも「脱・完璧主義」や「7割の完成度」を意識するみたいなことはよくいわれると思います。エンジニアとしても早ければその分多く開発できるし、開発コストも抑えることができるし、組織にとってもメリットは多いはず、やはりエンジニアとしても早いは正義だと(個人的に)思います。

綺麗だということ

AIエンジニアが使用するプログラミング言語PythonにもPEP8というコーディングスタイルガイドがあります。

その目的は読みやすくて、可読性が高く、一貫性のあるコードを書くためにこういうことは守ろうね、みたいなことが書いてあります。Python開発者たちがコードを読みやすく綺麗に書くことを非常に重要だと考えていることをスタイルガイドを通して感じることができます。

開発において、一度リリースしたからといってコードは未来永劫そのままか??というとそんなことはなく、開発したものが使い続けられる限り改修は行われます。その際、開発者本人が改修するとは限らない上に場合によっては、開発者が退職しているケースもあるかもしれません。改修担当者にとってどのコードが何の目的で書かれているかわかりやすければわかりやすいほど、作業も進みます。コードが他者から見てわかりやすいと改修やデバッグする上で作業性を大きく左右する、保守性において重要ではないかと考えます。

正確だということ

AI開発の最終段階では、それまでの開発内で使われていた学習データ(教師データ)とは別に使われていないテストデータをもとに評価検証を行います(開発したAIモデルの精度や処理時間など算出するため)。

リリースした後に扱うデータがテストデータと同じようなものかというと、そんなことは全くなく、開発中には遭遇していない未知のデータに対してもロバスト(頑健)であることが求められます。

ロバストな開発ができるどうかは開発物の品質を大きく左右します。


3.職人と工場長(現場監督)、エンジニアとPM

関係性が似ていると感じることは多いです。

(*木工職人の場合、やりとりの多くは工場長や制作担当リーダーみたいな人とが多いんですが、他の職方だと監督とやりとりする場面が多いと思うので置き換えた方がわかりやすいかもしれません)

制作においては工場長はあくまでもハブです。というと語弊があるかもしれませんが、工場長は内装業者から案件を受注し家具図・什器図をもらい図面だけでは読み取れないこと、スケジュール、お金に関することなどを内容業者と調整します。そして、各制作物ごとに工場長が担当の職人と打ち合わせを通し、制作物の詳細やスケジュールを共有します。職人は制作中に図面に書かれておらず、自身では判断できないことがよくあります。その際は工場長を通し内装業者に問い合わせを行います。。

とざっくりですが、ここまで書いているとエンジニアとPMの関係も同じとはいわないまでも近いと感じる人もいるのではないかと思います。

私はAIエンジニアしか経験がないので、他のエンジニアがどうかはわかりませんが、少なくとも木工職人と工場長、AIエンジニアとPMの関係性は共通点が多く、エンジニアとして仕事を始めた早い段階からエンジニアとPMの間に境界線を引いていたと思います。こっからここは、エンジニアが考える、そっから先はPMの領域、、、みたいな感じに。

ただ、この境界線の置き所が難しく、微調整を繰り返しながら最適なやり方を模索している途中です。

4.共通しないこと

思いつくことはまだあり時間をかけるとまだまだ書けそうですが、そろそろ今行っている開発に戻った方が良さそうなので、最後に共通していないことを書きたいと思います。

一番大きい違いは、グループやチームの存在を近くに感じるかどうかではないでしょうか。

木工職人としてはあまり意識することはなかったように思います。(途中、工場長みたいなこともやっていた時期があり、その際は作ることはどうしても二の次になりチームや組織としてどうするかみたいなことは考えていたような気がします)

Photoructionではいくつかの部署があり縦横無尽に連携していると思います。そういった組織の複雑性みたいなものは木工時代にはなかったので、新鮮であり勉強になることが多く、他者との関わり方みたいな部分で意識の修正が必要でした。

私に開発の話が届くまでに社内で幾つかのプロセスを経てきます。そのプロセスの具体的な内容まではわかっているわけではないですが、色々なプロセスの内容に触れる機会があると小説の一部を読んでいるようで面白いなと感じることもあります。

(あまり関係ないかもしれないが、組織人としてPhotoructionが掲げているvaluesに「敬意尊尚」とういうものがあり、それがどういったものかを共有する勉強会の参考図書となっていたTeam Geak(Googleギークたちはいかにしてチームを作るのか)は非常に参考になり、これから何度も読み返そうと思う)


最後に


思いつくままつらつらと書きましたが、技術的なことを書くにもう少し時間が必要だと思ったので、あまり考えずに済む題材をチョイスしましたが思っていた以上に時間がかかってしまった。

おが屑に塗れながらにしろ椅子に座ってキーボードをカチャカチャするにしろ、物を作るというのは面白いものですね。

これをエンジニアが読んでためになるとはあまり思えませんが、最後まで読んでいただきありがとうございますmm


株式会社フォトラクションでは一緒に働く仲間を募集しています

 

AIエンジニアという職業に対する考え方 before and after

こんにちは!株式会社PhotoructionでAIエンジニアをしています志賀です。 Photoruction Advent Calendar 2021の21日目の記事です。


目次

  1. はじめに

  2. AIエンジニアになろうと思った経緯

  3. AIエンジニアという職業に対する考え方 before

  4. AIエンジニアという職業に対する考え方 after

    (1). 巨人の肩の上に乗る

    (2). エンジンだけでは車は動かない

    (3). 高度なものはいずれ民主化する

    (4). AI民主化による回帰は悪か

  5. 最後に


1. はじめに

時が過ぎるのは早いもので、AIエンジニアとしてキャリアをスタートしてから、早2年経とうとしています。

そんな中過去の記憶を辿ってみれば、色々な思いや考えが沸いてきては消え、沸いてきては消えを繰り返している事に気がつきます。まるで、般若心経の作者に「色は空で空は色なのだよ。」と日々語りかけられているように感じています。

ただその繰り返しの中でふと後ろを振り返ってみると、細胞が破壊と再生をただひたすらに繰り返す中徐々に姿形が変わっていく成長期の子供のように、思いが沸いたり消えたりする中で実はAIエンジニアの職業観も大きく変わってきている事に気がつきます。という事で、この2年でどんな風に、AIエンジニアとしての職業への考え方が変わったのか振り返ってみたいと思います。


2. AIエンジニアになろうと思った経緯


実は前職では、今やっている事とは殆ど関係ないSalesforceというシステムのSIer業をしていました。

当時前職の会社に入社したばかりの頃は、ITに関して何の知識も持たない、いわゆるポテンシャル採用系のザ・新入社員だった為、ITの事もそんなによく分からなければ、残念ながら自社の導入しているシステムが本質的にどんな価値があるのかもあまりよくはわかっていませんでした。

そんな迷える子羊のような状態で、端からみればビクビク怯えていそうですが、当時の心境としては、新しい仲間、先進的な技術で世界の先頭に立てる事への期待で、ワンピースのルフィよろしく「どんな冒険が待ってんだ!!?」とウキウキしていました。

やがて、そんなこんなで新卒研修や業務に携わり色々と学んでいく中で、Salesforceの何がすごいのかを少しずつ知るようになりました。

しかし、それとは反比例するかのように段々とSalesforceという先進的ITシステムへの興味を失っていきました。普通に考えれば、すごい!ということを知れば知るほど、どんどんのめりこんでいきそうな気がするのですが。。この原因に関しては、4章(3)で話そうと思います。

そんな中、機械学習なるものと出会いました。それから、機械学習に関する書籍を買い、難解な理論を理解する事に次第に快感と感動を覚えるようになり、AIエンジニアとして転職する事を決意しました。

3. AIエンジニアという職業に対する考え方 before

当然の事ではありますが、AIエンジニアとして転職を決意してからすぐに転職できるわけではありません。

という事で、独学及びスクールでその後約半年間一から勉強するわけですが、当時勉強していたのは、例えば「ゼロから作るdeep learning」を読んで実装してみて、や、決定木やSVMなどのアルゴリズムをスクラッチで実装してみたりなど、いかにも機械学習入門者が最初やりそうな事をやってました。

このようにして、色々とアルゴリズムを勉強して自分で実装していく中で、「様々な機械学習アルゴリズムの仕組みを深く理解し、それを実装していく。」これがAIエンジニアだと思ってました。

ちょうど、スクールに通っていて三分の二ぐらいを過ぎた位までの、AIエンジニアという職業への認識なのですが、ここまでをbeforeとします。

4. AIエンジニアという職業に対する考え方 after

(1) 巨人の肩の上に乗る

スクールでの学習も最後の方になると、実際に論文を読んでFaster R-CNNという物体検出アルゴリズムを実装しようということになりました。

当然今まで、線形回帰から畳み込みニューラルネットワークまでスクラッチで実装してきたので、スクラッチとは行かずともTensorflowやPyTorchで一から実装していくのだと考えてました。

ただそこで行ったことは、何時間も費やして一からアルゴリズムを組み立てる事ではなく、論文を元に実装されgithubで公開されたアルゴリズムを流用する事でした。この時に、少し何というか拍子抜けする感覚がありました。ですが、実務を考えれば確かに既存の実装されているアルゴリズムで学習して応用する方が遥かに効率が良いと納得しました。

これは自分の中で、アカデミックな観点から認識していた「実装」という概念を実務的な観点から捉え直した瞬間でした。

(2) エンジンだけでは車は動かない

その後現職に就職し様々なプロジェクトを通して、どんなアルゴリズムも目的を達成する為の一つの道具でしかないという事を認識しました。

極論を言ってしまえば、たとえ機械学習ディープラーニングアルゴリズムをより深いところまで理解していなかったとしても、実務的な課題をクリアさえ出来るならそっちの方が良い。それぞれの道具をより深く理解する事よりも、その道具をどう活かし組み合わしで課題を解決するかの方が実務では遥かに重要だと理解しました。

その為、実課題を達成するためには機械学習アルゴリズムを理解するだけでなく、例えばPDFのデータから情報を抽出する等の前処理や、実課題に合わせた適切な評価検証、更にはAPIとして公開する為のインフラの構築、他プロジェクトに関わるメンバーとの円滑な意思疎通など、実課題を解決するために必要な道具は実に多くあるという事を思い知らされました。

ここで、「AIエンジニア」というのは、(勿論大分抽象的な言葉で捉え方は多岐に亘ると思いますが私の中では)「機械学習などのアルゴリズムを実課題を解決する為の一つの道具として、他の様々な道具とともに用いる事ができるエンジニア」というものに変化していきました。

(3) 高度なものはいずれ民主化する

このような事を実際の実務の経験を通して肌身で実感してから、「Salesforceを深く理解したエンジニア」ではなく、「Salesforceを課題解決の為の一つの道具として使いこなす事ができるエンジニア」をSalesforceエンジニアであると捉え直した上で、改めて前職で経験したSalesforceとは何だったのかを考える直すようになりました。

その結果、Salesforceは、CRMシステムという複雑で開発に大変手間がかかる一つのソリューションサービスを、誰でも使いやすい形に道具化したもの、つまり「ITシステムを民主化した」サービスであると今では認識しています。

思い返せば、当時、前職の会社のCTOの方がSalesforceに感動してSalesforceに惚れ、Salesforceを愛しているから今の職業をしていると言っていたのが記憶から蘇ります。当時のCTOは、このSalesforceによって得られる「ITシステムの民主化」による恩恵の素晴らしさにこそ感動し惚れていたのではないかと今では思います。では、なぜその感動が自分にはなかったのか。逆に興味を失っていってしまったのは何故なのか。

私の中では、それは「リープフロッグ」が原因であると結論づけています。

リープフロッグとは適当に訳せば「跳ぶカエル」となりますが、これは端的に言えば、様々な技術の変遷をすっ飛ばしていきなり新しい技術から参入するという意味です。リープフロッグの例として有名なのが、発展途上国のキャッシュレス化です。韓国に至っては決済比率の90%近くがキャッシュレスであるそうです。そんな国にそんな時代で生まれた人にとっては、キャッシュレスなど当然の事でその有り難みを実感することは難しいでしょう。一方で私のような現金で生きてきた人間にとってみれば、改札でわざわざ切符を買わずにスマホ一つで抜けられる有り難みを肌で感じ、いつも感動に身を震わしています。

リープフロッグの話が長くなりましたが、同じように、あらゆる技術をすっ飛ばしてSalesforceから始めた自分は、Salesforceによってもたらされた「ITシステムの民主化」の恩恵を肌身で感じていない為に、その素晴らしさもまた、理解はできても肌身で感じる事が出来なかった。それに加え、民主化されてしまったことに逆につまらなさを感じてしまった。それゆえに、興味を失ってしまったと理解しました。

今後AIエンジニアの在り方も将来のAIのあり方とともに変わっていくでしょう。では、今後AIがどうなっていくかと言えば、ITシステムが民主化されていったのと同じようにAIも民主化されていき、それに合わせてAIエンジニアのあり方も大きく変わっていくだろうと想像しています。

その場合、扱うサービスの対象がSalesforceから例えばAWSGCPに変わるだけで、本質的には職業のあり方として前職と何ら変わらなくなるのかも知れません。

(4)AI民主化による回帰は悪か

では、今後Salesforceに興味を持てなくなったのと同じようにAIにも興味が持てなくなるか、と言えばそうではないと確信しています。その理由は(3)で述べた通りですが、前職のCTOがSalesforceに自分なりの意義を見出していたように、AIを扱うAIエンジニアという職業を、「リープフロッグしていない」AIエンジニアとしてより強く意義づけする事ができると確信しています。

最後に


ちょっと、最後の方はエモい感じになりましたが、職業観を考える事はあまりないので良い機会になったと感じています。読んで何か得られるような内容ではないですが、「この人は自分の職業に対してこう考えてるんだな。自分はこう考えているけど。」と言った感じで、何か考えるきっかけにでもなっていたら嬉しいです。最後まで読んで頂きありがとうございました。

 

株式会社フォトラクションでは一緒に働く仲間を募集しています  

 

corporate.photoruction.com

www.wantedly.com

入社して2年間を業務日記から振り返ってみた〜2年目編〜

こんにちは!株式会社フォトラクションでWebエンジニアをしています南風原はえばる)です。

Photoruction Advent Calendar 202120日目の記事です。

導入

アドベントカレンダー2日目の記事に引き続き、今回は入社して2年目を振り返っていきたいと思います。

 

2年目は新規開発や機能改善案件とガッツリ開発に携わった1年だったと思います。

こんな人間が働いてますってことと、Photorucution開発の様子などがざっくりとでも伝われば幸いです。

 

では、振り返っていきましょう〜♪

 

1年目編の記事はこちら↓

photoruction-tech-blog.hatenablog.com

 

2020/11 編

[振り返りコメント]

当時やっていた案件は新規開発の案件だったので事例がなく、どういうUI/UXだとユーザーにとって分かりやすいかなどPdM、デザイナー含め何回も擦り合わせた記憶がある。

こういうUIだと操作性良さそうだな、けど工数結構かかりそうだな、けど、、ってなりながらどこまでを実現するのかのラインを話し合ってたな。

 

[振り返りコメント]

都度、PdMと確認取りながら開発していくって大事ですよね。

最近できてないな😂

 

[振り返りコメント]

分かりみが深い。

 

[振り返りコメント]

一年前まではIEの対応をしていました。

IEだと上手く動かない、スタイル崩れてる、重い。

当時は、早くIEを対象外にして欲しいと願いながら対応してました笑

 

[振り返りコメント]

実装の大半がやったことないことだらけなので、どのくらいでできそうかの見積もりはいつも難しいなって思います。

特に、既存機能の改修案件は影響範囲によって工数も大きく変わってくるので安易に見積もってしまうと全然足りなかったってなることも。

この辺は実務経験積んでいくと分かってくるのかなと思ったりしてますが、どうなんでしょうね?

2020/12 編

[振り返りコメント]

人の書くコードで性格がわかる!?!?笑

変数名のつけ方とか、人によって変わるから面白いですよね。

 

[振り返りコメント]

ユーザーからのフィードバックは仕事やってて一番嬉しいし、ドキドキな部分でもある。

普段の業務で使用するツールだからこそ、直感的な操作性って一番大事だなって思います。

2021/01 編

[振り返りコメント]

UI/UXってほんと奥深いなって思います。

シンプルが正義ってことでもない。

なぜこういうUIにしたのかとか、色々聞いてみたいからデザイナーさんともっと業務で絡みたいなと思ったり。

 

[振り返りコメント]

面接を担当するようになってからはより視野広く物事を見れるようになった感じがします。

弊社を知らない応募者にいかにして弊社のことだったりチームの課題感とかをわかりやすく伝えるか、興味を持ってくれるかなど伝える力が鍛えられる気がする。

あと、単純に社外のエンジニアとお話するのって楽しい。

自分のキャリアについての参考にもなるしね笑

 

[振り返りコメント]

いいプロダクトを作るためにそれぞれがそれぞれの立場で意見を出し合って進めていく感じとてもいいなと思う。

スケジュールがタイトになってるくと余裕がなくなりそういう話し合いすら蔑ろにしちゃいたい時もあるけど妥協せずにいいものを作ろうという姿勢って大事ですよね。(自戒)

 

[振り返りコメント]

ホント名前は大事!!!

誰が見てもわかる名前をつけるの&省略のし過ぎは後々見返した時になにこれ?ってなるので長くてもちゃんと意味が分かる名前をつけるようにしてる。

あとは、コメント添えてるかな🤔

2021/02 編

[振り返りコメント]

目先のことだけを考えての設計、実装は後々負債となってしまうのでちゃんと先の先まで考えて設計するのって大事ですよね。

あとは、運用コストが大きくならない設計にするのも大切。

どのくらい先まで考慮すればいいのかは難しいところですが、、

 

[振り返りコメント]

ドキュメントの作成は本当めんどくさいなって思うタスクの一つ。

けど、先延ばしにすればするほど毎回同じことをメンバーに共有する時間が発生したりしてそれはそれで自分の首を絞めるだけなので開発しながら合間に整備していかないとなって思うけどいつも最後にまとめてやっちゃいます笑

2021/03 編

[振り返りコメント]

わかる、だっっっるい。

 

[振り返りコメント]

PhotoructionはWeb側とモバイル側のデータ同期も考慮してAPI実装とかもしないといけないので頭の片隅には常にモバイル側への影響とかも考えながら設計、開発する必要があります。

2021/04 編

[振り返りコメント]

一つのバグは氷山の一角に過ぎないってやつですね。

 

[振り返りコメント]

この時期は、ずっとリモート勤務ということもありこっそり沖縄に帰省して仕事をしていました。

こういう働き方ができるのはありがたいなと思ったり笑

 

ちなみに、弊社にはリモートワークポリシーというのが存在しています。

こちらもぜひ読んでみてください↓

www.wantedly.com

2021/05 編

[振り返りコメント]

詳細設計って本当難しい。

いろんなことを考えて複雑な設計になってしまったり、考え過ぎて前に進めず停滞してしまうことも多々ある。

初めてやるような開発は、これ自分で実装できるの?ってのもあるしね。

この時期から担当した案件はまさにそう。

 

[振り返りコメント]

ユーザーからの反応を共有してくれるビジネスサイドのメンバーには感謝しかない。

こういう声が力になってるし、苦労して開発した甲斐があったなって今までの大変だったこととかが報われた感じがして次の案件でも頑張ろうってなるのでどんどんユーザーの声を伝えてほしいとひそかに思ってたりしてます笑

 

[振り返りコメント]

ガチでこの日は喜びのあまり震えた。

IE対応から解放されるだけでもだいぶ開発の負担減るので嬉しかったです。

 

[振り返りコメント]

本当に今までお世話になりましたぁぁぁ!!!

2021/06 編

[振り返りコメント]

チーム内でGatherというツールを取り入れて、バーチャルオフィス内で仕事をするようになりました。

ずっとリモート勤務でチーム内でのコミュニケーションが減ってるのもあり、こういった遊び心あるツールを用いることで少しでも楽しく仕事ができるのかなって。

この日は、リーダーと海辺で語りました🌴

 

WebエンジニアチームにGatherを導入した時の話はこちら↓

photoruction-tech-blog.hatenablog.com

 

[振り返りコメント]

ついに業務でもTypeScriptを書くようになりました。

最初は、手こずりまくりでしたが書けば書くほど型のありがたさだったり、開発のしやすさが感じられてめっちゃいいってなってます。

2021/07 編

[振り返りコメント]

ひぇーーーーー🥺

そういう日もありますよね。

2021/08 編

[振り返りコメント]

開発チームだけじゃなくビジネス側も含め全員でプロダクトを作っているってことが感じられるから実装レビューの時間って意外と好き。

 

[振り返りコメント]

毎日の仕事に少しでも癒しをということで、この時期あたりからPRレビューでLGTMに猫を添えるようになりました。

猫って正義🐈(私が一番癒されている)

 

LGTM画像はこちらのサイトから作れます↓

lgtmoon.herokuapp.com

 

[振り返りコメント]

現在担当している案件は大半がこんな感じなのでメンタル鍛えまくり。

スキルをもっとつけたいものです。それか時間止まってほしいっていつも思いながら仕事してる。

2021/09 編

難しいところから先に進めていくのがいいって言うけど、そこでずっと詰まってると時間だけが過ぎてく&モチベ低下&自信なくなってくる。 

なので、最近は一旦切り上げて別のタスクに取り掛かることでやる気とメンタルの維持を図ってる。 

楽しく働ける環境を自分で作るの大事😌

#エンジニア #業務日記 2021/09/17 

[振り返りコメント]

自分で自分の機嫌を取りながら働くのって大事ですよね。

じゃないと、ただただ辛いだけ笑

他の方が楽しく働くために工夫していることとか知りたいな。

 

お客様とのMTGほど緊張するものはない。

会社ごとに運用方法が様々なため、こういう風に使いたいんだけどできる?という斜め上からの質問に終始ヒヤヒヤ。

まじでプロダクトの仕様完全に理解してないと終わる😅

#エンジニア #業務日記 2021/09/28 

[振り返りコメント]

ほぼ毎日顧客とMTGしている営業の人たちは尊敬でしかない。

2021/10 編

最近チームの雰囲気が良い気がする。

一人ひとりの行動がチームに伝染していっていい方向に変わってきている感じ。

いいね、素敵だ。

#エンジニア #業務日記 2021/10/01

[振り返りコメント]

一人一人がチームのために動けるチームって強いよなって思う。

そういうチームにより一層していきたいですね。

私にできることってなんだろう?ってたまーーに考えたりしてる。

 

先週からずっと苦戦していた実装がやっと一段落ついた。

まだまだ作らないといけない機能があるから達成感に浸っている場合じゃないけど、出来なかったことが出来た瞬間は半端なく嬉しい😳

#エンジニア #業務日記 2021/10/04

[振り返りコメント]

出来なかったことが出来た瞬間は半端なく嬉しい

こういう瞬間を定期的に味わえるから、開発って楽しいなって思う。

なんなら仕事って楽しいって思ったりする。

 

時間かけて書いたコードを消すのは一瞬で忘れるのも一瞬😳

今の構成が今後の機能開発する上でどんどん複雑な実装になっていくのが見え見えで自分の首を自分で絞めてる状態になってたのをリファクタした。

自分で書いたコードなのになんだこれ状態。。

ま、あるあるだよね?w

#エンジニア #業務日記 2021/10/05

[振り返りコメント]

プログラムってすぐ書き換えることができる点はいいところでもあるけど、あんなに時間かかって書いたのに一瞬で消し去ってリファクタする時はちょっと虚しい。

けど、未来のことを考えるとリファクタリングは大事。

 

[振り返りコメント]

こういうツッコミをしてくれるテックリードのキャラ結構好き😊

2021/11 編

入社して2年が経ちました!

感覚としてはまだ2年しか経ってないのかという感じですがw

入社当初は、エンジニアとして全然過ぎて上司に負担かけることも多かったが、今はそれなりに開発スキルもついてきて自走してタスクをこなせるのはもちろんのこと周りにも少しは貢献できているのかなって思っているところ。

現在は、開発以外にも開発組織の改善に関する取り組みにも携われているので引き続き精進します💪

#エンジニア #業務日記 2021/11/01

[振り返りコメント]

フォトラクションに在籍して3年目突入ということで、色々できることが増え楽しい反面、チームの中では古参という責任感も若干ありますが引き続き楽しく働けたらいいなと思ってます。

まとめ

2年目は新規開発や機能改善案件とガッツリ開発に携わった1年だったと思います。

エンジニアとしての開発スキルもそうですが、案件をリリースまで持っていくために他メンバーとの関わり方やプロダクト開発の進め方など色々学ぶことの多い1年になりました。

 

3年目は、開発業務以外にも組織やチームへ目を向けて組織改善などにも取り組めたらいいなと思っています。

 

フォトラクションアドベントカレンダーもラスト1週間となりました。

明日からはAIチームの記事が続きます。乞うご期待!!

 

株式会社フォトラクションでは一緒に働く仲間を募集しています

受託開発から自社開発になって変わったこと

こんにちは。

株式会社Photoructionでwebエンジニアをしている土岐(とき)です。

Photoruction Advent Calendar 2021の19日目の記事になります。

目次

1、はじめに

2、受託開発の頃に大事としていたこと

3、自社開発で大事にしていること

4、これからやっていく上で大事にしていきたいこと

 

はじめに

まずは軽く私の自己紹介から。

IT業界に入る前は異業種の仕事を色々していましたが、ちょうどブロガーという仕事が生まれた頃でしょうか。私はブログの中身を見て楽しむよりサイトのデザインを見て惹かれていき、そのうち自分で作ってみたいと思うようになりました。まだHTMLやCSSすら知らなかったど素人ながらもググってwordpressテーマを作り、更にそこからVPSサーバでLAMP環境をググって構築しドメインを借りて公開をおよそ2ヶ月半程度でやってみた事がIT業界に入ったきっかけでした。

1社目はmovabletype、DoやLumen、wordpress、laravel、その他javaandroidアプリなど、主にphpがメインであるものの割となんでもいろんな案件を受託しちゃう10人程度の小さい規模のシステム開発会社で、PMやデザイナーはおらず全員エンジニアで構成された会社でした。

そこで私は初めてデスマーチというのを体験しました。おおよそ4〜5ヶ月間常駐先に缶詰になりながらjavaでできた巨大なレガシーシステムを読み解いていき、設計書やフロー図・シーケンス図などに落とし込むのが仕事でした。何日も泊まり込みというのはザラで家に帰っても寝る時間ぐらいしかいなかったので、残業時間だけで月150時間位はいってました。そして残業代はどんなにしても一律3万円までという会社でしたので中々のブラックだったな...と勉強になりましたね(泣)

2社目はwordpressをメインの受託会社。自社商品の仮装マシンも売りにしており、割と誰もが聞いたことがあるような結構大手な会社から受注し、そのサイトの開発から保守まで受け持つ、なかなかやり手なベンチャーでした。

1社目とは異なりPMやデザイナー、シニアエンジニアなどが揃っており、基本1案件を一人で行うものの、何かあった時は頼れる先輩エンジニアがいたことは心強かったですし、色々と教えて頂けたのは本当にありがたく私の財産になりました。

 

受託開発の頃に大事としていたこと

いろんな案件をこなしてきましたが、やはり受託の場合は「納期までに実装して納品する」事が第一です。

ミッションをクリアするために主に3つの事を気をつけていました。

 

1、コミュニケーションのルールを決めておく

よくあるのが実装・テストフェーズに入った後などPMや顧客とのやりとりで

「こんな機能作ってって前に言ったよね?」

「聞いてません。提出した設計書を確認時にそちらからもOKを頂きましたよね?」

みたいな「これは言った、言わない」問題。いわゆるコミュニケーションの不足による仕様の認識がズレることです。まぁよくあることですね。

実際、依頼側が言い忘れていた場合もあるし、受注側が忘れていた場合もあります。また実装したものを触ってみて細かいところまで考慮漏れだった事もありますし、依頼側の要望が途中から変わってくることもあります。

そういう時はムキになってこちらは悪くない!と言い張る争いをしても案件は終わらないし、相手と気まずい嫌な空気が生まれてしまうだけ。そんな不毛なやりとりが大の大人でも現場でよく起こったりします。

そこで私はキックオフや割と最初の段階で相手といろいろ取り決める際に以下のことを提案します。

  • 基本やりとりはslackで。口頭だと聞き漏らすことや忘れることもあるので必ず文章化して残したい。
  • 画面名や機能などの名称を統一・共有しておく。こうすることで、コミュニケーションを取る際に双方の認識が合致しスムーズにやりとりできるため
  • チームの全員の認識が一致するために、最新の確かな仕様をいつでも誰でも振り返って確認できるようにして欲しい。そのため仕様書の更新をその都度して頂きたい(口頭やslackだけでは不確かだったり二転三転するため)

こういうことを最初に取り決めておくことで、なるべくコミュニケーションコストを下げお互いにとってイラつかないようにするのが双方にとってスムーズだと学びました。

 

2、まずは30%でもいいのでなる早で作る

じっくりと丁寧なものを期限ギリギリに提出するよりも、完成度が30%でもいいのでプロトタイプを早めに提出してそれに対しフィードバックをもらう。

そしてまたそのフィードバックに対しサクッと作る。

そういうサイクルを繰り返す。

上記の1でも少し書いたのですが、実装したものを触ってみて細かいところまで仕様を決めていくというのはよくあります。

というのも要件が固まり仕様を決めても、細かいところまでは決めていない・気づかない事はよくあります。(完璧な仕様書というのは最初から作れないもんです。人間だもの)

そのためざっくりでもいいのでまずは動くものを提出し触ってもらうことで、依頼側と開発側、双方の認識が噛み合ってきます。

口頭や文章だけではうまく伝わらない事もあっても、実際のものを通して認識をすり合わせる事で完成度を高める事ができるので、なるだけ早く形にするのは大事だと知りました。

早いは正義!

 

3、早い段階で別チームに知らせる

大きい規模のシステム開発など、別の会社やチームと組んで一つのシステムを作る時、自分達の領域だけでは解決できない機能があります。(例えばスコープ外の機能と連携しないと表示できない部分とか、webとモバイルでデータを受け渡さないといけない部分が出てきたりなど)

そういう時に大事なのは、何か疑問が出てきたらすぐに別チームのエンジニアと早めに情報を共有することでした。

なぜなら別チームにもそれぞれスケジュールや優先順位があるからです。

別チームと連携しないと進めない問題が出てきた時に、できるだけ早い段階で共有しておかないと別チームが切羽詰まってきます。そして別チームが遅れることで、こちらもそれに合わせて対応が遅れてきたりと...まぁ全体的に遅れてくるので、やはり連絡・共有は早いことに越したことはありません。

早いは正義!!(2回目)

 

自社開発で大事にしていること

さて。そんな受託の頃とはうってかわって、このPhotoructionではなかなか他では味わえないような面白いメンバーで構成されています。

まずこのPhotoructionは「建築業界をスマートにする」というミッションで立ち上がった会社なので、建築業界出身の方とIT業界出身の方がおおよそ半々。

そのうちシステムの開発部にはエンジニア(web,IOS,android)、デザイナー、PMチーム(プロマネ)、QA、CREチームと構成されていますが、PMは全員が建築出身の方で構成されています。

受託の時は「納期までに納品する」ことが第一になっていたのですが、ここでは「ユーザに価値のあるものを届ける」ことが第一になってきます。

とはいえ、はじめは「ユーザに価値のあるものを届ける」と言っても具体的にどういう姿勢でやっていけばいいのか慣れませんでした。

今までは決められた仕様を期限までに作るやり方に慣れていたため、仕様が二転三転するのに困惑しましたし、仕様を決める時からエンジニアも参加できるのですが、エンジニアは現場の空気感や使っているユーザのことはあまりわかってる人はいません。

そのためエンジニアが加わるとどうしても「どう作るか」な目線で決めたがります。これはシステム的にまたはデータの観点からベストなやり方で作ろうとするからです。

ですがユーザのニーズからかけ離れたものを作ってしまったら本末転倒です。

そのため建築業界出身の方と一緒にうまく協力していく必要があります。

受託の時とは違って1人では良いものは絶対に作れません。「みんなで作っていく」ということが受託との1番の違いだという事を教えて頂きました。

 

これからやっていく上で大事にしていきたいこと

「できない理由」を探すのではなく「どうしたらできるか」といったスタンスで

仕様を決める際、ユーザの要望に向けてあれもこれもやろうかといろいろ案が出てくるのですが、どうしても期限を考えると現実的に実装できる機能を絞り、この機能は「リリースまでにできるか・できないか」というスタンスになりがちです。

ですが本来私たちのミッションは「ユーザに価値のあるものを届ける」こと。

時間の許す限り、よりユーザにとっていいものを作るのが大事になってきます。

そのためエンジニアとしては設計や実装において「できない理由」を探すのではなく「どうしたらできるか」といったスタンスで取り組むのが大事なのではないか。と私は思っています。

なかなか大変であろう機能をお願いされた時、「他の案でカバーできないか」「別のやり方(簡単な機能)でいいか」などとすぐに返すのではなく、まずはどうしたら実現可能かを考えユーザの求めるものに寄り添う姿勢でやっていくこと。

限りある時間の中でいかにクオリティの高いものを作れるか、そこがエンジニアとしての腕の見せ所になってくるのではないかと思います。

 

一緒に作っていくチームメンバーとのコミュニケーションにおいて

どうしてもエンジニアという仕事をやってると細かい所まで目が行くようになります。

具体的に言えば設計だと

  • 求められている機能の確認
  • 既存仕様とそのコードの確認
  • 機能を追加する事によって生じる影響範囲の確認

実装だと

  • 求められている機能を作って動くようにする
  • 書いたことでクリティカルなバグが発生していないか
  • 他の機能にも影響がないか
  • 書いた処理が他の処理と被ってる部分がないか、コードをもっとスマートに省略できないか

テストだと

  • 想定外のバグがないか
  • そもそもこちらの認識の抜け漏れがないか

……などなど。

システムを細かいところまで確認し作り上げるのがエンジニアの仕事なので「細部まで厳しくチェックする目」を持つようになり、それを要件やコードだけでなく色んな部分に向けるようになってきます。

 

でもそれは決して「人の至らなさ」に対して向けるべきではないはず。

一緒に案件をやってるメンバーはあくまで「良いものを作りたい」という同じ目的の下集まってる同士であり仲間です。

加えて人間なのでどうしてもコミュニケーション不足による認識の齟齬や勘違い、言葉足らず・逆に一言多い、積んできた知識・経験の差などというのは必ず発生します。

そもそもITと建築というバックグラウンドが違う人間同士のコミュニケーションなのでそういう事が起きて当たり前です。

そのため人の発言に対し重箱の隅をつつくような揚げ足を取ったり、間違った知識や認識に対して人間性を否定するかのような批判をする、といったことは絶対にあってはいけない事です。

 

ちなみにPhotoructionにはそんな人は誰一人いません。それはPhotoructionの理念の一つに「敬意尊尚」というのがあるのですが、これは心理的安全性の高い組織を作るために「互いをリスペクトし、立場に関わらず相手の意見に耳を傾け、建設的な議論をすること」を良しとしてる風潮です。これによりチーム内のやりとりはフランクな空気でとても仕事がしやすくなっています。

今、Photoructionはいろんな機能が密結合しており開発するたびにバグが多数出てきてしまっているのが現状です。

 

そのため自分達が書いたコードや成果物には「性悪説」な目を向けて。

ですがチームメンバーには「性善説」な目を向けて、これからもやっていきたいと考えています。

 

最後まで読んでいただきありがとうございました。他の記事もぜひご覧ください!

 

 

株式会社フォトラクションでは一緒に働く仲間を募集しています

corporate.photoruction.com

www.wantedly.com

【ノーコード】Slackで最もバリュースタンプが押されている人を表彰できるようにしてみた

f:id:photoruction_tech_blog:20211220100258p:plain

フォトラクション採用責任者の野田です。アドベント・カレンダー18日目の記事として、「SlackでValuesスタンプが誰のどんな投稿に押されているのか数えて、獲得数が多い人を表彰できるようにしてみた」というネタを思いつき、Botを作ってみました。

 

GASなどは使わずノーコードで作成できるので、世の中のValues定着に頭を悩ませている人事担当の方のお役に立てれば嬉しいです!

Valuesのスタンプを数えようと考えた背景

フォトラクションは7月にValuesの再策定を行いました。これまで書籍を題材にしてValuesの元となる価値観の勉強会をしたり、締め会ではValuesの体現者を表彰するなど、組織にValuesを定着させるために連続的に施策を行ってきました。

結果として、Valuesを目にする頻度が増えて慣れてきた部分はあると思います。

 

しかし、Valuesは日々の業務の中で使われてこそ意味があります。そこで、日々のSlackの中で誰のどんな行動がValuesの体現として称賛されているのか可視化出来ないかと考えました。

また、スタンプが集まると称賛されるらしいという文化を作ることで、積極的にValuesを体現しよう、仲間のValuesを体現した行動を称賛しようという風にベクトルが向かうと良いなとも思っています。

可視化のためのアプローチ

  • Zapierを利用しValuesのスタンプをトリガーとしてスプレッドシートにデータベースを構築する
  • 関数を駆使してデータベースを整形し、スタンプを獲得している数が多い人と投稿を毎月自動的にソートする
  • Slackのワークフロービルダーを使い、スプレッドシートから取得した情報を取り込んだ文章を、任意のチャンネルに日付をトリガーとして投稿する

アウトプットのイメージ

こんなポストを毎月指定の時期に自動投稿する

f:id:photoruction_tech_blog:20211215103557p:plain

Zapierを利用しValuesのスタンプをトリガーとしてスプレッドシートにデータベースを構築する

(1)Slack上で押されたValuesのスタンプをトリガーに設定する

みなさんZapierはご存知でしょうか。ノーコードで様々なアプリと連携して自動化をしてくれる便利なサービスです。ZapierでSlackとGoogleスプレッドシートを連携させてまずはデータベースを作成します。

①タイムスタンプ②押されたスタンプ③スタンプを獲得した人④スタンプが押された投稿の4つが格納されていれば今回の目的は果たせるため、指定されたスタンプ(今回は各Valuesのスタンプ)が押されると、上記4つの情報をスプレッドシートにセル追加するように設定をします。

NewReactionAddedをトリガーとして設定します。

f:id:photoruction_tech_blog:20211215103628p:plain

トリガーに設定するスタンプを設定します。画像では最速挙動のスタンプを設定していますが、後ほど全てのスタンプで設定をする必要があります。

f:id:photoruction_tech_blog:20211215103647p:plain

 

この時、チャンネルを指定すれば任意のチャンネルのみで集計、指定しなければ全チャンネルで集計となります。

例えばValues用のチャンネルを作って公式に「このチャンネルでのスタンプは集計して表彰に利用します」とアナウンスすることで、そのチャンネルに注目を集めるやり方もあると思います。今回は全てのチャンネルで集計しています。

これにてトリガーの設定は完了です。

(2)必要な情報をスプレッドシートに送信し、データベースを作成する

(1)でトリガーを設定したら、今度はスプレッドシートに送信する設定です。+のボタンを押してステップを追加してGoogle スプレッドシートを選択します。先程のデータをスプレッドシート上に追加したいので、アクションは「2. Create Spreadsheet Row in Google Sheets」を選択してください。

f:id:photoruction_tech_blog:20211215105015p:plain

手順に沿ってアカウントを設定して、データを蓄積するシートを選択します。(シートは事前に作成しておきます)送信するデータは以下の4つです。

1.Message User Name

2.Message Ts

3.Reaction

4.MessageText

f:id:photoruction_tech_blog:20211215105123p:plain

以上でZapierの設定は完了です。これでSlackに指定されたスタンプが押される度にスプレッドシートにデータが飛ぶようになりました。

関数を駆使してデータベースを整形し、スタンプを獲得している数が多い人と投稿を毎月自動的にソートする

続いて、データベースを整形してSlackに自動投稿を飛ばす準備をします。ここまでで、スプレッドシートには以下のようなデータベースが出来ています。

f:id:photoruction_tech_blog:20211215105406p:plain

方針としてはシンプルにCOUNTIFS関数を使って当月に追加されたデータを数えて、Rank関数で順位付けしQuery関数を使って抜き出します。

大きく以下の手順です。

【下準備】

①元データを参照し、編集用のデータベースを作成する

②COUNTIFS関数で拾えるようにタイムスタンプを変換する

【スタンプを集めた人を集計する】

③COUNTIFS関数で当月に獲得したスタンプの獲得数を数える

④Rank関数でランク付けする

⑤Query関数で1位の投稿を集める

【スタンプを集めた投稿を集計する】

⑥Query関数で当月にポストされた投稿を抜き出す

⑦UNIQUE関数で⑥を列挙し、COUNTIFS関数で集計し、Rank関数でランク付けする

⑧Query関数で1位の投稿を集める

※⑦と⑧は上と同じ手順です

【下準備】

Zapierから飛ばしてきたシートに関数を事前に入れておいても、最下部にセルが追加されたタイミングで下部の関数が削除されてしまうため、編集用のシートを用意します。

シンプルに(='DB'!)でセルを参照するだけだと同期性が悪く、毎回セルを上書きしないとデータが最新に更新されなかったので、より同期性が強いIMPORTRANGE関数を使います。

f:id:photoruction_tech_blog:20211215110621p:plain

一番左上のセルに関数を入力すると、指定したURLの指定したシートの情報を自動で同期してくれます

任意のスプレッドシートのシートをまるっと参照できる便利な関数で、シートごとに権限を分けたいときなどに役立ちます。(詳しい構文などは既出の記事に譲ります)

続いて、Zapierで飛ばしたタイムスタンプですが、このままだと何のことかわからないためyyyy/mm/ddの形に置き換えます。これは後ほどCOUNTIFS関数で拾うために必要な処理です。

f:id:photoruction_tech_blog:20211215110824p:plain

タイムスタンプのままだと1636934988等の数字の羅列ですが、処理を入れると2021/10/25という日付になります。

詳細かっ飛ばしますが、=(B2+32400)/86400+date(1970,1,1)という処理を入れてください。こうすることでタイムスタンプが現在の日付に変換されます。詳しくはこちらの記事を

後ほどの行程でCOUNTIFS関数を利用して当月の投稿を集計するのですが、その際に各投稿の年と月を条件で設定する必要があるため、yyyy/mm/ddに変換したら年、月の列をつくってYear関数とMonth関数でそれぞれ月と年を抜き出しておいてください。

f:id:photoruction_tech_blog:20211215111117p:plain f:id:photoruction_tech_blog:20211215111108p:plain

こんな感じになります。空白がエラーになるのを防ぐためにIF関数を入れているためわかりにくいですが、シンプルにYEAR関数とMONTH関数を使っているだけです

【スタンプを集めた人を集計する】

続いて当月にスタンプを集めた人の集計を行います。ここまでくればあとは結構シンプルです。集計用の新しいシートを作り、オーソドックスに一番左側の列に集計したい人名、一番上のセルに集計したいスタンプ名を設定して、COUNTIFS関数でDBから数えていきます。

f:id:photoruction_tech_blog:20211215111207p:plain

こんな感じです。

以下2点ワンポイントです。

①UsernameはUNIQUE関数で自動取得させる

f:id:photoruction_tech_blog:20211215111234p:plain

人名の列挙は自動的に行いたいので、DBのUsernameの列をUNIQUE関数で検索させると良いと思います。こうすることで、新しいユーザーが追加されても自動的に一番左の列に追加されるので手動を挟む必要がなくなり自動BOT化できます。

②日付はtoday関数を参照させる

f:id:photoruction_tech_blog:20211215111339p:plain

このシートのそもそもの目的は、毎月任意の日付になったらSlackのワークフローを使って自動投稿をさせることです。したがって、Slackに投稿する時の日付でカウントされている必要があります。

そこで、適当な場所にtoday関数で現在の日時を表示しておき、year関数やmonth関数を使って現在日時を表示し、COUNTIFS関数で条件を拾うときに、ここの日付を拾うようにしましょう。当月ではなく前月の数字を集計したい場合は=MONTH(TODAY())-1 のようにしておけばOKです。

【スタンプを集めた投稿を集計する】

先程は一番左の列をusernameにしてCOUNTIFS関数で集計しましたが、今回は一番左の列を投稿にして集計していきます。(その先でやることは同様なので省略します。)

f:id:photoruction_tech_blog:20211215111424p:plain

投稿文を一番左の列に自動で集めるやり方として、今回はQuery関数を利用します。

Query関数はデータベースの中から「○列の値がXXの時、△列の値を返す」といったことができる便利な関数です。例えば先程のデータベースから「F列が2021年、G列が12月のとき、投稿のセルの値を返す」ということが出来ます。

 

このQuery関数にUNIQUE関数を加えることで当月に投稿されたポストの原文を重複なく列挙することが出来ます。

Query関数の構文は自由度が高く長くなるので、こちらの記事をご参照ください。

最後にRank関数で数えたスタンプの数を順位付けします。

【Slackに投稿できる形に整える】

この後の行程で、Slackのワークフロービルダーを活用して投稿文を作るのですが、その際に参照できる形にシートを整えましょう。

一番上のセルに順番に項目を記載して、その下に各項目の一番のデータを返しておきましょう。前までの行程で作ったシートをQuery関数で検索させるのが一番楽だと思います。

f:id:photoruction_tech_blog:20211215112108p:plain

Slackのワークフロービルダーを使ってスプレッドシートの値を取得し、自動投稿する

ここまできたら後は簡単です。Slackにはワークフロービルダーという機能があり、様々なものをトリガーに自動投稿するBotを作ることができます。

今回は「毎月最初の月曜日」をトリガーとして、ここまでのプロセスで作成してきたスプレッドシートから値を取得し、文中に挿入して自動投稿文を作成しました。

雷のマークからワークフロービルダーを立ち上げて

f:id:photoruction_tech_blog:20211215112139p:plain

参照するスプレッドシートや参照したいセルを選択します

f:id:photoruction_tech_blog:20211215112157p:plain

すると、スプレッドシートから取得した値を変数として文中に挿入できるようになるので、挿入しながら文章を作成します。

f:id:photoruction_tech_blog:20211215112223p:plain

保存したら完成です!

これで毎月決まった時期がやってくると、前月に各Valuesスタンプを最も獲得した人と投稿を調べて自動投稿してくれるbotが完成しました。

ノーコードでも簡単にBOTは作れる!

Zapierを利用することで簡単にデータベースを作成することができるので、多少スプレッドシートの作法に慣れている人であればアイディア次第で簡単にこのようなBOTを作ることが出来ます。

ちなみに、Zapierの無料プランではなんと月に100回までしかスタンプを数えてくれないので、本格導入される方はお気をつけください,,,(約2,000円で750回、5,000円で2,000回数えられるので許容範囲かなと思います)

フォトラクションのValuesが気になるよという方は是非以下の記事もご覧ください!

 

 

それでは!

 

株式会社フォトラクションでは一緒に働く仲間を募集しています


 

これまでに感じたQAエンジニアと他エンジニアの相違(QA視点マシマシ)

こんにちは!株式会社PhotoructionでQAエンジニアをしています日隈です。 Photoruction Advent Calendar 2021の17日目の記事です。

そもそもQAとは


QAという職種に馴染みのない方もいらっしゃるかと思いますので、軽く解説をしておきたいと思います。 QAは「Quality Assurance」の名の通り、品質保証を担当するエンジニアです。 「品質保証」と言っても会社や組織によって求められるものや方向性がわりとばらっばらなので「こういうお仕事です!」と断言しづらい部分はあるのですが、ユーザーが問題なくソフトを使用できることを担保するというのが基本的な業務になります。

具体的には概ね以下の業務が多いですね。

  • 企画の要件定義の際に「それいる?」「ユーザー使いにくくなってない?」と文句をつける
  • 開発エンジニアが作ってきたものに対してテストを実施してダメ出しする
  • テストで見付けた、細かくて要件が定まっていない部分に対して「こうしたほうが便利ですから!」と押し切る
  • リリース後のプロダクトをいじった際に感じたことを「やっぱここ変えたほうがよくね?」と言ってねじ込み、開発の仕事を増やす

以上を踏まえてQAエンジニアと一般的な開発エンジニアがどう違うのかというところを、QA歴10年ちょいの私の視点から見ていきたいと思います。

(かなり個人的な偏見が入っており、必ずしも全ての事例に当てはまるわけではないのでその点予めご了承下さい)

目次


1.QAは無産階級

2.QAは保守的

3.QAは大雑把

4.QAは細かい

5.まとめ


 

QAは無産階級


文字通り、QAエンジニアは単体では何も産み出せません。 「ユーザーが問題なくソフトを使用できること」を確認するのが業務である以上、大前提として誰かが何かを作ってくれないとそもそも仕事が始まらないのです。

その点開発エンジニアは自身の力でコードを書いて作るべきものをを作ることが可能です。凄い。

そんな皆様の作り出したものをテストという名の棍棒でぶっ叩くのが我々QAのお仕事なのです。 この点を指して、俗に「開発は創造者、QAは破壊者」などと言われることもありますね。

口さがない人からは「QAは寄生虫」なんて言われますが、泣いちゃうので面と向かっては勘弁して下さい。

 

QAは保守的


全てのQAがそう考えているというわけではないのですが、QAというものはわりと少なくない比率で「現状で問題なく使えているもの」に対する変更を忌避する習性を持っています。 過去の経験でいうと、「appのリニューアル&話題作りのため、UIどころか導線から何から全てガラッと変えましょう!」という案件に対して明確かつ強固な反対意見を出したのはQAだけでした。

開発エンジニアは新しい技術をキャッチアップしていく必要があるためか進取の精神を持っている方が多く、変化に柔軟に対応する方が多いように感じます。 対してQAの判断基準は「既存を含むユーザーが使えるか使えないか」という点が非常に大きいため、見た目上の変更はなくとも今まで問題なかった箇所にバグが発生する可能性のあるバックエンドの改修やデザイン大幅変更による既存ユーザーの使用感切り捨てなどにはどうしても抵抗したくなるのです。

決してスモーク/リグレッションテストを作り直すのがめんどくせぇなどという理由ではない点ご承知おき下さい。

 

QAは大雑把


これまでのところでも書きましたが、QAはユーザーのポジションでの「使えるか使えないか」が判断の基準です。 そのため、裏側で何がどうなっているかなどはまず確認しません。 めっちゃコードが汚かろうが、何かよく分からん処理が走ってようが、それが表に出てこない以上一切気にしません。

たまに開発の方が「問題なく動いてるけどちょっとコードがとっちらかってるので整理しますね」的なことを仰るのを見たりするのですが、個人的には現状でも大丈夫なのにわざわざ整理するなんてマメな方なんだなー、きっとお部屋も整理整頓出来る人なんだなーという尊敬の目で見ています。

 

QAは細かい


上の内容と相反してそうですが実は並列であり得るのです。

前項の通り裏側なんか気にしないQAですが、それはつまり表に出てきたものに関してはめっちゃ気にするということなのです。 toCtoB、ユーザー層がどのあたりかなどターゲットによっても変わるのですが、場合によってはデザイン確認において1pxのズレも許容しないなんてこともあります。

この辺開発の方からすると意味分からんと言われることもありましたね。 自分でもたまに意味分からんです。

 

まとめ


思いついたことをつらつらと書いてみましたが、QAエンジニアと他エンジニアの違いで一番大きいのはやはり「作る側か否か」という点かなーと思ってます。 「作る側」と「使う側」という根本的な相違からスタンスや視点の差も生まれてきてるように感じますね。

そんなわけで会社によってはQA vs 開発みたいな空気になることもあったりするのですが、今回の記事が相互理解に繋がるととても嬉しく思います。

ご精読ありがとうございました。

 

 

株式会社フォトラクションでは一緒に働く仲間を募集しています 

Androidアプリのアーキテクチャの現状

Androidアプリ開発者の久木田です。

この記事はPhotoruction Advent Calendar2021の16日目です。

まずはこちらの記事をお読みください。
また、この記事はあえてネガティブなことを抜き出して書いています。記事を読むタイミングによっては改善済みの場合もあります。

TL;DR

理想を決めたけど、あれもこれもまだまだダメダメです。

ただし、よくなる兆しも、よくしていく動きもあります!

これからのPhotoruction Androidアプリにご期待ください!

第1段目のゴール目標と現在

第1段目のゴールは「秩序をしっかり作って、秩序に慣れてもらうこと」です。

それで、今どうなの?というと、

  • 設計方針については理解できてるし、新しいものはそれに沿って作れているしリファクタする時も沿えている
  • ただ、これまでに作られた膨大なコードについては全然まだまだこれから

というところです。

これからどれだけ全然まだまだなのかをいくつか数字を出しながら説明していきます。

ファイル数からわかること

種類 条件
Activity 63 ファイル名にActivityがついている
Fragment 73 ファイル名にFragmentがついている
ViewModel 59 ファイル名にViewModelがついている
  41 ↑のうち、ViewModelもしくはAndroidViewModelを継承しているクラスのあるファイル
Repository 27 ファイル名にRepositoryがついている
Realm 49 RealmObjectを継承しているクラスのあるファイル
Room 26 @Entityが付いているクラスのあるファイル

これだけでもわかることがいくつかあると思います。

  1. Realm / Roomのファイルに対してRepositoryのファイルが少ない → Repositoryを経由していないDBアクセスが大量にある
  2. Activityの数が多い → ViewがActivityに直接紐づいているものが多い
  3. ViewModelって名前なのにAACのViewModelを継承してないファイルが多くある(これはそういう方針なのであれば問題ないと思うが、そうではないので問題と認識している)
  4. ViewModelがActivity / Fragmentに比べて少ない→Fat Activity / Fat Fragmentになっている

ステップ数からわかること

種類 条件
平均 210.8 拡張子が.javaのファイルの行数の平均
  75.8 拡張子が.ktのファイルの行数の平均
中央値 92 拡張子が.javaのファイルの行数の中央値
  35 拡張子が.ktのファイルの行数の中央値
ファイル 19 拡張子が.javaのファイルの1000行を超えているファイル数
  0 拡張子が.ktのファイルの1000行を超えているファイル数
  1. 特にJavaのファイルに関して、ステップ数が多い → 適切な責務分けがされていない
  2. Kotlinのファイルは比較的新しいこともあり問題があるようには見えない → 当然見えづらくなってるだけで問題点のあるコード、ファイルはある
  3. 平均と中央値の差が大きいことから、とにかくステップ数が多いファイルがいくつかありそう

こちらはこういったところでしょうか

コードからわかること

まだまだアーキテクチャに沿えていないコードが多いです。

それは↑のところからわかることも多いですが、実際はそれ以上に、アーキテクチャに沿えていない ≒ Fat Activity / Fat Fragmentなので、責務の分割から始めることになったり、そもそも密結合すぎて大幅に書き換えないとアーキテクチャに沿えなかったりというファイルも多くあります。

また、コードとはまた違いますが、package構成もぐちゃぐちゃだったりします。

これもアーキテクチャを決めたタイミングでpackage構成を決めているので、とりあえずはAndroid Studioの機能を使いながら移動させるだけですが、1072ファイルあるのでそれだけでも大変です💦

そのほか、あげればキリがないほど課題はありますが、本当にキリがなくなるのでこの辺で

1年で良くなったこと

辛そうな話ばっかりだとアレなので、最後によくなってることを話して終わりにしたいと思います。

2021年(2020年からやってることもあるんですが)で改善したことも併せて記載しておきます。

アーキテクチャの導入

これまでは設計の「せ」の字もないコードだったのをアーキテクチャを決め、設計方針を固めて書くようになったので、責務の分かれたいわゆるいいコードに近づいたと思います。

CI/CD/GitHub Actionsの導入

CIやActionsはまだまだできることはあるのですが、Lintの指摘やビルドが問題ないかなどまだまだ基本的なことしかやれていませんが0→1の大きな変化だと思っています!

やれることはあるのでこれからもどんどん面倒なことを自動化させたいなと思います。

今はライブラリのアップデートがめちゃくちゃ面倒なのでCIで自動でPR作られるようにしたいなって思ってます。

テストの導入

テストに関しても、これまで全く書かれていませんでした。そもそも書けるようなコードになっていません。(これは現在進行形です)

なので、アーキテクチャを決めて、それによって責務分けをしたタイミングで、次はテストコードを書くぞと決めて、新しいところのViewModelなど書くべきところは書くようにし出しました。

こっちもまだまだこれからですが、TDD的な書き方をしたり、テスタブルなコードを書けるようにして、どんどんよくしていきます!

今後どうしていくのか

とにかく、今は少しでも多くのファイルをアーキテクチャに沿った構成に近づけることを最も優先しています。(開発の傍らですが)

まだしばらくそちらに時間がかかると思いますが、大方の対応が完了すると別のつらみが出てくると思っています。そうなった時にはまた新しい施作を実行して行きます。

来年のアドベントカレンダーでは別の課題の解決をしてるといいな

 

株式会社フォトラクションでは一緒に働く仲間を募集しています 

corporate.photoruction.com

www.wantedly.com