Articles tagged with: システム開発

2024年の抱負


明けましておめでとうございます。

昨年末にアップした投稿にも書きましたが、昨年度は皆さま、本当にいろいろと有難うございました。
今年も引き続き、よろしくお願いいたします。

今年も抱負を書きます。
本稿の内容は年末にある程度まで考え、元旦に熟慮しました。

一年の計は元旦にあり、とはよく言ったもので、忙しくなってくるとこの言葉の意味がよくわかります。もう正月ぐらいしか計画をゆっくり考える時間がありませんから。
この抱負を仕上げた後は、詳細の内容についてより考えを深めます。そして、昨年末にアップした投稿にも書いた反省を生かし、改善する一年にします。

昨年は案件の増加に備えて3月に1人、4月に3人のメンバーを増やしました。また、既存の外注メンバーの二人には正社員になってもらいました。
ところが、増える一方の案件をこなす速度が釣り合わずにメンバーは疲弊し、増やしたメンバーのうち3人が去ってしまいました。研修計画や教育体制やその他の基盤が未整備なまま採用を急いだ焦りが招いた失敗です。

そうした経験を通して痛感したのは、弊社の企業としての基盤が未整備であることです。各自が個々に動いてしまいがちの弊社で、チームとしてのまとまりがとうとう持てませんでした。

その理由がフルリモートワークの弊害であることは確かです。また、フルリモートワークを遂行するにあたり、統一した事務手続きや研修資料、そして開発にあたっての各種のガイドラインがないことも致命的でした。

あと、もう一つ、うまく行かない理由として挙げられるのは、私の目指す会社の方向とメンバーのそれがずれていたことです。方向だけでなく、そこにいくための手段についても。

まず抱負として挙げるべき当面の目標。
それは、この正月にガイドライン(アクアビット蒸留書)のドラフト版を作り上げることです。
それと同時に、経営理念や企業理念を考え直し、業務計画を作り直すことです。

まずやるべき事を以下に書きます。

1.ガイドライン作成

昨年5月の連休に集中して作ったガイドラインを仕上げます。少なくともドラフト版として内部に出せるレベルには仕上げるつもりです。

昨年作った版は、案件の引き合いから商談、そして契約に至るまでは現状の運用の七割程度は盛り込めたはずです。ところが、開発ガイドラインに着手したところで連休が終わってしまい、そのあとは業務の多忙にかまけて全く進められずにいました。

そのあと、経営が苦しくなると、ますますガイドラインの整備に時間を使う余裕はなくなりました。
また、経営のやり方を変えなければと思うとともに通常の開発のやり方の限界を悟り、伴走開発やサービス提供に舵を切りました。それによって開発のやり方自体に変更が生じ、ガイドラインの必要性がはますます増しています。

今の弊社に足りないのは生産性です。
各自の作業を細かく見ていると、既存のロジックを再度作り直すか、既に作成したコードを構築しなおしているケースが散見されます。
各個人単位ではそうしたことはないはずです。が、別のメンバーが既に作っているコードを再発明したり、すでにある調査結果を再度読み直したり、といったことが起こっているようです。
そうした無駄や重複の部分を弊社内できちんと整理し、業務手順として作り上げる必要があります。それがガイドラインの目的です。

いうまでもなく、マニュアルは読むためにあるのではありません。各自が作り上げていくためのマニュアルです。その点については、昨年の師走に参加した「CHALLenGERS」の中で紹介されていた『無印良品は、仕組みが9割』の中に書かれていました。
作業そのものをまねるためにやり方が逐一書かれたマニュアルは必要ありません。
それよりも、誰がなんのために、いつやらなければならないのか。何故それをするのか。そうした作業の目的を明確にし、個人に視点が固定されないためのガイドラインが必要なのです。

そのガイドラインを(アクアビット蒸留書)と名付けます。

アクアビット蒸留書に盛り込むべき内容は、弊社のありとあらゆる作業です。引き合いから商談、契約に至る作業。経理の上で重要な記帳に関する作業。また、人事・労務に関する手続きや総務に属する作業。
そして、アクアビット蒸留書は永遠に未完成です。常にドラフト版でありながら、全員でこれを研修計画や教育体制が整っていない間に磨き続け、少しでも正規版に近づけるよう努力します。そして全員が遵守します。

そのため、アクアビット蒸留書は月一度、定期的に更新していきます。個人のノウハウややり方がアクアビット蒸留書に書かれているよりも優れているのなら、それを無理にやめさせるのではなく、むしろアクアビット蒸留書に取り込んで全員で共有します。
アクアビット蒸留書がその純度を増すごとに、余分な作業で時間を使うことが減り、案件の実装が円滑にいき、納品までの速度が増えるはずです。

2.弊社の業務の五分割

弊社の業務を大きく五つに分割し、担当者と目的を整理します。

昨年の反省として、代表の私の拡大・新規志向と、メンバーの会社や仕事に対するモチベーションの違いを埋められなかったことが挙げられます。
メンバーの立場からすると、既存の案件がまだ終わっていないのに、次々に新しい案件が飛び込んでくることで既存案件が積み残され、心理的にストレスになっていました。
また、あちこちを飛び回って新たな案件や考えや技術を持ち込んでくる代表についていけない事もストレスになっていたはずです。
新たな案件もいいけど、それよりも既存案件を単価を上げてしっかり維持する。そして案件の数は少なめにし、メンバーのフォローをしっかりすべき。そんなメンバーの不満を感じました。

それももっともで、一番ひどい時にはあるメンバーが十個強の案件を抱えていました。これは改善しなければ。

ただし、まず前提として考えておかなければならないのは、固定の案件ややり方を墨守していては会社の成長が見込めないことです。このAI時代にそんなやり方で会社が続くはずがありません。ましてや弊社のような零細企業が。
また、代表の性格的にも同じ案件ややり方を続けることはできません。そんな苦痛さえ感じるやり方では経営意欲にすら影響を与えます。

その相反する矛盾を解消するため、弊社の業務を五つに分けます。

一つ目は、既存の大型継続kintone案件です。
大口でかつ継続のお客様は単価を上げてもらいます。その上で、既存のカスタマイズ手法を踏襲したまま、引き続き開発にあたります。案件によっては伴走に近い形でやっているものもありますし、半常駐でがっつりやっている案件もあります。
これらのお客様は、弊社の経営の安定に欠かせません。が、それ以上にお客様から信頼をいただいていることが一番重要です。今年はこれらの案件を優先し、引き続きお客様のために力を尽くします。別紙に書いた案件が該当します。

二つ目は、既存のkintone開発案件です。
これらの案件は、伴走開発のやり方も取れないまま、既存のJavaScriptカスタマイズによるやり方で追加スポット保守や追加開発を続けています。別紙に書いた案件が該当します。
これらの案件は徐々にJavaScriptカスタマイズからプラグインやサービスを利用する形に変えていきますが、当面はJavaSctiptカスタマイズが必要になるでしょう。
また、この後に述べる三つ目の伴走開発の中で開発が必要になった作業も、随時この既存のkintone開発案件に加えていきます。

まず弊社メンバーにはこの一つ目と二つ目に集中してもらいます。
多くても一人当たり四つの案件に絞り、集中して当たってもらいます。

三つ目は、新規の伴走開発案件です。
これらは代表の私が主に携わります。
伴走案件の場合、アプリ構築やカスタマイズはお客様が行います。
カスタマイズを行う際はJavaScriptはなるべく使わず、既存のプラグインやサービスを積極的に活用します。
新たな案件が増えても、うちのメンバーには作業を振りません。一旦、代表の私の方で要件定義や伴走開発を行います。別紙に書いた案件が該当します。

四ッ目は地域活動やコミュニティーです。
代表の私は今年もまだkintoneエバンジェリストを続ける予定です。また、今年は弊社役員の妻が地域クラウド交流会のオーガナイザーとして本格的に活動を始めます。

代表はkintoneエバンジェリストとして、引き続きkintone Caféや各種のセミナーに積極的に登壇します。昨年の登壇回数は18回でした。そこで今年は登壇の回数を増やし、25回を目標にします。
そうした活動からは、地域活性化など、いくつかの案件の種も芽生えつつあります。今年も引き続きそうした活動に関わっていきます。
別紙に書いた案件が該当します。

また、オーガナイザーの妻も6/29に予定されている山梨での地域クラウド交流会を必ず成功させ、山梨県で弊社の基盤を構築します。

三つ目と四つ目に代表の私が当たることにより、私の持つ拡大・新規志向を満たすとともに、新規案件の創出も実現させます。

五つ目は新規サービスの開発です。
昨年、3つの新規サービスをリリースしました。
今年はそのサービスをより拡充していきます。そしてサービサーとしての認知度を上げていきます。

弊社の強みは、外部のSaaS/PaaSとの連携実績が多数あることです。そこに弊社の価値を打ち出し、アピールしていきます。

今年11月にはCybozu Daysが開催されることが発表されています。
そこに焦点を当て、当日は新規サービスをベースにブースを出展する事を目指します。
別紙に書いた案件が該当します。

3.評価制度・賃金テーブル・人事計画

弊社の業務を再構築した結果を基準にし、もう一度弊社の経営計画を作り直します。そこには評価制度・賃金テーブル・人事計画のそれぞれを改定し、盛り込みます。

すでに作成したビジョン・ミッション・バリューや人材育成や課題に加え、5年先の財務計画や人員構成計画や、評価制度・賃金テーブル・人事計画も全て作り直します。

弊社は、そもそもKPI(重要業績評価指標)設定が全くできていませんでした。評価制度以前の問題です。そのため、何を目標とし、個々のメンバーは何をすれば達成感や成長を感じられるのかがあいまいになっていました。
メンバーのモチベーションが極めて持ちにくい状態になっていた状態を改善します。

今年からは人事評価について、アクアビット蒸留書に書かれた内容をベースに考えていきます。
アクアビット蒸留書の中では、KPIの設定とその基準について詳しく決めていきます。

もちろん、決めていくにあたっては引き続き外部の力が必要です。ただし、自社で決めていくしかない事も分かっています。

4.コミュニティ・出展

コミュニティへの関与やCybozu Daysをはじめとした展示会への出展は弊社にとって大きなアピールの機会です。

今年のCybozu Daysの開催日は11月7-8に決まっています。今年も弊社は出展する予定です。
出展にあたっては、弊社の役員や経理人事担当が企画から当日まで積極的に関わります。また、代表の私も企画や出展までの準備を任せきりにせず、社運を賭けて準備にあたるつもりです。そのため、ここ数年のやり方を変え、自社のみで出展する事を念頭に準備にあたります。

出展にあたっては、上に書いた五つに分けた弊社業務のうち、新サービスをメインに打ち出します。また、代表の私のネームバリューは最大限に利用する予定です。

代表の私のネームバリューを有効に活かすためにも、代表のコミュニティへの関与の頻度を上げていきます。登壇回数は25回を目標にしますし、それも5分程度のLTではなく、より長尺(20-60分)の登壇についての回数で25回を目指します。
そのためにも、自ら積極的に登壇の機会を増やします。今までのように頼まれたり、依頼を受けたりした後に動き出す受け身の登壇ではなく、積極的に登壇機会を作ります。
また、地方でのセミナーや勉強会出席も引き続けます。

昨年の師走に弊社は山梨で独自イベント二つの創出に関わりました。そのうちの一つは弊社主催です。今年もすでに栃木でのkintone Café開設に関わっています。それだけにとどまらず、コミュニティの創出にさらに関わっていきます。

また、役員の妻が地域クラウド交流会(ちいクラ)のオーガナイザーとして山梨での開催を準備しています。
各地で開催されるちいクラにもなるべく代表の私も参加するようにします。それによってkintoneエコシステムの一員として貢献し、認知度も上げます。

また、各地の地域創生や活性化にも関わる予定です。
今までは単なる参加者でしたが、今年からは違う関わり方を模索します。

まずは一月の城崎と糸魚川から。
そして、一月の戸田市での新年会での展示から始めていきます。

5.ビジョン・ミッション・バリュー

代表の私の拡大・新規志向と、メンバーの会社や仕事に対するモチベーションの違いを埋めるため、もう一度弊社の目指す方向性を定めます。

企業理念

「一期一会の儲けよりお互いが継続して協業できる幸せを
最新技術をお客様、地域に提供し、メンバー、家族、パートナーと輪になって幸せになる」

・うそはつかず、でも失敗は認める会社であるべきです。

目標

「2027年3月までに
・正社員8名 外注パートナー10名に
・社員一人当たりの粗利を 150万円に
・サイボウズパートナーの賞を受賞
・他SaaS/PaaSでももう一つ今のkintone並みの知名度を得る」

価値

①システムを継続してもらえる品質と対応を行います
②技術に偏らず、お客様ビジネスの現場を尊重します
③経営を継続するための自社サービスを生み出します
④社員・協力社・技術者・家族の事を大切に考えます
⑤顧客とともに一期一会でない継続の関係を築きます
⑥技術の進化に先手を打ちながら、自社も進化します
⑦世の中の働き方改革に貢献する手本となり続けます
⑧地域の非営利組織・団体のために技術で貢献します

上記に書いた内容のうち、目標と価値はあまりいじりません。ただ、企業理念と経営理念はもう少し練り直します。
また、それらを基にしたより具体的な経営計画をこの正月に作り込む予定です。

6.ワークライフバランス

代表の私の拡大・新規志向と、メンバーの会社や仕事に対するモチベーションの違いを埋めるためにもう一つ必要なのはワークライフバランスへの考え方を整理することです。

公私の充実を両立させたいとする私の価値観はいささかも揺らぎません。
ただ、昨年は残念ながら私の日常は全て仕事にとられてしまいました。それは誰の責任でもなく、私の招いた因果です。

弊社のメンバーには無理な残業や休日の仕事はさせずに済んだはずです。ただ、それでもストレスを感じさせてしまったとすれば、それが今の働き方の標準なのでしょう。
昭和どころか、平成に若手だった私の働き方すら、今の若い人から見ると異次元であることを認めます。

ただ、私自身が仕事の苦しさや経営の辛さに負け、会社の統制を強化したり、ブラックな働き方をメンバーに強いたりすることは厳に慎まねばと自戒しています。
案件をどれだけ受けてもこなせるだけの仕組み作り。これが今までの弊社に欠けていました。仕組み作りをきちんと整備し、代表の私も含めてワークとライフのバランスがとれるようにします。
先ず隗より始めよ。その言葉通り、私から率先してワークライフバランスを整えます。

私のワークライフバランスが整うときは、弊社の経営も軌道に乗った証しです。

7.事業継続のためのその他の施策

経営を継続させるため、BCP計画(事業継続計画)も定めます。
ちょうど本稿を書いている最中、元旦に能登で震度七の地震が発生しました。
弊社も富士山噴火や首都圏直下型地震が起こった時に備えておかなければなりません。

事業を継続するための山梨に拠点を設ける計画も今年中にはめどがつくはずです。

もう一つ必要な施策は、発信を継続的に行うのが代表のみであることです。それは弊社の弱点だと認識しています。
個人商店ではなく、会社としてのアクアビットのためには、代表以外にも定期的に発信を行う必要があります。
弊社メンバーも思い立った時はイベントの時には発信をしてくれます。ですが、それをもっと自発的かつ随時やってもらうように働きかけます。

8.個人的な抱負

ここからは6.で触れたとおり、個人的な抱負を書きます。
私は遠方に出張することによって、旅への欲求を満たしてしまうきらいがあります。そして、ワークライフバランス目標への飢餓感が薄れてしまう可能性があります。そのため、プライベートの目標をこの場できちんと書こうと思います。
2023年は個人的な目標をどこにも書かなかったことが失敗の原因の一つでした。

以下に書くのは代表の私の個人的な抱負です。
・家族で宮崎と鹿児島に旅行します。これをもって全47都道府県を制覇します。
・今年は結婚25周年ですので、家族でハワイに行きます。
・次女の彼氏のご両親に挨拶するため、韓国にも行く予定です。
・私自身の個人としてのアピールポイントをkintoneエバンジェリスト以外にも打ち出します。
 ・ウイスキー検定二級合格です。三級に受かってから数年間、ほったらかしになっているので酒知識を貯めます。
 ・もう一つ、新たな趣味も作ります。そのためには苦手意識のある習い事に通って師匠に付くことも厭いません。
・共同著者でもよいので、今年は本の出版のための具体的な一歩を踏み出します。
・訪れる場所や読んだ本や観た映画の数は、昨年と同程度をめざします。

ただ、そのワークライフバランスの実現は、アクアビットの経営が継続できるための基盤を確立してこそです。
私のワークライフバランスが整うときは、弊社の経営も軌道に乗った証しです。
そのバロメーターとして個人的な抱負の達成を目指します。

上記、1ー8までが2024年の抱負です。
ガイドライン(アクアビット蒸留書)を整理し、そのためにも弊社の業務を五つに分割します。ビジョン・ミッション・バリューも定め、コミュニティや出展の目標も掲げました。これらを実現させるために今年一年、懸命に努力します。

これらが実現した暁には、弊社の経営は好転するはずです。

ただし、それまでにも決めるべき事、やるべきことはたくさんあります。

ですが、今はAIがあります。
弊社でも使っていますし、サービス運営者やAIの開発者とも密につながっています。
AI元年に遅れをとらないよう、抜かりなく準備を進めていきます。


kintoneで詰まった時の問題解決



kintone Advent Calendar 2023
の21日目の記事です。

  Topへ↓

皆さん、kintone使ってますか!?

このページをご覧になっていると言う事は使っているはずですよね。

ユーザーとして利用する方、業務改善の道具として使う方、開発者として沼っている方、メシの種にしている方。それぞれだと思います。

システム開発に共通ですが、kintoneを使っていると、なんでや?と言うはまりポイントがあります。そのはまり方と、そこからの抜け出し方について、先日二つほど良い事例に出会いしました。
なお、本稿の内容は技術者として豊富な経験を積んでいらっしゃる方にはたわいもないものかもしれません。
が、システム開発に携わるのがkintoneが初めて、という方もいらっしゃるはず。そういう方向けに本稿を書いてみました。

2.cli-kintoneではまる問題

  Topへ↑

一つ目の事例はcli-kintoneです。
皆さん、cli-kintoneは使ってますか?
コマンドラインからkintoneのデータを任意の場所に出力できます。添付ファイルも。
また、任意の場所のcsvファイルをkintoneにインポートもできます。もちろん更新も。
バッチ処理もできるのでとても重宝します。
cli-kintoneサイト

普通の環境であれば、cli-kintoneはすぐに使えるはずです。

が、とあるお客様の環境では、これが全くつながらなかったんです。
このようなエラーに弾かれていました。


[2023-12-01T09:00:00.000Z] ERROR: error: Client network socket disconnected before secure TLS connection was established


[2023-12-01T09:00:00.000Z] ERROR: AxiosError: maxContentLength size of Infinity exceeded


[2023-12-01T09:00:00.000Z] ERROR: error: 403: Forbidden


[2023-12-01T09:00:00.000Z] ERROR: error: unable to verify the first certificate

そのお客様の環境は、ビルから外に出る通信はまず設置されたファイアウォールによって制限されます。さらにインターネットを経由する通信は離れた場所にある情報センターを必ず通ります。そこではProxyサーバーが設置されています。
kintoneにはBasic認証、id/pw認証に加え、ipアドレス認証またはセキュアアクセスも使っています。要するに厳重な防備が敷かれているのです。

これらのパラメーターの値を変更することで、上記のエラーは変わります。

こういう場合、通常ならば情報センターに問い合わせをします。エラーになった時間帯のパケットの調査を依頼し、何の設定値がおかしいのか、何がパケットの通信を阻害しているのか。
端末からkintoneサーバーまでとその逆の通信経路を追っかけます。

ところが、膨大なパケットを日々扱っている情報センターに対し、ログを取って欲しいと安易に調査依頼をすることはできません。
かといってこちら側のエラーメッセージも原因を追求するにはあまりにも不十分なものです。コマンドプロンプトからpingコマンドやtracertコマンドやnslookupコマンドを打っても根本的な解決にはなりません。
そのため、解消にかなりの時間をかけました。五里霧中を歩むがごとき。

3.問題解決のケース1

  Topへ↑

この時に私が採った問題解決手法は総当たりです。
問題解決の手法では山登り法と呼ばれるものに近いかもしれません。

cli-kintoneにはたくさんのオプションが設定できます。ユーザー認証情報、basic認証情報、proxy設定情報、証明書情報。
それらを全パターンの組み合わせで調べ、どの組み合わせパターンだとうまくいがないかを一つ一つ潰しました。
もちろん、そもそもの設定値が間違っているとつながらないので、それらは可能な限り知見を持つ方に事前に聞きました。

その甲斐あって、無事にcli-kintoneで接続に成功しました。

ただ、ここで言っておくべきは無闇矢鱈に試したわけではないことです。
上に書いた通り、cli-kintoneの公式サイトには接続にあたってのオプションが全て載っています。(–helpオプションに出てくるコマンドのうち先頭の二つはサイトには載っていませんが)

つまり、最初から試すべきパターンの上限枠は用意されているのです。後はこれらに基づいて組み合わせを試すだけ。

こうした総当たりを試すしかないパターンは、システム開発ではたまに起きます。
もし、五里霧中でどうしようもなくなった時も、ありうる組み合わせを全て試せば、必ず答えがあります。

総当たりを試す場合の判断基準は以下のとおりです。
・有識者から正しい設定情報を入手できること。
・パターンの上限を見定め、実行可能であること。
・自らのリソースで実行可能であること。
・システムに負荷がかからないこと。
・失敗によるデータ破損紛失の恐れがないこと。

それらが満たせれば、あとは根気よくパターンを試すのみです。

kintoneはプラットフォームです。幸いなことによほどのことがない限り壊れません。安心して試してください。
そして、kintoneもcli-kintoneもきちんとテストされた上でリリースされています。
設定値さえ正しければ、必ず何かのオプションで状況が打開できるはずです。
ぜひ頑張ってください。

ここでの問題解決の方法は、
・有識者から正しい設定情報を入手する。 ・・・正しい情報
・パターンの上限を見定める。 ・・・解決手段の見積
・システム負荷、データ破損を防ぐ。 ・・・影響範囲の確定

4.kMailerではまる問題

  Topへ↑

続いて二つ目の事例は上の件と同じ日に問題解決しました。kMailerについてです。

トヨクモさんのkMailerはkintoneからメールを送ることのできるサービスです。
メールテンプレートアプリを設置し、メール履歴アプリを設置し、アドレス帳アプリを設置します。

メールテンプレートアプリや送信履歴アプリ、ログアプリはトヨクモさんがテンプレートを用意してくださっています。
テンプレートアプリについて

あとはそれらをkmailer専用の管理画面から設定し、生成されたJavaScriptをkintoneのアドレス帳アプリに組み込むだけ。

メールテンプレートアプリは、各レコードにメールのテンプレートを保存できます。
メール送信画面で、設定したメールテンプレートを呼び出し、必要に応じて手を加えれば、アドレス帳のレコードに応じた送信先にメールが送信されます。アドレス帳アプリの任意の項目の値をにタイトルや文面に差し込むこともできます。
とても便利なサービスです。

製品サイト

お客様が送りたいメールはビジュアルを整えた形。クリスマスメールが送りたいの!
当然、メール内には季節感あふれる画像も添付します。つまり、HTMLメールです。

メールテンプレートを設定する際も、HTMLメールを前提にビジュアルを整えたい。それは当然ですよね!

ところが、トヨクモさんにご用意いただいたメールテンプレートアプリの中にある本文を格納するフィールドは<文字列複数行>フィールドです。
<文字列複数行>フィールドだと、見栄えが整えられません。そこで私はフィールドコードを変更した上で本文を<リッチテキスト>フィールドに格納するように変更しました。

これにより、お客様がメールテンプレートアプリで見栄えを整えられるようにしました。あとはメール送信画面からテンプレートを呼び出し、必要に応じて微調整を行ってもらえます。
お客様のご要望を満たせてばっちり!

・・・とは、いきませんでした。

まず、一つ目の問題。

お客様のご要望は、ビジュアルのメール本文に画像を含める事でした。
ところが、kintone上の画面上では画像が添付できるのに、保存すると画像が消えてしまいます。<リッチテキスト>フィールドを普段使っていない私の無知がばれてしまいました。
ということは、お客様は毎回メール送信画面上で画像を添付し直さなければなりません。これは大変。

しかもテストメールを送ってみたところ、添付されている画像の代わりにエンコードされた文字列が延々と連なっています。
いやぁぁぁぁぁぁぁ!!もはやホラーです。

ホラー以前にそもそもメールとしての根本からあり得ない状態です。それでいながら、宛先によってはきちんと画像付きのメールが送信できているのが謎。

二つ目の問題は、項目の差し込み機能がうまく動かないことが発覚したことです。
メール送信画面ではアドレス帳アプリの任意の項目を画面から差し込めます。
項目を差し込むことによって同じ文面のメールを送っても、差し込み項目の値に応じてメールの文面は変わります。名前とか。
差し込み機能は多くのお客様にメールを送信するお客様にとっては欠かせない機能。ところが、この差し込み機能がうまく動かなかったのです。

メール送信画面上で差し込み設定するときちんとレコードの値が差し込まれるのに、メールテンプレートアプリから持ってきた本文の差し込み設定が効かず、メールのプレビューにはカッコつきのまま表示されてしまうのです。
{{姓}} {{名}} 様
のような感じで。

これだと、メールテンプレートアプリが活用できません。そして、お客様は毎回メール送信画面から差し込み設定と画像添付設定をし直さなければならない。これは問題です。

5.問題解決のケース2

  Topへ↑

この疑問をXにポストしてみたところ、トヨクモのとある方が拾ってくださいました(感謝!!)。そしてしばらくやりとりさせてもらいました。すると、理由が解決しました。
要するに、私がメールテンプレートアプリ上で本文を格納するフィールドを<文字列複数行>から<リッチテキスト>に変えたことが一連の不具合の理由のようです。

私の失敗としては、以下の文章を読み逃していたことです。
「メールテンプレートアプリは、アプリテンプレートの構成のまま利用することを想定しており、変更を加えた場合の挙動は保証しておりません」
ちゃんと書かれてる! 私がここを見逃していたことが全ての敗因でした。

なお、一連の不具合については、メールテンプレートアプリの本文を格納するフィールドを<文字列複数行>にもどしたことで解消しました。

ただし、まだ問題が残りました。
それは、メールテンプレートアプリにビジュアルのメールを設定できなければ、お客様の効率が著しく落ちる点です。

お客様はHTMLタグが分かりません。そのため、お客様によるメールテンプレートの設定は不可能です。
また、kMailerの「ホーム > メールテンプレート一覧」からはHTMLプレビューも可能です。が、お客様にはできる限りkintone内で完結していただきたいと思うのは人のサガ。
送信予約を見るときはkMailerを使わざるを得ないとしても、kintone側でメールテンプレート作成から送信先のレコード抽出、メール送信までを一気通貫でやり切りたい!

そこで、今回は、私の方でメールテンプレートアプリのレコードを保存したタイミングで、
<リッチテキスト>フィールドの内容を<文字列複数行>フィールドにHTMLタグ付で転記するJavaScriptを作りました。

それによって、お客様がビジュアルのメールをご自身で構築できるようになりました。

また、画像についてはレイアウトがだいたい決まっていました。そのため、オンラインストレージ上に該当する画像を格納してもらい、メールテンプレートアプリの本文の <img src=””> タグにそのurlを設定することで解決しました。
このファイル名は常に同じにしてもらうか、または、下図のようにメールテンプレートアプリのリンク項目を入力してもらうようお客様に依頼しました。ストレージから得られた共有urlはそのままでは使えないため、変更してもらうための注記を加えた上で。

まずは無事にクリスマスメールが送れそうです。よかったよかった。

さて、反省しなければ。
私の反省は、
・kMailerのサイトを熟読していなかった。
・予断に基づいた構築に走っていた。
・kintoneの柔軟性を過信していた。
でしょうか。

ここでの問題解決の方法は、
・基礎となる情報ソースを読み返す。  ・・・基礎情報の重視
・自らの予断を見直す。  ・・・認知バイアスの修正
・有識者からの助言を得る。 ・・・多面的な視野

この3点です。

6.kintoneで一度開発してみてください

  Topへ↑

他にも、kintoneでトラブるケースはたくさんあります。
・ユーザーの要望をまとめないままに実装に走ってしまい、ヒアリング不足で変更・追加要望が土壇場で相次ぐ。
・kintoneの性能を甘く見積もっていて、特定の端末でしか限界値テストをせず、本番でトラブる。
・ユーザーの要望に対して過度なカスタマイズをしてしまい、あとで自分の首が絞まる。

どれもが、かつてやってしまったことのある失敗です。
全て、ひいひい泣きむせびながらリカバリーしました。汗顔のいたりです。

ですが、これからkintone開発に入っていただく方は、安心してください。
kintoneはプラットフォーム上で動きます。自分でハードウエアや基盤を用意する必要がないのがkintoneの良さ。簡単には壊れません。いろいろと試して、経験値をためていける環境がすでに用意されているのです。
ただし、ドキュメントはきちんと読んでくださいね。

さらには、システム構築の思考フレームワークというべき「kintone SIGNPOST」もあります。
kintone SIGNPOSTページ
この考えはkintoneだけでなく、既存のシステム開発でも活かせます。システムが無縁でも業務改善に役立ちます。

また、なんといってもkintoneには多くの開発者やユーザーがいます。そうした方々が豊富な知見を日々あちこちでアップしてくださっています。つぶやきで動画でブログでセミナーでユーザー会で。
たまに、この記事のようにしくじり先生よろしく失敗談を書いてくれる人もいます。

ぜひ、kintoneを使って業務改善の当事者として、システム開発の当事者として楽しさを味わってください!


事例:三宝興隆会様


会員管理の基盤をkintone中心とした構成に変更

  Topへ↓

三宝興隆会様は、宗教法人・三宝禅に関わる、または三宝禅に直接管理される全ての活動を支援運営する任意団体です。
宗教法人三宝禅は70年以上前から活動を開始しており、禅の精神を世界に伝えるためにさまざまな活動を行っておられます。

日本を発祥とした団体であり、昨今の世界中への禅の広まりによって、世界各国に会員を抱えておられます。その広がりはアジアだけでなくヨーロッパ諸国にも。
今の人類の悩める状況を禅の精神をあまねく広め、人々の悩みに寄り添う。その意思に賛同した世界各国の会員に向け、会報や書籍などによる活動を展開されておられます。

三宝興隆会様は、三宝禅の会員との会費徴収や連絡などを主な業務としていますが、世界各国に散在する会員との会費徴収に課題を抱えていました。
年会費が原則の会費ですが、途中で入会された方や、退会された方に対する月割りの会費徴収業務の煩雑さ。それが改善を要する課題でした。
会員管理にはMicrosoft Accessで作成したデータベースをお使いでしたが、メンテナンス担当の方が年配になっていたことやクラウド連携の必要性など、今後の保守に不安が生じていました。そこでkintoneの導入を判断されました。

正直にいうと、構築までに難航し、予定よりも時間がかかってしまい、ご迷惑をかけてしまいました。
その反省も踏まえて弊社の事例として投稿したいと思います。

kintoneを中心とした構成

  Topへ↑

最初にご連絡をいただいたのは2020年の12月です。代表がちょうどCybozu Days 2020 Osakaに登壇するため大阪に出張に行っていた時期だったので記憶に鮮やかです。

ご連絡いただいた時点で、御担当の山田様の脳裏には全体の構成についてのある程度明確な方針が定まっていました。
・kintoneで全世界の会員名簿を管理する。
・WordPressで会員向けページおよび、入金用のページを実装する。
・入金用のページにはStripeを使った決済処理を表示させ、Stripeに処理を任せることで堅固な決済処理を実現する。

あとは会計処理です。それについては弊社より会計freeeをご提案しました。
会員より会費の入金があった場合の仕訳はfreee側に自動的に登録するように実装すれば、会計処理も運用が回るはず。

freeeとStripeはSaaSです。PaaSのkintoneとはRest APIで手軽に連携できるはず。
特にkintoneと親和性の高いfreeeは弊社代表がオンラインハンズオンの講師も務めたことがあり、連携も簡単に実現できるはず。
そこまでできればあとはWordPress内にkintoneから値を表示させ、Stripeの入金画面を表示させるだけで実装は可能。
そう判断して着手しました。

MemberPressとStripeの仕様理解に苦しむ

  Topへ↑

ところが、これがとても難航しました。

2020年の12月。初めにご連絡をいただいた際、弊社は翌年の1月に初めてのメンバー二人の雇用を控えていました。
二人のメンバーのうち一人がWordPressに明るいとのことだったので、実装を任せることにしました。

まず、つまずいたのはMemberPressの理解です。
WordPressはCMS(Contents Management System)です。
その拡張機能は多岐にわたりますが、MemberPressはその一つです。
会員管理や会費納入状況によるコンテンツの表示制御ができるため、海外では比較的導入実績があるようです。

ところが、MemberPressはあまり国内で使われていなかったのか、日本語のドキュメントが少なく、有用な情報が見つけられません。
そこでまず、そもそもの機能の理解に手間取ってしまいました。機能の説明を一生懸命理解しようと努めましたが、言葉の微妙なニュアンスがくみ取れず、この機能や処理の制御がどのようになっているのかあいまいなままでした。
機能の理解がおぼつかない上に、APIのレファレンスやサンプルもすべて英語です。その微妙な機能の制御の理解がまったく進まず、ただ時間だけが過ぎていきました。

Stripeも弊社にとっては初挑戦です。
Stripeもドキュメントの多くが英語です。レファレンスはまだわかりやすかったのですが、テスト用の環境と本番用の環境が別だったため、環境構築やテストの実施などに紆余曲折がありました。

初めに任せていたメンバーは、頑張って実装に向けた作業を行ってくれました。
WordPressのログイン制御など、MemberPressだけで実現できない部分も実装してくれました。

が、時間はあっという間に過ぎていきます。
そうこうしているうちに、そのメンバーはCybozu Days出展を巡る価値観の違いもあって退職してしまいました。

初めて雇用に踏み切った代表にとっても挫折に苦しんだ時期でした。

メンバー交代で実装が前進する

  Topへ↑

メンバーの退職の少し前から、開発の遅れは顕著になっていました。
ところが当初の山田様のご要望では、2021年の年末にはリリースしたいとのことでした。その理由は、会費徴収の切り替わりのタイミングです。年末だと切りがよいので、この時までに実装したいとのことでした。

ところが、この時点で実装は間に合わないことが明らかでした。
そこで、弊社に専任で関わってもらっている技術顧問に実装に入ってもらいました。

そして、11月末でメンバーが退職してからは、弊社の技術顧問がバリバリと実装を進めてくれました。

引き継いだ時点で退職したメンバーががんばって仕様の理解を進めてくれていました。それもあって、MemberPressやStripeの仕様の理解も進み、実装のめどがみえました。

さらにはWordPressに表示する文字列もシステムによって切り替える部分を簡単に切り替えられるような仕組みも実装できました。

ただし、年末には間に合わず、運用は後回しをお願いしました。
ご迷惑をお掛けしてしまいました。

なお、kintoneについては早い時期に実装は終えており、
こちらについてはあまり修正の必要がありませんでした。
この時、WordPressのデータベースを使わずにkintoneを使う実装にしていたことが、
データベースを整備する手間を省いてくれました。

会費のほかにも寄付金の入金もできるように

  Topへ↑

連携のほとんどはphpを使っています。
kintoneで処理が行われればWebhookでMemberPress(=WordPress)にユーザーを作成すると同時に、Stripeにもアカウントを作成し、さらにfreeeの取引先にもデータを追加します。
WordPress内で入金処理が行われれば、StripeのWebhookを通してfreeeに仕訳登録の処理を行い、kintoneにもその旨の情報を更新します。

それらの仕組みのほとんどは2021年の年末までに実装にめどをつけ、年明けからテストに入りました。
その結果、2月頭には本番環境にプログラムをリリースできました。
なお、山田様と弊社のやりとりは全てオンラインで完結しました。一度もお会いしていません。コロナの中だからこそ、このような複雑な実装がオンラインだけで実現できたことでも
印象に残っています。

結果、今回の一連の仕組みについては、
このような連携となっています。

その後、追加で機能の拡充のご要望もいただきました。
会費だけでなく、任意の金額の寄付金も入金できるようにする機能です。
そちらも無事に納品ができました。

とはいえ、反省点は無数にあります。
今回の遅れについてはメンバーのアサインや指導方法など、ありとあらゆるところで代表である私に非があります。
任せるべきところとフォローすべきところのツボがずれていたこと、英語のドキュメントを通した仕様理解についての見通しが甘かったことです。

あらためて、遅れてしまったことについては三宝興隆会様にはおわびします。
そして、それにもかかわらず事例記事のアップのご快諾をいただいたことに感謝を申しあげます。ありがとうございました。

今後の展開

  Topへ↑

これからも会費徴収や税処理、経理処理にあたっての国の制度変更もあり、
改修は発生するとみています。

まずは、現時点で運用に乗っていることに油断せずに行きたいと思います。

そして、弊社にとっても貴重な経験値が得られた結果を無駄にせぬよう、
StripeやMemberPressとkintoneやfreeeとの連携に向けたご要望に対応できるようにしたいと思います。

まとめ

弊社にとって三宝興隆会様はkintoneとStripeやMemberPressの連携など、英語ドキュメントとの戦いでした。これはとても貴重な経験値となりました。それもあってとても印象に残っています。

まずは今後の運用も油断せずにいきたいと考えています。ありがとうございました。

三宝興隆会様のご紹介

名前 三宝興隆会
ウェブサイト http://www.sanbo-zen.org/

スマレジアプリコンテストで佳作をいただきました


弊社の応募した「チェアサイドレジ」が第二回スマレジアプリコンテストで佳作をいただきました。
まずはこのような機会を作っていただいた上に、受賞の栄誉までくださったスマレジ社の皆様と審査員の先生方に御礼を申し上げます。

今回、応募したきっかけ。それは、昨年11/26に行われた「スマレジDevelopers Day」への参加でした。コロナでオンラインイベントが続く中、Cybozu Daysを除けば久しぶりのリアルイベントがこの「スマレジDevelopers Day」でした。(サイト)
会場では、第一回のスマレジアプリコンテストのグランプリ受賞者である大幸パートナーズさんが登壇されました。アプリ受賞にあたっての苦労など、スマレジアプリの作成にあたってのノウハウが聞けました。また、主催のスマレジ社からは、スマレジアプリストアの目的や意義についてのお話がありました。その中には、技術者にとってオープンな場を作りたいとの思いがこもっていました。


この中で、第二回スマレジアプリコンテストの募集要項も発表されました。
大幸パートナーズさんの受賞アプリであるcleeeanで実現した機能に感心し、スマレジアプリの仕組みにうなずく私。
その時、私の中にひらめきが降りてきました。
「これ、うちのココデンでも入れられるんちゃう?」と。
矯正歯科にスマレジを導入し、それをkintoneとつなぐ。その場でアプリの連携や構成が頭の中であらかた組み上げられてしまいました。

この頃、私の精神状態は結構参っていました。
それはCybozu Days 2021の出展によって弊社のメンバーと私の価値にずれが発覚したためでした。
人を雇うことの難しさ、経営の奥深さ。
Cybozu Daysではあえて私は経営者として裏方に徹しました。出展するコンテンツの開発も弊社メンバーか協力会社の技術者に委ねました。皆さんの頑張りもあって、Cybozu Daysでは並み居るブースの中で一定の存在感は出せました。成果はあったと思います。

その一方で、Cybozu Daysでは自分の技術者としての証しを封印してまで経営者に徹しようとしたのに、経営者としての能力に自信をなくしてしまった自分がいました。
このまま技術者として衰えていってもよいのか。自己研鑽はしなくても良いのか。技術者としてコンテンツを作る気概は残っていないのか。そんな葛藤と向き合う日々でした。

悩む日々の中で、自分の技術者・経営者としての長所や短所を見直しました。
見直す中で長所に挙がったこと。それは、私の妻が10年前から矯正歯科医院、ココデンこと、ココデンタルクリニックを経営していることです。
世の中には多くの技術者がいます。ですが、妻が歯科医で診療所を経営している技術者はあまりいないはず。その点、私は他の技術者に比べて恵まれているのかもしれません。

ココデンの開業や経営にあたっては、かなりの苦しみと苦労と試練がありました。私は妻の苦労をすぐそばで見ていました。また、歯科経営が家計に与える苦しみを共有しました。
ところが私がココデンの開院にあたって担った作業は、LINE/Facebookページの開設や初代のホームページ作成のみです。診療所のシステムに関する領域には一切関わりませんでした。
なぜ関わらなかったのか。それは、当初の開院時から電子カルテのシステムが業者によって導入されていたからです。それはスタンドアローンのサーバーで動いていました。ですが、アナログな妻はシステムを患者さんの口内写真の保存のみにしか使っていませんでした。
受付も雇っていないため、全ての業務は、妻がワンオペかつアナログ作業で回していました。
患者さんの診断カルテは手書き。支払い授受も現金による手渡し、またはCAFIS端末を利用したクレジットカード決済。
つまり、ココデンにはシステムを導入する余地がなく、私が関わる余地もなかったのです。

開院以来10年、経営で十分に苦しみ、試行錯誤を重ねてきたおかげか、ここに来て患者さんがコンスタントに来るようになりました。少しずつ経営も好転する兆しが見えてきました。
それとともに、妻も年齢を重ねてきました。ワンオペをいつまでも続けるのはしんどい。今回の機会に思い切ってシステムを取り入れるよう、妻を説き伏せられるかもしれない。
また、経営者として反省する中で、自社サービスの開発が必要ではないか、と課題を感じていました。

「スマレジDevelopers Day」の会場で私の脳裏に湧いた着想とは、こんな感じでした。
自分一人で開発し、その成果をスマレジアプリコンテストに応募してみよう!

今年の正月の三日間は、休みを取らずにシカレジ(仮称)の企画や構想に充てました。
正月が明けても、わたしの中からスマレジアプリコンテストへの思いは去りません。
政府の統計情報が蓄積されているサイトを何度も訪問して統計情報を分析しました。図書館では分厚い統計情報の本のページを繰りました。本屋に行くたびに歯科経営の専門書コーナーで長い間立ち読みして知識を蓄えました。
そうした作業の甲斐があって、少しずつシカレジに必要な項目や連携すべき点、オペレーションで改善すべき点について学ぶことができました。
もちろん妻にはどういう項目が必要かを聞きました。受付の運用なども見聞しました。また、妻の弟が埼玉県で歯科医院を経営しているので、訪問して電子カルテシステムの内容を見せてもらいました。

こうした作業から感じたのは、今まで私が有利な立場を活かしていなかったことです。目の前に歯科経営の教材があり、それを技術者・経営者としての糧にできたはずなのに、何の成果も得ていなかったこと。私はとてももったいない日々を過ごしていました。

1月はそんな風に過ぎていきました。開発にも取り掛かっていて、kintone内部やスマレジとの連携はうまく行きそう。
そんな中、1月の半ばにスマレジ社のご担当者様からいただいたのは、患者さん向けの情報ページをLINE ミニアプリで実装してみないかというお話です。
さらに、妻からはシカレジはダサいから、名前をチェアサイドレジに変えたほうがいいんじゃない?という提案まで。

ここでシカレジ、あらためチェアサイドレジについて概要を説明します。

チェアサイドレジの中で、患者さんが診療情報を確認する手段として私が考えていたのは、ウェブサーバーに認証付のページをおくことでした。
CMSでページを構築し、それをkintoneやスマレジと連動する。それらを連携する開発は経験済みなので可能。それが私の当初の目論見でした。
ところが、ここでLINEミニアプリという提案が登場します。私は、この時にご提案をいただくまでLINEミニアプリのことを全く知りませんでした。そもそもLINEと連動させるシステムすら全くご縁がなく、未経験でした。
でも、LINEのユーザー認証を取り入れられれば、セキュリティはさらに強化できそうです。セキュリティだけが弱いと感じていたので。残り時間は少ないけれど、チャレンジしてみよう、と決断しました。

ところが間の悪いことに、1月の末頃から本業の方で案件の引き合いを連日のようにいただくようになりました。
案件が来ると私が対応しなければなりません。要件定義やヒアリング、さらには上流工程などの調整。一方では既存の案件のコーディングの指導や指示を弊社メンバーに行います。案件の難易度によっては私が手を動かす必要が生じます。その合間には機密保持契約や基本契約の締結を行い、見積書や請求書の提示などの作業もこなします。もちろん経理業務や雑務も頻繁に発生します。それらが怒涛のように一気に押し寄せてきました。
私からチェアサイドレジに携わる時間が顕著に奪われていきます。

そのような案件の活況は、第二回スマレジアプリコンテストの締め切りの3月末どころか4月半ばまで続きました。
そのような状況に追われる中、私は正直、3月初旬の時点ではもう応募すらできまい、と半ばあきらめかけていました。
でも、気力を出し、わずかな合間に資料やアプリをまとめて応募にこぎつけられました。妻がロゴの原案を考え、イラストレーターの長女がそれをロゴデータにしてくれました。

受賞した時の思いは、この記事の中にも書いています。

率直に打ち明けると、「スマレジDevelopers Day」の時点で、私はヤマっ気を持っていました。
雇用やコロナ感染によって悪化してしまった財務状況を、スマレジアプリコンテストでグランプリをとることによって解消しようという欲。
ところが、案件の引き合いが増える中で、なんとか財務を持ち直すことに成功しつつありました。
そのため、4月の末にスマレジアプリコンテストで佳作を受賞したご連絡をもらった時、グランプリの1000万円を逃した悔しさはありませんでした。純粋にアプリが評価されたことへの感謝だけがありました。

5/26には第二回スマレジアプリコンテストの授賞式がありました。
最初のユーザーはココデンタルクリニック、つまり妻を予定しています。そのため、妻にはきちんとスマレジの仕組みを知ってもらう必要があります。そこで一緒に授賞式に来てもらいました。



授賞式は動画配信の予定があったのですが、機材のトラブルによって、私が登場するのは講評の部分からです。
ただし、妻が動画を撮影してくれていました。

なお、この時のスピーチで私は大したことを話していません。
むしろ、この後の座談会で話したことのほうが重要です。ただし、残念なことに動画は残っていません。
座談会では、各社さんの応募したアプリの工夫や思いも伺えました。また、店舗に訴求するスマレジの可能性を感じました。店舗オペレーションに特化したスマレジをkintoneが補完できる可能性も含めて。
弊社の価値は、kintoneの中だけに閉じていては発揮できません。kintoneをベースにした、他のPaaS/SaaSと連携するところにあると確信しています。

まだまだチェアサイドレジには直すべきところが残っています。それはこの記事でも書いた通りです。
これは私が引き続き開発していきます。自分でやるべきタスクだと思っています。
上に書いた通り、私自身に技術者としての可能性が尽きていないことの証し。それがこのチェアサイドレジだと信じているからです。

そして、弊社の将来のことを考えると、自社サービスの展開にチャレンジし経験を積んでおくことは、将来への布石としてやらなければいけないことももちろんです。

それらも含めて弊社にとってはとても重要な受賞だったと思います。
あらためて授賞式に来てくださった方、皆様、スマレジ社、審査員の皆様、ありがとうございました。


リモートチームでうまくいく


著者の名前は今までも、さまざまなインタビューやネットニュースなどで拝見してきた。著者が経営するソニックガーデン社の取り組み事例として。
著者の登場する記事の多くはCybozu社に絡んでいることが多い。
そういえば、一時期、私と同じくkintoneのエバンジェリストだった方もソニックガーデン社の社員だった。
それもあって著者やソニックガーデン社のことは前から気になっていた。

著者やソニックガーデン社が唱える理念には、共感する部分が多い。
本書の前に著者が出版した『「納品」をなくせばうまくいく』は、私の心を動かした。
情報処理業界で生計を立てるものにとって、納品という営みはついて回る。それをあっさりとやめようと宣言する著者の言葉は、私を驚かせてくれたし、共感もできた。
システム業界にとって納品という商慣習は常識だった。だが、それはもはや非合理な商慣習ではないのか。そう考えていた人はいたかもしれないが、実際に行動に移す会社がどれだけあるだろう。

本書はそんな著者がリモートワークの要諦を語ってくれるというのだ。書店で手に取り、購入した。

弊社はもともと、リモートワークを実施している。
私自身はほぼリモートワークの体制で仕事を行っている。
だから、本書を買わなくてもリモートワークの本質はつかんでいるつもりだ。ではなぜ、本書を購入したのか。
それは、私の役目がプレーヤーから経営者に変わったからだ。

私はリモートワークの全てを自分の中に言葉として血肉にできていない。
それは私がプレーヤーであり続けてきたからだ。だから、私がいくらリモートワークの効能を人に勧めても説得力に欠ける。
だが、そろそろ外部の協力技術者も含めたリモートワークの体制を作ることを考えなければ。

弊社として、今後もリモートワークでいくことは間違いない。
そのため、経営者としてリモートワークを技術者にお願いする必要に駆られるだろう。その時の裏付けを本書に求めた。本書を読み、より一層の論理武装をしたいと思った。

私がやっているリモートワークとはしょせんプレーヤーのリモートワークだ。私自身が築き上げてきた仕事スタイルでしかない。そう自覚していた。
こんごはリモートワークを管理する側としての経験や知見が求められる。
私がやっているリモートワークの管理とは、しょせんはリモートワーカー同士の連絡に過ぎない。リモートチームになりきれていない。
その構築のヒントを本書から得たかった。

本書を読んだ後、弊社は雇用に踏み切った。そこで私は監督者として立ち振る舞うことを求められた。
ところが、私はどうもリモートワークの監督者として未熟だったようだ。期待する生産性には遠く及ばなかった。

それはもちろん本書や著者の責任ではない。私が未熟だったことに尽きる。それを以下でいくつか本文と私の失敗を並列してみたいと思う。

「セルフマネジメントができる人たちで構成されたチームを作り上げることでリモートチームは成立するのであって、その逆ではありません。多くの企業において、リモートワークの導入を妨げているものは、リモートワークそのものではなく、その背景にあるマネジメントの考え方ではないでしょうか。」(118ページ)

セルフマネジメントができるとはつまり、技術力が一定のレベルに達していることが条件だ。技術があることが前提で、それを案件の内容や進捗度合いと見比べながら、適切にマネジメントしなければならない。残念ながら、その技術力の見極めと案件への振り分けにおいて失敗した。これは経営者として致命的なミスだったと思う。

「私たちの会社もROWE(完全結果志向の職場環境)をベースに考えています。私たちがアレンジしているのは、その成果とは個人の成果ではなく、チームの成果であるとする点です。」(136ページ)

弊社も私を中心としたハブ型ではなく、各メンバーが相互に連携する組織を考え、メンバーにもその意向を伝えていたつもりだった。だが、どうしてもハブ型の状況を抜け出せなかった。
残念ながらメンバーが一定程度の技術に達していないとこのやり方は難しいかもしれない。お互いが教え合えないからだ。いくつかの案件では成功もしかけたのだが。
もう一度チャレンジしたいと思う。

「監視されなければサボる人たち、監視されないと安心しない人たち、そんな人たちでチームを組んだところで、リモートチームは実現することはできませんし、そもそもそんな人たちがオフィスに集まったとしても、大した成果を上げることなどできないのではないでしょうか。」(173ページ)

これも完全に書かれている通りだ。ただ、私としては実際は働き具合がどうだったのか、今となっては確かめる術もないし、そのつもりもない。結果が全てだからだ。

「オンラインでは物理的な近さも遠さもないので、フラットに誰とでも絡むことができるからです。」(206ページ)

私が間違えたことの一つが、本書の中でも紹介されているRemottyのようなお互いの顔が見られるツールを導入しなかったことだ。それによって例えば雑談がオンライン上で産まれることもなかったし、日記や日報を書いて見せ合う環境も作りきれなかった。

「新人のリモートワークは“NG”」(177ページ)

外部の人に弊社の失敗事例を告げた時、真っ先に指摘されるのはこのことだろう。私がしでかした間違いの中でもわかりやすい失敗がこれだ。いきなりリモートワークで走り出してしまった。

私がしでかした失敗によって、本稿をアップする一週間前に一人のメンバーを手離してしまった。お互いが持つ大切にしたい考えやスキルのずれなど、もう少しケアできることがあったのに。とても反省している。

弊社の救いはまだメンバーが残っていることだ。もう一度このメンバーでリモートワークの関係を作っていきたいと思う。
私を含めた弊社のメンバーにリモートワークが時期尚早だったのは確かだ。ただ、まがりなりにも一年近くはリモートワークの体制を続けてこられた。なんといってもCybozu Days 2021は、弊社と弊社に近しいメンバーだけで無事に出展できたのだから。
今後も週二回程度はリアルの場を作りながら、もう一度リモートワークの環境を作っていきたいと思う。

なお、本書に書かれている社長ラジオは、毎朝のスラックでのブログアップとして続けている。これは私の考えを浸透させる意味では貢献してくれているはずだ。そう信じている。
本書に書かれていることで役に立つことは多い。

‘2020/05/29-2020/05/31


kintone Café JAPAN 2021でミッションに挑みました


11/13に催されたkintone Café JAPAN 2021は、全国のkintoneユーザーや技術者有志が集まるイベントです。有志によって運営されています。
毎回、さまざまな趣向をこらしたイベントが行われ、kintoneを愛する人々の知見と刺激と交流を生んでいます。

今回のJAPANでも複数のセッションが企画されていました。私は冒頭のセッション
Excelインポートミッション!君はこのトラップに気付けるか!?
のミッションに挑戦者として指名されました。技術者代表として。

このミッションの具体的な進行を私が運営者に教えてもらったのは、JAPANイベントが始まる30分前。
指令されたのは、Excelとkintoneを画面共有で皆さんに見せながら、その場でExcelに仕込まれた不正データを見抜き、データを整えた上でkintoneにインポートするミッション。

私にとって幸いだったことは、初っ端が私ではなかったことです。
最初の挑戦者であるキンスキ松井さんに課された10分間のミッション。これはまさにスリルに満ちていました。
頻発するエラーに四苦八苦される松井さんの姿を見ながら、私はミッションの雰囲気を把握することができました。


さて、私の出番です。私に割り当てられた時間は15分。技術者枠なのでさらに難易度はアップしています。
スタートの合図とともに、割り振られたスペース上のアプリとインポート対象のExcelを開きます。
すると、松井さんのミッションにはなかったルックアップやチェックボックスフィールドが加わっていました。さらには、Excel上での住所連結、氏名分割までも。
結局15分ではミッションをクリアできず、二回の延長をお願いして約20分を要してしまいました。
ただ、皆さんにはとても盛り上がってもらえたようです。Twitter上でたくさんの応援や感動したとのお褒めもいただきました。ありがとうございました。


このセッション、出た本人がいうのもなんですが、神企画だったと思います。
観覧されている皆さんにとっては、手に汗を握るスリルがあり、データをインポートする方法の知見がたまります。ミッションで使われるExcelのデータも一見それほど複雑ではないため、kintoneに触れて間もない方でも理解できる配慮がなされています。
さらに、ミッションを課された私にとっても、奔放なExcelデータをkintoneに取り込む経験がたまります。

実際、システム開発を営んでいると、今回のミッションで提供されたようなExcelに遭遇することはしばしばあります。
都道府県の列に見知らぬ県が混ざっていたり、誤字やスペースが混ざっていたりのデータはザラにあります。選択肢にない値や異体字、さらには違う文字コードのデータが混ざっていて文字化けする場合もあります。厄介なことに目には見えない改行コードが混ざっていることもあります。

普通、そうしたデータのインポートには時間をかけて対応します。入念に移行のデータを検証し、準備する時間を確保するのがセオリーです。
そうした移行に関する手続きは、昨年のkintone Advent Calendarで以下の記事としてアップしたのでご参考にしていただければ。
kintoneにシステム移したいんや

ただしこの記事に書いたような、移行の作業にじっくりと専念ができるかどうかは何ともいえません。そうはお客様が許してくれない場合があるからです。
例えばお客様先で利用を始める段になって、システムにバグが出ることもあります。それがプログラムのミスならまだいいのです。kintoneは修正が比較的容易にできるのですから。
問題はデータに不備があったり、アプリの設計と食い違っていたりした場合です。しかも、こちらの移行設計のミスならまだしも、お客様が直前で項目を修正したり、今までに発生していなかったデータがCSVに紛れ込んでいたりするからタチが悪い。
訪問したお客様先のその場で設計変更が必要になり、その場でデータを旧システムからもらい、その場でデータを加工して取り込む状況に追い込まれることだってありえます。

さすがに、お客様先で今回のミッションのように15分の制限時間を課されることはないでしょう。
ですが、技術者としては現場での応急対応が求められることは想定しておかないと。
アウェイの場での孤独な作業。お客様からの無言の期待と圧力を感じつつ、その場でExcelのデータとkintoneアプリの構成を比較して正しいデータに直す。それには臨機応変な対応が必要ですし、さまざまなエラーのパターンを同時に考えながら手を動かすことも必要です。こうした場数を経験しておくと後で技術者のキャリアの上で役に立ちます。
私も何回か、現場で加工したデータを取り込みなおしたことがあります。

こうしたやり方は従来のウォーターフォール型の開発では許されません。アジャイル開発やスクラム開発でもあまり推奨されないはずです。ですが、kintoneは症状の度合いによってこうしたLive感に満ちた開発・修正が可能です。むしろ、そこに真価を発揮します。
今回のミッションは、その経験を思い起こさせてくれました。また、出た当初のkintoneに惹かれた気持ちも思い出させてくれました。
このミッションにチャレンジすることは、kintone技術者としてのスキルを鍛えてくれるはずです。

Twitter上でもこのミッションを自社の研修に使ってみたいというつぶやきを見かけました。弊社でも同様にミッションを課してみようと思います。

司会の「けいん」さん
@soulxoxo

サポートの「よしみ」さん
@yoshiminxkay

一人目の挑戦者の「松井」さん
@kinsukicom

ガヤりの「とうげ」さん
@touge_moved

の皆様、ありがとうございました。あと、観覧者の皆様、声援ともどもありがとうございました。

時間が取れるかどうかはわかりませんが、今回のミッションの中で行った処理については、ゆくゆくは記事にしたいと思います。
なの、ケインさんがnoteでミッションに必要なアプリやExcel一式をダウンロードして使えるようにしてくださっています。

続いてのセッション『それkintoneで作って下さい!駄菓子屋さんの棚卸システムを1時間で仕上げちゃおう!
は、まさにkintoneのファストシステムの良い例です。
ファストシステム。最近ではこの言葉は使われていませんが、kintoneが出た当時はファストシステムと銘打たれていました。迅速に構築のできるシステムであることを訴えて。
今回のセッションでは、要件定義をもとに基本設計とアプリ構築を同時に行いながら、棚卸しシステムのプロトタイプを一時間で作り上げてしまいました。
このセッションは弊社のメンバーにぜひ見てもらいたいと思いました。従来のシステム開発なら、持ち帰って検討して要件定義した後に実装するため、早くても三週間はかかっていたでしょう。それが一時間でできてしまうkintoneの性能と機能をフルに活用した良い例です。

続いてのセッション『教えて!みんながkintoneから学んだこと』も良かったです。
先日のcybozu daysでは、kintone SIGNPOSTが正式にお披露目されました。現場の課題をどのようにシステム要件にし、それをシステムとして組み上げるか。その際はシステム開発に留まらず、コンセプトや社内のビジネスフローの再構築にまで話を広げる必要があります。その中では体制やコンセプトの整理も求められるでしょう。
現場の声としてあがった本セッションの内容は、kintone SIGNPOSTの生きた事例として参考になりました。

続いてのセッション『チャレンジ!きんとん関数ドリル』は、
ここ二年間でkintoneに追加された機能として特筆される関数を取り上げていました。このセッションではkintoneの関数の奥深さを味わうことができました。
私は出題された10問のうち6問しか合わず、関数についての理解の浅さを露見させてしまいました。
なんでもJavaScriptで解決してしまおうとする考えから切り替えていかなければ。
それにしても、松田さんによる関数の分析はお見事としか言いようがありません。ここまで理解してこそkintoneエバンジェリスト。私も精進しなければ。

この後もkintone SIGNPOSTの紹介や懇親会などがありました。が、実家にいた私は両親と食事に出かけたため、この後の懇親会には参加していません。さぞや盛り上がったことでしょう。

また来年も開催されると思うので、楽しみにしたいと思います。

重ねて皆様、ありがとうございました。

当日のTwitterまとめはこちらです。


kintoneが今年、拡がるために


はじめに

あけましておめでとうございます。
今年もよろしくお願いします。

弊社の年頭の抱負はこちらにアップした通りです。
その中で、kintoneを軸にするという項で、今年も弊社はkintoneに注力する旨を書きました。

そんな中、年始の2日に家族とワインを飲みながら団らんしていました。
テレビには家族が観たい「逃げるは恥だが役に立つ ガンバレ人類!新春スペシャル!! 」が映っていました。
そこに登場したテーマがコロナであり、選択式夫婦別姓であり、リモートワークであり、働き方でした。

私はドラマを観ながら、これってサイボウズさんの打ち出しとるテーマやんか、と目をみはりました。

昨年、弊社にとって顕著にkintone案件が増えました。また、旧システムからkintoneにシステムを移行したいとの案件のご依頼も増えました(ブログ)。
おそらく、その流れは今年も続いていくことでしょう。
それは、サイボウズさんの掲げる理念が世の中に広まったこととkintoneの魅力が世の中に行き渡りつつある証しだと思っています。
もともと、そうした働き方を変えたいとの機運は世に行き渡りつつありましたが、昨年のコロナはそれを促したのだと思っています。

ただ、kintoneはまだ世の中で誰もが知っている存在になっていません。
弊社のレベルでは顕著に案件が増えたとはいえ、それはもともと弊社が受けていた案件数が少なかっただけの話。
弊社の尺度ではなく、世の中全体でのkintoneのシェアを考えると、kintoneにはもっと広まる余地も拡がる伸びしろもあるはずです。
今年はその流れがより速まり、より拡がるはずです。より多様な業種や規模の企業にkintoneが採用されることでしょう。

ただ、それを口で予想するだけで済ませてはなりません。
自らが率先してその流れをより速め、広げていくことがkintoneエバンジェリストの役目であり、サイボウズ・オフィシャルパートナーとしての存在意義だと思っています。

そこで、kintoneに何が必要か。それを年頭に考えてみました。

kintoneの弱点

まず、kintoneに足りないのは、規模でしょうか。
今のところ、大規模案件や中小以上の規模の基幹システム案件に対して、kintoneを勧められる状態にはありません。
というのも、
https://jp.cybozu.help/k/ja/admin/limitation/limit.html
にも書かれているとおり、100万件以上のレコード件数に対しての品質保証が明記されていないからです。

過去データを保存する期間は、法令によると受発注や仕訳だと七年が定められているようです。
月間15000件の伝票が発生するお客様の場合、一年で180,000件。七年で1,260,000件のデータが発生します。
つまり法令上の保存レコード件数をkintoneが満たせないと見なされる可能性があります。

US版のKintoneは完全にAWSが基盤となったそうですから、オートスケールには対応しているはずです。

日本版のkintoneについても、今、サイボウズさんではNecoプロジェクトとManekiプロジェクトが進行中だそうです。


その成果を待ちたいと思います。

kintoneはもう一つ、アカウント管理回りにも改善の余地がありそうです。
例えば、大企業の複雑かつ大きな組織が一斉に組織改編を行う場合を考えてみましょう。周知のとおり、Cybozu.comのアカウント設定では組織の事前設定ができます。とはいえ、なかなか思った通りにいきません。ま、弊社はその部分の作業をお客様に委ねてしまっているのですが。
あと、ゲストスペース内アプリの権限設定の際に組織やグループが使えないのも不便だと思っています。

あと、スペースやレコード上のコメント機能も、ChatWorkやSlack並みの使いやすさをお客様から求められることがままあります。
kintoneの良さは、コミュニケーションとデータの融合にあると思うので、コミュニケーション機能のより一層の拡充は期待したいですね。

技術者としてすべきこと

さて、新年からクレクレマンのような要望を書いてしまいました。
とはいえ、昨年のkintoneに行われたバージョンアップの頻度は私たちの期待を満たしてくれています。
おそらく上に述べたようなことは私が言うまでもなく、サイボウズさんでも考えてくださっているはずです。
となると、こちらとしてはただ要望をいうだけではダメですよね。それだとクレクレマンに堕ちてしまう。
ユーザーや開発者の立場から広めるための働きかけを行わなければ。

例えば、kintoneのキャッチフレーズを考えるというのはどうでしょう。
kintoneを使えば何が良いのか。何が変わるのか。言葉を尽くしてそれを語るのはたやすいと思います。
ですが、一言でkintoneの良さを語るのは難しい。シンプルにズバリと本質をつく言葉を今年は考えたいですね。

また、ユーザーがシステムを作る手段としてkintoneの認知度は相当高まってきました。
また、年末にテレビCMが始まったことで、さらに認知度は上がっていくことでしょう。
とはいえ、技術者に対しての認知度はイマイチです。
さまざまなシステムを作る技術者の皆さんにこそ、kintoneの認知度を上げ、採用してもらわねば。

昨年、kintoneエバンジェリストとしてのインタビューでもその想いは語りました。
そこでも語った通り、わが国のシステム開発の生産性はまだまだ伸ばせる余地があると思います。統制のための統制、仕様のための仕様、ドキュメントのためのドキュメントではなく、設計から実装までの各フェーズが共通のフォーマットで流れるような仕組み。
海外のサービスの開発速度が速いのは、それができているからではないでしょうか。
わが国の場合、ミスが許されない文化性の違いもあるのでしょう。ですが、これからはバグや仕様を恐れない開発手法があってもよいと思います。
kintoneは画面や設計がプラットホームとして共通なので、共通言語で語れる部分も多く、スクラッチ開発よりもやりやすいはずです。

ただ、各アプリの連携やシステム全体の設計についてはkintoneは不得手ですよね。それを自動的に作れるようなツールが作りたいと常々考えています。各アプリを横断したER図や機能連携図を簡単に作れるようなツール。
これができれば、お客様との仕様確認も楽になるし、開発者側でもkintoneを導入する機運はさらに高まるはずです。それがわが国のシステム開発の生産性を上げられればいうことはありません。

弊社も昨年は、土壇場での仕様変更に何度も苦しみました。
ですが、その都度、kintoneの良さを生かしてすぐにリカバリできました。
今年はそのリカバリ手段をより研ぎ澄まし、要件定義に時間をかけずに、なおかつ、バグや仕様変更にもすぐに対応できるような体制を作りたいです。
それには、自社であらゆるパターンに対応できるJavaScriptやプラグインのストックをより多く作ることでしょうね。
その中で汎用的に出せそうなソースコードはブログなどで公開することで、エコシステムに貢献できればと考えています。

あと、今後は大手企業様の事例も増えるでしょう。
サブスクリプションの課金にも抵抗がないお客様には、積極的にサードパーティー製のプラグインを提案していこうと思います。
そのあたりは柔軟に取り組みたいですね。

あとは、ブログやYouTube、SNSなどの手段以外に、どうやって認知度を広めるかですよね。
kintoneにもともと興味を持ってくださっている方は、上記のようなメディアに来てくださいます。
ですが、世の中にはkintoneの存在すら知らない人がまだまだいらっしゃいます。そうした方にどうやって広めていくか。
おそらくkintoneのテレビCMはそうした意図で作成されたのだと思います。

あとは、私たちがどうテレビCMを補完するような発信ができるかですね。
おそらく私の場合は技術者向けのイベントや、SIerさんへの内部発信など、今まで取り組んできたことを深めていくのが良さそうです。
それと、弊社の場合、「自治会 IT」で検索すると一番上に登場しています(サイボウズさんの記事ですが)。

そのアドバンテージを生かし、今年は自治会やNPOにkintoneを告知するような手立てを考えていきたいと思います。
自治会やNPOといえば、比較的年配の方が活躍されています。年配の方は、ブログやYouTube、SNSに触れることも少ないように思います。そうした方へのアピールですね。
例えば市役所と組んだり、広報誌で告知したりといった手段で、実際に赴いてkintoneをアピールするのはどうか、と考えています。
おそらくそうした皆さんにkintoneを説明するには、システム用語を極限まで減らすなどの配慮が必要でしょう。

コロナで果たしてそうした機会がいただけるかどうかは不明です。が、チャレンジしてみたいと考えています。

kintoneが今年、拡がるためにはほかにも思いついた手段があれば試してみようと思います。


kintoneのPromiseを説明できるスキル


以前よりお付き合いさせていただいている株式会社アディエム様(https://adiem.jp/)より、
先日ご依頼を受けたたkintone開発案件は、何重にも入れ子になった多重Promise処理が必要でした。

弊社にてコーディングと単体テストを行い、無事納品にこぎつけられたのですが、
アディエム社の技術者様にもコードの説明を行う必要が生じました。

弊社の代表もPromiseの習得にはかなり手を焼いたのですが、そのスキルを習得できたかの判断基準は、その内容を人に説明できるかどうかです。つまり今回、うまく説明できたかどうかは、弊社代表がPromiseを理解できているかのベンチマークにもなりました。

説明を行った結果、アディエム社の技術者様にPromise処理をご理解していただけたようです。追加の処理を実装し、さらにテストまでも行えるまでになったとか。その結果を以下のようなメッセージでいただきましたのでご紹介します。

先日はコードのレクチャーをありがとうござました。
本日、検索部分のエラーハンドリングを追加し、本番環境にリリース致しました。
負荷テストとして4001件のデータを使用して、正常に更新されることも確認しました。

kintone APIのノーマル呼び出しパターン、kintone promise を使ったパターン、promiseでも thenにresolve, rejectを引き渡すパターン、thenとcatchを書くパターンと、かなりケースの整理が できました。また返値の扱いもデバックすることで理解が進みました。
まだうまく関数化して可読性の良いソースを書く自信はありませんが、長井さんソースを参考にさせて 頂きたいと思います。

以上、ご報告まで。

弊社代表は以前より、kintoneのエバンジェリストとしてサイボウズ社より任命されております。
最近はこうしたマンツーマンに近い形で、技術をお伝えする案件も増えつつあります。
その中でこうしたご評価を頂戴したことは、弊社代表にとっても自信になりました。もちろん、スキルの習得に終わりはありません。新たな技術も次々と世の中に生まれています。まだまだ切磋琢磨していかねば。精進します。

今後もアディエム社とはkintone案件のご提案からコーディング・テストまでを協業できる関係を築いていければと思います。
kintoneでのシステム開発のご相談、アディエム社、および弊社にお気軽にお寄せ下さいませ。

また、もし御社の技術者に対し、こうしたマンツーマン形式でのレクチャーをご要望の際は、
ご連絡をください! ご相談に乗らせていただきます。