こんにちは、FLINTERSでバックオフィス部門を担当している横山です。
本ブログは「梅雨にも負けないFLINTERSブログ祭り」に関連した投稿となります。 と思ったら、今年は全然梅雨がきませんね？弊社ブログ祭りのおかげでしょうか♪
今回のテーマは #エンジニアリング指針 です。
日々共に働く仲間を集めるべく、新卒・中途共に採用活動を行っている弊社ですが、その活動の中で社外の方に
「弊社にはエンジニアリング指針があり、こちらを外部に公開していることが、特徴の一つです！」
と、よくよくアピールしております。
一方で、
「アピールしている君自身はその指針を日々の業務に活かしているのかね？」
「エンジニアじゃないし、コード書かないしあんまり関係無いよね、って思ってるんじゃないの？」
という言葉がある日突然天から降ってきまして、ハッとし慌てて今回筆を取った次第です。
開発部門では無い、自身のバックオフィス部門でも活用可能なのか！？
エンジニアリング指針をもとに自身の業務を振り返ってみたいと思います。
エンジニアリング指針序文
ユーザー価値の高いシステムを素早く提供し続けることで、今までにない未来を作り出す。
これが我々の達成したいことです。
これを、「ユーザー価値の高い業務フローを素早く提供し続ける」と読み替えると
- 入社の方向けの各種社内準備フロー
- 必要なツールのアカウント発行フロー
- 書籍購入申請フロー
などなど、社員にとって価値の高い社内の業務フローを構築、提供しつづける毎日です。
今までにない未来と言うと大げさですが、達成したいことで間違いないです。 うんうん大丈夫、我々の部門にも活用できそうな気がしてきました。
ユーザー価値を確かめる
苦労して完成させたとしても、ユーザーに価値をもたらさなければ誰も利用しません。
我々はソフトウェアやデータを作るだけにとどまらず、それらをユーザーが活用する場面まで関心を持ちます。
事前に価値をもたらせるか不確かな場合には、モックやプロトタイプによる価値検証を検討します。価値検証はできるだけ早く実施できるようにコードを書かない方法を優先します。
検証用にコードを書いた場合、価値検証後の本番プロダクトコードに安易に検証用コードを利用しません。保守運用の観点から利用の是非を検討します。
またリリース後は洞察を得るためにKPIを追跡し、プロダクトの改善に活かします。
基本的にバックオフィス部門は、誰かに求められて業務フローの構築等の業務がスタートすることが多く、価値が全くわからない状況は少ないです。
ただし、価値の大小を充分に検証せず、取り敢えずプロトタイプ的にササッとフロー構築し、それが正式フローとして運用されていくことは正直多いです。
何からのKPIを持った上で、そのフローをそのまま残すのか？なくすのか？改善するのか？の判断タイミングは設けたほうがより良くなりそうです。
ということで、この項目の評価は △ です。
変化に強い構造を作る
環境は常に変化します。プロジェクトが少し進めば新しい視点が加わり、やりたいことややるべきことが変化します。また、利用しているライブラリやサービスは機能追加や脆弱性修正により変わっていきます。
そのため、我々は変化に強い仕組みを取り入れます。
- 変化が起こりやすい箇所の特定と変更を局所化するアーキテクチャとデータモデリング、変更しやすくするためのテストに取り組みます。
- アジャイルな開発プロセスを採用します。利害関係者の要望やチームのプロセス・成果物を明らかにし、目標の設定と実行のサイクルを短期間で回し、目標の調整とプロセスの改善に努めます。
- プロダクトを隅々まで把握し発展させることができるメンバーを継続的に育てるために、設計やコードをピアレビューします。
事業拡大を広げる弊社では、いままで発生していなかった新たな条件での業務、というものが毎日のように生まれており、社内でも有数の変化に悩まされている部署であるとも言えます。 この結果、業務の標準化がしにくく、人による匠な調整で乗り切ることも多いです。
アジャイルな改善と言えなくもなく、部署としては変化に強い組織と言えるのかもしれませんが、、、これを膨大に繰り返し続けると対応する社員の業務負荷も大きくなるため好ましくないです。
変化が起こりやすい箇所の特定と変更を局所化するアーキテクチャとデータモデリング
この部分に着目し、やることをただ羅列した業務のマニュアルだけでなく、業務の設計図、業務のフロー図をつくり、まさに変化の起こりやすい箇所の予めの特定をしておくべきだと気づきました。
冷静に考えると当然のことなのですが、業務が広範囲にわたるバックオフィス部門では、どうしても目先の業務を終わらせることに目が行きがちです。
ということで、この部分の評価は ✕ です（涙）
適正な品質を目指す
プロダクトの品質は様々な視点からみることができ、例えば利用時の品質と製品品質の２つの視点が挙げられます。
品質は一面だけを見ず多面的に評価し、適正な品質を目指すことが重要です。またいずれの品質への要求も環境の変化と共に変化します。
利用時の品質が低いプロダクトはユーザーに価値をもたらしません。一方で製品品質が低いプロダクトは開発速度や拡張性やコスト効率等の点で、変化する品質への要求に応え続けることが難しくなります。
我々はビジネス課題を解決するのに必要十分な品質を定義することで評価できるようにしたうえで、点検し、向上させるよう継続的に努めます。
この点についても非常に自身の業務において、反省すべき部分が多そうです。
ビジネス課題を解決するのに必要十分な品質を定義することで評価できるようにしたうえ
担当している様々な業務について、各担当者同士で暗黙的に求められる各業務品質レベルの共通認識を持っていますが、きっちりとした定義ができていないこともとても多いです。 定義したものと現状の認識に大きな乖離は無いとは想定していますが、評価をする観点では定義付けすべきと感じました。
また、適正な品質を目指す上で、エンジニアリング指針には以下項目の記載があります。（詳細説明文は今回は省略します。）
- 品質を手軽に高められる工夫をする
- テストし監視する
- データを理解する
集計業務におけるアナログな集計からツール導入や、付与権限業務におけるミス防止のための自動チェック機構（プログラム）の作成など、最近では少しずつ品質を高める動きも始まってきました。 ここは引き続き行っていきたいです。
ということで、まだまだここも発展途上ということで、 △ 評価です。
個人の強みを磨きチームで活かす
個人の能力や経験は均一ではありません。
個人がチームに貢献する際に様々な形があることを我々は理解しています。
各人が強みを伸ばしながら、チームとして最高の成果をもたらせるように努力します。
私の部署に限らず、弊社では部署に新たな仲間が加わった際には、ドラッガー風エクササイズ*1を実施し、メンバー同士理解を深める機会を設けています。
この点については ◎ と評価しておきます。
新しいことに挑戦する知性と勇気を持つ
我々の取り組むテクノロジー分野では日々新しいツールやプロセスが提案され、ベストプラクティスが変わります。
今取り組んでいる手法を深く追求するとともに、新しいコンセプトに好奇心を向け、知性と勇気をもって取り入れる挑戦をしていきます。
この点はまさに日々痛感しており、
- 業務の設計能力を高め続ける
- テクノロジーの活用を更に加速させる
この２点については、バックオフィス部署と言えど避けて通ることはできず、
弊社の行動規範の一つである
学びを結集し、 新たな付加価値を見つけよう。
を胸に知性を磨き
大丈夫、やってみよう。 全ては一人の熱量から始まる。
を掲げて勇気を持ち、
頼れるバックオフィス部門を引き続き皆で創っていこうと思います。 （今回評価でよろしく無い点が多々あったため、早速改善していかねば！！！！）
おしまい。
