春の入門連載2021の7日目です。

はじめに

こんにちは、TIGの須田です。

私は新卒でフューチャーへ入社しITの世界でのキャリアが始まりました。その後、一度フューチャーを離れIoTプラットフォーマーのソリューションアーキテクトとして多くのお客様へ自社サービスの導入支援やIoTシステムの設計や構築の支援をしておりました。そうしたソリューションアーキテクトとしてのロールを通じて、多くの経験や学びを得ることができたのですが、その中でも特にTechnical Credibilityというキーワードについて自分の経験を交えて本ブログにて書いてみたいと思います。

本ブログのシリーズが、春の入門記事＆新人だった頃の自分に伝えたい内容を書こう、というテーマであったので迷わずこのテーマについて取り上げようと決めました。

Technical Credibilityとはなにか

Technical Credibilityとは無理やり日本語に訳すと技術的信頼？ 信頼度？ となります。Technical Credibilityの厳密な説明や定義が少ししにくいのですが、技術力やそのナレッジを通して信頼を得ていくこと、そのプロセス、と自分は解釈しています。

私はこの言葉をソリューションアーキテクトとして活動していた際に初めて知りました。ソリューションアーキテクトというロールはお客様の抱える課題や実現したいことに対して、主にテクニカルサイドからどのようにそれらを解決・実現できるかについて具体的なアドバイスやご支援するものです。そうしたロールであることからも、技術的なアドバイスを求められることが大きく期待されています。

こうした技術的なやり取りを通じてお客さんの信頼を得ていくプロセスをTechnical Credibilityを得る、とここでは表現したいと思います。

ソリューションアーキテクトの仕事そのものについてはこちらのエントリがとても参考になります。またこちらのエントリにもTechnical Credibilityの大切さについての言及があるのでこちらもぜひおすすめです。

フューチャーは経営とITをデザインするという言葉が示す通り、ソフトウェアエンジニアであってもお客様の業務を理解し、一緒にシステムを作り上げていくことが求められます。そのためTechnical Credibilityの考え方が同じく重要だと考えています。

ここからはTechnical Credibilityを築くことの重要性や、その際にどのような考えやアクションが重要になってくるのか、またその中でのちょっとしたTipsなんかにふれていきたいと思います。

Technical Credibilityがなぜ大事なのか

ITの世界に限らずTechnical Credibilityは私たちの日常のいたるところで適用できる考え方だと思っています。例えば体調が優れないときは病院へ行き専門医に原因や対処法を診察してもらいますし、何か資産運用を始めたいとなった際にFPに相談される方もいらっしゃると思います。こうしたシーンにおいて、私たちが知らないことやより深く知りたいことを、その知識や経験を有している専門家に相談しアドバイスをもらうという観点では私たちITコンサルタントに期待される役割と同様です。

まず初めに、こうした特別な事情を有した相談は誰にでもできるものではありません。そうした経験を有している方へアドバイスを求めることが自然です。そうした際にまず大事になってくるのが、この人に相談ができる・したいと認知してもらえていることです。私たちも期待した答えが得られなさそうだったり、詳しくない人に専門的なアドバイスを求めようとはまず思わないですよね（あえて専門家以外の方にフラットな意見を聞くことが重視されているようなシーンでは話は変わるかもしれません）

こうしたアドバイスをもらう際に、その一連のやり取りの中でこれぞまさに求めていたアドバイスだ！ といった助言をいただけたとします。そうすると、また似たような悩みや関連する相談事があった際に、ぱっとその人の顔が思い浮かび、また相談してみようかしらと考えるのは自然なことではないでしょうか。そうした体験を繰り返すことで、最初はさしあたった相談や課題が主だったのが、より多くのことについてもまずこの人に相談にのってもらいたい、この人なら何かアイデアがあるんではないだろうかと大きな信頼へと変わっていきます。

このプロセスこそがTechnical Credibilityが築かれることでもたらされる好循環で、こうした信頼がうまれることでより多くの機会を創出することにつながります。特にビジネスの世界ではこうした些細な相談事から大きなプロジェクトへつながったり、はたまた一緒に大きな仕事をしていこうという機会にもつながってきます。

それではTechnical Credibilityを築くためにはどうしたらよいのでしょうか。このアプローチは人それぞれあると思いますが、私自身の経験や私自身がこの人はとてもTechnical Credibilityを築くのが上手だなと思える人たちの振る舞いを見て学んだポイントについてふれていきたいと思います。

Technical Credibilityを築くには

自分の経験・知識を還元できそうな領域を見つける

まずは自分が提供できる専門性や得意な領域を見つけることがとても大事です。これについて、何かの専門家である必要はなく、自分の経験に裏付けされた何かアドバイスができる、といったそういったもので十分かと考えています。例えば、DynamoDBを使ったデータモデルの設計実装経験とその過程で得られた知見や、ライブラリの選定を通じて得た各プロダクトの特徴や適したユースケースを理解している、はたまた倉庫業務のアプリケーション開発を通じて得られた倉庫業務の知識そのもの、特定の産業用途に特化した独自プロトコルのフォーマットのパース処理を通じて得られプロトコル仕様、こうした人それぞれの経験がまさに価値を生んでいきます。こうしたナレッジは誰しも持っているものではありません。さらに、商用環境での導入などを通じてより実践に即したノウハウなどは、やってみたの域を超えた高い付加価値を有しています。

こうした経験はこれから同じチャレンジをする人たちや、今まさにはまっている人たちにとってはとても有益な情報となります。このように、まずは自分がこれまで経験をその中で培ったナレッジから何か貢献できることから始めていくことで、その人のTechnical Credibilityを築いていくことができるのではないでしょうか。こうした過程を重ねていくことで、○○のことなら前にｘｘさんが教えてくれたからまた相談してみよう、ぜひメンバーとして一緒にやってもらいたいといったラベリングができあがり、より大きな相談事をもらえたり、チャンスへつながっていくのではないでしょうか。とにもかくにも、自分の経験や知識を惜しげもなくシェアしていくことが大事な一歩かと考えます。

例えばこのように普段使っている便利な小技だったり、やってみて分かったはまりどころ、がっつり業務導入した知見などを技術ブログとして共有することも社内、社外問わず自分のラベリングを作るのに効果的な手法ですね。

• 実践Drawio | フューチャー技術ブログ
• 産業用機器向けフィールドネットワークModbusで温湿度センシング | フューチャー技術ブログ
• 2020年秋にVue.jsのアプリケーションを作るなら、押さえておきたい5つのポイント | フューチャー技術ブログ

常に最新の情報をキャッチアップする

個別の技術要素を正しく理解することが全ての基本です。これがやりたかったらこのAPIを使えばよさそうですねとか、このクラウドサービスとこの機能を組みあわせれば実現できそうですね、など様々な技術要素を考慮しながら具体的な課題へのアプローチを提示できることがまずは重要です。特に、昨今のクラウドサービスの拡充やそれらのサービスの成長スピードなんかを考えると、つい昨日までしてた苦労が実はマネージドサービスやSaaSとして提供されていたり、新しい機能が使えることでよりシンプルな実装になったりというのはよくあることとなってきました。そのため、最新の情報を常にキャッチアップしておくことも、不要な苦労を避けてもらうためにも非常に重要となってきます。

こうした個別の技術要素を正しく理解しながら、自分の引き出しを増やして、いざという時にすっとアイデアや解決策そのものを引き出せるようにしておくこともとても大事なスキルとなってきます。

情報収集の仕方についてはみなさん好みのやり方があると思うのでここではふれませんが、すぐに試せる環境を手元に用意しておくことをおすすめします。最近ではDockerコンテナなどでたいていの実行環境はdocker pullで利用できますし、試すだけの環境構築の敷居はかなり下がっていると感じます。また様々な機能がクラウドサービスやSaaSとしても提供されるようになり、何かを確認したい・知りたい時は自分で手を動かして理解する方がよほど早くなってきているとも思います。前述したように、昨今における機能の充実速度はとても速いです。たくさんの利便性を享受できる一方で、理解しなくてはいけない事柄も同時に増えてきているとも言えます。こうした状況では実際に手を動かしてプロダクトを理解し、想定通りの挙動がとれた・できなかったという経験を通じたキャッチアップや理解の方が結果的に効率的なことが多いです。特に自分で手を動かすことで、ただ知っている状態より深みが増します。さきほど書いた通り、自分が実際に体験した事柄が価値を生んでいきます。そのため、手元ですぐに試して確認したり失敗したりできる環境をメンテナンスしておくが非常に大事です。さてやってみるか、となった際にその初速を高められる準備をしておくことをおすすめします。

また最近ではO’Reilly Mediaのように、書籍を横断したキーワード検索ができるものもあり、短期間でよりピンポイントでの深堀をしたい際はこうしたサービスを活用していくのもおすすめです。

課題の本質を考える

ある悩みや課題に対して、具体的な解決策を説得力をもってぱっと提示できることの重要性についてはさきほど記載した通りです。

一方で、その課題やゴールが果たして適切なものなのかを一歩立ち止まって考えられることも、相談相手のためにも重要なことが多いです。例えば、実はその課題の本質には別の根本的な課題があって、そちらにアプローチするのがより効果が高いといったシーンです。専門家へ相談するようなシーンにおいては、相談者自身も何が課題になっているかが分からない、把握が難しいケースも多いです。特に初めての取り組みや、ナレッジの取得が難しいような課題に取り組む際に私たちも何が分からないのか分からない、といった経験が一度はあるのではないでしょうか。こうした状況下で設定した課題やゴールについて、相談を受ける側はいい意味で第三者的な見方ができます。あれ、これって本当に実現したいことなのかな、という事が浮かんだら投げかけてみることで相談者にも新たな気付きをもらすことができますし、何よりもこれこそがアドバイスの神髄ではないのでしょうか。

またITの世界では、同じ課題感であっても属する業種業態などによってもとらえ方やアプローチが変わってくることもあります。そのため、技術要素しか興味がないので、、と食わず嫌いせずに、その課題が置かれている業界背景などにも目を向けてみることで得られるものもたくさんあります。

こうしたいわゆるドメインへの理解をどう行っていくかですが、一般的な知識であれば今では色んな情報が簡単に手に入るのではないでしょうか。私はよく就職活動なんかで使われるような業界本なんかも最初は読んだりします。よりテクニカルなトピックについては、最近だと動画コンテンツが充実してきています。例えば、既に活用されている方も多いかもしれませんがUdemyもおすすめで、ITコンテンツ以外の業界に特化した技術コンテンツなども充実しています。例として、製造業ですと様々なフィールドネットワークのためのプロトコル技術や、PLCといった機器操作方法などのコンテンツもたくさんあり、体系だった理解を効率的に進められます。またYouTubeにもこうした多くの動画が公開されており、短い時間で体系だったキャッチアップが必要な際にとても有用なコンテンツとなっています。まずは気になるWordなどで検索してみることをおすすめします。

例えば私はIoT関連のプロジェクトを担当することが多いのですが、その際に専門的な機器設備の仕組みなどをキャッチアップするのにこのYouTubeチャンネルにお世話になってます。

https://www.youtube.com/c/Theengineeringmindset/featured

ちなみに実機を使った何か確認がしたい！ という場合はヤフオクだと専門的なデバイスも入手しやすいのでこちらもおすすめです。

どうしてそうするのか・したのかを蓄積する

どんなシステムや技術課題、業種業態の話であっても、実現したいことやそのポイントには多くの共通点があることが多いです。そのため、どうしてそのような判断をしたのか、どのようなアドバイスのステップや検討を経由したのか、といったログを残しておくことも非常に重要です。これは前述した引き出しから適したアドバイスを素早く引き出せることにもつながります。

Architecture Decision Records(以下ADRs)をご存じでしょうか。私はロール上、システムアーキテクトとして実現したい仕組みや解決したい課題へのアプローチを立案することも多いのですが、ADRsのアプローチは非常に有用です。どのような過程を経由したのか、その各過程ではどういった考えあったのか、を形として残すことでなぜそうするのかを第三者にもステップを追ってシェアできます。どんなに解決策やアプローチが優れていたとしても、そこに納得感が伴わないとなかなか行動に移しにくのも確かです。そういった観点でもこういったログを一緒に作る、というアクションもこれまでの考えをより納得感をもった理解を促すためにも非常に大事なのではないでしょうか。

具体的なADRの例ですがADRの具体的な作り方はこちらがとても分かりやすく整理されていておすすめです。

• 実践ADR - kawasima

おわりに

新卒でフューチャーへ入社した際はいわゆるIT未経験だったこともあり、テクニカルな側面でのキャッチアップや研磨にとにかくがむしゃらだったことを今でも覚えています。

それを正しく人に伝え、そこからさらなる価値を生み出していくこと、そのためにより広い視野で食わず嫌いせずにキャッチアップを続けることの大事さを新人だったころに自分に伝えてあげたい、、、ぜひ自分の得意な領域に磨きをかけつつも、色々な技術に実際に触れてみて、みなさんしか作れないTechnical Credibilityの源泉を蓄えていってください！